Schmoilitos Way

...

2011-06-16T09:43:00.000-07:00

null byte injection

2009-10-16T12:13:00.001-07:00

In this 2008 blog post, Portswigger says that null byte attacks against web applications are nothing new. It's almost 2010, and they're still nothin' new, but they sure can be fun!

During a recent web app assessment, I found one very similar to the example in Portswigger's post. I tampered with it a few times, but wasn't really sure if it was an exploitable condition or not.

I saw some requests containing a file name, similar to:
/servlet?file=image_N.jpg

I began trying some basic attacks, like:
/servlet?file=../../../../etc/passwd

These attacks always resulted in the application cleanly handling the exception, and giving me a friendly error message in a HTTP 200 response. Not quite ready to give up, I decided to try the following:

/servlet?file=../image_N.jpg

This also generated an error, but this time it was a 500 Internal Server Error from the application container. This meant that the validation routine was not necessarily aware of my ../'s, but was probably concerned with the format of the file name. To be sure, I tried the following:

/servlet?file=image_N.foo /servlet?file=../image_N.foo

Both of the above requests generated the clean error message. Only when the string ended with _N.jpg, did I get a 500 error, which told me that the logic was:

1. Validate the file name extension is .JPG.
2. Validate that the file name is of the format image_N, where N is a random integer.
2. Try to read the JPEG from the file system.

This is great if you want to read JPEGs, but I had my heart set on arbitrary file access. So how do we by-pass the _N.JPG filter? I pressed the staples easy button on my desk and it injected a null byte like:

/servlet?file=../../../../etc/passwd%OOimage_N.jpg

After a number of attempts to determine the directory depth of the file system, I was happy to see the contents of the passwd file in my browser.

Then things got interesting . . .

This application had been pen-tested before. It had also been scanned using a popular commercial static analysis tool, and had gotten a clean bill of health. So, let's just say that management was a little, um, curious about why this bug was still alive and well. And by curious, I actually mean furious.

So what went wrong? After the first pen-test, the blatant directory traversal bug was "fixed" with a new validation routine that scrutinized the end of the file name. This new routine was declared a validation routine in the static analysis tool, and any subsequent data flows that passed through it were considered safe. Game over. Hooray for tools!

Lessons Learned

Behind every tool is the person who wrote it, and the person operating it. These people are just as likely to make mistakes as the developer who wrote the target application. Once again, we're reminded that there is no silver security bullet. Tools help, but it comes down to proper education, process, and people to actually find and fix bugs.

Mainlining new lines: feel the burn

2009-10-15T12:45:00.000-07:00

Since the blog has been pretty stale for the last couple of months, I've decided to try and spice things up with a couple of war stories from recent web app pen tests. No XSS bugs here. I'm talking about complete, CPU melting, rack busting pwnage and destruction, shock and awe, all delivered over HTTP. OK, maybe I'm being a little dramatic, but at least they won't be XSS bugs. Besides, if you own the box, who needs XSS?

Command Execution in Ruby on Rails app

This RoR application was accepting a user supplied URL which got passed to an external application via IO.popen(). If I could inject a back-tick or escape from the quoted string being passed to popen(), I could execute arbitrary commands. My problem was that these basic injection attacks were failing because the devs did a decent job of validating input. Part of the validation approach relied on passing the user supplied data to Ruby's URI.parse() function. The parse() function would raise an exception any time I injected a "malicious" character, and the script would stop executing before calling popen().

I knew I had to find some sort of filter bypass bug in URI.parse() if I wanted any pwnage, so I fired up irb and after a few manual fuzzing attempts I had it:

nullbyte:~ mikezusman$ ruby -v
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-darwin9.8.0]
nullbyte:~ mikezusman$ irb
>> require 'uri'
=> true
>> require 'cgi'
=> true
>> u1 = "http://www.google.com"
=> "http://www.google.com"
>> u2 = "http://www.google.com`ls`"
=> "http://www.google.com`ls`"
>> u3 = "http://www.google.com%0A`ls%0A`"
=> "http://www.google.com%0A`ls%0A`"
>> URI.parse(u1)
=> #
>> URI.parse(u2)
URI::InvalidURIError: bad URI(is not URI?): http://www.google.com`ls`
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/uri/common.rb:436:in `split'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/uri/common.rb:485:in `parse'
from (irb):7
from :0
>> URI.parse(u3)
URI::InvalidURIError: bad URI(is not URI?): http://www.google.com%0A`ls%0A`
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/uri/common.rb:436:in `split'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/uri/common.rb:485:in `parse'
from (irb):8
from :0
>> URI.parse(CGI::unescape(u3))
=> #
>> x = URI.parse(CGI::unescape(u3))
=> #

