I’ve spent a long time in the trenches and recently I’ve been getting more and more jaded - if that’s even possible. I’m sure at least once a week someone in the office hears me utter the nearly completely useless comment, “everything’s broken anyway, who cares?” Now I think it’s time I actually explain myself. In the last decade and a half that I’ve been in interested in webappsec I’ve had the opportunity to talk to nearly every self proclaimed expert in the industry and more and more I’ve been able to get them to say or admit that “everything is broken.” I think what they mean is that if an attacker takes any system and apply enough resources against it they will get into it, break it, take it off line or whatever it is they want to do.

I’ve talked to a number of people regarding the percentages of sites they are able to break into or find exploits in. A few years ago we were all collectively hovering around 70-80% (Jer has some good stats on this) - but we were only talking about that in context of certain classes of webappsec bugs. Could the number be higher? And I don’t mean higher by a few percentage points - I mean approaching 100%? Let’s assume for a moment that there is one or more 0day remote vulns in each of the major web servers out there that we haven’t uncovered - they happen fairly regularly so let’s just take it on faith that there is at least one or more left. Then let’s assume a large number of the remaining sites host insecure applications on top of them (we’re finding that number to be well into the 90% range for anything at all dynamic). Then let’s assume a large percentage of the very small remainder have insecure network configurations (we find that number alone to be around 70%). Then let’s assume the server providers, or administration paths are insecure to physical wire tapping, or direct exploitation against the underlying DSL modems/routers of the people who administer the site. Then let’s talk about DNS, or router/firewall exploits, ASN.1 and so on. Then let’s talk about man in the middle exploits, browser exploits, mail exploits, Instant Messaging exploits, exploits against mobile phones and so on and so on… And let’s not forget social engineering. None of which are covered by that original 80% that I think we were all talking about a few years ago.

Remember, before we were at 80% and that was bad enough. In fact, you may all remember the Joel Snyder comment that there is no way anyone could exploit 70% of sites. I think he and others like him felt that 70% was apocalyptic and Acunetix was simply smearing marketing FUD. But what if the number was really worse? And I mean a lot worse. What would people say? What would people think? Would they stop consuming? No - which is why I don’t think talking about it is FUD, or at least not particularly effective at getting consumers to understand reality. But more importantly, who cares? If it’s all broken anyway, why do we keep releasing patches for things that are residing on top of a critically broken infrastructure while there are far more new products, features and services appearing on a daily basis - each with their own holes?

Consumers will keep consuming, companies will keep patching, hackers will keep hacking - nothing will change because of this post or any great realization of how broken things really are. Does that mean I’m throwing up my hands and giving up? Of course not, it’s my livelihood. But it does mean that I’m not that interested in new exploits, as they are just another way to exploit something. That may be interesting to an outsider who isn’t properly initiated, but I think if you spend enough time talking to experts you too may come to the same realization I did. And that is not to spread an apocalyptic view of the Internet, given that I know consumerism will win over any security flaws.

Many of the CISOs I talk to mention esoteric bugs as their top concern and I have to stop them and explain how unlikely it is that they’ll be hit by that specific kind of exploit, but rather how incredibly likely it is they’ll be hit by something mundane that’s been out there for years. It’s less sexy to talk about it, but we still haven’t found good solutions to problems we’ve known about for 10+ years. As a simple example - why are we still using IPv4, dns, telnet, FTP and HTTP when we have IPv6, dnssec, ssh, scp and HTTPS? Again - I don’t want to sell FUD, I actually just want to stop talking about percentages. The truth is, if you have something interactive connected to the Internet, it’s probably exploitable in some way, and really, it’s not that terrible of a thought considering it’s pretty much always been that way. If you want my advice, take a cue from the military and air gap anything you don’t want broken into. And with that downer, I hope you’re having a good weekend.

I know a lot of people are just tired of the same old PCI ASV rant that really surfaced last year, but I got an email today and I thought it was worth a re-post. Mike Bailey sent this over and I re-printed it with his permission:

