Classic bug: phpBB 2.0.12 authentication bypass

December is always a very busy month at work, so it has been a while since my last post. Here's another classic bug: the phpBB 2.0.12 authentication bypass. I am not sure who discovered this bug, but the first references to it seem to be from February 2005.

As the title says, this is an authentication bypass bug, which means an attacker can access any account on a vulnerable phpBB version without knowing the password. This is not your typical web application bug though, it has to do with serialization and you could patch it by adding only one byte to the vulnerable code.

So how does it work? A phpBB forum has a ‘remember me’ function, which basically gives you a cookie which automatically logs you in. The cookie looks something like this:

a:2:{s:11:"autologinid";s:32:"96948aad3fcae80c08a35c9b5958cd89";s:6:"userid";s:4:"3207";}

This format is created by the PHP serialize function. Basically, it is a technique to store a complex structure into a string. If we unserialize the above example, we get this (print_r output):

Array
(
[autologinid] => 96948aad3fcae80c08a35c9b5958cd89
[userid] => 3207
)

So our cookie is used to store an array containing two strings: our userid and something called an ‘autologinid’. As it turns out, the autologinid is just an MD5 hash of the phpBB password. Not such a good idea, as this makes phpBB vulnerable to passing-the-hash attacks. phpBB 3 doesn’t use this type of cookie anymore though.

The bug is in this part of the phpBB source code (simplified):

$sessiondata = unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename]));
if( $sessiondata['autologinid'] == $userdata['user_password'] ){
// autologinid matches password
$login = 1;
}

Doesn’t look that bad does it? After unserializing the data, It simply compared the autologinid in our session with the MD5 of the user’s password. They use the == operator to compare two strings, nothing wrong with that. But what if one of the operands in the comparison is not a string? Take for example the following PHP code:

if(true == ‘96948aad3fcae80c08a35c9b5958cd89’){
echo ‘true!’;
}

You may not expect it, but this piece of code outputs ‘true!’. PHP simply converts the string to a boolean and unless the string is empty or ‘0’ PHP will convert it to ‘true’. So what does this have to do with our vulnerability? Let’s take another look at a part of our serialized cookie:

s:32:"96948aad3fcae80c08a35c9b5958cd89"

Our MD5 hash is prefixed with s:32:, which means this variable is a string with a length of 32. So instead of just specifying the string itself, we also specify its type! The trick is to simply change this part of our cookie to:

b:1

Which makes our cookie:

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:4:"3207";

For the unserialize function, this simply means: the value of autologinid is a boolean with the value ‘true’. The next step is to change our cookie on the forum to this one. The forum will compare the password hash of the user with userid 3207 to ‘true’, tricking phpBB into thinking we have the actual password hash! A logical next step would be to change the userid to '1', which is the userid of the forum administrator user, giving us full control over the forum.

