Because if you do, you’ve probably installed QuickTime without realizing it. Why is this relevant? Well, if you’ve been in a cave for the last week, you may not have heard about the Quicktime/Java vulnerability discovered during the CanSecWest conference, which happens to affect just about anyone with those two applications installed. If you try to uninstall QuickTime, it’ll happily oblige, but then iTunes won’t work anymore. So it boils down to two options: Either disable Java, or find another MP3 player for the time being (unless you bought a bunch of DRM-protected music from iTunes, in which case you’re locked in).

As reported by SC Magazine today:

“Essentially, it’s a click-and-you’re-owned vulnerability, so clicking on a URL out of an email or a website that has malicious content [could lead to exploitation],” she said. “If you look at the Microsoft advisories in dealing with IE vulnerabilities, the same sort of common sense applies here.”

In a post today on the Matasano Security blog, Thomas Ptacek delivered a dire warning about the flaw, but did not confirm a public exploit.

“There are a lot of things we’ve learned in the past couple of days that lead us to believe that the QuickTime hole is going to cause real (read: Mom’s bank account) problems,” he said.

Incidentally, Apple recently announced that they have sold over 100 million iPods. That translates to a lot of vulnerable computers. And that’s not even including all the people who use iTunes without actually owning an iPod.

From TippingPoint’s perspective, talk about getting your $10,000 worth. This is huge, and since they own the rights to the information, so they can milk the limelight as long as they want.

Here’s a glimpse at how the fun began:

Shane Macaulay shortly after claiming the prize for the “Pwn To Own” contest
(Photo credit: dmuz)

Client-side browser vulnerabilities, the ones that require the browser software on your computer to make a request to a web site hosting a malicious web page, are on a sharp rise. Sophos reports:

From January to the end of March, Sophos identified an average of 5,000 new infected webpages every day, indicating that this route to infection is becoming more popular with cybercriminals.

and

Not all of the infected websites were created by the hackers themselves. Sophos has found that the majority, 70 percent, were bonafide websites that were vulnerable to attack because they were unpatched, poorly coded or had not been maintained by their owners.

This means there are 3500 newly infected web pages a day that are on bonafide websites. Couple this with the fact that there are browser vulnerabilities where no patch is available that effect most users and you have to say the bad guys really are winning.

Understanding the attack scenario

It takes two to tango in this devastating exploit scenario. An attacker needs to find a vulnerable website and he needs to craft a browser exploit to plant on it. But the beauty of this attack from the attackers perspective is it is opportunistic and the odds are in his favor. Here are the ingredients:

1. the set of website vulnerabilities that allows modification of content
2. the set of bonafide websites unpatched for the modification vulnerabilities
3. the set of browser flaws that allow attackers to execute code
4. the set of browsers unpatched for the code execution vulnerabilities

The attacker just needs one ingredient from each set, 1-4, and he can compromise a client machine that visits the bonafide websites. Unless one of the ingredients above is completely eliminated the opportunistic nature of this attack makes it clear that there is always going to be a certain percentage of compromised machines.

So which is the best set above to eliminate? Number 1 doesn’t seem like an easy target since there are many web servers and thousands of web applications, including custom web applications. Number 2 isn’t a good plan because attackers could just host their own fake web site, which while not as dangerous is still a significant attack vector. Number 3 looks like a good set to eliminate. Even though browsers are very complex there is still only a handful of them which makes the code that needs to be secure reasonable. Number 4 doesn’t solve the zero day problem or the problem where a patch hasn’t been released by the vendor yet.

Attacking the root cause

We need to get on to solving number 3 in earnest. Vendors who supply browsers or plug-ins that extend browsers such as Apple Quicktime need to do a much better job of software security. You guys are the weak link in the chain for client systems. If client computers can be compromised, the internet security foundation crumbles.

There is some good news. We don’t need to find every browser or browser plug-in vulnerability, just the ones that allow code to be downloaded and executed on the client. This is a big category but it is limited. If you look at MITRE’s CWE there is only a certain set of root causes that have the consequence of remote command execution:

1. CWE ID 77 Command Injection
2. CWE ID 79 Cross-site scripting (XSS)
3. CWE ID 88 Argument Injection or Modification
4. CWE ID 121 Stack Overflow
5. CWE ID 122 Heap overflow
6. CWE ID 123 Write-what-where condition
7. CWE ID 124 Boundary beginning violation (‘buffer underwrite’)
8. CWE ID 128 Wrap-around error
9. CWE ID 129 Unchecked array indexing
10. CWE ID 132 Miscalculated null termination
11. CWE ID 134 Format string vulnerability
12. CWE ID 170 Improper Null Termination
13. CWE ID 190 Integer overflow (wrap or wraparound)
14. CWE ID 192 Integer coercion error
15. CWE ID 196 Unsigned to signed conversion error
16. CWE ID 252 Unchecked Return Value
17. CWE ID 364 Signal handler race condition
18. CWE ID 415 Double Free
19. CWE ID 416 Use After Free
20. CWE ID 426 Untrusted Search Path
21. CWE ID 469 Improper pointer subtraction
22. CWE ID 479 Unsafe function call from a signal handler
23. CWE ID 590 Improperly Freeing Heap Memory

There are certainly more vulnerabilities that are specific to the designs of the browsers or plugins but this is a good start. Eliminate these and the bar has been significantly raised.

Apple, Mozilla, Microsoft, Opera and all the plug-in vendors, the client side browser vulnerability crisis is yours to solve. We need significantly less remote code execution vulnerabilities in your code.

Slowly but surely, I’m catching up on my blogging backlog. As I posted before, Day 2 of CanSecWest was a long day, with presentations running from 9am to 9pm. Here are some of the highlights:

Barnaby Jack’s talk, Exploiting Embedded Systems – The Sequel!, was mostly the same as last year’s talk with a couple notable exceptions. Last year, he exploited a UPnP stack overflow in the DI-524, while this year it was a 0day in the DI-604 which he didn’t provide further details on, other than the fact that it was a null pointer exception. This is significant because NPEs are often assumed to be unexploitable — you get an access violation, and the program crashes because the null page isn’t mapped. Ah, but what if 0 is a valid memory address? In the ARM9E processor, this happens to be where the exception vectors live. When certain events occur the processor looks to these locations to determine where to jump. For example, when there’s a software interrupt, it jumps to the address stored at 0x00000008. It’s even better than a stack overflow! But for all those embedded systems programmers scrambling to review their code, don’t worry, you can avoid this simply by configuring the ARM to store the exception vectors starting at 0xFFFF0000 instead. Problem solved. There were a few glitches getting the demo to work properly (people were flooding the wireless network), but overall the talk was well-received.

I also enjoyed Mark Russinovich’s presentation on Vista Internals: User Account Control, Protected-Mode IE, and Bitlocker, in which he outlines many of the features implemented in Vista in order to solve the problem of running as an unprivileged user without sacrificing functionality that users expect (e.g. the ability to install programs). For anyone like myself who hasn’t really paid much attention to Vista, it was a great primer; for anyone who has it was probably boring. But come on, it’s the SysInternals guy, can’t go wrong with that. He even said “Process Explorer” a couple times when he intended to say “Task Manager” — old habits die hard.

HD Moore’s Live Free or Hack Hard: Metasploit 2007 was impressive as always. Not much to say other than they’ve added a ton of new features and the interface is getting better all the time. What’s really amazing is the tiny amount of code required to extend its functionality. Of course you have to learn Ruby first.

Marcel Holtmann from RedHat presented Wii Control You, in which he demonstrated a Linux driver for the Nintendo Wii controller and his progress on reverse engineering the PS3 controller. Good stuff.

Finally, Luis Miras spoke on Other Wireless: New ways to get Pwned in which he focused on wireless controllers using RF, specifically keyboards and mice. He simply tapped in to the datapath between the microcontroller (MCU) and the transmitter IC, then reversed the communication protocol by observing the patterns generated in response to certain keypresses. Once the protocol was deciphered he could attach his own MCU to generate any traffic pattern desired. Sadly, the demo was a bust because his trusty PICSTART microcontroller died in transit. You can always count on Luis for an interesting talk; however, the “oh crap” moment of this one had nothing to do with hijacking keyboards and mice, but rather the fact that the other published applications for the transmitter IC include car alarms and home security systems.

Lightning talks were the reason this day didn’t end until after 9pm. There were about 15 of them, the best of which included:

• HD Moore talking about the ANI vulnerability and some of the obstacles overcome to arrive at a working Vista exploit
• A guy from the MSRC telling the other side of the ANI vulnerability, from initial disclosure through final patch release
• Adam Laurie and one of his students from Dojo, demonstrating an trivial Denial of Service in a HID RFID reader they had just discovered
• Alex Sotirov from CORE discussing (and soliciting suggestions on) new methods of exploiting heap overflows
• Marc Alfonso discussing the Open Source Helicopter, an unmanned aerial vehicle (UAV) kit they will eventually release

Then everyone went out and knocked a few back on Microsoft’s nickel. Not a bad way to end the day.