I’m hoping you’re interested in this, seeing as your sites were the source of a lot of the original Hacker Safe/McAfee Secure drama. Russ McRee and I have been doing a lot of research about the certifications over the last few months and have come up with a huge amount of new material.

The main points:

* We have found new XSS exploits on McAfee’s on websites
* We have a long list of more sites with XSS, CSRF, SQLi, RFI, and other holes that are supposedly “McAfee Secure”.
* We got a PCAP of a scan and discovered that they do indeed fuzz for XSS (there was a lot of speculation about this on the sla.ckers.org forums a while back)
* McAfee is beta-testing a meta-shopping service where one can shop on “McAfee Secure” sites to ensure that they can be trusted
* This service is itself full of holes
* McAfee promised to publish the standards that they use for certification several weeks ago. They haven’t, and from what I’ve heard (Russ has seen a draft), what they have is extremely broken

I’m starting to release details on my blog (shameless plug, I know, but hear me out). The first post can be found at: http://skeptikal.org/index.php?entry=entry081009-213000

Honestly, I wouldn’t care if you reposted the details on your own site-I’m just trying to get the word out about this. I frankly think we have enough concrete evidence to put serious doubt on their abilities as a PCI ASV, and to expose the McAfee Secure certification for what it is. I just don’t have the level of exposure that will be necessary to do so.

I’ve been talking with a few other people about it, and decided that you were the first place to go for that.

Being someone who is constantly fighting against snake oil, I’m happy to repost any rants people have about snake oil. For the record, I understand the business reasons behind going to the low cost ASVs - because that’s all the PCI requires. I just happen to think you should do a good job, even if you are going to try to undercut everyone else.

I heard a rumor from a friend of mine who took another ASV and put up a website with exactly three links from the main page. One to an XSS vuln, one to a SQL injection vuln and the last to a command injection vuln. The scanner didn’t find anything, even though that’s the only thing you could even do on the site. Completely safe. He asked me not to mention their name, but I certainly wouldn’t stop someone else if they wanted to do their own research and happen to find the same thing. That is all.

Today is the day we can finally start talking about clickjacking. This is just meant to be a quick post that you can use as a reference sheet. It is not a thorough advisory of every site/vendor/plugin that is vulnerable - there are far too many to count. Jeremiah and I got the final word today that it was fine to start talking about this due to the click jacking PoC against Flash that was released today (watch the video for a good demonstration) that essentially spilled the beans regarding several of the findings that were most concerning. Thankfully, Adobe has been working on this since we let them know, so despite the careless disclosure, much of the work to mitigate this on their end is already complete.

First of all let me start by saying there are multiple variants of clickjacking. Some of it requires cross domain access, some doesn’t. Some overlays entire pages over a page, some uses iframes to get you to click on one spot. Some require JavaScript, some don’t. Some variants use CSRF to pre-load data in forms, some don’t. Clickjacking does not cover any one of these use cases, but rather all of them. That’s why we had to come up with a new term for it - like the term or not. As CSRF didn’t fit the requirements for clickjacking, we had to come up with a new term to avoid confusion. If you like Michael Zalewski’s term “UI redress attack” better use that one, it’s just not CSRF and shouldn’t be mistaken for any other attack, since it really is different. Here is the technical detail:

Issue #1 STATUS: Unresolved. Clickjacking allows attackers to subvert clicks and send the victim’s clicks to web-pages that allow themselves to be framed with or without JavaScript. One-click submission buttons or links are the most vulnerable. It has been known since at least 2002 and has seen at least three different PoC exploits (Google Desktop MITM attack, Google Gadgets auto-add and click fraud). All major browsers appear to be affected.

Issue #1a STATUS: Unresolved. JavaScript is not required to initiate the attack as CSS can place invisible iframes over any known target (EG: the only link on the red herring page). Turning off JavaScript also neuters one of the only practical web based defenses against the attack which is the use of frame busting code.

