jorkeo - hosting geek : security

PHP on IIS7 for Shared Hosting- AWESOME article!

jorkeo — Wed, 25 Jun 2008 08:17:32 GMT

check it out on IIS.NET - http://learn.iis.net/page.aspx/208/fastcgi-with-php/

here are a couple of excerpts from the article that I strongly recommend:

-----------

PHP Security Recommendations

The following recommendations describe how to tighten security of PHP in shared hosting environment. To make the recommended changes locate and open php.ini file and edit it as described below:

Disable remote URL's for file handling functions:
- Set allow_url_fopen=Off
- Set allow_url_include=Off
Disable register_globals:
- register_globals=Off
Restrict where PHP can read and write on a file system, e.g.:
- open_basedir="c:\inetpub\"
Disable safe mode:
- safe_mode=Off
- safe_mode_gid=Off
Limit script execution time:
- max_execution_time=30
- max_input_time=60
Limit memory usage and file sizes:
- memory_limit=16M
- upload_max_filesize=2M
- post_max_size=8M
- max_input_nesting_levels=64
Configure error messages and logging:
- display_errors=Off
- log_errors=On
- error_log="C:\path\of\your\choice"
Hide presence of PHP:
- expose_php=Off

-----------
and how to ensure you can configure your own PHP.INI for each site:
-----------

Specifying php.ini location

When PHP process starts it determines the location of configuration php.ini file by using various settings. The PHP documentation provides detailed description of the PHP start up process. Note that one of the places where PHP process searches for php.ini location is the PHPRC environment variable. If PHP process finds a php.ini file in the path specified in this environment variable then it will use it, otherwise it will revert to default location of php.ini. This environment variable can be used to allow hosting customers to use their own versions of php.ini files.

For example if there are two websites: website1 and website2; located at the following file paths: C:\WebSites\website1 and C:\WebSites\website2 then the php-cgi.exe process pools in <fastCgi> section of applicationHost.config can be configured as below:

This way owner of website1 can place their own version of php.ini into the C:\WebSites\website1, while the owner of website2 can use their own version of php.ini located in C:\WebSites\website2. This configuration also ensures that if there is no php.ini found in location specified by PHPRC environment variable then PHP will fall back to using the default php.ini file located in the same folder where php-cgi.exe is located.
-----------

Check it out in more detail

- jorke

Technorati Tags: PHP on Windows,PHP,IIS 7,FastCGI,IIS7

Hacked Web Applications causing storm - rattling Windows...

jorkeo — Mon, 28 Apr 2008 16:01:35 GMT

For the past few days a "Cyber attack" has been taking place and according to internetnews.com :

"number of infected IIS servers at 282,000. Less than a day later, security firm F-Secure wrote its own blog entry, putting the infestation at over 500,000"

and f-secure :

"Performing a Google search results in over 510,000 modified pages."

Without pointing out the reporting inconsistencies between servers and pages .... what is actually happening here..

First of all its not at all related to the security advisory that was released last week. Nor is it in fact related to any other security issue with IIS, ASP, ASP.NET or Windows. It's really important to understand that, its all to do with dodgy and insecure development practices.

Well very simply put its an age old SQL injection attack on a web site that modifies the return code adding a hidden link to a site that downloads malware to client viewing the web page. Nothing new technology wise here, just a new method of delivery - which really should not affect those who have kept their machines up-to-date.

In this case the attackers have chosen to target ASP/ASPX based web sites that have poorly written validation methods and deliver their code via a database content management system. The result being that pages on the site will return a hidden script tag that directs to one of the sites listed in the earlier articles - which picks on particular vulnerabilities available on the client machine, not just those related to software developed by Microsoft either.

Well that's all very nice you say - but "How do I protect myself against these kind of attacks?".

The way I see it, there are three areas of responsibility where lies the ability to protect the world against those few malicious people.

1. The Developer - FIX YOUR BROKEN CODE! Seriously - check your code for possible attack vectors and test, test test. I've seen heaps of web sites and web servers compromised due to poorly written or no validation checking. Incorrect security settings deploying to high risk environments. Don't always assume you know who is going to access your app. Don't assume that app will exist with everything local to it. Catch those errors - I could go on. There is heaps of guidance around this - here is a few to start you off:

2.The Client - Keep your machine up-to-date - as Coatsy says "go to update.microsoft.com and Download the golden padlock of goodness" from Microsoft Update.

3. The System Admin / Hoster / Guy who has to run the web server - Hey I sympathise with you most (of course I would!) You have to get a site with poorly written code up and running, and now what? you have to check the thing isn't going to compromise your server? but of course the code supplied doesn't work in your standard low security settings to you need to bend the rules to allow that code to work.. Be Strong!

But you may have been too late, and you have to clean this mess up on your server - how are you going to prevent this malicious code being delivered to and from your server, while keeping everything up and running?

Stop the attack coming in

If you are using IIS7 or URLScan on IIS6.0/5.1 you can filter the request to prevent the incoming attacks. In IIS7 This is what the configuration string looks like in your server wide applicationhost.config file (based on the info in articles):

Stop it going out

This is a little trickier, but due to the awesome modularity of IIS7 (only going to look at this) you can very easily write a module that can look in all the requests scan for the URL sequence in the response and send it to null. More information on doing this is at the IIS.NET website. Hey, if I get enough comments I'll write one and post it up here!

Done and Dusted

What we all need to remember about these kind of attacks is that vulnerability in the web sites being targeted are not limited to just a particular operating system platform. SQL Injection attacks is rampant in many platform agnostic applications and its such a simple thing to prevent.

As you have probably guessed I'm pretty passionate about this subject, and when I see such misguided reports and irrational reactions to incorrect or misunderstood information, it inspires me to ensure that the truth of the issue is available. Speaking personally; In my short time at Microsoft, I have never seen such commitment behind ensuring that the Windows Operating System is the most versatile and secure operating system on earth.

- jorke

Note: Graphics "borrowed" from Microsoft Japan Security Bulletins

Technorati Tags: SQL Injection,Security Vunerability,IIS,Windows,Microsoft

Potential Security Vulnerability for NetworkService / potential new IIS exploit

jorkeo — Fri, 18 Apr 2008 11:25:39 GMT

Important heads up with regards to a potential privilege escalation issue when running under NetworkService – which we all know is the IIS default.... But also note that it requires native code or full trust .NET.

Hosting Providers with Shared Hosting configurations should pay careful attention to this and ensure that they are running a customised version of medium trust at the very least - http://msdn2.microsoft.com/en-us/library/ms998341.aspx. Also be wary of any custom ISAPI extensions - i.e do a code review.

High level summary:

Processes running under Network Service identity can elevate to Local System on XP, Win2k3, Vista and Win2k8. Additionally, on Win2k3 any process running with an identity that has SeImpersonatePrivilege can elevate to Local System, and this privilege is required by IIS worker process identity. The Elevation of Privilege requires running native user code or full-trust managed code.

Our guidance is of course to move your app move WPI away from NetworkService to a windows account. Additionally on Win2k3, our guidance includes disabling Distributed Transaction Coordinator service (to close the hole where any identity with SeImpersonatePrivilege can elevate).

More information here: http://www.microsoft.com/technet/security/advisory/951306.mspx

Let me know if you have any further questions or require advice.

- jorke

UPDATE (6:23pm 18/4/08):

Check out Ken Schaefer's Blog for the origin of this potential issue.

Technorati Tags: Security Vunerability,NetworkService,IIS,exploit