Pwnie Award Winners and Video Posted

Congratulations to all of the nominees and winners of the 2008 Pwnie Awards.  We had a much larger turnout for the ceremony this year and we actually had people present to accept their awards and give acceptance speeches.

In case you missed the awards, you can see the list of winners at the Pwnie Awards site.  Or get yourself some fresh popcorn, a cold beer, and some nice buggy code to relax and watch the video that Alex Sotirov just uploaded today.  Be sure to mock the guy with the “I 3> Pwnies” t-shirt.

Vegas, baby, Vegas

It’s that time again.  It’s 110 degrees in Las Vegas and if that wasn’t causing the locals enough worry, the yearly invasion of hackers this week certainly will.  Expect to see more humungous LCD displays blue screen and guys walking around in the heat wearing black leather trenchcoats (that’s dedication!).

Anyway, it looks like there will be a lot of cool stuff happening at BlackHat, and here are some of the talks and events that I am looking forward to on Day 1:

Anyway, if anyone is trying to hunt me down, DM me on Twitter.

Evolution is Punctuated Equilibria

In evolutionary biology, the theory of punctuated equilibiria states that evolution is not a gradual process but instead consists of long periods of stasis interrupted by rapid, catastrophic change.  This is supported by fossil evidence that shows little variation within a species and new species that appear to come out of nowhere.  These changes are found to occur in small groups on the periphery of the central population where selection pressures are higher and often in response to changes in the external environment.  Eventually those peripheral groups replace the dominant species in an abrupt change.  While this theory has also been applied to the social sciences and business, it also applies to Internet security.

In the late 80′s, it was the “summer of love” era on the Internet.  Research institutions and universities were freely connecting to each other in a way that would make anyone of modern Internet sensibilities blush.  Internet sites regularly engaged in risky behavior, including exchanging traffic without the use of a protective firewall to protect against accidental infections (as such things were rare in those days).  Most users used weak passwords and some (Richard Stallman, notably) used none at all.  And then, just like in the Guns N’ Roses music video, the party was unceremoniously ended in the sudden cold November rain.  The Morris Worm swept through the Internet, taking machines down faster than anyone could imagine.  The era of innocence and non-disclosure of security vulnerabilities on the Internet had come to a close.

After the Internet worm, a variety of organizations were quickly established in order to track and address vulnerabilities in the Internet infrastructure.  The Computer Emergency Response Team (CERT) was established to handle any similar situations and a variety of mailing lists such as Phage, the Zardoz Security Digest, and Core Security Mailing List were established to discuss and track security vulnerabilities.  All of these lists and groups, however, were closed communities and the CERT security advisories were light on details in fear that revealing full details would enable attackers.  Thus began the era of partial-disclosure of security vulnerabilities.

A small full-disclosure movement began to grow on the periphary of the Internet.  This community believed that CERT was doing the community a disservice by not pressuring vendors to address vulnerabilities and revealing full information because system administrators were not able to determine whether they were vulnerable or not and should take the potentially disruptive risk of patching security vulnerabilities.  With full-disclosure, all parties are notified of the vulnerability at the same time.  Vendors are pressured to address serious vulnerabilities quickly and users have enough information to decide whether they should work around the vulnerability and/or apply the patch when it becomes available.  This community was centered around the Bugtraq mailing list.  This community quickly grew through the mid 90′s and early 2000′s until it became the dominant method of vulnerability disclosure on the Internet.

If the late 80′s was the era of free love on the Internet, the late 90′s and early 2000′s was the era of free exploits.  Fully working exploits for serious vulnerabilities were regularly published on Bugtraq often as part of the disclosure of the vulnerability.  These were often remote privileged code execution exploits in serious Internet infrastructure like BIND, SSH, NCSA HTTPD, Sendmail, and Apache.  These exploits allowed administrators to easily test if they were vulnerable or not.  If they ran the exploit and they got a remote shell, they were definitely vulnerable.  Similarly, if someone wanted to take joyrides on the Internet, all they had to do was subscribe to Bugtraq, wait for an exploit to be posted, and then start scanning for vulnerable machines.  Thus were “script kiddies” born.  This environment continued through the early 2000′s.

