The attackers looked around for vulnerable ASP pages and identified a library that allows users to upload images. Attackers are known to exploit upload forms by uploading CGI scripts such as EXE, PHP or ASP files to the web server. When these files are accessed through the web server, the web server tries to interpret or execute these files as legitimate CGI or ASP. This means that code is executed on the server side and this code can be anything from a normal web application to a backdoor allowing remote access to the server. In this case, this library had taken precautions to only allow certain file types to be uploaded. The image library made sure to only allow files with certain file extensions (.gif, .jpeg etc) and possibly checked the contents of the files to make sure that it is indeed an image.

So how were the attackers able to execute remote code on the victim web server?

The attackers made use of a filename with the extension .CDX. Such files can refer to various file types, one of which is a graphics file type used by Corel Draw. Additionally, by default IIS interprets CDX files as ASP scripts. This image library allowed users to upload files with this extension and store it on the web server. However the image library could also check if the contents of the file contain an image or not. To bypass that check, the attackers included the contents of a real GIF file and embedded some VBScript code. The image library would detect the GIF file and allow the upload to take place, while the IIS server would interpret the VBScript code just similar to any other ASP script on the server. This combination keeps everyone (both IIS and the image library) happy, and therefore the attacker gets execute his or her custom VBScript code on the IIS server just as if he had uploaded an ASP file!

Once the CDX file was uploaded, the attacker then started sending it commands. In this particular case, the attacker uploaded a variation of a well known ASP backdoor that is typically used by Chinese speakers. From this point on the web pages were modified to include code that exploited a security hole in Internet Explorer. This meant that visitors who went to the infected website could end up running arbitrary code on their desktop computers. Such code usually installs backdoors and spyware on the victim machines. To keep tabs on this story and how it develops visit the Attack research blog which should be posting a juicy update soon.

How does one prevent similar attacks?

Since filtering by file extension was bypassed, it might appear that an appropriate fix would be as simple as making sure that CDX files are not successfully uploaded to the server. However this fix is not hacker proof and it alone does not provide a complete solution. Such a solution will only be sufficient until attackers find another way of bypassing this security mechanism.

To solve this issue we should be looking at the source of the problem. Allowing files in the “images” or “uploads” directory to be executed by the server is probably the main culprit. Setting the correct permissions on the web server to only read such files would be a good solution to this issue. Additionally, if anonymous uploads are not needed, then it is a good idea to avoid providing that functionality in the first place.

Note that this solution does not do much to prevent the GIFAR attacks that target the client-side rather than the server-side. But that will be for another post.

How does it work? This static html page simply contains IMG tags that link to the logout url for various websites including Facebook, Gmail, Ebay, Youtube and Yahoo. If an unwary user visit this web page then he or she will instantly get logged out of these popular websites. While this is a nuisance, it is not considered a serious security hole and knowledge of this issue is widespread throughout the security community.

In fact this sort of issue has a name - Cross Site Request Forgery or CSRF / XSRF, and can have very serious repurcussions. This security flaw relies on the fact that web browsers will happily go to any URL that is referenced by any website, even if the URL refers to a totally different website. If the URL performs an action, (eg. logs out the user or transfers some money to another bank account) AND the URL’s parameters are predictable, then that web application is typically vulnerable to a CSRF attack. Major sites such as Gmail were previously found to be vulnerable to CSRF. In the case of Gmail, attackers were able to add an email filter that forwarded the victim’s emails to their own email address.

To solve this issue, web developers usually create a secret that the attacker cannot predict and that is known between the web application and the legitimate user. Making use of POST requests is not a solution to CSRF since attackers can force web browsers to submit forms. The solution is to make use of a challenge token for each request - or at least those requests that execute a sensitive action.

As web-security consultant Joshua D.Abraham said, web developers addressed only one instance of the problem. They did not fully assess the whole application to check for similar issues!

This shows the importance of using an automated web vulnerability scanner. Web vulnerability scanners have an important role to play in the security testing of web applications. Not only do scanners make the process of testing Web Applications more efficient but they can also serve to double check the website developer’s work. Since most large websites are constantly changing, it makes sense to schedule a periodic scan to make sure that any vulnerabilities are detected before they hit customers or your website’s reputation.

By making use of an automated web vulnerability scanner such as Acunetix, a developer or security professional could have found these high profile vulnerabilities. It would possibly have prevented American Express the embarrassment of having to deal with a second security flaw after just a few days!

