Showing posts with label iis. Show all posts
Showing posts with label iis. Show all posts

Friday, November 30, 2012

ASPY.a - Malware Source Identified as Blackhat Control Panel Developer

I've spotted a trojan/shell exploit that targets ASP.NET named ASPY.a making the rounds again recently. By no means a 0-day or brand new bit of malware, ASPY.a has been around for about 2 years. It takes advantage of vulnerable ASP scripts, uploads itself to a web server and in unpatched systems that lack sensible permissions policies and the latest updates, it can grant remote attackers administrator access. Microsoft Security Essentials will catch it, however I've seen at least one version of Symantec that does not completely remove compromised files - with Symantec server-level compromise was prevented, but the website itself remained controllable.

So why am I writing a post about a 2 year old piece of malware? The story here is that the circulation appears to be driven by a developer based in Russia that sells "server control panel" (панель управления сервером, управление) software for novices tasked with IIS-based website management. The name of the company is  ISPserver, the software is named ISPmanager (I would stay far away from their website). If you are seeing html and asp/cs files with lines saying "Created by ISP manager 151515" its time to strip permissions from those files and run an antivirus.

Wednesday, October 31, 2012

FastCGI and Application Pool CPU Limiting in IIS7

Or, How To Fix the "Unable to place a FastCGI process in a JobObject" / 0x80070005 Error When Applying a CPU Limit to an IIS7 Application Pool

Here is our example - you have a website that uses several different programming languages running on an IIS7 server. Perhaps your main site is running .NET, and you are using PHP for the website's blog, or Python for a mailing script. You have installed the FastCGI module to speed things up and have it configured successfully.

Unfortunately, CPU utilization is overall fairly high for this site. You want to make sure that it doesn't get *too* high and crash the server, or overwhelm other applications and services you have running on the same server. This article assumes that you already have configured a dedicated application pool for your site, and per the best practices you are running the application pool under a unique application pool identity user, and not the Network Service. It also assumes that you only have one application pool configured for the site - handling both 


When you open task manager, quite a bit of the CPU utilization is being used by w3wp.exe processes - configuring FastCGI has the php-cgi.exe processes under control.
You decide to configure CPU limits for the application pool. This can be accomplished by opening IIS Manager, selecting Application pools from the left hand side, selecting your application pool, clicking Advanced Settings and reconfiguring the values under the CPU header. At a minimum, you will need to set Action to KillW3wp, set a limit (the values are assigned in 1/1000th of 1 percent so don't forget to carry your decimal point!) and assign a reset interval to ensure the application pool is reset and not left in an off state during the few hours a week that you as a server administrator are allowed to sleep.
Normally, this would work just fine. But with FastCGI applied to your site, PHP will become unresponsive, and provide the following error:

* Unable to place a FastCGI process in a JobObject. Try disable the Application Pool CPU Limit feature * Error Number: 5 (0x80070005). * Error Description: Access is denied. 


In a nutshell, FastCGI places php-cgi.exe processes inside of job objects. The Windows Process Activation Service does the same thing when CPU limits have been applied. Having both active means that Windows will try to put one job object inside of the other, which is verboten. 

Fortunately, there is a hotfix available (KB970208) that prevents this nesting behavior from occurring. Download it here. After downloading, restart the server and the error should be resolved. 

Another alternative is implementing Windows Server Resource Manager. Arguably WSRM is the preferred solution, however it deserves its own (forthcoming) post, as WSRM capabilities extend way beyond a FastCGI band-aid.

What about Windows Server 2003? Unfortunately, you are out of luck in that scenario in terms of an easy hotfix. For Windows Server 2003 users, it is necessary to segment FastCGI and non-CGI applications into different folders and create distinct application pools for both. Then you can manage CPU limiting features separately without issue.

RAT Bastard

Earlier this week, several servers I maintain were targeted by automated attempts to upload a remote access trojan (RAT). The RAT is a simpl...