In a previous post I covered how to export a private key to decrypt SSL traffic in Wireshark. This is dandy, as long as you have access to the private key.
What do you do if you don't have access to the private key??? Perhaps you are using a windows box and the certificate policy is set to not allow the export of the private key. Yes, a super ninja can take it, if they know enough about the file locations and DPAPI, but it's hard. Maybe I'll cover that soon. What if you are the client and the server is some commercial service? You'll never get that key.
If you are on a windows host, you are in luck! Enter my new best friend, STrace, from Microsoft. STrace uses MS Research's amazing tool, detours. I'll avoid a huge digression and just say that detours is crazy awesome. It intercepts win32 functions in memory and allows the code to be altered on the fly. That's right "re-writing the in-memory code for target functions". Yikes!
STrace was written for something other than our purposes. It's meant to be used in conjunction with HTTPREPLAY. This allows of debugging a web browser session over and over, without the server. Booooorrrriiinnnggg. Actually it's very cool, but not for us.
One of the things that STrace does for us, to support its original goes, is to inject itself into processes that are using SSL. You simply find the PID of the process and inject the DLL and you get your data out, unencrypted. The data is in a format designed for HTTPREPLAY, which is only a bit of a pain.
Going for the Gold!
If you've ever dealt with LDAPS failures in AD, you know how tricky they can be. You can only watch the SSL negotiation, then you lose out. If the issue involves a lying crappy vendor of a developer who just read about LDAP when the project started, you always want to look at the data they are sending. LDAP on the wire never lies! Too bad that by default, the Domain Controller Certificate Template is set to not allow export of your private key. If you're like me, you may have the party turn off SSL and suddenly it all works. Hmmmm... We must see what is really being sent!
First off, the strace readme.txt is full of awesome and it's short. It's worth a once over.
The first step in the process is to figure out which process is our LDAP SSL server. We know that SSL for LDAP is on port 636, so we run netstat -b -n -a to get the list of ports and their process names and the PID
That gets us this:
TCP 0.0.0.0:636 0.0.0.0:0 LISTENING 428
[lsass.exe]
Now we know that LSASS is the process and the PID is 428. LSASS!! Oh no, that is super protected certainly we can't touch it. This may be the Holy Grail.
If you follow the readme file, your first attempt will fail. Luckily the error is mentioned right in the file.
Note that you may get some permission issue if you want to "inject" the STRACE DLL in "protected" processes (Injib may fail with error 5 (ACCESS_DENIED) on OpenProcess()). One way to workaround this problem is to run INJLIB from a CMD running under the system account.
That sound great, but how?
We will use some pstools to get the rest of what we need. If you don't know pstools and the Sysinternals Suite, you may not actually be a windows admin.
psexec -s will let us run a process as system!
let's try
psexec -s "C:\Program Files\STRACE\INJDLL.EXE" /p:428 /d:"C:\Program Files\STRACE\STRACE.DLL"
Now, if you run something like Sysinternals Process Explorer and do a find for "strace" you will see it is now attached to LSASS. No errors, no LSASS detects evil, shutting down...
At this point, you should see a strace log file on your desktop, but you don't. Sysinternals Filemon will show us why. The default location is the desktop, but where is system's desktop, it's not under documents and settings. Filemon finds it here.
C:\WINDOWS\system32\config\systemprofile\Desktop\STRACE_LSASS_PID_428_24062009_223405.LOG
3:35:26 PM lsass.exe:400 WRITE C:\WINDOWS\system32\config\systemprofile\Desktop\STRACE_LSASS_PID_428_24062009_223405.LOG SUCCESS Offset: 9630 Length: 26
Now, we can use some LDAP Tools to connect to the server over SSL and watch what happens.
When I bind to the DC, I get a whole lot, but I'll pull out the good stuff:
06/25/2009 23:55:41:078 - SecBuffer #1 BufferType:0x00000000 cbBuffer:47906816
06/25/2009 23:55:41:078 - SecBuffer #2 BufferType:0x00000000 cbBuffer:54197772
06/25/2009 23:55:41:078 - SecBuffer #3 BufferType:0x00000000 cbBuffer:-1
06/25/2009 23:55:41:078 - SecBuffer #0 BufferType:0x00000007 cbBuffer:5
06/25/2009 23:55:41:078 - SecBuffer #1 BufferType:0x00000001 cbBuffer:45
06/25/2009 23:55:41:078 - SECBUFFER_DATA - 45 byte(s) / DecryptMessage - OUTPUT
=====================================================
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 0123456789abcdef
0000: 30 2b 02 01 01 60 26 02 01 03 04 17 61 64 6d 69 0+...`&.....admi
0010: 6e 69 73 74 72 61 74 6f 72 40 62 6c 69 6d 2e 62 nistrator@blim.b
0020: 6c 61 6d 80 08 70 61 73 73 77 6f 72 64 lam..password
=====================================================
06/25/2009 23:55:41:078 - SecBuffer #2 BufferType:0x00000006 cbBuffer:16
06/25/2009 23:55:41:078 - SecBuffer #3 BufferType:0x00000000 cbBuffer:-1
06/25/2009 23:55:41:093 - SecBuffer #0 BufferType:0x00000002 cbBuffer:5
06/25/2009 23:55:41:093 - SecBuffer #1 BufferType:0x00000001 cbBuffer:22
06/25/2009 23:55:41:093 - SECBUFFER_DATA - 22 byte(s) / EncryptMessage - INPUT
=====================================================
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 0123456789abcdef
0000: 30 84 00 00 00 10 02 01 01 61 84 00 00 00 07 0a 0........a......
0010: 01 00 04 00 04 00 ......
=====================================================
We see here that it gets some buffers and decrypted messages. I see my username and password and then some sort of response.
To verify our suspicions, we make the same conneciton, this time without SSL and capture it via wireshark.
If we look for the same data, we get these two frames:
0000 00 0c 29 bb 00 2e 00 1a 4b 79 8d 34 08 00 45 00 ..).....Ky.4..E.
0010 00 55 c1 14 40 00 80 06 5c 60 0a 01 64 97 0a 01 .U..@...\`..d...
0020 64 95 0a 87 01 85 b6 56 6c 8e 73 0a 76 db 50 18 d......Vl.s.v.P.
0030 fc 00 d0 48 00 00 30 2b 02 01 01 60 26 02 01 03 ...H..0+...`&...
0040 04 17 61 64 6d 69 6e 69 73 74 72 61 74 6f 72 40 ..administrator@
0050 62 6c 69 6d 2e 62 6c 61 6d 80 08 70 61 73 73 77 blim.blam..passw
0060 6f 72 64 ord
0000 00 1a 4b 79 8d 34 00 0c 29 bb 00 2e 08 00 45 00 ..Ky.4..).....E.
0010 00 3e 26 b4 40 00 80 06 f6 d7 0a 01 64 95 0a 01 .>&.@.......d...
0020 64 97 01 85 0a 87 73 0a 76 db b6 56 6c bb 50 18 d.....s.v..Vl.P.
0030 fa c3 f6 bf 00 00 30 84 00 00 00 10 02 01 01 61 ......0........a
0040 84 00 00 00 07 0a 01 00 04 00 04 00 ............
If you notice, we have a byte for byte match for the bottom part of the packet. If you break out your TCPIP Illustraed, you will find that the top of each frame is the Ethernet, IP and TCP header data, we are getting just the LDAP protocol payload!
If we look closer, we see that all our LDAP traffic is there. The downside being, that we don't get information on the host sending the data and we don't have libcap format, so tools like wireshark can't dissect the protocols for us in a nice way. If you understand libcap, it looks trivial to create fake Ethernet, IP and TCP data and drop in the payload to make a libcap file, or use existing parsers to dissect the messages. Its beyond me though.
The last down side is that I can't find out how to un-inject the strace dll. So far, only rebooting has fixed this.
And that is that... If you can detour the SSL from LSASS, you can do it anywhere!
And that is that... If you can detour the SSL from LSASS, you can do it anywhere!