Injecting a URL encoded version (%0A) of a new line (\n) would get my URL encoded back-tick (%60) through the URI.parse() function unscathed. After the successful call to parse(), the data was passed to popen() and my commands would be executed. My attack looked like: http://victim.com/controller?param=http://www.google.com%0A%60ls%0A%60

Lessons Learned

Relying on the result of a call to a third party routine doesn't necessarily equate to "input validation." However, used differently, URI.parse() could have very easily helped to prevent this bug. URI.parse() returns a new object whose members could be used to construct a safe string to be passed to popen(). This would work because everything after the %0A gets dropped:

>> d = "http://www.google.com/%0A%60ls%0A%60"
=> "http://www.google.com/%0A%60ls%0A%60"
>> r = URI.parse(CGI::unescape(d))
=> #
>> r.path
=> "/"
>> new_arg = "#{r.scheme}://#{r.host}#{r.path}"
=> "http://www.google.com/"

If you relied on the above as "input validation", you just would have gotten lucky that the function chopped off everything after the new line. Some times luck is enough. But when dealing with user data being passed to a system command, a little extra scrutiny can go a long way towards protecting your application. URI.parse() makes it easier for us to enforce additional validation checks by letting us look at each piece of the URI (protocol/scheme, host, path).

When fetching user supplied URI's, this sort of fine grained input validation is something we should be doing anyway. For example, simply parsing the URI would not block an attack against the local host, since http://127.0.0.1/ is valid. We might also want to make sure that the protocol is http|https (not ftp, for example) and that our application isn't being used to scan the network on the inside of the firewall (by blacklisting internal IPs and host names).

Moral of the Story

Just like many other bugs, this one could have been prevented with better input validation. Even if you think you're doing a good job validating your input, remember that not all input validation routines are created equal. Stay tuned for my next post, where we'll explore the short comings of relying on static analysis tools to catch similar bugs.

Update 10/22/2009
@emerose filed this bug report.

BlackHat 2009 and Defcon 17: EV SSL MITM Demo

2009-08-04T10:52:00.001-07:00

For the second year in a row I had BlackHat live demo issues. Shame on me.

Fortunately, the demo worked at Defcon. Had it not worked, however, I was prepared with a video thanks to Camtasia.

You can view the video here.

The demonstration shows a MITM using a regular SSL certificate (Domain Validated) to intercept data sent to a site protected with an Extended Validation (EV) SSL certificate. Since the browser treats the high-assurance EV certificate the same as a low-assurance DV certificate, the user is never warned about any connection downgrade. All they might notice is the "flicker" of the green EV badge.

Insecure Cookies and You: Perfect Together

2009-06-16T20:02:00.000-07:00

Who uses the secure cookie flag? Web developers who don't want their user's cookies being leaked out over non-SSL protected sockets. These developers realize that protecting user credentials on the wire is only half the battle. If an attacker can sniff a user's cookie off the wire when it's sent in plain text, who cares if the credentials are protected? The attacker still gets access to the application.

Who doesn't use the secure flag? Yahoo! Mail. Microsoft Live Mail. GMail and Google apps. All of these sites, and many others, protect the transmission of credentials using HTTPS. Unfortunately, immediately after you authenticate to one of these sites and get a valid session cookie, the browser is redirected to a plain text HTTP interface of the site. Google at least gives users the option of protecting their entire session with SSL. Others do not. If these companies start setting the secure flag on their cookies, their sites will break.

The "Secure" cookie flag is just a patch for a poorly implemented browser Same Origin Policy. Essentially, it allows a web application to opt-in to a strict interpretation of SOP on the client side that will prevent cookies from being leaked over insecure protocols. Why do we have to do extra work to be secure?

I propose a new cookie flag, called the "insecure" flag. Use of the insecure flag would allow web sites that don't care about protecting session cookies to opt-out of a strict interpretation of SOP, thus exposing their session cookies to the world and allowing their applications to work. If you want to protect your users' credentials over HTTPS, but then expose their sessions over HTTP, this will be the flag for you!

Imagine that. Secure by default. No extra work to do things right. What a concept!

Ah, wishful thinking :-)

NYS CSCIC Conference

2009-06-03T16:23:00.000-07:00