Issue #2 STATUS: Unresolved. ActiveX controls are potentially susceptible to clickjacking if they don’t use traditional modal dialogs, but rather rely on on-page prompting. This requires no cross domain access, necessarily, which means iframes/frames are not a prerequisite on an attacker controlled page.

Issue #2a STATUS: To be fixed in Flash 10 release. All prior versions of Flash on Firefox on MacOS are particularly vulnerable to camera and microphone monitoring due to security issues allowing the object to be turned opaque or covered up. This fix relies on all users upgrading, and since Flash users are notoriously slow at upgrading, this exploit is expected to persist. Turning off microphone access in the BIOS and unplugging/removing controls to the camera are an alternative. Here is the information directly from Adobe.

Issue #2b STATUS: Unresolved. Flash security settings manager is also particularly vulnerable, allowing the attacker to turn off the security of Flash completely. This includes camera/microphone access as well as cross domain access. Resolved using frame busting code, bug #4 below notwithstanding. However, as pointed out elsewhere, it is possible to directly frame the SWF file example here and here.

Issue #2c STATUS: To be fixed in Flash 10 release. All versions of Flash on IE7.0 and IE8.0 can be overlayed by opaque div tags. Using an onmousedown event handler the object click registers as long as the divs are removed by the onmousdown event handler function. Demo here of stealing access to the microphone.

Issue #3 STATUS: To be fixed in the final release candidate. Flash on IE8.0 Beta is persistent across domains (think “ghost in the browser”). This would be a much worse vulnerability except for the fact that it is beta and almost no one is using it.

Issue #4 STATUS: To be fixed in the final release candidate. Framebusting code does not appear to work well on some sites on IE8.0 Beta. Instead it is marked as a popup which is blocked by the browser - disallowing the frame busting code from executing.

Issue #5 STATUS: Unresolved. State of clicks on other domains can be monitored with JavaScript (works best in Internet Explorer but other browsers are vulnerable too) which is cross domain leakage and can allow for more complex multi-click attacks. For example a page that has a check box and a submit button could be subverted upon two successful clickjacks. Additionally, this can make the attack completely seemless to a user by surrendering control of the mouse back to the user once the attack has completed.

Issue #6 STATUS: Unresolved. “Unlikely” XSS vulnerabilities that require onmouseover or onmousedown events on other parts of pages on other domains are suddenly more likely. For example if a webpage has a XSS vulnerability where the only successful attacks are things like onmouseover or onmousedown, etc… on unlikely parts of the page, an attacker can promote those exploits by framing them and placing the mouse cursor directly above the target XSS area. Therefore, otherwise typically uninteresting or unlikely XSS exploits can be made more dangerous.

Issue #7 STATUS: Fixed in current releases post 1.8.1.9. Firefox’s Noscript plugin’s functionality to forbid iframe’s can be subverted by iframing a page that contains a cross domain frame or as Ronald found by using object tags. Giorgio Maone validated the issues and issued patches in future releases of the code as well as other potential clickjacking mitigation. 1.8.1.6, 1.8.1.7, 1.8.1.8, 1.8.1.9, 1.8.2 and 1.8.2.1 all contain anti-clickjacking code. All prior versions to 1.8.1.9 were vulnerable to cross domain clickjacking.

Issue #8 STATUS: Unresolved. Attempts to protect against CSRF using nonces can often be overcome by clickjacking as long as the URL of the page that contains the link that includes the nonce is known. Eg: Google Gadgets exploit discussed in Blackhat “Xploiting Google Gadgets” speech. The only semi-decent defenses against this are to omit the nonces in JavaScript space and also include the frame busting code in the same JavaScript. This will break for users who do not use JavaScript though, so it is not an ideal solution.

From an attacker’s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren’t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.

