Fuzzing and MS08-67

Yesterday was pretty exciting. I'd been looking forward to it for quite some time, as it was my turn to lead the penetration testing/exploit dev class at NYU Poly. My subject for the class is fuzzing, and the first part consisted of a lecture on fuzzing history and methodologies followed by demos of COMraider, AxMan, and a video of an ActiveX exploit. I think the students are going to have some fun with ActiveX this week :-) Next week we'll be going over SPIKE in-depth.

What made the day more special was that I got to lead such a class while the rest of the infosec world was busy either patching MS08-67, or reversing it. This bug, found being exploited in the wild, ended up being a pre-auth stack overflow in a Windows RPC service. Precisely the kind of low-hanging fruit that Microsoft's SDL initiative, which includes fuzzing, was designed to stomp out. In fact, in a post-mortem write up by Michael Howard (the man behind SDL), he says:

"I'll be blunt; our fuzz tests did not catch this and they should have."

Howard doesn't go into detail about why fuzzing didn't work, which leads me to hypothesize the following:

1. The vulnerable function wasn't fuzzed at all.
or
2. The vulnerable function wasn't fuzzed correctly. According to the two Stephens, passing a string like \aaa\..\..\..\f is enough to trigger the overflow in the vulnerable function (which canonicalizes paths). The overflow occurs when there are not enough directories specified in the string to match the number of ..'s.

If the fuzzing engine used to test this function was not aware of the expected format of the string, it could have just passed in large string of A's, or perhaps a long string of random characters. Since such data would not be a valid path that requires canonicalization, the overflow would not occur, and would go undetected.

The lesson here is to think carefully about fuzzing strategies. It is not unreasonable to send a large string of static or random characters while fuzzing a target of an unknown code base. However, in this case we are talking about white-box fuzzing, since MS was fuzzing their own code. The fuzzer should have been given some knowledge of the data expected by the function. It would have been trivial to create fuzz strings of mangled and malformed paths that would have triggered this bug. The problem is simply that this didn't happen (atleast, not when MS fuzzed it).

The no-exploit exploit

Dean wrote a cool post on how to drop and run .EXE's on a client just by getting them to view a web page in Internet Explorer. Yay ActiveX!

The link: http://carnal0wnage.blogspot.com/2008/08/owning-client-without-and-exploit.html

Itunes and Vague SSL Error Messages

After reading Dans' recent blogs, I started poking around and checking out how some other non-browser SSL clients handle invalid certificates.

First up, ITunes. I fired up TSeeP with a self signed certificate, and started MITMing phobos.apple.com. The result:



Hmm. Pretty vague. Error -9812.

Next, I tried my trusty revoked login.live.com cert, just to see what would happen. The revoked certificate generated:



Error -9808. Another vague one. Ok, lets Google "itunes 9808".

First hit: http://soccerislife8.blogspot.com/2008/02/itunes-error-9808.html
That page tells you to follow another link to: http://techupdate.blogvis.com/2008/02/09/itunes-error-9808/

The second link is where the "fix" for error 9808 is. From the blog post:
Also under Security make sure that the “Check for server certificate revocation (requires restart)” is unchecked. Then click ok and fire up iTunes.

One of the many comments:
I had the same problem and unchecked the “Check for server certificate revocation (requires restart)”.

It works. Thank You.

According to the comments, there are a number of folks who might come across such a vaguely worded error message, look to Google for help, and follow these instructions without a second thought that they could be degrading their own security.

In short, if you're responsible for an application that acts as an SSL client, it is not enough to just perform certificate validation. When certificates turn out to NOT be valid, you need to act appropriately, prevent the connection, and WARN the user.

A better version of the Itunes invalid cert messages:

"SECURITY WARNING: There has been a problem validating the identity of an Itunes server. If you are using a public network, please connect to the Internet over a trusted connection such as your home or office network, and try again. If problems persist, reach out to your technical support contact for your Internet connection."

Domain Validated SSL Certificates

Regarding the SSL certificate I procured from a major Certificate Authority, the following two points would have helped prevent the issuing of the certificate.

1. An automated connection outbound over SSL to login.live.com (using a secured DNS server).
If this was done, it would have been obvious that the domain already has a valid, non-expired certificate. Why would Microsoft need another one? This should have thrown a red flag.

2. Actual domain validation (DNS poisoning was not used).
WHOIS information was simply disregarded. It also appears that it was a person who messed up, not necessarily a system. Awareness training is always a good thing. The scariest part was that people I spoke to on the phone saw nothing wrong with what I was requesting.

I don't want to name the CA who messed up - that won't help anyone.

I will, however, give props to a CA who did a great job. It may have just been one guy there who saw the badness, but he promptly called me with a loud and direct WTF?!

"There is no way we can give you that certificate", he told me. Way to go Digicert!

Strydehax the Olympics!

My buddy strydehax put a couple of hours into investigating the controversy surrounding the age of Chinese gymnasts. Check it out here.

NYSEC, OWASP Chicago

I'm off to NYC for NYSEC tonight, and tomorrow I'm off to Chicago for some work and some play. I was originally going to Chicago to hang out with my buddy, but coincidentally, there is a local OWASP chapter meeting on Thursday. Even cooler is that Rohyt had been scheduled to speak there, so I also get to go show some support for Intrepidus.

In other news, I'm finally starting to get caught up with work and back in the swing of things after Vegas. I'm continuing with more SSL VPN research, as well as some generic SSL research to follow my live.login.com stunt. Unfortunately, I have more ideas than I have time to research them.

SSL VPN Slides - BlackHat 2008

Yesterday I delivered my presentation on web based SSL VPN security at BlackHat in Las Vegas. The slides can be viewed here.

Thanks to all who attended my presentation. I'll be writing a paper soon to highlight the major points, so stay tuned for that.