The early to mid-2000′s could be considered the hangover from the free love 80′s and free exploit 90′s of the Internet.  Instead of Internet worms being a one-time event, they became an almost regular occurrence with ILOVEYOU (May 4, 2000), Code Red (July 13, 2001), Code Red II (August 4, 2001), Nimda (September 18, 2001), SQL Slammer (January 24, 2003), Blaster (August 12, 2003), and many others in between.  Many of these worms used exploits that had been posted publicly to Bugtraq to spread.  Clearly something was not right.  This onslaught of Internet-crippling worm outbreaks quickly brought about several evolutions in Internet security: “responsible” disclosure, the home router firewall, and Microsoft’s Security Push and Secure Development Lifecycle (SDL).  It was no longer enough to respond to security vulnerabilities and incidents as they happened; Internet security required proactive measures to protect against future disasters.

From 2003 until roughly the present, “responsible” disclosure and the duality of offensive security research and defensive security products have driven the security industry forward.  Security researchers have investigated and discovered volumes of security weaknesses, vulnerabilities, and attacks.  All of these have required security patches, restructuring, and risk mitigating technologies née product opportunities: anti-virus, firewalls, intrusion detection/prevention, patch management, etc.  Hundreds of vulnerabilities have been “responsibly” disclosed and patched.  Patching has become a monthly Shamanistic ritual for most IT departments.  There are now defensive security products to defend against every possible perceived security threat (imagined and real).

With all of this, Internet malware has only become more prevalent on users’ systems.  The United States Departments of Commerce, State, and Defense, have sustained targeted attacks and on multiple occasions detected large amounts of sensitive information being remotely extracted from their networks.  There is a serious DNS cache poisoning vulnerability that currently affects 50% of the nameservers on the Internet, almost a month after the issue has been disclosed throughout the tech and mainstream media and a week after a highly-effective exploit for it has been publicly released.  The Internet security community is holding its breath waiting for (hoping for?) widespread attacks, perhaps to justify their continued existence.

Clearly, we are not any closer to securing the Internet, if that is even possible.  If anything, the dangers on the Internet have gotten worse as the malicious actors have changed from joyriding teenagers to Internet worms to espionage and organized crime.  Right now, Internet security is due for another period of rapid change.

UPDATE @ 20080729: As pointed out in the comments below, the “cybercrime is bigger than drugs” figure is bogus.  I have removed it and instead used a reference to Microsoft’s latest Security Intelligence Report showing a general growth in malware.

Crippling Crypto: The Debian OpenSSL Debacle

This weekend at The Last HOPE, Jacob Appelbaum, Karsten Nohl and I gave the following presentation on the Debian OpenSSL weak PRNG vulnerability.

In May 2008, a weakness in Debian was discovered which makes cryptographic keys predictable. A Debian-specific patch to OpenSSL broke the pseudo-random number generator two years ago, which led to guessable SSL and SSH keys. The vulnerability allows for impersonation of secure servers, as well as the potential to login to SSH secured systems. Since many popular derivatives like Ubuntu and Xandros are affected, the weak keys are found all over the Internet. The panel will present their approach to generating lists of weak keys using cloud computing and explain how they collected large numbers of SSL certificates of which several thousand are weak.

Presentation materials:

  • Slides
  • Forthcoming: Weak RSA keys
  • Forthcoming: Patch to ssldump to decrypt SSL traffic if the remote site has a weak RSA key and RSA key agreement is used

Pwnie Nominees Announced

Finally, the moment that everyone has been waiting for: the announcement of the nominees for the 2008 Pwnie Awards.  After receiving 134 submissions, we have painstakingly narrowed down the submissions to 37 nominees across 9 award categories.

