MacOS X Vulnerability Metrics: Apple vs. The World

Apple dropped a ton of security updates this week and since everybody loves vulnerability metrics, I’m going to join in on the fun also. But unlike seemingly everyone else, I’m not going to compare MacOS X to another operating system and tally up which system had the most critical vulnerabilities this month. I’m going to compare bug hunters: Apple vs. external researchers vs. upstream packages and draw a (hopefully) interesting conclusion.

I have always been fascinated by the number of unattributed vulnerabilities in Apple’s security update notices, which I am assuming are internally identified vulnerabilities (Apple Product Security, perhaps?).  Apple is pretty unique in this regard, most closed-source software vendors don’t issue security updates for internally identified vulnerabilities in shipping products. So we have to either assume that everyone else is only fixing the vulnerabilities in the development branch of their next release or they aren’t even looking. Software, especially critical software connected to the Internet, is not the Ronco Showtime Rotisserie: You can’t just “set it and forget it.”

So let’s see how they stack up for the year so far. My methodology is simple. Count vulnerabilities by CVEs, eliminate duplicates, and tally up which vulnerabilities were: unattributed, credited to an external researcher, or fixed as part of Apple updating an externally developed part of MacOS X to a newer version. Although WebKit is an open source project, I considered it Apple code so vulnerabilities fixed in it are counted as either internally or externally found vulnerabilities.

The 2008-003 update had 41 security updates: 12 of which were internally identified, 10 reported by external researchers, and 19 vulnerabilities fixed in upstream software packages. The 2008-002 update was a whopper with 20 internally identified vulnerabilities, 8 externally reported, and 62 (!) in upstream packages. The relatively petite 2008-001 update had 3 internally identified vulnerabilities, 5 externally reported, and 3 from upstream packages.

I counted up all of the Apple Security Updates (including iPhone, AirPort, etc) for the year and the grand totals were:

  • Internal: 44
  • External: 53
  • Upstream: 84

This brings me to my guess as to what Apple is doing and my advice to software vendors: You should be finding and fixing at least as many vulnerabilities in your shipping products as external researchers are. There is no reason that you can’t keep up, you have the source code and they don’t.  Only finding and fixing vulnerabilities in development for future releases and treating external vulnerability reports like other bug reports (customers X have issue Y w/ product Z) is a bad model for security vulnerability response when “customers X” are 98% of Internet users, “issue Y” is remote code execution, and “product Z” is Flash.

Flash Zero-Day Attacks WoW

Right now there are a number of reports about a lethal Internet cocktail: an zero-day Adobe Flash exploit and widespread (20,000 domains at the time of writing) domains compromised via SQL injection to spread the drive-by-download attack.  It feels like one of those days when you tell your friends to take a day off from using the Internet.

I was forwarded some links to the exploit and its payload by Ryan Naraine and spent a few hours reversing the exploit, its payload, and the malware that it downloads.  It turns out that the whole attack just steals World of Warcraft passwords, which would have been nice to find out 4 hours ago when Ryan posted it, but I was having fun in IDA Pro instead of Twitter-land and pagination is disabled on the website and I missed it.

Anyway, here is a quick walkthrough:

  1. The flash.swf file exploits an unpatched vulnerability in Flash (UPDATE @ 20080529: It turns out that it was not an unpatched vulnerability, but a vulnerability that was fixed in the Flash 9.0.124.0 update released on April 8th)
  2. The exploit payload uses familiar techniques to lookup API functions by a 32-bit hash value, and uses URLMON.DLL to download an executable to C:\6123t.exe and runs it.
  3. The downloaded executable disables Kaspersky Anti-Virus (what, they don’t have any others in China?) extracts a UPX-packed DLL (Ow.dll) from its resources segment and loads it as a keyboard hook DLL.
  4. The keyboard hook targets World Of Warcraft and uploads captured information to the attacker’s server disguised as HTTP requests.

Overall, nothing too complicated, but there are some funny bits where the downloaded executable calls a ton of GDI functions to retrieve various values and does nothing with the results (am I missing something here?):

