CAPTCHA-Jacking

RSnake and Jeremiah Grossman did a really good and thorough job of going over clickjacking and many different ways that it can take place. And until I sat up one night and made my own example, I didn't consider how easy and how serious it was.

Before reading on, please note two things: 1) I'm not claiming to have discovered something new, and 2) I'm not recommending a new name or anything. Rsnake and Jeremiah did all the work and listed a whole series of things that could happen that they admitted were not exhaustive.

However, the most common way to work clickjacking is by completely hiding the target site in a transparent (0.0 opacity) iframe over "the red candy-like button". A teammate and I worked through a proof of concept, though where the idea was to make the target site visible and then use div's above the iframe to hide all the parts you don't want. The most common example would be to have the user solve a CAPTCHA. There are plenty of sites that explain that using a CAPTCHA is a great way to eliminate XSRF and clickjacking all at once.

RSnake and Jeremiah were right - the best way to avoid clickjacking is by using framebusting code. That solves a couple of other problems (although because with IE you can specify a security zone for an iframe it's not bulleproof, but at least you could have noscript that warns the user they might be getting clickjacked) such as dealing with DNS binding attacks. And if users were better about using different passwords for different sites, you can always ask for their password for sensitive actions.

Favorites Scmavorites

Okay, a hundred sites have posted information on the iPhone exploit where you can bypass the security code required to unlock the phone. I don't think as I was playing with it last night that I discovered anything that nobody else has discovered. But I'll give a run-down of all the nifty things I was able to do with it once I got to the favorites screen:

• If a single favorite has a URL, you can tap that and get Safari - the full shebang, so go to a jailbreak site. Game over. I think the security code is stored on the SIM, however, so this wouldn't necessarily bypass that - but since the phone is jailbroken, you should be able to run a telnet or ssh service in the background (good luck following that IP address for long, though).
• If the favorite has a physical address, tap that to get to maps. More on that later
• From Maps, put in the name of a company you know has a website. When the pin comes up for it, follow the link - back in Safari. Game over - as above.
• From Maps, you can also see the home address of every contact on the phone. Or overwrite the contact information for every contact on the phone.
• If a Favorite has an email address, you can tap the email addy to get to a Mail compose window. Cancel the message, and you have *full* mail access. Also, if there are links...
• Hit Text Message and you go to the SMS composer window. Cancel that SMS message, and you can read all their previous SMS messages.
• If the victim's Home button is configured to go to iPod, then you get full iPod controls.

Now, before you think I've gone all gloom and doom on you, I haven't. That's a very targeted attack against a single person. The most common way this would happen would be as a social engineering attack. I often get asked if somebody can use my phone because their ride hasn't shown up at the bus stop yet. The Emergency Call feature is what that's for - press Emergency Call and tap the numbers you need, but you don't get access to all the other junk. So this is a one person at a time sort of attack. This isn't some freaky remote exploit (not that it couldn't be).

There are a couple of things I haven't experimented with on this. First, I've only got one iPhone and not a budget for doing research on the iPhone, so jailbreaking it while it was locked could brick my phone at my own personal expense. If somebody else wants to hit a jailbreak site with a "locked" phone, be my guest. Second, some websites are able to open Maps from Safari - this works just like opening Youtube. Can you also open Stocks? Notes? Arbitrary other app on the phone?

And of course, Apple will probably have this fixed in the next rev of firmware (putting off copy/paste yet again). And until that time, you can either make new favorites with just phone numbers, or you can remove all your favorites, or you can change the home button behavior to go to the home screen instead of favorites. Or you can avoid getting your iPhone into the hands of strangers.

On Source Code Review

First of all, Jeremiah Grossman's periodic Web Application Professional's Survey is online - so go take it.

That being said, I've kept quite silent on the value of static source code analysis for awhile now because I'm pretty sure what the reaction will be, but one of the questions on the survey was regarding which measures to application security go first.

There have been several places where static analysis has gotten a dissed, where it might not be necessary. Most notably of which, I think Fortify Software did their own software a disservice at the Iron Chef Blackhat edition at Black Hat last year. The competition was between some of their source code analyzers and some of their dynamic analyzers. The application testers won hands down.

Before I begin, know that I believe that there is no silver bullet to application security.  Nor do I think static source code analysis is the "best" method of finding vulnerabilities.  Here are some of the valid or most important reasons that static analysis should not stand alone:

