I'm Feeling Lucky

Posted by Robert Freeman on April 29, 2008 at 5:08 PM EDT.

I’m feeling lucky; it’s not every day that bloggers here get to share diverging opinions. In a recent blog post, it was postulated that Google’s “I’m Feeling Lucky” button should be reconsidered as a security hazard. But, it’s really no more dangerous than using the regular Google search button. Let me explain. First, Google is active in malicious webpage crawling just like we are here. Second, if they know a site is malicious and you click on “I’m Feeling Lucky”, Google will redirect you to the full search listing instead of automatically sending you to a malicious website. So there’s one main case left—what about when Google doesn’t know a site is malicious. In this case, who is to say that a user that clicked on “I’m Feeling Lucky” would be able to discern the malicious site in a full search listing, especially since it would be the first item returned? Personally, I’m skeptical that they could. On the other hand, there may be some clues for advanced users that don’t use this button anyhow.

Are you Feeling Lucky?

Posted by Gunter Ollmann on April 24, 2008 at 6:33 PM EDT.

Given the proliferation of site’s infected with malicious drive-by download attack code, it’s about time to retire Google’s “I’m Feeling Lucky” search button isn’t it?

While mass defacements have always caused consternation with the security community, the dramatic increases in mass attacks this year are more worrying than usual. Unlike previous years in which the objective was to post some kind of message for the world to see, today’s generation of mass attacks are profit driven and seek to subtly inject sites with hidden iFrame encapsulated URL’s which subsequently cause malicious JavaScript to be executed within the victim’s browser – thereby propagating malware through a drive-by download vector.

Over the last couple of months we’ve been observing weekly defacements number in the hundreds-of-thousands. The specific vectors change every few weeks. For a short while it was though ISS-ASP-SQL vulnerabilities, the next it is through Search Engine Optimization (SEO) injection attacks, and today it’s being reported that more than half-a-million sites have been infected through a simple SQL injection vector.

Several years ago I commented on the potential dangers related to the way people used search engines for accessing their online banking portals – i.e. the URL’s and site names were so hard to remember that banking customers were simply typing “mybank online” or similar in to their favorite search engine and clicking the first or second link on the results page – kind of like an alternative DNS infrastructure. At the time I pointed out that even simple SEO attacks (or page rank escalation) could advantageous to phishers.

Now, since just about any popular Web site appears to have an equal probability of containing an embedded drive-by download link, the risk is greater than ever in blindly following links between sites. It’s for this reason I think it may be a good idea for Google to consider retiring the “I’m Feeling Lucky” button.

Sure, we’ve all played with the “I’m Feeling Lucky” button on slow and boring days. But in today’s drive-by download world I've got the feeling that ”luck” is probably a depreciating commodity as far as the Web is concerned.

As Clint Eastwood once said in Dirty Harry, "you've got to ask yourself one question: Do I feel lucky? Well, do ya, punk?"

More on Automatic Patch Based Exploit Generation

Posted by Tom Cross on April 23, 2008 at 4:32 PM EDT.

I thought I'd follow up on Gunter's post with some technical points about this paper. In essence, I think the authors have demonstrated a powerful tool that could be a useful asset to a vulnerability analyst, but their abstract, and the conclusions they draw, assume solutions to difficult problems that remain unsolved in the open, public security research space.

The paper describes a toolset that produces exploits from patches almost instantly, and goes on to discuss the implications of instant exploit generation from patches, raising the specter of worms propagating in the hours while patch distribution is still taking place.

However, the toolset that is actually described in the technical details of the paper does not provide that sort of capability. The tool does not only require a patch diff, but also either an input that reaches the vulnerable code, or an indication by the tool's user of the specific locations where the attacker controlled data that ultimately exercises the vulnerable code is input into the program. From that information the tool produces a set of inputs that would be rejected by the patched version.

There are two points that I'd like to make about this. The first is that working back from a patch diff, it can take time to determine what inputs reach the vulnerable code, depending on the nature of the vulnerability. Starting with just a patch you might not even know what feature of the program is embodied by the code without spending some time studying the context. If you know where the correct outside interfaces are, the static analysis feature of this tool could be tremendously helpful in finding an input set that gets you to the vulnerability, but it depends on the bug. In many cases bugs are close to the surface, and so an experienced analyst wouldn't need an automated tool to determine the path quickly.