Last week I presented at the NYS cyber security conference in Albany. My talk was about attacks that leverage publicly available information, such as data indexed in search engines and/or stored in social networks. I also showed how this data can be used in highly targeted spear phishing attacks. My spear phishing demo used my netextender ssl vpn exploit, since it is usually trivial to find a companies SSL VPN gateway. Once you find the ssl vpn gateway, some passive recon of the system can reveal a tremendous attack surface on the victim (client) machine.

At the end, I touched on some problems with commercial PKI, but I didn't really get into it. I'm saving that for some up coming blog posts. I got some great feedback at the end, and also met a bunch of cool folks. Thanks for listening. Slides are available here.

I couldn't stick around for both days of talks, but I managed to see the two key notes on day one. The second one was by Phil Reitinger, Deputy Under Secretary, National Protection and Programs Directorate (NPPD) U.S. Department of Homeland Security.

/me lets his fingers recover from typing that title

During his talk, Mr. Reitinger offered up five priorities for the US as we move forward with our new cyber security initiatives. I'm paraphrasing here, and I didn't take great notes. That's because I'm just some dude with a blog, and not a journalist.

1. We need to build our capacity. DHS needs people. We also need to work with academia to build programs that churn out people with the right skills and knowledge.

2. Establish relationships between public and private sector. Mr. Reitinger joked about the infinite loop of meetings where public & private sector folks agree that they are both willing to share data - starting at the next meeting.

3. Develop (and follow) a standard incident response & recovery plan.

4. Streamline Identity Management. In addition to managing user identities, he also mentioned something to the effect of "being able to better identify who we're connecting to." Maybe this means we'll eventually get something better than SSL site validation.

5. Metrics. Specifically, he mentioned software quality metrics. One thing that keeps popping into my head is the fact that the airforce got a locked-down version of XP. How did the air force quantify the improved security? And when will everyone else benefit?

Subprime PKI and SSL Rebinding

2009-03-24T09:31:00.000-07:00

I'm on my way out of Vancouver today after an awesome time at CanSec West 2009. Met alot of awesome people, and learned some cool new tech.

The talk Alex and I gave, "Subprime PKI: EV SSL certs and MD5 Collisions", was also well received. We'll be releasing our paper and source code soon, but until then, here is a screen shot of a MITM attack against an EV SSL protected web site from our live demo (note the presence of the "green glow" in the browser).

Thanks to Garett Gee for the photo. You can check out the rest of his photos here.

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

2009-02-26T06:31:00.000-08:00

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

2009-02-23T11:32:00.001-08:00

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)?

Top Web Hacking Techniques of 2008

2009-01-26T19:53:00.000-08:00

Jeremiah has put out a request for the top web hacking techniques of 2008. This post serves to summarize my suggestion, which is ActiveX Repurposing attacks. These are attacks where malicious web sites abuse the functionality of ActiveX objects already installed on Windows machines, in order to download and execute code (among other things). No debugger necessary :-)

References:

1. An ActiveX Dropper described by Dean: Owning the Client without an Exploit

2. Sensepost Juniper SSL VPN ActiveX repurposing by Haroon: ActiveX Repurposing.. (aka: Other bugs your static analyzer will never find..) (aka 0day^H^H 485day bug!)

3. SonicWALL SSL VPN ActiveX repurposing by yours truly: Network World article
and SonicWALL announcement.

4. Hmm, I thought this was more recent, but it was actually from 2005 (read down in the wiki): Sony DRM Root Kit Scandal

How do you trust?

2009-01-15T08:18:00.000-08:00

SSL PKI is designed to do two things: encrypt data on the wire, and allow web site validation through the use of trusted third party signatures. The former works pretty well, the Debian weak key debacle aside. Unfortunately, the latter seems about as robust and secure as Windows 98. Case in point, https://discovercard.com. As my colleague Mike Walker points out, DiscoverCard.com forces users to enter credentials on a page served over an insecure HTTP connection. In doing so, Discover leaves users with no real way to tell who they are giving their credentials to. This is a perfect example of an implementation specific design flaw that fails open and renders SSL site validation useless.

Unfortunately, Discover Card isn't the only organization breaking PKI. The pillars of Internet security, our trusted third party Certificate Authorities, have been having a rough time recently. A number of implementation specific flaws at multiple CAs have allowed outsiders to abuse their systems and obtain certificates for which they are not authorized to hold. Sure, these implementation specific flaws can be fixed, but the lasting damage to the trust we have in PKI can't be undone. Further, the way PKI has been handling these situations seems to further undermine whatever trust remains.