Thanks to Adobe, Microsoft, Firefox, Apple and the various other vendors and people who have been helpful/supportive and care to fix the issue. Also thanks to the researchers who found these issues independently after Jeremiah and I were unable to do our speech, but kept it to themselves (Arshan Dabirsiaghi, Jerry Hoff, Eduardo Vela, Matthew Matracci, and Liu Die Yu). I will release a whitepaper to the informer via hackers for charity sometime today or tomorrow. I’ll also make that whitepaper available publicly sometime next week and information forthcoming when I have some time to put it up. Source to generic clickjacking code available here. I will keep this post up to date with additional issues and updates as I am aware of them.

I ran into this a few weeks ago and I thought it was just so silly I had to post it. If you telnet to an SSL/TLS enabled port and type in “GET / HTTP/1.0″ and hit enter it immediately responds with this rather poorly thought out error message:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />

The irony is that it’s saying that it doesn’t know what I’m saying, even though it clearly does know what I’m saying since it tells me what I’m doing wrong. Pretty stupid error messaging and pretty easy to use to fingerprint the web server. Just thought it was funny enough to pass along.

I’m already back in the airport after a long day over at the world OWASP conference in New York. Among other things that were noteworthy was some extremely tacky marketing schwag from the ISC2 folks that says, “I fill the holes in your SLC”. I feel dirty having even typed that. I wish I were kidding. Ridiculous pictures of Dave Aitel wearing said schwag may or may not end up online in the near future. In the meantime, I wanted to do a brief overview on where we are and how things are progressing.

Jeremiah and I gave a brief talk yesterday outlining the timeline of events, and high level concepts of what was going on. We didn’t talk specifics other than some personal remediation advice - yes Lynx is your friend. I felt really lame giving a speech saying I wasn’t giving a speech, trust me. This was not a career highlight, by any stretch. Hence the self flagellation of telling everyone to loose a volley of squishy OWASP balls at me. I missed most of the volley in the picture I took of it, but you can still clearly see several of the OWASP balls in flight:

Click to enlarge

Jeremiah and I answered quite a few questions from the audience before, during and after the speech, and I’m sure a number of people are already working on their own versions of what they think we’re up to, given that a number of people were quick to tell us they were working on some demo code of some aspects of their interpretation of what we were talking about. I’m sorry to be vague, I really am.

Lastly, we did tell the audience that we will most likely be releasing a whitepaper on the informer’s website of Hackers for Charity prior to doing our full announcement (maybe a week or so before). It’s just a nice thing to do for kids, and we totally support Johnny Long’s efforts. Please sign up. It’s a good cause. If you must know the details and are too cheap to help kids in third world countries or you happen to be a kid in a third world country, I’m sure it will leak out in other ways and we’ll also post the whitepaper publicly later as well.

So, no time line still as of yet, but we are getting regular updates from Adobe and we’re confident they are being as expeditious as they can without risking introducing other issues in the process of issuing their fix. We’ll keep you updated.

There’s been a bit of drama over the last week or so around the upcoming world OWASP conference in New York. It’s surrounding a talk that Jeremiah and I were planning on doing the first day of the conference. Jeremiah and I have been working on some interesting browser security issues which also effect a lot of downstream people/websites/technologies as well. Sounds like a good talk right? We thought so too!

Alas, it turns out that some of the issues we found weren’t just a little bad - they were a lot bad. So bad, in fact, that we felt compelled to do some responsible disclosure. One issue lead into another issue into another and poof - we have at least two and probably more incoming vendor patches at a yet to-be-determined date. And we’ve only worked with a few vendors. So… yah. It’s pretty bad.

As you may have guessed the first is a browser company, Microsoft (to be expected since it’s a browser issue to begin with). The second is Adobe - who have been working closely with us on this one since we first told them about the problem. We have been working on proof of concept code since before Blackhat and finally got our ducks in a row with real working exploit code a few weeks ago. And that is pretty much when the problems started. None of the issues we found relating to the browser were particularly easy to fix, it turns out.

The related issues we found that affect websites (instead of browsers) is thankfully slightly easier to deal with on a one off basis, but that too is going to be a problem. There are a lot of much easier hacks out there against websites for sure, but what we’ve been working on breaks some previously good security measures. The correct solve will not be patching every web-site on earth. Instead it will likely end up being a browser patch against every major browser. The idea of every webmaster in the world patching their own sites is a non-starter. Although I’m sure lots of people are going to run out and patch their sites rather than wait for the normal browser patch and release cycle for all browsers everywhere. We’ve discussed the high level concern with both Microsoft and Mozilla and they concur independently that this is a tough problem with no easy solve in sight at the moment.

So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information we’d have to be sharing. We’d much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue. There will still be holes in many websites due to this problem even after the short term patches are available, but we’d rather a few of the more critical problems get patched before we go public.

However, I must stress, this is not an evil “the man is trying to keep us hackers down” situation, a la Michael Lynn vs. Cisco, or Chris Paget vs. HID, or MIT vs. MBTA and so on. We proactively decided it was better to pull the speech ourselves for the time being and for anyone who was looking forward to the speech all I can say is I hope to make it up to you once the vendors are in a better spot. It wasn’t an easy decision but it really feels like the best option we have given the current situation. If you’re desperate for a way to patch your browser from the issue disable scripting and plugins for the time being. More to come.

Okay, so my last post on timing precision was interesting, but then I went back and started doing more thinking and I found a few ways to get even better precision out of a typical timing attack. Let’s look at a real world HTTP request and response:

Packet: 1, Time: 0.000000 DNS Query (outbound)

Packet: 2, Time: 0.101079 DNS Response (inbound)

Packet: 3, Time: 0.103195 SYN (outbound)

Packet: 4, Time: 0.147479 SYN+ACK (inbound)

Packet: 5, Time: 0.147536 ACK (outbound)

Packet: 6, Time: 0.147801 HTTP request (outbound)

Packet: 7, Time: 0.327528 ACK (inbound)

Packet: 8, Time: 0.825132 TCP segment HTTP response (inbound)

Packet: 9, Time: 0.826323 HTTP Response (inbound)

Packet: 10, Time: 0.826416 ACK (outbound)

Now normally a timing attack would encompass this entire mess, but really we are only interested in a few time slices. We can completely disregard the DNS request and indeed up until the seventh packet, which is the acknowledgment that the packet was received (when we know that our packet has arrived and is in the process of being served up). That right there shaves 1/3 of a second off of my example (this was a real example, btw).

And again, when we are receiving the response, we don’t actually care about the last two packets, only the 8th packet (the returned data). The difference between packet 7 and 8 is what we are actually interested in. By combining this technique with the previous one about finding the exact time the packet arrived by calculating the precision you can identify exactly when the 6th packet arrived, and not just when you got your ACK in the 7th packet. The ACK is important but it gives you a slightly skewed result since it is a timestamp based on when you received it and not based upon when it was sent, unlike the Date: HTTP header that you receive in the 8th packet.

If you don’t look at the packet level information you are introducing up to 1/3rd of a second out of only .826 seconds on the first request, and still a few extra milliseconds extra even if you discount the DNS request. Point being there are certainly some enhancements to be made to the old timing attacks of yesteryear. Looks like a tool waiting to be made…

If you’ve been watching the Olympics you might have see the pretty amazingly close call between Phelps and Cavic. I looked at lots of different pictures and video of it and everyone was saying it was a close call, but they also said it was 1/100th of a second difference. Was it? Okay, here is where we get into our webappsec theory of the day.

So let’s take a normal run of the mill timing attack over a somewhat latent connection, or worse yet, somewhat spotty and latent connection. You normally have two paths of latency - to the target host and back. For those of you who don’t know what a timing attack is go read this or the rest of this post won’t make any sense. The target host has to respond within a certain set range of milliseconds or you know that you have found a successful timing attack. This all relies on your connection being fairly latency free as people will argue with you time and time again. We are lacking precision, and that makes the attack less useful.

Here is where Michael Phelps comes to save the day. I’m no photo finish expert, it looked closer than 1/100th of a second to me. Either way, what if it had been even closer than that? Clocks lack a certain precision. Normally that’s okay, because the smallest people normally want to go down to in their daily life is seconds. Try landing a space shuttle or judging the Olympics with a degree of accuracy of 1 full second. No one’s going to be happy with those results. Although Michael Phelps might not have been 1/100ths of a second ahead of his competitor he might have been closer to 1/1,000,000th’s of a second on the other side of the 1/100th time marker. Clear as mud? No?

So let’s say Phelps touched the wall at a time marker of .001001 and Cavic touched it at .000999. The time difference is only 2/1,000,000ths different but that’s enough of a precision to make it different instead of a tie. God forbid Cavic touched the wall at the same 1/10,000ths of a second or all hell would break loose at the Water Cube and then it would have been a speedo showdown for sure. Okay, so it might not have really been that close at all, but you see my point. Now, back to webappsec.

Let’s say you know that there is some sporadic latency between you and the target. And it’s somewhere between 30 milliseconds and 80 milliseconds at the worst, but for your tests to be valid you need to have the least amount of latency as possible since the timing attack itself is only a fraction of a second different. You can actually time your attack to take advantage of the Date: HTTP header. Let’s say take that as an example where I send my packet at 22:51:50 and 69 milliseconds. When I get a return response of Date: Tue, 26 Aug 2008 22:51:50 GMT I know that the packet was received prior to the clock striking 51 seconds and therefore there is no or minimal latency. If I get the response back and it says Tue, 26 Aug 2008 22:51:51 GMT I know the result is invalid because there was too much latency.

This all hinges on you being able to identify the exact millisecond of precision on the remote computer, which you can do with a large enough sample size. The smallest value is the closest to being accurate. While this doesn’t completely get rid of all the latency issues, it certainly could give you a much higher level of precision in your timing attacks.

Stefan Esser has a really good article about how MySQL and SQL truncate columns which can lead to security holes. He uses a good example of a column that has a width of 16 chars but he submits something with 17 chars. Obviously enforcing length is one way to enforce that, even if it almost never happens. But one other thing came to mind.

Harkening back to my days of reading Rain Forrest Puppy’s papers, I realized that often times the code does a straight regex or string matching. Eg: if ($username eq “admin”) { fail(); } but if the $username was “admin    ” it clearly will fail the string match since it’s not an exact match, but it will have the same net effect in the database of passing the check and allowing you to access the admin data. Likewise padding in front of the username will have the same effect in some cases - depending on how the SQL query is constructed (if it’s encapsulated). Anyway, good article, go read it!

On good authority I was told to take a good hard look at the newly proposed HTML 5.0 spec that’s floating around the WHATWG. Firstly my eyes went to the new video and audio tags which are meant to help users deal with the apparently confusing nature of the fact that we have img tags instead of just using embed for everything. Personally I think that’s just a horrible idea that’s going to break a lot of blacklists out there and potentially open more security holes depending if the scriptable video objects are allowed, but there you have it.

Anyway, so then my eyes glanced across the new iframe spec and lo and behold I saw a miracle. Someone over at the WHATWG was really paying attention. Firstly, there’s a new parameter called sandbox which is similar in many respects to IE’s proprietary security=”restricted” parameter but with more granular controls. That’s not necessarily a good thing if you don’t like being framed, but it does give websites more control over what happens to their site once they frame a site that turns out to be bad.

But more importantly there is another new parameter called seamless which will allow a page of the same origin domain to iframe a page without having all the usability issues (double scroll bars, _self targets and so on) of the original iframe model. That’s great news for websites that want to frame and control a page on their own domain (a la content restrictions) without all the crazy usability issues with iframes. There’s some other security concerns with allowing content to be accessible on your site - there needs to be some tag to disallow rendering unless it’s embedded within an iframe to prevent someone from calling the malicious child frame directly. However, this is a big step forward in the right direction.