The second point is that the set of inputs that are blocked by a patch are not the same as the set of inputs that could be considered an exploit. If the patch is correct (and they aren't always correct) the later should be a subset of the former, but an attacker is looking to induce a specific behavior. Denial of service conditions are usually easy to induce once you have input that reaches the vulnerable code, but remote code execution can be extremely challenging, as anyone who has read Mark Dowd's recent paper can see.

It is my opinion that most of the time between patch distribution and exploit propagation for serious vulnerabilities is taken up by the work involved in figuring out what interfaces relate to the patched code and the non-trivial task of obtaining remote code execution, particularly if operating system security measures are in play. This toolset does not address either of these problems, and therefore, using the publication of this result as a basis for assuming that attackers can instantly produce working remote code execution exploits from distributed patches is not warranted.

However, history has shown numerous examples of fairly rapid exploit propagation after patch disclosure. An assumption that attackers cannot release exploits instantly is also not warranted regardless of this result. For example, an attacker may have independently discovered a vulnerability and previously developed an exploit for it, which he or she might dump in an open forum once patches are released as the vulnerability would be less useful as a secret at that point. Furthermore, to Gunter's point, there have been numerous examples in the past of automated tools that help analysts discover and exploit certain constrained classes of vulnerabilities in specific repeatable contexts.

Furthermore, I don't mean to disparage the work done by these researchers. This tool could be incredibly useful to an analyst, particularly when input is heavily permutated before reaching a vulnerable operation. I am very impressed with the rigor of this analysis method and I think the tool could be applied to a number of other parts of the vulnerability discovery and analysis problem that aren't discussed here.

"Automatic Patch-Based Exploit Generation is Possible" - So say we all.

Posted by Gunter Ollmann on April 22, 2008 at 12:21 PM EDT.

Over the weekend I managed to read a new security paper titled “Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications” that goes in to some depth of how to automatically reverse engineer security patches and create (reliable?) exploits.

It’s an interesting paper, and I’d recommend that most security professionals read it (I wouldn’t worry too much about the math that’s in there if I was you – it’s more of a case of “math for math’s sake” than actually adding value to the paper).

I’ve been in two minds about commenting about the paper, but having read some of the nonsense editorials and blogs referring to the paper – “the sky is falling” – I figured it would probably be valuable to provide an “insider’s” perspective on automated exploit generation from patches.

My initial hesitation on posting was largely due to a case of “well, isn’t that nice, haven't people been doing this already for a couple of years” and, quite rightly, the authors imply that several times in their paper “best security practices dictate that we conservatively estimate the power of an attacker, our results imply that in security critical scenarios automatic patch-based exploit generation should be considered practical.” – better late than never.

Brass Tacks

Getting down to brass tacks – yes, it is technically possible to automatically generate exploit material for a fixed vulnerability using knowledge of the differences between the patched and unpatched software – no surprise there.

While I’m not aware of any commercial tools that automatically do this today, there certainly is a historical market for tools, plug-ins and add-ons that simplify that task for security researchers and reverse engineers to do this very thing. Several of these tools have the capabilities to generate the pseudo code necessary to craft an exploit for the particular OS flavor they are running (“reliability” is open for debate though).

I suppose the question is whether it’s to the attackers advantage to use a tool that automatically creates exploit code from newly released patches? If it was to work reliably, then the answer would be “of course!” We have already observed the commercial incentive behind attackers slipping in and out in the midst of a shrinking patching window. Looking at the value of exploit code traded within the darker side of the Internet, we’ve seen its exponential value curve become steeper – prices increasing for exploits released within hours of patch availability, and prices hitting rock bottom for exploits released a day or two later - pricing which has probably been driven to a large extent by the use of x-morphic attack engines in drive-by-download attacks.

I’d have to wonder though whether it’s to the commercial attackers advantage to invest in creating a robust auto-exploit generating engine, are the economics right? As the paper points out, not all vulnerabilities are created equal, and various levels of code obfuscation techniques can probably make it pretty darn difficult to auto-gen an exploit (and not hang/crash the exploit generator). So, to create a reliable tool is going to take a fair amount of effort (and more effort to maintain the tool going forward as vendors rework their patching response) from some reasonably skilled reverse engineers. Meanwhile, those very same reverse engineers can churn out reliable exploits at a fast enough rate to keep their employers happy – and still be able to manually bypass most reconfigurations the vendors may implement.

That said, we can probably look forward to someone somewhere releasing a public beta for exploit auto-generation fairly soon – most likely someone trying to prove their skills, and unlikely to be involved in the commercial attack scene (yet?). If I had to place money on where we’ll see the first “proper” auto-gen exploit tool, it’ll probably be from a Metasploit contributor.

Fame & Fortune

Does fame & fortune await the developer of a “reliable” auto-exploit-generator? Fame/infamy probably does – I’m not so sure about the fortune part unless they can set up a business and commercialize it (even then, it’ll probably be cannibalized by the bad guys and incorporated into their commercial offerings for one percent of the cost).

So, going beyond the notoriety of building a reliable auto-exploit-generator, is it actually likely to be useful in attacking and claiming victims through missing patches? Until the opportunity window slides firmly shut on application patching – yes, probably. I say “probably” because I suspect that future automated tools will also use stock shellcode and exploit techniques – which will subsequently be easier to stop using protocol-based intrusion prevention systems.

But let’s be clear, the probability that an auto-exploit-generator (working off newly released patches) actually changing the threat landscape is pretty small. For one thing, the dangerous vulnerabilities lying in contemporary operating systems tend to be real pigs to exploit reliably and require a considerable amount of elbow-grease to develop and get right, and they’re not really getting any easier. Yes, vulnerabilities like the one lying at the root cause of Slammer are fairly simple, but the industry has moved on since then – lessons have been learned – and those types of vulnerability are much rarer (but not impossible, since there are still humans doign the coding).

In a battle between man and machine, I know where I’d place my money. I’ll meet your auto-exploit-generator and raise you a Mark Dowd… although some may argue that thats cheating since Mark may be a machine sent back in time.

CAPTCHA's and Mechanical Turks

Posted by Gunter Ollmann on April 14, 2008 at 4:52 PM EDT.

Last month I introduced the topic of “security ergonomics” and mentioned that I’d try to cover some of the presentation topics from the IBM internal conference a little later. Well, I guess it’s a little later, and the topic for today is CAPTCHA.

Back in February I pointed out some of the problems with CAPTCHA’s, namely the fact that they had become so difficult (in an effort to combat automated OCR tools) that they were defeating the very customers they were designed to protect. In essence, the “Tell Computers and Humans Apart” had failed, and that computers were appearing more human than the human customers.

As a security technology goes, I think CAPTCHA’s are a prime example of an industries failure to understand its customers and embrace a semblance of security ergonomics.

What irks me the most is the assumption that the end-user is at fault for poorly considered Web application security and that it's their liability. I guess, to my mind, CAPTCHA’s remind me of compulsory drug testing in professional sports:

1. It has nothing to do with what you’re there for (e.g. You’re there to run a race, not pee in a bottle)
2. Everyone is assumed to be guilty (i.e. you fail the test if you refuse to take it)
3. It punishes the minor infraction (e.g. you’ve just come back from a weekend in Amsterdam)
4. The professionals already know how to bypass the tests (e.g. they have the money to buy the “undetectable” drugs)

Perhaps the fourth point above is the most pertinent.  The professionals already have the capabilities by bypass today's CAPTCHA “security” features.

Last year we observed the downloadable “Melissa Strip” tool that provided a new pornographic picture for each CAPTCHA solved and throughout the first parts of this year we’ve seen each major free-email (e.g. Hotmail, Yahoo Mail, Gmail) CAPTCHA system fall to automated OCR solvers.

Irrespective of these automated tools; let’s not forget that the professionals have been employing flesh-and-blood humans for several years to break CAPTCHA’s online via Web sites (e.g. hacking sites offering free porn for each CAPTCHA solved).

As amusingly as it may seem, but you can even make a fair bit of money breaking CAPTCHA’s on behalf of the professionals.

Using a “crowdsourcing” business model closely resembling Amazon’s Mechanical Turk,  the professionals now pay recruits to break pages of CAPTCHA’s for money – where the rate per page/CAPTCHA is negotiated up front by the “employee”.

 
(a typical “page” of CAPTCHA’s)

For example, a recruit that can answer 10 CAPTCHA’s per minute can earn $3 per hour.

 
Note that item (2) above says the following (according to Google's translating service):

"Your new job is to reprint the text with images in English. Examples of such images: primer1, example2, primer3. There is a need knowledge of English letters and a British possession layouts at the secondary level. For each correct input text with images, you may receive up to 1 cent, depending on where you choose to "bid". You are limited only by their speed text input from the keyboard, that is, in a minute you can handle an average of 10 pictures. Thus, at an average price of 0.5 cents per correctly entered the text of your earnings will be 3 dollars per hour."

While some other sites offer a fixed rate of $1 per 1,000 CAPTCHA’s.

 
In general, becoming an “employee” is no more sophisticated than entering your details in their registration page and selecting how you want to be paid (e.g. Z-purse, Webmoney, Rupay and e-gold).

 

Now, while this may not sound like a lot of money to you and I, it is important to remember that there’s a lot of people in developing countries only too willing to earn a few extra dollars per day online (after all, thousands are employed in China selling gold earned in the MMORPG "World of Warcraft").

The last few times I've presented on this subject, people have asked me whether it's all illegal. While I’m certainly no legal expert, I doubt that the “employees” are doing anything wrong or could be successfully prosecuted. I suspect that the professionals are probably abusing the terms & conditions of the sites that are deploying the CAPTCHA’s as a security device but, frankly, it’s not like they’re going to care.  The CAPTCHA’s are just a minor hurdle in the creation of user accounts that can be used to propagate spam and other nefarious attacks – so breaking a few T&C’s is hardly something they’re going to lose sleep over.

So, with all that in mind, why do commercial Web sites still persist in using CAPTCHA’s? It’s not as if they are stopping the professionals (or anything above script-kiddie level). In fact, the techniques needed to stop the folks that use these CAPTCHA-breaking schemes are the very same techniques that should have been implemented in the first place – rather than impose a weak and distracting “security” system on the end-user.