Last summer when I disclosed the details of how I got the live.com certificate to Microsoft, I told them I wasn't going to do anything bad with it, they said thanks, we shook hands, and that was pretty much the end of it. A few weeks ago, when Sotirov and crew disclosed that they derived their very own key capable of signing certificates that would be trusted by all web browsers, the researchers told Microsoft, Mozilla, etc, that they wouldn't do anything bad with it. These companies again said thanks, hands were shook, and that was pretty much the end of that.

We rely on WebTrust audits and other mechanisms to ensure that our commercial Certificate Authorities do their job well, and so we can be sure we're sending our data to the web sites we trust. Unfortunately, when the audits are useless and the Certificate Authorities screw up like they did in the above two scenarios, companies like Microsoft and Mozilla are forced to make a tough call:

Do they
a) Revoke the root CA for which a duplicate signing key was derived by unknown individuals, thus breaking the Internet for many businesses and individual users
or
b) Do nothing and trust that these guys really only have an expired certificate, and didn't generate one valid for the next couple of years since they so very easily could have.

In the end, the trust that backs PKI is replaced with the trust of a few select individuals at the organizations who manage our root certificate programs (a.k.a the browser vendors). The millions of dollars spent on web trust audits are meaningless. The CAs could have just paid all of their money earmarked for audits to Sotirov and Appelbaum in exchange for their silence, and PKI would lived to fall another day.

Burn your SSL Certificates?

PKI, while good on paper, is hard to implement securely. It has taken almost two decades for us to have web browsers that actually support the one method that PKI has to protect itself from rogue certificates: Certificate Revocation Lists. And it doesn't really matter, since not everyone is using IE7 or Firefox 3 yet. CRLs, which are essentially blacklists, are completely ineffective when you don't even know what rogue certificates are actually in existence.

I don't think trusted third parties are enough. We need technology that puts the ability to make trust decisions back in the hands of end users, rather than trying to make these decisions for them.

So what can we do differently? I'm of the mindset that client side certificate / public key caching, like that of SSH, can drastically improve our ability to make trust decisions when communicating on the Internet. SSH shows us that we can communicate securely without trusted third parties. The next question is how best to apply this to web browsers. Hashes of public keys are not easily consumed by casual Internet users. Another Intrepidus colleague, Aaron Rhodes, brought up the idea of vanity hashes that are actually easily recognizable patterns. This could help, but it would certainly complicate key management.

In an effort to actually try and help make things better, rather than just ranting about how bad PKI is on this blog, I've actually been working on a plug-in for Firefox that lets users white list SSL public keys SSH style and alerts the user when they change. It is actually alot harder than it would seem. In my next post, I'll talk more about this plug-in, and the challenges I've faced in getting it working.

-schmoilito

(Cross post on blog.phishme.com)

A brief description of how to become a CA

2009-01-02T07:04:00.000-08:00

Anyone can create a Certificate Authority. Check out this blog describing how to do it with OpenSSL.

Becoming a trusted CA is a different story. Microsoft, Mozilla, Apple, and other browser companies and OS vendors have a policy stating what it takes to participate in their root CA programs.

http://technet.microsoft.com/en-us/library/cc751157.aspx
http://www.apple.com/certificateauthority/ca_program.html
http://www.mozilla.org/projects/security/certs/policy/
http://www.opera.com/docs/ca/

Nobody is perfect

2009-01-01T12:34:00.000-08:00

Just before Christmas, an admin from StartCom certificate authority disclosed that he was able to procure an SSL certificate for Mozilla.com from a registered agent of the CA Comodo. He was not authorized to obtain this certificate, and the RA and CA clearly failed to properly vette his cert signing request. Shame on Comodo. You can read the entire saga on mozilla.dev.tech.crypto.

The discussion resulting from StartComs blog post is quite interesting, and touches on many issues spanning from internal CA domain validation procedures, to how to revoke a certificate in the Mozilla root cert program. One issue in particular, is exactly what I talked about in my last post.

Frank Hecker, of the Mozilla Foundation, said "[right] now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.)."

When a flaw in a CA validation mechanism is uncovered, it can sometimes be trivial to fix. The hard part is determining if any other certificates were obtained by taking advantage of the same flaw, and then revoke them. Although I can imagine a methodology for this process, I can't comment on how any given CA would actually tackle this problem. Based on my own application security experience, I will say that I'm sure lots of logs that would need to be parsed, might not actually exist.

