NeoInvoice is a multi-tenant open source invoicing system, that currently contains an unauthenticated blind SQL injection condition in signup_check.php. The input for the value field isn’t being properly sanitized, and is used in string concatenation to create the SQL query:
require_once("config.php");
if (isset($_GET['field']) && ($_GET['field'] == 'username' || $_GET['field'] == 'email')) {
$field = $_GET['field'];
$table = 'user';
$taken = '0';
$not_taken = '1';
} else if (isset($_GET['field']) && $_GET['field'] == 'coupon') {
$field = 'name';
$table = 'coupon';
$taken = '1';
$not_taken = '0';
} else {
die("<div class=\"error\">Invalid Field</div>");
}
if (!isset($_GET['value'])) {
die("<div class=\"error\">Invalid Value</div>");
}
$value = preg_replace("[^a-zA-Z0-9_.\-\*\/\+\, @]", "", $_GET['value']);
if ($value != $_GET['value']) {
die("<div class=\"error\">Invalid Value</div>");
}
$connect = mysql_connect(MYSQL_HOSTNAME, MYSQL_USERNAME, MYSQL_PASSWORD);
if (!$connect) {
die("<div class=\"error\">" . mysql_error() . "</div>");
}
$query = "SELECT $field FROM $table WHERE $field = '$value' LIMIT 1";
mysql_select_db(MYSQL_DATABASE, $connect);
$result = mysql_query($query, $connect);
if (mysql_num_rows($result)) {
echo $taken;
} else {
echo $not_taken;
}
Line #29 there is the key, by concatenating untrusted data into the SQL query, it has made SQL injection trivial. This vulnerability can be demonstrated with the following request:
signup_check.php?field=username&value='+OR+SLEEP(5)+OR+'
This results in the following query being executed:
SELECT username FROM user WHERE username = '' OR SLEEP(5) OR '' LIMIT 1
The author has been notified, but has yet to respond. Based on the one open ticket for the project, there’s likely other possible attack vectors.
Update: TrustedSec has a write up:
Yahoo! Voice compromised. Over 400K clear-text accounts. Analysis and story here: http://t.co/B8ko49pB – Still unconfirmed. — TrustedSec (@TrustedSec) July 12, 2012 Earlier today a group called “D33Ds Company” released a large (17MB) dump from a Yahoo server. The dump includes information from a MySQL database, and the email addresses and passwords from over 450k users. Based on some of the emails and the naming of the tables, I suspect that the data is from Associated Content – a company that Yahoo bought in 2010, and closed in 2011 – replacing it with Yahoo Voices.
Note: This was written in 2012, but not published at the time. The point is still valid, perhaps moreso than ever and deserves to be made publicly. The content has been updated as appropriate, though the core of this article remains intact from the 2012 draft. I would like to note that this doesn’t apply to every environment, there are some where developers are very knowledgeable about security, and write code with minimal issues – my current employer happens to be one of those rare & exciting places.
phpMyID is a simple solution for those that want to run their own OpenID endpoint – the problem is that its author stopped maintaining the project in 2008. Despite this, there’s still quite a few people that use it, because it’s the easiest single-user OpenID option available.
Unfortunately, the author didn’t follow best practices when building the software, and as a result multiple security flaws were introduced. In 2008, a XSS was identified and never fixed (CVE-2008-4730), in the years since then it seems the software has been below the radar.
Update: The VICIDIAL team has publicly released a new version that, according to them, has corrected the issues I’ve pointed out here. Please make sure you are using the latest version available. If you aren’t sure if your instance is safe, contact your friendly local penetration tester to verify it’s secure as you expect it to be.
Update: The SQL Injection vulnerability has been assigned CVE-2013-4467, and Command Injection assigned CVE-2013-4468.
So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack?
I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.