Read more about the reported vulnerability in this article

Note: a large number of vulnerabilities described in this post can be exploited to bypass safe_mode. It is not recommended to rely on this PHP functionality for the security of your web servers. Only use safe_mode as a supplement to PHP code that has been truly audited (with AcuSensor technology of course).

Not all vulnerabilities described are simply a safe_mode bypass. The IMAP toolkit crash is more than just a crash!

Incorrect php_value order for Apache configuration

This vulnerability affects sysadmins that rely on the safety features of safe_mode to protect their servers against users executing malicious php code on the server. This security flaw was reported by SecurityReason. In their advisory, SecurityReason show how it can be exploited by attackers who can modify the PHP configuration by editing the Apache configuration (httpd.conf) or .htaccess. In the case that error_log directive is already set to a php script, if the php script can be edited by the attacker, then the attacker can also bypass PHP’s safe_mode feature. This is a local exploit.

Fixed a crash inside gd with invalid fonts (CVE-2008-3658)

GD handles image processing in PHP. It can also be used to read font files through the imageloadfont() function. This particular function suffers from a buffer overflow which can be used to execute arbitrary code or cause a denial of service. This vulnerability would affect any PHP code that calls this function and supplies it with user defined font files (normally *.gdf files).

Fixed a possible overflow inside memnstr (CVE-2008-3659)

An attacker can execute arbitrary code if he or she can specify the delimiter in the explode() php function. Although usage of the explode() function is very common, it is not common behavior nor recommended to make use of user defined delimiters. Therefore most applications should not be vulnerable to this. However this vulnerability can be locally exploitable to bypass safe_mode restrictions.

Fixed security issues detailed in CVE-2008-2665 and CVE-2008-2666

CVE-2008-2665 detailed another vulnerability that can be used to bypass safe_mode. The vulnerability is a directory traversal issue in the PHP function posix_access() which allows one to check permissions of a file. CVE-2008-2666 describes an even more subtle bypass where chdir and ftok functions can allow access to files that should not be accessible through safe_mode if the directory starts with the string “http:”.

Crash with URI/file..php (filename contains 2 dots) (CVE-2008-3660)

If you are making use of FastCGI module then users accessing your webserver could cause a Denial of Service by simply supplying two or more dots in front of the php extension. This vulnerability could easily be triggered unintentionally so it is highly recommended to update if the web server is making us of FastCGI.

IMAP toolkit crash: rfc822.c legacy routine buffer overflow). (Fixes CVE-2008-2829)

PHP made use of old code written in 1988 which did not handle large buffers, thus leading to a classic buffer overflow. How can this be exploited? If you are making use of PHP code that reads messages from an IMAP server, then that code is exposed to a buffer overflow. By exploiting this security hole attackers can crash the HTTP server and execute arbitrary code and gain access to the server. Emails exploiting this vulnerability will typically consist of large address lists in the To or CC email header. This vulnerability is described in the PHP bug report and could easily be triggered unintentionally and intentionally if one is making use of PHP applications that use the PHP IMAP functionality such as TWIG.

When upgrading make sure that you go for version 5.2.8 (or greater) which was issued to fix a flaw that was introduced in version 5.2.7.

So what is the reason that such vulnerabilities materialize and do not get fixed? Two months ago I too reported a XSS vulnerability to a Bank’s security team. The case was very similar to the security hole in American Express’ website. The vulnerable script was a search script that echoed back the search string. After being told that they knew about the vulnerability, I asked “why not fix it?”. The reason? The Cross Site Scripting vulnerability does not affect the sensitive website (ebanking site) which is on a different server.

In the network security world, this would have been a good answer especially when the servers are segregated. However when it comes to Web Application Security, the situation is a bit different. If the secure ebanking site shares the cookie with the other websites on the same domain (eg. secure.bank.com and www.bank.com share the same cookie), then the risk is immediately understood. Cross Site Scripting on one site affects the other site. Even when that is not the case, Cross Site Scripting can cause trouble. Attackers have previously exploited XSS to launch very convincing phishing attacks on an Italian Bank or to increase their google ranking. Besides that, reputation is easily hurt if (like AmEx) your organization is trying to project the image that it takes security seriously!

A new version of the popular scripting language, PHP includes a couple of security fixes (taken from the Changelog):