One person who commented on the StartCom post that started this all critiqued the post by saying it seemed dodgy that StartCom was blatantly pointing out flaws in a competing CA. The reader did, however, understand the severity of the problem that was found and thanked StartCom for publicly disclosing it. I agree with the reader, and I think StartCom did a good thing in disclosing this bug.

So in the interest of full-disclosure, here is what happened on Friday December 19 (three days before the StartCom disclosure). I found a flaw in StartCom's domain validation mechanism that easily allowed anyone to authorize themselves for ANY domain name, on various .TLDs. While I only tested .COM, many other TLDs were available including .GOV.
The screen shot above shows the domain names my StartCom account was allowed to create signed certificates for. These certificates would have been trusted by Firefox, but not Internet Explorer. The first one is a domain I control. Phishme.com and Intrepidusgroup.com are domains owned by my employer for which I am not an authorized contact, and for which I should not have been, but was, granted a signed certificate. Needless to say Paypal.com and Verisign.com are companies I'm also not authorized for.

Fortunately for Verisign and PayPal, a defense in-depth strategy succeeded for StartCom. While I by-passed StartComs domain validation process, my attempts to create a signed certificate for Verisign.com was flagged by a black-list and not permitted. This is good news for the prominent sites on the black-list, but bad news for lesser known sites that rely on the trust gained by having a valid SSL certificate (small credit unions, for example).

Because they're a good CA, the StartCom team was immediately aware of my attempt to get a certificate for Verisign. I disclosed the details of the flaw to them, and the simple problem was fixed within hours. But the question remains: did anyone else take advantage of the flaw?

PKI is not a perfect system, and there is no perfect CA. But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure.

(cross post on PhishMe)

More than one way to skin a CA

2008-12-31T12:57:00.000-08:00

Alex Sotirov, Jacob Appelbaum, and crew did some awesome work. They showed that it was possible to exploit RapidSSL's use of MD5 for signing certificates in order to create their own rogue CA signing certificate. This exploitation is many orders of magnitude more severe than when I used a loop hole to get the login.live.com certificate from Thawte.

So what should happen when a CA screws up? Last summer, folks thought that the CA which issued the login.live.com certificate should have its status as a trusted CA revoked. I'm sure people feel the same way about RapidSSL. In my opinion, they are correct. However, it is clear that this could not happen, as it would effect the millions of businesses that rely on these CAs being trusted, which is what a VP at Verisign reaffirms in the comments of this post.

A different question that Appelbaum asked during the presentation in Berlin, and one I've asked many times during my research of Certificate Authorities, is: if we were able to do this, how do we know if anybody else has done the same thing?

No one can ever give a straight answer. I've reported a number of flaws to CAs responsibly; flaws that can allow people to get certificates that they shouldn't be allowed to get. The flaws get fixed, and thats great, but the damage that could have already been done is immeasurable.

It sucks when an online retailer gets hacked one or even multiple times. It's bad for them, and it's bad for their customers. When a trusted CA gets hacked, it sucks for the ENTIRE INTERNET. The CAs are supposed to help us secure the Internet. What does it mean if they are not secure themselves? To me, it means that we can't rely on trusted third parties.

I know that abandoning PKI and trusted third parties is a bad idea, and probably won't happen. However, people need to be more involved in the process of making trust decisions when communicating online. And I don't mean little yellow locks and green address bars. I have some ideas on how to make better use of SSL in web browsers and other SSL clients. So far, I've gotten mixed responses to them from my peers :-) However, with what the Sotirov/Applebaum team accomplished, maybe my ideas will make more sense. Stay tuned...

(Cross post on PhishMe)

You don't need to be a hacker to abuse DNS

2008-12-09T12:59:00.000-08:00

This morning I woke up, took a shower, and went straight to my laptop to let everyone on Twitter know that I had made it through another night, and had even decided to bathe. Unfortunately for me and my loyal followers, Optimum online had some tricks up its sleeve. It seemed that my DNS servers could not resolve www.twitter.com or twitter.com. Hmm. Check out Google. It's up. CNN? Up. Log on to EVDO, Twitter is fine. What the heck?

This DNS error was not like any I was used to seeing. I wasn't getting a vanilla browser message saying the page could not be displayed. No, I was getting an Optimum branded page telling me that the "domain could not be found." Fortunately, the page offered me a variety of SPONSORED and pay-per-click links that I could burn some time clicking on. Of course, when you follow the links that actually go to Twitter, DNS still would not resolve, and I'd end up on the same "domain not found page," where I could click on more links and generate more cash for Optimum online.