The awards ceremony will be held on Wednesday, August 6 at 6:00pm in the Palace 2 ballroom at Caesar’s Palace.  Before the ceremony, the Pwnie Judges will meet in an undisclosed location and vote on the nominees to determine the winners.

Congratulations to all the nominees and we hope to see everyone in Vegas!

Pwnie Award Nominations Close Today

This is just a friendly reminder that the nominations for the Pwnie Awards close today.  You can nominate your peers for the following categories:

And of course, please come join us for the Pwnie Awards Ceremony at the BlackHat Briefings USA Conference on Wednesday, August 6th.

Dan Kaminsky Disqualified from Most Overhyped Bug Pwnie

I can be pretty skeptical and cynical at times (part of what drives my interest in security) and I am especially skeptical of massively hyped vulnerabilities. If anything, I tend to underhype what I do and let others hype it for me if they think that it warrants more attention.

With all of the hype around Dan Kaminsky’s DNS vulnerability, I naturally doubted that all of the hype was warranted.  I was flattered, however, when Rich Mogull called and invited me onto a conference call with Dan Kaminsky and the other Doubting Thomas (Ptacek, that is).  Dan explained the full details and scope of his attack and both of us were impressed and agreed that it is way more serious than we had imagined.  Yes, I am being light on the specifics here because I was sworn to secrecy and if I were to break it, Dan would cause my nameservers to rickroll me until the end of time.

In summary, when the full details of Dan’s attack come out, you will most likely be impressed.  I definitely was.

ARDAgent.app Vulnerability Analysis

Apple recently released Mac OS X 10.5.4 with accompanying security updates for 25 vulnerabilities.  Notably absent, however, is a fix for the recently brouhaha’d ARDAgent.app local privilege escalation vulnerability.  The exploit is extremely simple and unfortunately, it seems that the fix is not; otherwise Apple would have fixed it in this batch.  For more information on the exploit including temporary fixes and workarounds to protect yourself until Apple fixes this vulnerability, see the full write-up at MacShadows.com.

In the interest of fully understanding Mac OS X security issues, let’s dive in and see how this vulnerability works.  As a reminder, the vulnerability is that ARDAgent.app, a set-user-id root executable, responds to the “do shell script” Apple Event, effectively running arbitrary commands as root.

Applications must announce that they can receive Apple Events before they may be scripted.  In Cocoa applications, this is done by setting the NSAppleScriptEnabled property to “YES” in the application bundle’s Info.plist file.  In Carbon applications, an application is made scriptable by simply calling the AEInstallEventHandler() function.  AEInstallEventHandler() lets the application define which Apple Events it can handle and supply the handler functions for them.

ARDAgent.app did not do anything special in order to respond to the “do shell script” Apple Event, this event is defined in the StandardAdditions Scripting Addition in /System/Library/ScriptingAdditions.  Scripting Additions are dynamic libraries (dylibs) that will be loaded automatically by the Apple Event handler if the application receives an Apple Event that is defined in them.  There are several Scripting Additions in /System/Library/ScriptingAdditions, but they may also potentially be found in /Library/Scripting/Additions or ~/Library/ScriptingAdditions.

Interestingly, ARDAgent.app calls AESetInteractionAllowed() with kAEInteractWithSelf after installing its own Apple Event handlers which is supposed to restrict the processing of Apple Events to only those sent by the process itself.  It obviously does not seem to have its intended effect in this case.

This is a pretty isolated vulnerability not a massive security hole in AppleScript.  Set-user-id executables should not be scriptable and ARDAgent.app appears to be the only application that violates this.

UPDATE @ 20080704: As mentioned in the MacShadows security forums from the link in the comments below, SecurityAgent is also susceptible to this, but only when SecurityAgent is running with increased privileges (after a sudo, unlock of System Keychain, etc). But this is not because SecurityAgent is setuid, it is because it still receives Apple Events when it runs with increased privileges. It doesn’t, however, appear to call any Apple Events functions. So I am not sure why it is processing Apple Events (handled in a base framework?). If anyone knows why, let me know.

