Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

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.


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.

The Demos #

We did three demos – they were simple enough that I didn’t think there was any risk of having issues. Well, lesson learned.

The machine we used was a fresh Windows install just for the talk – though in the rush, there were a couple differences between it and the machine we had been testing with. In the panic of trying to get the talk done in the short 25-minute slot, I mistook these differences for a failing of one of the demos.

Custom HID Firmware #

The first of the three demos was a completely custom firmware, that presents itself as a HID device (and as a mass storage device, though without media present – this is to make firmware updates easier) – the demo went without a hitch.

I would have liked to show the tools and the update process, though there just wasn’t time. Brandon is working on videos that will be posted to YouTube that walks through each demo step by step.

The team behind the Rubber Ducky saved us a lot of time, thanks to the tools they had built – as we were able to support the same encoded format they used.

Hidden Partition #

The hidden partition is a great patch, as there’s no way to tell that it’s there – everything works as expected, no reason to suspect that anything has been altered.

It divides the NAND space into two partitions, and the firmware lies about the size, to indicate that only half of the space is there. The “public” section is the first that’s mounted, and only a specific action will cause the second, hidden partition to become visible.

It’s a simple change, but it sends a clear message that there can be more than meets the eye with these devices. From a forensics perspective, the only way to ensure that what you are getting is accurate and complete, is to dump the NAND directly – without allowing the controller to access it.

Password Protection Bypass #

This demo seemed to go wrong, but it actually performed perfectly – I was just in too much of a rush to think though what was happening, and why I didn’t see what I expected.

When I plugged the device in, I was expecting to see two drives from it – one “public”, the other unmounted. I only saw one. Two things went wrong here:

  • “Show Empty Drives In Explorer” – By default Windows doesn’t show unmounted removable drives in “My Computer”; this is a setting I always change, and expected to see the unmounted drive. As this was a fresh install, the default setting was still set – the drive was there, I just couldn’t see it. This threw me off.
  • Wrong Password – During the demo I typed in some random junk to the password field of the “Lock” tool, and instead of it unlocking the drive as expected, it gave me the wrong password dialog. The issue here is a bug in the Phison code, when supplying a password more than 16 characters long it treats it as a bad password. So it was working, but the password I supplied was too long, triggering that bug.

We later tested that drive again, and sure enough – it worked flawlessly, as long as the random password wasn’t longer than 16 characters.

The patch works by altering the buffer that stores the data once received over USB; it forces it to 16 “A”s, so that any password will work. Because of how it works, the patch must be applied before the user sets their password – otherwise it’ll just make the data inaccessible.

That was painful.

The (maybe) error… #

During the talk I referred to modes 7 and 8 as being encrypted – this is probably wrong, at least on the devices we demoed. The two modes are password protected, and according to some documentation are encrypted, and according to other documentation they aren’t.

The question came up in a conversation after the talk – we’ve not had the time to dig into this feature more since then, but it’s looking like it’s just a password check with no encryption.

The password changing patch was added at the last minute, to replace another demo that we didn’t like – we identified the USB command being sent, and patched it. Due to time constraints we didn’t dig into the feature to verify the document (from a device manufacturer) was correct; after the question was raised we dug into a little more and looked for other documentation and code to support the claim – it looks like the document we were referencing was incorrect.

So, it looks like I misspoke – the patch still works as expected, though the feature itself seems to provide less protection than we initially thought. Sorry!

The Code & Docs #

We have everything on the repo now, and we’ve added some additional documentation to the wiki.

This isn’t simple to do – the code is complicated to write, and the effort to use the patches and custom firmware is a bit more than I’d like. We’ve tried to document things as well as we can, hopefully it’s easy enough to understand.

Next Steps #

We really hope that releasing this will push device manufactures to insist on signed firmware updates, and that Phison will add support for signed updates to all of the controllers it sells.

Phison isn’t the only player here, though they are the most common – I’d love to see them take the lead in improving security for these devices. They have an opportunity to stand up and protect users – as the most common provider of these controllers, I’d truly love to see them take this as an opportunity to lead the industry.

What we’ve released just scratches the surface of what can be done here – until signed updates are enforced, there’s no telling what games these devices could be playing.

Adam Caudill

Related Posts

  • On The Ethics of BadUSB

    Last Friday, Brandon Wilson and I gave a talk on BadUSB at DerbyCon – I wrote some about it yesterday. Yesterday, Wired published an article on the talk, kicking off several others – only the authors of the Wired and Threatpost articles contacted us for input. There has been some questions raised as to the responsibility of releasing the code – so I want to take a few minutes to talk about what we released, why, and what the risks actually are.

  • phpMyID: Fixing Abandoned OSS Software

    phpMyID is a simple solution for those that want to run their own OpenID endpoint – the problem is that its author stopped maintaining the project in 2008. Despite this, there’s still quite a few people that use it, because it’s the easiest single-user OpenID option available. Unfortunately, the author didn’t follow best practices when building the software, and as a result multiple security flaws were introduced. In 2008, a XSS was identified and never fixed (CVE-2008-4730), in the years since then it seems the software has been below the radar.

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

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

  • Irrational Attribution: APT3.14159

    Note: This is satire / fiction; well, more or less – probably more more than less. Any resemblance to real companies, living or dead, is purely coincidental. WASHINGTON, D.C — Unnamed White House officials that spoke on the condition of anonymity, have stated that a major American company has been hacked, and the attackers are threatening to release terabytes of proprietary information. The name of the company has not been released at this time.