Optimum better shape up. Fios is in town now, and I don't like it when my ISP earns cash if their DNS servers screw up. Let alone the thought that they could intentionally force DNS glitches in order to generate some fast cash via sponsored links. What a racket!

Lets not forget about the bad habits this teaches end-users. "The server you were looking for cannot be found, so here click on these links instead." I can't wait until I see a message like that on my banks web site!

Who thinks ISPs would not stoop so low as to launch DNS attacks against their own customers? As far as I'm concerned, thats what Optimum did to me.

CheckFree.com owned; SSL, little yellow locks surrender.

2008-12-05T07:34:00.000-08:00

A Washington Post blogger reports that the CheckFree.com domain name was hijacked. CheckFree is an online bill pay solution which many banks use to provide customers with a convenient method of making payments online. Apparently, attackers took control of the domain name by obtaining Check Free's credentials for their domain registrar account at Network Solutions. They were able to simply change the name servers for CheckFree.com (as well as any other Check Free domain), and all users would be redirected to attacker controlled web servers hosting malware and self-signed certificates.

On SlashDot, one person mentions that they were served a self-signed certificate when they clicked through to CheckFree from their bank. This attack could have been even nastier if the attackers had procured a legit CA signed certificate. Maybe the Network Solutions credentials also worked for CheckFree's EquiFaxSecure/Geotrust account (check out the cert for https://mycheckfree.com). If they had a valid cert and weren't hosting malware, who knows how long the hijacking could have lasted. All Check Free traffic could have been routed through the attacker servers in plain-text. Scary.

Fuzzing and MS08-67

2008-10-24T05:08:00.000-07:00

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

2008-09-11T07:06:00.000-07:00

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

2008-09-02T15:50:00.000-07:00

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

2008-08-25T06:38:00.000-07:00

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!

2008-08-19T14:37:00.000-07:00

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

2008-08-19T13:02:00.000-07:00

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

2008-08-07T18:17:00.000-07:00

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.

Thoughts on IE8

2008-07-02T12:05:00.000-07:00

I read quite a bit of stuff on the IE8Blog today. Most interesting to me are the improvements surrounding ActiveX controls. Among the big changes here are Per-User (non-Admin) controls and Per-Site Controls.

Per-User Controls are installed by standard users without the need to elevate privileges. Administrative rights will no longer be required because the control will only be exist within the profile of the user who installs it, preventing exploitation of other users of the system.

More importantly, Per Site controls allow users to white list certain sites to use certain controls. This is a great break through in the fight against ActiveX re-purposing attacks, where malicious web sites abuse functionality in legitimate controls. Where security conscious developers once had to maintain their own white-listing code within the control, IE8 will do this for them by default.

This is great for complex web applications (like SSL VPNs) that use ActiveX controls to perform sensitive/dangerous actions on the client. Unfortunately, there are still many organizations out there that haven't even embraced IE7 yet, so these defenses may not help the users who really need them for quite some time.

On the XSS front, IE8 will also have a few new tricks. One of them is a client side black-list XSS filter (like a wimpy NoScript) that will block attacks and notify users. Unfortunately, to avoid "breaking the web", it appears from this post that the filter will only block the most obvious SCRIPT tag injections.

Another new feature is the toStaticHTML() JavaScript method. This looks like another blacklist, but is intended to allow a web site to render third-party Web2.0 content safely in the browser. Hopefully it uses a robust black list!

Another new feature that I'm really excited about is domain highlighting. In order to prevent phishing and other social engineering attacks, IE8 will highlight what it determines to be the owning domain name in the address bar. Anything site controlled, like sub-domains and URL text, will be grayed out, so that the user can more easily key in on the important parts: the protocol and domain name. Simple, but effective.

Recent OWASP Events

2008-06-19T03:55:00.000-07:00

Last week I presented at FROC.us and my demos worked fine. Last night at the OWASP NY/NJ chapter meeting my demos failed hard! Fortunately for me, everyone was very nice and understanding, and the presentation was able to hold its own without the demos. Thanks for everyone who came out to both of these events!

You can view my slides here:

FROC.us - SSL VPN Security (different from what I'll be presenting at BlackHat)

June 18 2007 OWASP NY/NJ - Reverse Proxy Abuse

Here are videos of the demos I tried to show last night:
Abusing XMLHTTP for local resource access
Exploiting 5 WebApps with 1 HTTP Request

I had some resolution issues that prevented me from getting them up on YouTube, but I'll try again later when I have more time.