• Upgraded PCRE to version 7.8 (Fixes CVE-2008-2371)
• Fixed missing initialization of BG(page_uid) and BG(page_gid)
• Fixed incorrect php_value order for Apache configuration
• Fixed a crash inside gd with invalid fonts (Fixes CVE-2008-3658).
• Fixed a possible overflow inside memnstr (Fixes CVE-2008-3659).
• Fixed security issues detailed in CVE-2008-2665 and CVE-2008-2666.
• Fixed bug #45151 (Crash with URI/file..php (filename contains 2 dots)).(Fixes CVE-2008-3660)
• Fixed bug #42862 (IMAP toolkit crash: rfc822.c legacy routine buffer overflow). (Fixes CVE-2008-2829)

Additionally, Stefan Esser described a vulnerability that was silently fixed in PHP 5.2.8.

Obviously this update not only includes security updates but also a large number (170) of bug fixes that probably makes it worth the update. Many of these non-security fixes solve stability issues and make this update worth it. However the security issues fixed in this version may in some cases force your organization to upgrade some or all of its PHP installations depending on the case. In this post I will be describing these vulnerabilities in more detail so that one can easily prioritize application of this PHP update.

Upgraded PCRE to version 7.8 which addresses CVE-2008-2371

What is CVE-2008-2371 about? The Changelog from PCRE gives the following description:

11. An option change at the start of a pattern that had top-level alternatives
    could cause overwriting and/or a crash. This command provoked a crash in
    some environments:

      printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest

    This potential security problem was recorded as CVE-2008-2371.

To exploit this vulnerability an attacker needs to be able to pass regular expressions to the pcre_* functions. The most obvious case where this is an issue is when a PHP script allows regular expressions to be defined by the user. For example, plugin for Wordpress called Search Regex might expose this vulnerability. If this particular Wordpress plugin only available to the administrator who is doing a Wordpress migration, then the vulnerability is somewhat contained. There are cases where the website administrator or webmaster is not given system access to the website. In this context, this vulnerability will indeed affect the PHP installation. Another possibility is that an attacker can target the administrator by making use of an additional vulnerability such as Cross Site Request Forgery (XSRF).

Fixed missing initialization of BG(page_uid) and BG(page_gid)

Details of this vulnerability were published by SecurityReason on Bugtraq and various security mailing lists. The advisory describes a vulnerability where the first Apache child process will incorrectly set the uid to 0 which is normally assigned to the root user on UNIX and Linux systems. The correct behavior would be to assign the uid to the correct user, typically the “www” user for Apache. By making use of this vulnerability, an attacker may be able to bypass certain security restrictions that PHP’s safe_mode is meant to apply. So who can this attacker be? It will have to be someone who can modify the php flags (modify php.ini or htaccess), which is typically someone with access to modify .htaccess or php.ini. I am waiting for feedback from the security researcher who discovered this vulnerability, so this description is subject to change.

ZipArchive::extractTo() silent fix

As described before, PHP fixed a vulnerability that was reported by Stefan Esser in the zip extraction functions. This is a traditional directory traversal vulnerability that allows attackers to dump their files anywhere that the Apache user can write to. In this case, the attacker will upload a zip file to the PHP script in question which includes compressed files with filenames such as “../../../var/www/backdoor.php”. PHP scripts that extract uploaded zip files on the fly would expose this vulnerability. Websites allowing such functionality should be immediately upgraded to the latest version of PHP which fixes this vulnerability.

That’s it for now. Part two of this post coming up soon!

A search friendly URL looks like this:

Or like this:

However, these kinds of URLs are creating a lot of problems for web vulnerability scanners and their crawlers.

Below is the crawl result of a sample application that is uses the mod_rewrite module:

As seen above, the crawler is confused when dealing with such URLs, thinking that BuyProduct and Details are directories and handling them as such.  Also, the crawler did not find any inputs for this web application therefore cannot test it properly.

In order to handle this kind of situations, in the previous versions of Acunetix WVS we implemented a solution that allows defining rewrite rules through a graphical tool where the user can manually define the rewrite rules and these rules will be parsed by the crawler and the crawler will rewrite the URLs automatically. Another option was to import the file with the rewrite rules.