I’ll post my thoughts from Days 2 and 3 of CanSecWest pretty soon. Thursday was a marathon 12 hours of talks followed by a Microsoft party, and Friday I went straight from the con to the airport to catch the red-eye back to Boston, so I just haven’t gotten around to it.

Before I do that, though, let’s talk about the “Pwn To Own” contest, which turned out to be interesting. Here’s the premise. Dragos purchased two MacBook laptops and challenged the conference attendees to hack them, with the prize being, naturally, the laptops themselves. The 15″ MacBook could be claimed by compromising an unprivileged user while the 17″ edition would require root compromise. An unexpected development was that TippingPoint decided to sweeten the pot, adding a $10K cash bonus to the reward.

The contest officially started around noon PST on Thursday, with the caveat that if nobody had hacked them within the first 24 hours, they would be configured to periodically scrape web pages, thereby increasing the attack surface to include client-side attacks. Of course, both MacBooks had all the relevant security patches applied, including about 20+ updates that Apple (coincidentally?) released Thursday morning.

Friday noon rolled around and they still hadn’t been claimed, so as promised, Dragos and crew set up an e-mail address to which people could send URLs that would be visited from the target machines using Safari. Well, I don’t know exactly what time the compromise happened, but a couple hours later I ran into Shane Macaulay who told me he’d already won the MacBook, with some help from Dino Dai Zovi. When I asked him what the vuln was, all he’d say is that it was a Safari client-side attack, and said to ask Dino for more details.

The exact details aren’t public yet, but your best bet is to refresh Matasano’s blog entry or TippingPoint’s ZDI Upcoming Advisories page. In the meantime, word on the street is that if you’re using a Mac, you should disable Java — oh, and by the way, this affects Firefox as well as Safari. In other words, sounds like a Java Runtime vuln as opposed to a browser issue. Here’s the best part: This wasn’t a zero-day that Dino had been sitting on, waiting for the right moment to release. Nope, he discovered the vulnerability and wrote the exploit the night before. In the Matasano blog comments, he claims he got lucky, but having worked with Dino in the past, I think he’s just being modest.

Now Microsoft has had plenty of high-profile security breaches, no hiding from that. But what are the chances that someone could have discovered and reliably exploited a 0day in Vista (or even XP or Server 2003), start to finish, in a single evening?

Meanwhile, if you’d like to read some more well-informed and passionate diatribes on Mac punditry, I’ll point you to our friends over at Matasano, who take delight in exposing the bloggers and journalists who treat OSX as the panacea of secure computing. Smart writing, and entertaining to boot!

[Update: Windows users, if you have QuickTime installed, uninstall it, or disable Java. Thanks a lot Apple!]

Thought I would post a few thoughts on today’s talks:

For some reason I expected more out of Jose Nazario’s talk on Reverse Engineering Malicious Javascript. Basically, it could be summarized as follows: Use command-line Javascript interpreters such as njs to figure out what obfuscated Javascript does without having to execute the malicious code in the context of a web browser. Near the end, he mentioned that he had been seeing increased amounts of Flash-based malware, and mentioned that flasm was a useful tool for extracting the ActionScript from .swf files. Very clearly presented but pretty basic content.

Adam Laurie delivered a great presentation on weaknesses in RFID, peppered with live demos that kept the audience engaged while not glossing over the technical details. He demonstrated the process of cloning various RFID cards using a reprogrammable Q5 tag and some custom Python code. He talked at length about how RFID is implemented in passports and some of the inherent weaknesses in the internationally adopted passport standard. The encryption key is derived from the document number, date of birth, and expiration date, all of which are printed on the passport. He was able to brute force the key for a British passport based on the fact that the passport numbers are issued sequentially (doh) and the issue date was stamped on the outside of the envelope, making the expiration date trivial to derive. The notion of passport profiling based on implementation errors was also discussed, with one example being Australian passports which incorrectly generate the random ID and handle the access control protocol slightly different from other countries.

I have to question what the CanSecWest screening committee was thinking when they accepted the idea of presenting Fun with IPv6 Routing Headers in 3D. The slides were laden with text and packet diagrams, so even though 3D glasses were handed out, they didn’t help much. Adding to the frustration was the fact that the presenters, Philippe Biondi and Arnaud Ebalard, spoke with a heavy French accent and most people had difficulty understanding them. Normally when you can’t follow the presenter, you can rely on the slides to help you derive some technical context. Unfortunately this was impossible with this 3D slide deck. All I know is that IPv6 Type 0 Routing Headers are similar to source routing in IPv4 and they aren’t handled consistently across various OSes and hardware vendors. Here’s hoping they publish a legible version of the slide deck because I’m sure there’s some interesting content. I lasted about 20 minutes before walking out of the room with a headache.

