A few days ago Microsoft released a Security Advisory (http://www.microsoft.com/technet/security/advisory/2416728.mspx) about a vulnerability which affects all versions of ASP.NET. This vulnerability known as Padding Oracle exploits the way an ASP.NET application handles encrypted data. ASP.NET encrypts data to prevent an application from tampering with it. Because of this vulnerability, an attacker can send data to a site and analyze the error response which provides a lot of information enabling the attacker to break the ASP.NET’s encryption in a matter of hours or minutes. An attacker then would be able to read a vulnerable application’s files and tamper with the data contained in them.

Workaround

A workaround that you can use against this vulnerability is to enable <customErrors> mode in the web.config file of your application, and explicitly configure your applications to always return the same error page – regardless of the error encountered on the server. By mapping all error pages to a single error page, you prevent a hacker from distinguishing between the different types of errors that occur on a server.

Enabling the Workaround on ASP.NET V1.0 to V3.5

If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0, or ASP.NET 3.5 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings:

<configuration>

<system.web>

<customErrors mode=”On” defaultRedirect=”~/error.html” />

</system.web>

</configuration>

3) You can then add an error.html file to your application that contains an appropriate error page of your choice (containing whatever content you like).  This file will be displayed anytime an error occurs within the web
application.

Enabling the Workaround on ASP.NET V3.5 SP1 and ASP.NET 4.0

If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings.  Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0:

<configuration>

<system.web>

<customErrors mode=”On” redirectMode=”ResponseRewrite”
defaultRedirect=”~/error.aspx” />

</system.web>

</configuration>

3) You can then add an Error.aspx to your application that contains an appropriate error page of your choice (containing whatever content you like).  This file will be displayed anytime an error occurs within the web
application.

How to Verify if the Workaround is Enabled

Once you have applied the above workaround, you can test to make sure the <customErrors> section is correctly configured by requesting a URL like this from your site: http://mysite.com/pagethatdoesnotexist.aspx

If you see the custom error page appear (because the file you requested doesn’t exist) then your configuration has been setup correctly.  If you see a standard ASP.NET error then it is likely that you missed one of the steps above.

Microsoft is currently working on a patch to fix this vulnerability. Once released, we will apply this on all of our Windows servers. This workaround will not be needed after that.

Starting today, we’re introducing a series of posts through which we intend to bring you the latest updates from our developers and tech experts. This corner will give you an insider’s view on the new features around the corner, useful tips and tricks and all the techie gossip at Indi Domains!

For the first installment of the series, we’re tackling a very common aspect of most hosting queries – Extensions that are available on Servers. As many of you may know, on IIS systems it is not always possible to figure out what libraries are supported, whereas it is much simpler on machines running Apache.
(Disclaimer: Being a Linux fanboy, this post might display a little bit of favoritism to the Linux platform)

Therefore, today we’re going to tell you a little bit about how one can check if the IonCube Loader is available on a Linux Server using PHP.

Ioncube is a handy extension when you want to protect files with PHP encoding, encryption, obfuscation and licensing capabilities. If you have a proprietary software that you distribute or you simply wish to encode your script, you should use IonCube. There are other methods to encode PHP scripts, but IonCube is by far the most secure. You can easily figure out if IonCube is running by looking at the information from PHP info. To check this you need to create a PHP file with the content as:

phpinfo();

Here, you will see a Zend Engine badge with the version for IonCube loader (the version on our servers is v3.3.7).

However, this only gives you very basic information on the IonCube version running. If you need more information on IonCube, you can use the sample PHP script attached below. Use an FTP client to upload the file “ioncube_advance_tester.php” to root directory of the website. Depending on your hosting package, it may be named “public_html” or “web”.

This script will output diagnostic results and give you information on getting server side parameters. You can use this script to check other parameters.

The file uses the ioncube_loader_version_array() function to get a list of all config parameters into an array. We then iterate through this array to echo results. It is a very simple and straightforward script. Apart from checking whether IonCube is installed, the script also checks if other server settings are correct.

We have created functions for the Introduction and More Information sections. This is only to exhibit how everyone should code using PHP 5. You can take this script and run it on any Apache server; however this script does not support IIS.

Hope this was an informative read. Let us know what you think!