Malicious Scripts found in asp.net solution explorer at Runtime - asp.net

I have found some unknown .php files in Soultion Explorer of asp.net website while running locally.
When ever i navigate between pages it dynamically created two files in the name of 1. eval code and 2. jsc3.js.php
i understood this is malicious intrusion in my system and i need to over come this.
please help me.
Thanks in advance.

The above is a Internet Explorer Add-On was downloaded and installed automatically from a malicious website.
Add-On Name - PeteBH Class (related DLL - yayWmKee.dll in c:\windows\system32)
For Complete information about this threat please refer - http://www.threatexpert.com/report.aspx?md5=da146c6c26ac0ef5d26dbe571e32008a
How to remove :
1. Disable this add-on in Internet explorer Manage -addons option.
2. Remove the registry entries specified in the bove link (carefully and on your own risk).
3. Log in as Administrator in Safe Mode and delete the yayWmKee.dll from "C:\Windows\System32".
Always be sure about the pages visited and things downloaded.
Thanks for all the replies.

Related

Troubleshoot ASP.net WebForms download file problem

In my webpage, I have a download button will write excel to response and it work previously. But I got a problem today that browser on client (tested IE and Chrome) cannot download exported excel from ASP.net webforms suddenly without changing code and software install.
When I test in Chrome, console show that Resource interpreted as Document but transferred with MIME type application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.
I used the notepad to open the downloaded excel and the content become the my web html page.
I tried to login server and use the browser in server, the file can be download normally with correct content.
I have tried to copy the web folder to another server and iis setup, it show same behavior that the downloaded excel become html content of my page on client browser but work in server browser.
May I have any idea how to troubleshoot on this case please?
Thanks
Are you facing this issue on a domain/managed network? If yes, are you the administrator of the network? If that's not the case, please give these suggestions a try:
If you’re using an antivirus or firewall software, make sure Chrome
is trusted or allowed by these programs. You can also try
temporarily disabling your antivirus or firewall to see if this
resolves the issue.
Just to make sure we eliminate malware from the
scenario, please follow the steps from this help article.
Try resetting the Chrome browser to see if that helps.
Also, creating a new user profile on your Chrome can be helpful.
If the issue persists, download and run Chrome Canary. It is the
cutting edge developer version of Chrome that can be installed
alongside Stable Chrome. It's possible the problem won't exist on a
future version.
refrence article

No Icons in Kentico Admin Page

I'm very new to Kentico and just started using Kentico 11 for my companies CMS and have run into a lot of issues...most of which I've figured out by trial and error. The issue that comes up most often for me is that each time I create a new website with the wizard in the Admin page, no icons appear in either the dashboard or the applications list or on the top menu bar. It doesn't look like anyone has had this issue before, and I'm curious about how to fix it. I'm using IE 11.
Here is a screenshot:
As you can see from the screenshot, no icons appear anywhere in the dashboard, menu, or menu options. Please help with this issue.
these icons come from the font /App_Themes/Default/Fonts/Core-icons.woff. Check if it is loaded correctly.
A couple things can cause this:
Most common, Kentico caches static objects pretty heavy, so try a simple CTRL + F5 to see if it refreshes things.
If you have not granted access to the user running the website (granted on the app pool), there could be permissions issues with IIS not being able to get to the files it needs. Typically you grant at least read and execute permissions at the /CMS level to the IIS_IUSRS user in the file system on your machine.
Least common, the files weren't added during the install. To check this, run the installer again but in a different location like your Desktop, then spot check/compare a couple directories: /cms/cmsscripts and /cms/app_themes for any differences.
Thank you for all your help. I found the answer and it was very basic and simple. For me the problem was Internet Explorer options not being enabled.
Talking with Kentico support is what tipped me off to this fix:
In IE 11, Go to Internet Options > Security Tab > Click Custom level > Scroll down until you get to Downloads > Under Font download check Enabled.
That was it. Like I said very simple, but on a development server where everything is disabled, it made a huge difference in performance of the Kentico interface.
I hope this helps someone else.

An error occurred on the server when processing the URL. Please contact the system administrator

When I tried to modify Microsoft forefront Unified access login.asp page and pages that comes with it ,
I prepared my custom files for css; inc files ; InstallAndDetect ..etc
but When i inserted those files under CustomUpdate folders i got this error :
" An error occurred on the server when processing the URL. Please contact the system administrator. "
I tried files i prepared before by putting them in the place of the default files propvided by the system.
Ofc the naming is respecting when using customupdate files!!
Do you have any idea how can I solve this issue??
I'm afraid I don't have a proper picture of what exactly might have caused the problem in your case.
But I just went through resolving the same error message on my system (2012 R2, IIS 8) (while searching for the solution I came across your post)
And it turned out that what was causing my problems was the use of classic ASP parent paths (with "../" in them)
Switching to absolute and virtual paths solved the issue for me.
See here: http://www.iis.net/learn/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/classic-asp-parent-paths-are-disabled-by-default
Thank you for your answer.
Actually there was a bug with the product itself.
It didn't recognize the path to the CustomUpdate folder for any of custom folders in InternalSite folder.
I had to ask for a hot fix from Microsoft support to be able to use customized files (CSS , asp, images ).
Once the fix was installed, everything was working fine and I was able to see the customization I have done to the login page.

Resource interpreted as Stylesheet but transferred with MIME type text/html (IIS)

I get the following warning in Chrome: "Resource interpreted as Stylesheet but transferred with MIME type text/html." This happens when running the website in the browser from IIS 8 (on Windows 8). If I run the website from Visual Studio (2010) using the File System I have no issues (meaning that the CSS has been applied to the website and the website is viewed as expected).
I've read through some posts on this issue, but have not yet been able to resolve it. If someone can give me some suggestions, that would be great.
Actually, I just found out that in my case it happened to be a rights (permissions)-issue. I had a look at the MIME-types before in IIS and they we're set accordingly, that is for CSS set to "text/css". When I added the Users-group to have permissions on the website-folder to have "Read & execute, List folder contents and Read"-permissions set to Allow, it solved the issue.
Conclusion
It may be that due to using a different root websites-folder for IIS that you're CSS "cannot be accessed" properly. Though you would think that the problem is with you're MIME type settings in IIS, it may be that the User-group (you probably need to add the IIS_IUSRS-group as well if you haven't already) wasn't added to the default root folder of where you're websites are located and thus experience this issue.
Follow these steps:
1. Open turn windows features on or off
2. Select and enable Internet Inforamtion Services
3. Select and enable World Wide Web Services
4. Select and enable Common HTTP Features
5. Enable Static Content
6. Press ok
This was a permission issue for myself. I have a problem with new projects my company shares and it allowing my app pool permissions. I have to go in and add the my-pc\Users group and tell it to trickle down the permissions, and give it full rights. Even when I thought I did this to get me access to the page, the JS / CSS files didn't have that group. After re adding it again, the CSS and JS files loaded up and this message was gone from the debugger.
In your configuration file add the css mimetype (text/css), it worked for me..
adding "AddType text/css .css" to my .htaccess in root folder worked for me.
Similar to pjdevries, in my case, this was caused by the inetpub folder being copied or recreated on another volume by the sysadmin. The solution was to grant the local users group execute, read and list permissions to the new inetpub folder

"The Resource Cannot Be Found: /Login.aspx" on new v5.20 Install

Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?

Resources