UPDATE @ 20080705: I have poked around at this a bit more this weekend, and it turns out that an application does not need to call any Apple Events APIs in order to receive and process Apple Events.  While Cocoa applications must set the NSAppleScriptEnabled property, any Carbon application automatically handles Apple Events.  At the lowest level, Apple Events are sent over Mach ports looked up from the bootstrap server, so you need port send rights in order to send it Apple Events.  This means that a client will not be able to send events to an application running as a different user unless it is setuid/setgid (ARDAgent) or is run with increased privileges, but still checks its ports in with the bootstrap server (SecurityAgent, which is launched by securityd with gid=0 on Tiger in certain situations).

ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My!

As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on MacOS X Tiger and Leopard.  While Intego calls this a critical vulnerability, I’m mostly with Ptacek on this one where I am saying this vulnerability is not nearly that serious.  For one, it only works when it is run as the user who is logged into the console.  This means that no MacOS X servers are affected by this, but it can allow a web exploit or trojan horse to gain root access without the user’s knowledge or permission.  Also while root access is pretty serious, it is not necessary in order for the malware to do bad things to your system (i.e. install itself to run automatically, backdoor Safari, etc).  So I will dub this a serious, but not critical, vulnerability.

Perhaps the most interesting fact about this vulnerability is where it came from: a  thread (from Google cache because the forums seem to be down now) on the forums at Mac Shadows, a mac underground web site.  The aforementioned thread was discussing how to build AppleScript-based trojans until “callmenames” discovered the vulnerability and the discussion moved towards the vulnerability and ensuing news and attention.  And at the time of writing, the forums on the site have been taken offline.

The big question on everyone’s mind is when malware will begin to seriously affect MacOS X and what will happen when it does.  As for when, I am betting that it completely depends on market share, as per Adam O’Donnell’s game theoretic analysis.  As for how bad, that will all depend on Snow Leopard: when it will ship, how it will improve MacOS X security, and how many users will install it.

Snow Leopard will hopefully raise the bar for MacOS X as much as Vista did for Windows.  Of course it won’t stop all security attacks, but it should make exploiting them beyond the reach of most attackers.  I’d personally like to see the following improvements:

  • Real address space layout randomization.  Library randomization with dyld loaded at a fixed location just doesn’t cut it.
  • Full use of hardware-enforced Non-eXecutable memory (NX).  Currently, only the stack segments are enforced to be non-executable.  Welcome to the new millennium where buffer overflows aren’t only on the stack.
  • Default 64-bit native execution for any security-sensitive processes.  I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process.  Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
  • Sandbox policies for Safari, Mail.app, and third-party applications.  Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications.  I love the scheme-based policies, by the way.
  • Mandatory code signing for any kernel extensions.  I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk.  Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate. 

I’m hoping that Snow Leopard ships before we see too much Mac malware, fixes all of the above, and that it is a free upgrade.  Yes, I know that’s unlikely, but users will not pay money for security features.  When users don’t upgrade and are subjected to malware, Apple may still get a bad rap for it.

Pwnie Awards Nominations Open

It’s about that time of year: the days when a young man’s thoughts drift from work and toil to lighter things. Like pwnies. No, not the Lisa Simpson kind of pony, but the 2nd Annual Pwnie Awards at BlackHat USA.

The pwnie awards are an annual awards ceremony to celebrate the successes and failures of the security research and larger security community. Check out the site for more info and send in your nominations. Please submit nominations for vulnerabilities or research disclosed between June 1, 2007 and May 31, 2008 and the nominations will be announced on July 14th.

And make sure to come to the ceremony to enjoy the stand-up comedy, musical performances, and exquisitely handmade gold-painted My Little Pony dolls (with little imperfections so that you know they were made by a real-live Pwnie Judge).

Follow

Get every new post delivered to your Inbox.

Join 43 other followers