• Static analysis is really best at finding semantic flaws - bad API use or failure to use certain API's, etc.
• Static analysis doesn't give compelling pretty pictures and videos of your application giving up information.  The results of a static analysis are only meaningful to developers, and then, only meaningful to developers who understand the real risk of the types of findings.
• Static analysis almost always requires really expensive tools to do a really, really good job.  There are grep types of analyzers, but they don't follow taint through an application.
• Static analysis may analyze components of your code that don't get used.  There are still prioritization decisions to be made.
• Static analysis tools can't find logical flaws such as privilege escalation or XSRF.
• Static analysis has different requirements than black box testing:
• Developers who understand the code and can fix it
• The source code
• For many tools, the code needs to at least build (doesn't have to run)
  

However, there are some really, really good reasons static analysis should be a part of your security toolbelt:

• Static analysis can find vulnerabilities that dynamic analysis can't - corner cases.  "This cross-site scripting flaw only exists on Tuesdays" - if your application was tested in a running state on Monday, you won't know that the flaw exists.  Thread safety issues are very bad for an application, but a black box test of an application might never cause one to come up, and if it does, it's nearly impossible to reproduce, and the results don't say to the oracle that it was that type of vulnerability.  (For example, the application gave you access even though you used the wrong password.)
  
• The results of static analysis are meaningful to developers.  They get lines of code back where untrusted data enters the application, where it flows through the application, and when it exits the application.  These are the exact lines that the developers need to fix, which a black box test alone can't give you.
• Since the results of a static analysis are geared toward the developers, it provides "instant training" for developers.  "What does it take to make this shut up?"  (While I prefer developers understand why you want it to shut up, finding all the places is pretty good, too.)
• Static analysis can happen much earlier in the development process, long before the application is functional.  This gives black box testers more time to test the really cool stuff that static analysis can't find.
• Static analysis can take place as part of a build process, automatically generating problem tickets and/or preventing the promotion of code with high-probability, high-risk findings.  This can be done with automated black-box tools, but it requires a running environment - many more moving parts.
  

So I'm convinced that as long as Iron Chef Blackhat is run the same way as it was last year, static analysis will always lose simply because to a spectator, the results are just boring.  However, that doesn't mean that it shouldn't be a very, very vital part of the development process.

Coding is a Science, not an Art

This has more to do with coding than engineering - two different phases of development.

When I've done code reviews, when I very clearly see a flaw and point it out, the first response is denial. (See The Five Stages of Web Application Security Grief - the devs have the same initial phase.) Developers are so quick to point out the really old defenses (it's a hidden form field; we validate that the drop down list only contains the values we expect when we render it). When you clearly explain the failures of those defenses, they move on to pure denial ("you have to show me"). Then you show them.

It doesn't have to be this hard.

Coders, know that writing code is not an art. It is a science. If it's a science, a found failure is not a comment on your value as a human being. It's a comment on your tendency to make typos, not press the right key, or simply to not have adequate information to execute the problem at hand. If I were to say that your theory has a flaw - that hurts. You've really invested something of yourself into that. But if I simply point out that you failed to carry a 1 or to consider the null hypothesis, or to turn the knob before pressing the button, it hurts much less.

Engineering is different. But if coders (myself included) were far less defensive about their code and actually valued it enough to take recommendations on how to make it better, we could get to the making it better part much, much sooner. Value your skill enough to allow others to help you make that skill better. Even the most elite of ninjas need training.

Drive By Password Changing

Just glancing at some sites that I use day to day, I've found yet another that not only doesn't require the old password to change the password, but also has no other evident controls to prevent XSRF. And this one is a pretty big one, too. I notified them, but I'm sure I'll get a canned help desk response "to change your password, click on the Change Password link and enter your new password twice".

While I don't totally disagree with Billy Hoffman's paranoia of all things Web 2.0, you would think that the more Web 2.0 sites would actually be more concerned about security. Password issues aren't specific to Web 2.0, nor is XSRF. But you would think the people working on implementing new methods would have already figured out how to do the old methods right.

Data Destruction

And I thought I was doing the right thing with tools like DBAN (when I only have a little time) or shred so I can set my own paranoia level high. I suspect at temperatures this high, that there's little magnetic remnant of the data. But you have to do this in a secure place (or shred first, melt later).

XPFA in Hollywood

Well, it turns out that Cross-Personality Framing Attacks (XPFA) aren't just fact, they make good fiction, too. While Bruce Schneier asks his readers to come up with movie plot threats, the writers for CBS (at the very least) are up to the same. I saw an episode of Without a Trace tonight (Season 4, Episode 5 - or 75 "Honor Bound") where an XPFA ends up being a very pivotal plot point in the show. Certainly, there are other fictional shows where similar things happen.

It's unfortunate, however, that it doesn't just make for good fiction. These types of image-destroying attacks take place all the time, and real peoples' lives are being impacted because of them. And there's simply no real defense against it. Sadly, the only real victims are the people being attacked, and it's rare that the people who "fall for it" are inconvenienced. So there's little incentive for people who read fake profiles and ads to disbelieve what they read. This one really depends on people to be responsible, and just don't believe everything you read.