CODE:00401714 push 0 ; dwFlags
CODE:00401716 push 0 ; lpSig
CODE:00401718 push 0 ; hdc
CODE:0040171A call GetTextCharsetInfo
CODE:0040171F push 0 ; hdc
CODE:00401721 call GetFontLanguageInfo
CODE:00401726 call GetDoubleClickTime
CODE:0040172B push 0 ; bPrevious
CODE:0040172D push 0 ; hCtl
CODE:0040172F push 0 ; hDlg
CODE:00401731 call GetNextDlgTabItem
CODE:00401736 push 0 ; color
CODE:00401738 push 0 ; hdc
CODE:0040173A call GetNearestColor

Still 20k sites were compromised, a reliable Flash zero day exploit was burned, and the threatcon was raised to steal WoW passwords? I know that the size of the WoW economy rivals many nations, but I still find it somewhat strange.

UPDATE @ 20080528: The Adobe PSIRT is now reporting that the vulnerability is not zero-day, but is in fact a different exploit for the recent vulnerability reported by Mark Dowd.  The exploit that I looked at appeared somewhat different in structure from Dowd’s, but it does use the same corrupt DefineSceneAndFrameLabelData tags and DoABC ActionScript bytecode tags.  It looks like I jumped the gun on this one and it is actually just a different exploit for the same vulnerability.  I have also just found a much more thorough analysis and description of the same exploit that I was looking at on the ThreatExpert blog.

Debian’s Predictable PRNG and Cloud Computing

As the details of the Debian OpenSSL weak PRNG vulnerability came to light, I saw HD Moore’s Debian OpenSSL Predictable PRNG Toys and wondered how quickly I could generate the same for SSL certificates.  I had also been itching to take Amazon Web Services out for a spin, so it seemed like the perfect opportunity to do so.

Amazon Web Services is best described as a “cloud computing platform.”  Like competitors such as Google’s AppEngine, the main idea is that your application runs in an off-site hosted virtual environment.  Unlike Google’s AppEngine where the application developer must develop to Google’s Python APIs, Amazon’s services are based on language neutral Web APIs and hosted applications run within Xen virtual machine instances.  With Amazon Web Services, you get

  • Elastic Compute Cloud (EC2) – Dynamically launched Xen images with 1 32-bit core, 2 64-bit cores, and 4 64-bit core virtual machines.
  • Simple Storage Service (S3) – Remote storage of unlimited objects up to 5GB allowing download over HTTP and BitTorrent.
  • Simple Queue Service (SQS) – Reliable remote queued messaging.
  • SimpleDB (SDB) – A minimal database for storing structured data and supporting a SQL-like query language.

I used an SQS queue to distribute key generation tasks, 20 EC2 worker instances to generate keys, and an S3 bucket to store the generated keys.  As a simple benchmark, generating all 1310721 possible 1024-bit RSA keys on a 32-bit little endian system took somewhere around 45 minutes.

The design of my system was simple. My local workstation at home would be the controller that divides up the keyspace and populates the SQS work queue with messages indicating the units of work that need to be performed, launches EC2 instances as needed, and monitors the status of running instances. Each EC2 worker job would pull units of work off of the queue until it was empty, store the results in S3, and then shut the virtual machine down once it finished.

EC2 lets you launch pre-configured virtual machine images and, as one may expect, they had a number of Debian-based images with the weak OpenSSL PRNG already. I scripted up a key generating worker job based on HD’s getpid() faker and tested my code on a local VM running an Ubuntu LiveCD and a single EC2 instance. I spent a few hours building ad-hoc scripts using RightScale’s AWS Ruby Gems to push, run, and monitor jobs on EC2.  I launched 20 instances (the default quota) and finally went to sleep for the night.

In the morning, I had all of the 1024, 2048, and 4096-bit keys generated for the default public exponent of 65537 generated.  It turns out that 4096-bit keys are very rare2, so you only really need the 1024 and 2048-bit keys.

So, in summary:

  • 20 EC2 instances generating Debian weak RSA keys: $16
  • A few thousand SQS operations: $ 0.06
  • Transfers between EC2 and S3: $ 0.00
  • Downloading 500 MBs of compressed RSA keys from EC2: < $ 0.01
  • Having your RSA private key: Priceless.

Footnotes:

1. 32768 PIDs * 2 different public exponents * whether ~/.rnd exists

2. Lee, Homin K., et al. “Cryptographic Strength of SSL/TLS Servers:
Current and Recent Practices.”
ACM Internet Measurement Conference, October 2007.

Follow

Get every new post delivered to your Inbox.

Join 3,863 other followers