However, apart from the fact that this is a manual process, the user must manually define the rewrite rules and that’s not always an easy task,  sometimes it’s very complicated or even impossible.  In companies where freelance web developers are hired, usually the administrator auditing the site is only administering the server and is not responsible for the actual content of the site or not familiar with the source code of the site.

Because the AcuSensor Technology has inside information from the scanned application, it can provide information to the crawler about the actual filenames and about input parameters.  Therefore when AcuSensor Technology is enabled on the website, the crawler can correctly parse the site structure and the file inputs and able to properly test the web application.

As seen above, the crawl results for the same site when AcuSensor Technology is enabled, the real files appear in the crawl results: buy.php and details.php.

Also, now the crawler has information about the input parameters for these files (GET param id and the list of possible values). Therefore, the scanner can properly audit the web application.

Other files have been discovered in the application directory (database_connect.php, takeover.php, …).  One of these files also has an input parameter and can be tested even if this file is not directly linked from the website.  With a typical black box scanner such files are never audited.

The AcuSensor Technology is available in Acunetix WVS version 6 and has a number of advantages that will improve the quality of the scan results.

Secure access control is crucial in web server and web application configurations since a website is always exposed and will always  be a target!

In the following article you can read more and learn (using examples) about Directory Traversal attacks, how to check for them and most important of all, how to prevent them.

http://www.acunetix.com/websitesecurity/directory-traversal.htm

These measures address security issues associated with passwords by introducing an additional secret that is not static. The problem with passwords is that they can be easily copied and abused. Additionally, it is not easy to choose a unique and hard to guess password for each service that you subscribe to.  That makes passwords one of the major security nightmares for services such as PayPal and your local bank. Two factor authentication addresses these concerns.

What two factor authentication does not target is web application security flaws. One of the questions that I have been asked when presenting my Surf Jacking research was “but doesn’t the security token prevent stealing other user’s credentials?” The answer to that is that yes it does but that does not prevent this particular attack. If your web application has a security flaw such as Cross Site Scripting then the attacker never needs to get your credentials. Such attacks usually happen after the victim has authenticated by supplying his username, password and secret key. Once clients authenticate to a web application, the web application assigns a session cookie to the web client. Many account hijacking attacks target this behavior by stealing the session cookie rather than the password or the secret 6 digit key. What this means is that at the end of the day, the overall security of a web application does not only rely on strong authentication methods, but also on the security of the web application itself.

Long story short: If you downloaded WordPress 2.1.1 within the past 3-4 days, your files may include a security exploit that was added by a cracker, and you should upgrade all of your files to 2.1.2 immediately.

Longer explanation: This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.
It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.

Basically, a cracker gained access to one of the Wordpress servers and modified two files from the Wordpress installation.  One of these files is theme.php (located in the wp-includes) directory where the cracker inserted the following pieces of the code:

Screenshot 1 – Code from wp-includes/theme.php

This modification introduced a system code execution vulnerability in the Wordpress code.
It was possible to read the contents of the /etc/passwd file using an URL like:

http://host/wordpress-2.1.1 infected/wp-includes/theme.php?iz=cat+/etc/passwd

A vulnerability like this one cannot be detected with a typical black box vulnerability scanner. The cracker introduced a new input parameter named ‘iz’ and the value of this parameter is sent through the ‘passthru’ function (the PHP passthru function will execute an external program and display raw output). This input parameter is not directly linked from anywhere; therefore a black box scanner will never know about this parameter and will not test it.

This is where the AcuSensor Technology comes into place; it builds a list with all the inputs from the application (by parsing the source code and intercepting variable access). E.g. on PHP it intercepts all the access to $_GET and $_POST arrays and build a comprehensive list with all the possible inputs. Therefore, when scanning the application with AcuSensor Technology enabled, the ‘iz’ input parameter will be discovered and tested (as shown in the Screenshot 2).

Screenshot 2 - Parameter iz found in theme.php

Even more, the AcuSensor Technology will build a list with all the files in the application directory, therefore allowing us to scan for files which are not directly linked from the website. If an attacker gains access to the website and creates a backdoor file in the application directory, this file will be found and scanned if AcuSensor Technology is enabled.

Screenshot 3 – Application Sensor Data (list of files from current directory)

Because the ‘iz’ parameter is now found, the scanner can test it and report the vulnerability, as shown in the screenshot below.

Screenshot 4 – The alert reported by Acunetix WVS v6 with AcuSensor Technology