Law.Com SSL VPN Article and Microsoft IAG Hands On Lab

Today I'm out to teach a Microsoft IAG Hands-On-Lab outside of Boston, Mass. It is a basic intro class to IAG, which is Microsoft's SSL VPN technology.

Also, last month Bryan Dykstra wrote a follow up article about my SSL VPN research on Law.com. It's a good read, and provides a nice overview of some of the threats effecting these devices.

Reversing Crypto: SonicWall SSL VPN Flaw

Haroon Meer's SSL VPN ActiveX repurposing attack is number 9 on Jeremiah Grossmans list of the top 10 web hacks of 2008 :-) Congrats to Haroon! I figured this would be a good time to document the details of the Sonicwall flaw I discovered and disclosed last year at blackhat. Some details are in the slides, but I've been meaning to put a detailed description here for some time. So here goes...

In the beginning, there was a flaw...

First, the initial flaw was VERY simple, and easy to exploit. Any web site could instantiate the ActiveX control (NELaunchCtrl), and the very first thing the control would do is send an HTTP request to the invoking server to determine if the control should upgrade itself. If the server sent back an unrecognized response, the control would download an unsigned .EXE file from the server, and execute it on the client. Very basic, and easy to exploit. To find the flaw, you simply had to intercept the ActiveX initiated HTTP requests with an SSL capable proxy, then replay and fuzz them.

This flaw was reported to SonicWALL (with recommendation of using code signing certificates to prevent malicious code execution), and they eventually released a patch for me to test. This is when it got interesting.

Then, there was a patch...

Upon initial testing of the fixed control, the very basic repurposing attack was indeed thwarted. Further interception of the traffic generated by the control showed a series of challenge/response requests between the client and the server.

Example challenge:
https://sslvpn.server.com/cgi-bin/sslvpnclient?validateserver=128248573387261264

Example response (from HTTP response body):
SERVER_CHAIN="NjQ3MjZGNkM2OTZENkY2NzZGNjQ3MjY5NjM3MjYxNzM=";

VALIDATE_DATA="NEQ2NUQ1MzcwNDNBODhDRUFBMDgwMzMxNjAzRDhGQ0U4MDczRjQxOTNGQTdDODgzRUQ5RDdBQTAzQjg3QURFQg==";

Base64 decoding of the VALIDATE_DATA yielded binary data that had to be some sort of cipher text. SERVER_CHAIN, on the other hand, would reveal a stream of hex numbers, that would eventually decode to a 16byte string such as: drolimogodricras

These 16bytes were unique for each validation request, as was the cipher text. Also interesting was the fact that the SERVER_CHAIN and VALIDATE_DATA were unique even when I replayed requests with the same value passed in validateserver.

At this point I knew I was dealing with a stream or block cipher, that SERVER_CHAIN what seemed to be an Initialization Vector, and VALIDATE_DATA held what seemed to be the cipher text. Now I just needed to find out what algorithm was being used and what the encryption key was.

No IDA Skills Required

Next, I started looking at the control itself. I knew there was a new method exposed named ValidateServer(). This method had to be called for the control to continue running, and this is also what triggered the challenge response. Before I jumped into IDA, I ran strings.exe on the binary. Below is what I saw.



In the above image is a red circle, and a red square. The red circle shows the following text: s)3!cW^L1%S&V@N~
It doesn't take much to realize that these 16bytes look an awful lot like a passphrase.

In the red box, we see some encryption related error messages that indicate the encryption method: AES128. For AES128, our 16byte string above would be an acceptable passphrase. Remember that 16byte string we assumed was an IV? Well, 16 bytes is the correct size for anAES128 IV.

Now we've identified all the key parts of the new server validation mechanism SonicWall implemented to attempt to defeat the repurposing of their ActiveX client by rogue sites.

1. The input is a unix time stamp generated by the client, and sent to the server for encrypting.
2. The server generates a pseudo-random IV and encrypts the timestamp with a symmetric encryption key that client already knows. The IV and cipher text are sent back to the client.
3. The client receives the IV and the ciphertext, and attempts to decrypt the cipher using the hardcoded, pre-shared encryption key.
4. If the decrypted plaintext matches what was originally sent by the client, validation succeeds and the control can be used (or attacked.)

The Source Code

To repeat the repurposing attack, I wrote the following C# and ran it on my rogue server. Sorry for the screenshot, but I can't find the actual source file at the moment.



At least they didn't use ECB ;-)

Conclusion

For a second time, I reported everything above to SonicWall. They patched again, and said they fixed it. However, the fix did not include the recommended mitigation of using code signing certificates to validate the .EXE that gets downloaded by the ActiveX. That said, the control still relies on some sort of obfuscated client/server validation routine. That's bad news, since it can probably be broken again by someone with enough time on their hands. But then again, I wonder if they would have gotten a code signing certificate signed with an MD5 hash ;-) Security through obscurity FT(L|W)?