The patch for this vulnerability whas a simple one. The phpBB team simply changed the line:
if( $sessiondata['autologinid'] == $userdata['user_password'] ){
to
if( $sessiondata['autologinid'] === $userdata['user_password'] ){

In other words, they switched from the == to the === operator. The PHP manual has the following description for the === operator: “TRUE if $a is equal to $b, and they are of the same type.”. The fix was this simple, by changing the operator, the two compared types have to be equal, so an attacker can no longer supply a boolean instead of a string and bypass authentication.

The moral of this story? Every piece of input is important, don’t allow users to supply serialized data, unless absolutely necessary!

Classic bug: Modem AT command injection

This is the first article in a new series: classic bugs. These are bugs that may not always be recent, but surely are interesting, or just still relevant. I think this first bug is both.

I am talking about a bug which could be read about on the Bugtraq mailing list in 1998. The poster, Max Schau started his e-mail with ‘this is an old exploit’, even then. With this bug, you can tell modems (the old analog 56k kind) to hang up. The problem is that with a modem, the data and the modem commands all go through the same communications channel. Sometimes, modems have hard time distinguishing between the two. So, if you can trick someone into sending a modem command, you can influence their modem.

The classic example is the hang up command (ATH0). If I can trick someone into sending that string (preceded by three plus signs) through their modem, a vulnerable modem will hang up. This is easier than it may sound, many systems respond to ICMP echo (ping) packets, and reply to the packet with the same data. So all I have to do is send a modem user an ICMP echo packet containing an AT command and it will reply to the packet, sending the command through the modem.

This denial of service used to be very popular and the beautiful thing is: it still works! At Fox-IT we still have an analog line we use for war dialing. Today, I hooked up a modem and dialed into one of the free dialup ISPs. Using a simple ping command from the original advisory, I was able trick the modem into hanging up! A couple of sources report some modems will hang up when merely visiting a site with an AT command in it, I was not able to reproduce that behavior with my modem.

I spend about half an hour trying to inject other commands (for example to trick the modem into dialing a given number), but was unsuccessful. With other modems this might work better. In the original advisory, someone mentions it may be possible to get modems to dial 911, which would be a big deal. In today’s world, criminals would most likely use it to get modems to dial their premium-rate telephone numbers.

Fortunately, not all analog modems are vulnerable to this attack. Some modems require a pause before sending commands, which makes this attack impossible (or at least very hard). A way of ‘patching’ your modem is in the original advisory, this involves changing the default escape character (+) in your modem using an ATS2 command. It seems the escape character can only be a single byte, so it would be easy to brute force if you know someone has changed it.

Something strange is going on at wpad.be

After writing my last WPAD post, I decided to check if any WPAD TLDs are serving malicious wpad.dat files. So, I took a TLD list I found on the MozillaWiki and tried to retrieve wpad.dat on all of the wpad.tld domains, using cURL with a spoofed user-agent.

I was able to connect to 50 of the nearly 700 TLDs and 24 of them are serving a wpad.dat file. Of those, five seem to be non-malicious (at least, for now): they are either serving a legitimate wpad.dat file or are telling clients not to use a proxy.

The remaining 19 however, all contain the same wpad.dat file (at the same IP address). Among these are some serious domains, such as wpad.at, wpad.be, wpad.in and wpad.es. The wpad.dat tries to match the URL against these shell expressions and tells the browser to use a proxy only if the URL matches:

http://*ad*nd*c*m*sh*ds*js
http*//*s*s*mp*tn*s*p*

Clearly, these people are trying to obfuscate the URLs they are proxying. I had some trouble figuring out what the targets are, but a couple of my colleagues at Fox-IT were able to find a match: http://pagead2.googlesyndication.com/pagead/show_ads.js. Looks like they are intercepting requests for Google ads. At the moment, the proxy seems to return an empty .js file for this request.

According to the HTTP headers, the wpad.dat file has been there since 13 October 2008. It does contain the text ‘testin testin’ so perhaps they are just preparing for something.

Hacking random clients using WPAD

About two weeks ago, I registered the wpad.nu and wpad.fm domains. WPAD stands for Web Proxy Autodiscovery Protocol and is used by browsers to automatically find the correct proxy server for a URL. The protocol is quite simple: basically if your hostname is host-27.us.company.local, the browser will try to download a wpad.dat configuration file from wpad.us.company.local and if that doesn’t exist wpad.company.local and in some cases finally wpad.local. This doesn’t sound too bad, unless your hostname is wpad.us.company.com (notice the .com tld instead of .local). In this case your browser may be trying to download a proxy configuration file from wpad.com, which could be owned by anyone!

Fortunately wpad.com, wpad.net and wpad.org are owned by Duane Wessels, one of the good guys. He provides some statistics on his site, which show his domain serves about 25 404’s each second (he returns a 404 for the wpad.dat configuration file)!

I registered wpad.nu and wpad.fm thinking I would get a couple of requests every day, however in the last two weeks, nearly 600 unique IP addresses have been asking for the wpad.dat file! About 2/3 seem to access the file through wpad.fm, the rest through wpad.nu. The .nu TLD belongs to some small island in the South Pacific Ocean, but is quite popular as ‘nu’ is the word for 'now' in several languages, including Dutch.

As I am one of the good guys as well, I also do not serve a wpad.dat file. If I did, I could tell the victims browsers to use my server as a proxy, which would allow me to eavesdrop on or modify their web traffic (replacing all downloaded .exe files would be an easy attack). Also, as Chris Paget points out, Internet Explorer will happily NTLM authenticate against any proxy, so stealing domain credentials is also a possibility (which then could potentially be abused for VPN or Outlook Web Access).

Finally blogging

Welcome to my shiny new blog! This is just a place for me to put up my ideas and the results of small experiments. I work for an IT security company in The Netherlands as a technical auditor/penetration tester, so I will keep things mostly technical and security related.