Tomorrow looks promising, with presentations from Barnaby Jack, HD Moore, and Luis Miras, as well as a couple talks on Vista.

[Update: Flat version of the IPv6 Routing Headers presentation is online.]

As you may have guessed, I’m out in Vancouver the rest of the week attending CanSecWest. Looking forward to catching up with old friends and former colleagues and meeting more of you lurkers!

I am always overly paranoid about getting owned by 0day at these conferences. My work laptop won’t run Linux cleanly without rebuilding the kernel, and since I don’t have time for that stuff anymore, I’m resigned to running Windows XP. The Windows and BitDefender firewalls are enabled — hopefully they work. My wireless card is physically disabled, and all web and e-mail traffic is being routed either over VPN or through an OpenSSH SOCKS5 proxy. That should do it… or at least make somebody else a more appealing target!

On a semi-related note, why is my BlackBerry acting so flaky here? It won’t even negotiate a full-speed EDGE connection on Rogers Wireless, meaning I can’t use it to browse the web, and e-mail trickles in kind of randomly, whenever it feels like it.

[Update: Maybe it's not just me having BlackBerry issues? Credit: nCircle blog.]

The Web Application Security Consortium (WASC) just published statistics on the prevalence of various web application vulnerabilities. The list was compiled from 31,373 automated assessments performed during 2006 by four contributing companies, with the methodology around data collection described as follows:

The scans include a combination of raw scan results and results that have been manually validated to remove false positive results. The statistics do not include the results of any purely manual security audits (aka human assessments).

As with any statistical data, the results of this study should be digested with a healthy dose of skepticism and a solid understanding of the sampling bias. Take, for example, a political tracking poll conducted by phone during normal business hours. The results of the poll will only account for the opinions of voters with publicly listed phone numbers who happen to be home during the day (and who don’t screen their calls to weed out tracking polls). The sampling bias of the WASC study is that it only accounts for the findings of automated web application scanners. As a result, it primarily reflects the capabilities and limitations of these scanners, not the general state of web application security, as one might reasonably expect from a WASC publication.

Keeping this bias in mind, what does this data really tell us, beyond the fact that automated vulnerability scanners find a lot of XSS? Does it give us true visibility into the actual prevalence and distribution of vulnerabilities in custom web applications? My answer is no.

Let’s look at a sample of the prevalence data:

• 100,059 instances of XSS across 26,531 web apps
• 23 instances of Insufficient Authorization across 4 web apps
• 84 instances of Insufficient Authentication, all occurring in 1 web app
• 426 instances of Path Traversal across 374 web apps

Those numbers just don’t pass the “giggle test.” The category that stands out the most in that list is Insufficient Authorization, a very common vulnerability in my experience. It’s highly unlikely that only four of the applications contain authorization-related vulnerabilities. All this does is highlight the limitations of automated web app scanners.

What about Cross-Site Request Forgery? That doesn’t show up at all on the list, despite the fact that the vast majority of web applications are vulnerable to it (even Jeremiah agrees on this point). It’s not on the list because it isn’t something the automated scanners can detect with any degree of accuracy. For the same reason, several categories on the OWASP Top Ten aren’t even represented, such as Buffer Overflows and Denial of Service.

Now let’s talk about false positives. The methodology clearly states that the data is a mixture of raw scan output and manually validated results. Since the results are presented in aggregate, it is impossible to derive real meaning from the figures without insight into the following information:

• Which results came from which product
• Which results have been manually validated
• The historical false positive rates, by category, for each product

There is also lack of clarity around the definition of “one vulnerability.” Consider this code snippet:

Map params = request.getParameterMap();
PrintWriter pw = response.getWriter();
for (String key : params.keySet())
  for (String value : params.get(key))
    pw.println(key + "=" + value + " ");

An automated scanner might report that as 100 different XSS vulnerabilities, one for each parameter that it fuzzed. However, there is only one actual flaw in the code. This is a simplistic example, but I suspect the inflated XSS numbers are partly due to this type of accounting.

In conclusion, here are the key takeaways from this list, after accounting for all of the weaknesses inherent to the methodology and the data itself:

• Automated web app scanners find a lot of XSS and SQL Injection
• Automated web app scanners are ineffective at finding vulnerabilities that require some understanding of higher-level logic, e.g. Insufficient Authorization or CSRF
• Including raw scan results from a category of products that are notorious for high false positive rates makes the resulting statistics even less meaningful
• The many-to-one mapping of vulnerabilities to actual instances of flawed code artificially inflate the prevalence of certain categories

In other words, this study provides minimal value to a veteran pen tester, and is misleading to just about anyone else.