Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Security Done Wrong: Leaky FTP Server

Update: I’ve just spoken to AMI, and received some very important information; so here are the key points and clarifications:

  • To clarify, the ‘vendor’ I refer to is a customer of AMI; it is this customer’s public FTP server that exposed this information.
  • Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment. It’s not currently known if the customer was following recommended practices.
  • The ‘Ivy Bridge’ code was unmodified, meaning that the customer had not made any alterations to this specific copy.

AMI is preparing a press release. The ‘vendor’ still hasn’t responded (to me or AMI).

Assuming the vendor was following AMI’s instructions, the private key found on the vendor’s public FTP server should have little practical value; though how this vendor was handling keys isn’t known, so the usefulness of the key is also unknown. There is also the possibility of other AMI customers violating AMI’s instructions. We know we have a key; we don’t know how it’s been used.

Publicly revealing the source code still has some potentially interesting implications, even with the assumption that the vendor was following AMI’s instructions on key handling. As this code may be under additional scrutiny from researchers, it’s likely that new flaws will be found that would have been missed otherwise.

Original Article:

A few hours ago I received a call from my frequent research partner, Brandon Wilson, about an open FTP server hosted in Taiwan serving up some rather interesting data. Internal emails, various system images (and even the Ghost software!), numerous photos – some personal, some high resolution PCB images, private specification sheets, Excel documents loaded with private information – but that wasn’t the worst.

In a folder called code was quite a treasure. The source code for different versions of American Megatrends (AMI) firmware – but there was even a bonus on top of that! They included their private signing key with the code in the ‘Ivy Bridge’ archive.

308204A30201000282010100ED71D63F21FF0B4563A43D871D22448FC9...

If you aren’t familiar with how AMI does UEFI firmware upgrades, they were nice enough to produce some documentation (PDF).

By leaking this key and the firmware source, it is possible (and simple) for others to create malicious UEFI updates that will be validated & installed for the vendor’s products that use this ‘Ivy Bridge’ firmware. If the vendor used this same key for other products – the impact could be even worse. Even with a quick reaction, odds are users will be unprotected for some time. As users often don’t install firmware updates unless they are having issues – I expect this one to be around for a while.

This kind of leak is a dream come true for advanced corporate espionage or intelligence operations. The ability to create a nearly undetectable, permanent hole in a system’s security is an ideal scenario for covert information collection.

This vendor’s lax (non-existent?) security could have much broader repercussions though. For AMI, they now have a major piece of intellectual property freely available for download by competitors. For users, this code could now be subject to new scrutiny – if a security issue is found in the firmware, it could potentially impact all users whose firmware is based on the leaked code.

If the code was old, as it’s been when products like Symantec’s were leaked, this might not be so bad – but it’s not.

References in the files indicate that the code is from sometime in February 2012 – so this is fairly current code. For AMI, I hope they perform a security audit of their code to make sure that this leak doesn’t put users at excessive risk.

A foolish oversight now has the potential to impact many.

Adam Caudill


Related Posts

  • Making BadUSB Work For You – DerbyCon

    Last week Brandon Wilson and I were honored to speak at DerbyCon, on the work we’ve been doing on the Phison controller found in many USB thumb drives. This was my first time speaking at DerbyCon – it’s a great event, with a fantastic team making the magic happen. Slides: Video (which I’ve haven’t been able to bring myself to watch): Now that the dust has settled, I would like to provide some updates, thoughts, and extra information – and maybe correct an error I made during the presentation.

  • LinkedIn: The Breach That Isn't but Is

    The definition of a data breach seems to be reasonably straightforward and easy to understand — but that isn’t always the case. LinkedIn is back in the news thanks to a dataset containing profile information for 700 million records being traded among the darker actors on the internet. But LinkedIn is very clear about how they view this situation: This was not a LinkedIn data breach and our investigation has determined that no private LinkedIn member data was exposed.

  • First, Do No Harm: Developers & Bad APIs

    Primum non nocere (first, do no harm) – an iconic phrase in modern medicine, yet also applicable to many other fields. This is something I wish more people would think about, developers especially – and primarily when writing new APIs. In general, developers don’t have an impressive history with security – quite frankly, developers suck. Seeing as I consider myself a developer, that’s painful to admit. Chris Andrè Dale posted an interesting article some time ago that got me thinking: Why it’s easy being a hacker: A SQL injection case study – Chris pointed out the problems with educational material that developers are using, and just how bad the examples are.

  • Evernote: Doing it (mostly) right

    (Update: See here for more information about what they did wrong, including a vulnerability I found in the password handling of the Android app.) So the big news today is Evernote being popped; with 50m users and user base that often stores sensitive material – it certainly is a tempting target for many reasons. Important: Evernote just implemented a service-wide password reset. Please read our post for details and instructions http://t.

  • Win by Building for Failure

    Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?