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

  • Linode: Another Breach Notification Gone Wrong

    Last night I received an email from Linode about a possible breach and mandatory password reset that reminded me of another recent email, in some disturbing ways. Dear Linode customer, Linode administrators have discovered and blocked suspicious activity on the Linode network. Not too long ago, I received a similar email from Evernote – not just in it’s text, but in the errors made. Dear Evernote user, Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.

  • 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.

  • Verizon Hum Leaking Credentials

    or, Christmas Infosec Insanity… A friend mentioned Hum by Verizon, a product that I hadn’t heard of but quickly caught my attention – both from a “here’s a privacy nightmare” perspective, and “I might actually use that” perspective. While looking at the site, I decided to take a look at the source code for the shopping page – what I saw was rather unexpected. Near the top is a large block of JSON assigned to an otherwise unused variable named phpvars – included was some validation code, a number of URLs, some HTML, and the like.

  • Juniper, Backdoors, and Code Reviews

    Researchers are still working to understand the impact of the Juniper incident – the details of how the VPN traffic decryption backdoor are still not fully understood. That such devastating backdoors could make it in to such a security-critical product, and remain for years undetected has shocked many (and pushed many others deeper into their cynicism). There are though, some questions that are far more important in the long run:

  • Much ado about Juniper

    Since this was published, more detailed information has become available: analysis of the SSH backdoor, the VPN backdoor, and the cryptography of the VPN backdoor. If you want a more detailed understanding of what was done, please take a moment to read these pages. The news is tearing through the information security community – Juniper seems to be on the lips of everyone now, let’s take a quick look at the information available: