In light of my last gloom and doom post, I wanted to turn the tables and add some humor. A while back a bunch of us came up with the concept of a security expert rehabilitation program. Once we give up security and go back to manual labor we need to re-acclimate ourselves to the rest of society. So, in no particular order, here’s what the rehabilitation program might look like:

Step 1: Sign up for a MySpace account. Facebook is fine too. Actually why not all of the social networking platforms? It’s easier to keep in contact with everyone if you do. Make sure to fill out each form field completely and accurately!

Step 2: Pick a password that is easy to remember and make sure to write it down on a sticky note. Feel free to tell your friends in case they want to use your account too. Better yet, make a list of all your passwords and change them all - to “password”. If someone is annoying and makes you use a number, “password1″. An upper case, a number and a special character use “Password+1″. Now tear up that pesky list you just made. You’re living easy now aren’t you?

Step 3: Download every third party widget, gadget, movie, game you can think of onto your social networking profile. Cuz that’s fun. And make sure to put every gory detail about who you are, where you live, what your birthday is, what your mother’s maiden name is, what you like and dislike, etc…. And feel free to update it regularly with any and all personal information that may have changed. That way people can get to know you better.

Step 4: Log into your newly created webmail account and email all your friends your likes and dislikes. Don’t forget to enable HTML rendering so you can see all the neato pictures! And don’t feel afraid of hitting reply to those spam emails. That’ll help them know that you’re not interested.

Step 5: Start downloading toolbars and desktop applications galore so that you can get your real time stock quotes, shop for beanie babies and know what the weather is like in Iceland at all times.

Step 6: Go ahead and remove all that anti-spyware and anti-malware junk. It makes your computer so much faster if you do! Plus, who wants to keep hitting “Ok” and “Allow” to every security warning? Turn `em off!

Step 7: Go ahead and plug that laptop right into the Internet. No need to use a firewall. Those are just complicated anyway. Or better yet, just go to the local cafe and use their public wifi. Hey, cute girls hang out there - that’s what normal people do: they hit on cute girls who are using open wifi. You want to be normal too, don’t you?

Step 8: Don’t bother to lock your computer when you go to the bathroom at your cafe. Let the police worry about crime - it’s not your job anymore.

Step 9: Open all the attachments you get in emails. Hey, they might be important, and you don’t want to be rude to whomever sent them to you, now do you? That’s not what normal people do.

Step 10: And finally, start clicking on all ads everywhere. They wouldn’t give a “special offer” to just anyone!

If I don’t post before then, have a great week and a good Halloween for those of you who celebrate the more pagan of holidays!

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: Fixed in Flash 10 release. All versions of Flash on IE7.0 and IE8.0 could 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 seamless 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). The clickjacking overview whitepaper has been released here. 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.