Multiplexed Wired Attack Surfaces

Kyle Osborn and I presented Multiplexed Wired Attack Surfaces at ToorCon 15. This was the second time we gave the talk. The first was at Black Hat USA 2013, but the ToorCon video was posted first.

The basic idea is that connectors on electronic devices are often used in unexpected ways and that some devices, especially phones and tablets, even multiplex several functions onto a single connector. We demonstrated how we are able to access an interactive shell on certain Android phones by connecting a special serial adapter to the phone's USB port; although we were physically connected to the phone via the USB port, we were not using USB.

Similar multiplexed interfaces are present on a wide variety of portable devices, often accessible via USB or headphone connectors. An excellent example using a headphone jack was published earlier this year. We hope that our talk will raise awareness about the attack surfaces presented by these types of interfaces.

The talk at ToorCon was a lot of fun. We got a shell and activated adb on a phone handed to us by a volunteer from the audience. I hope you enjoy the video, but you should also read the paper we wrote for Black Hat.

We've posted links to several resources related to the talk.

Unintended Acceleration, Software, and Sadness

A few years ago I became concerned about reports of sudden unintended acceleration in Toyota vehicles, especially when some of my family members started driving new Toyotas. At first I was skeptical of the reports, but they kept coming. In time, a friend of a friend had a terrible accident, and I was only two trustworthy people removed from a firsthand experience.

I started paying more attention to the reports, and I developed a very strong suspicion that software was to blame. Three simple facts led me to this suspicion:

1. The engine throttle was controlled by software.
2. The brakes were controlled by software.
3. Nobody knows how to make software without bugs.

The first fact surprised me a little. The second surprised me a lot. The third is common knowledge to anyone who has ever developed software, but it may be surprising to those who haven't.

When I first learned how to program in BASIC as a child, I was taught that computers don't make errors; people do. If you write a perfect program, the computer will do exactly what you expect. This is a tantalizingly optimistic view, and it helped me challenge myself to become a better programmer. Unfortunately it is not true.

During those early years my programs were small and simple. Sometimes I could write an entire program in a single page of text. It seemed very possible that programs could be perfectly correct, but somehow they never were. There was always a bug, and almost every time the bug was my own fault. As time went on, I started working on larger and larger software projects, and it became clear to me, as it should to any software developer, that the likelihood of bugs increases when software complexity increases.

This is a Big Problem. It is so big that many of the greatest minds in computer science have devoted their lives to it. Some very interesting progress has been made, but it is still largely an unsolved problem in real-world systems. It is hard to create a program that correctly implements a specification. It is hard to create a correct specification. It is hard to implement a programming language correctly. It is hard to build correct interfaces to other programs. It is hard to build computers that reliably execute programs correctly, especially in environments with high levels of electrical noise like the engine compartment of a car.

By the way, I often use "is hard" to mean "might be impossible".

Not all software is equally buggy, of course. It is possible to create computer systems that are more reliable than others (consider the hardware and software on spacecraft, for example), but it is difficult to do. It is a very different problem than the problem of building reliable mechanical systems.

The problem of software bugs is probably the biggest reason that computer security is so awful. We don't know how to make software without bugs, and bugs tend to undermine security. This is why people in the information security community seem to understand and expect bugs more than most other people; we spend our lives discovering, analyzing, exploiting, and fixing bugs. We find bugs that others miss. We break things that are supposedly unbreakable.

To me, the unintended acceleration reports smelled like buggy software from the very beginning. Few of the reports were identical, but all of them involved the inability of the driver to influence a computer that controls the engine throttle.

Some of the reports agreed on a particular point: Pressing harder on the brake pedal did nothing. This is terrifying to imagine. Your car accelerates rapidly even while your foot is on the brake pedal. You press harder and harder until the pedal is at the floor. Maybe you have time to switch off the ignition or shift into neutral, but how long would it take you to think of that? It might take only a second of unintended acceleration to cause a fatal accident.

At first Toyota denied the problem. Then they recalled floor mats. At the time, I thought that was a pretty stupid response to what seemed like a software bug. Then they recalled pedals. Then they blamed the drivers. They repeatedly said that they couldn't recreate the problem when testing the software (but any software developer knows that an inability to reproduce an error rarely means that a bug doesn't exist).

I started wondering: Have any information security professionals audited the software? Has anyone actually skilled at finding bugs looked for bugs? As far as I could determine, the only people who had tested the software were automotive engineers employed by Toyota. Automotive engineers might not know anything about finding bugs, but they should at least know something about fail-safe design.

To me, the most troubling part of the whole thing was that the brakes and all fail-safe mechanisms were also under computer control. Really? You would make a car with software throttle and also give it software brakes? Don't you know that an automobile is a lethal weapon? Have you never seen software fail? How about a traditional brake system just in case, even if it is only activated when the brake pedal is fully depressed? How about a mechanical linkage that limits the throttle when the driver slams on the brakes?

I can't imagine any engineering culture within Toyota that would fail to consider such things unless it is simply a case of automotive engineers putting too much trust in software because they don't understand software failures. Maybe they tested the things ten thousand times, unaware that they should have tested ten trillion different conditions.

As I became more and more convinced that a software bug was to blame and that nobody was properly looking for it, I started planning a blog post. I considered trying to reverse engineer a car. Even better, perhaps I could convince someone more skilled than me to try to find the bug.

Then the unexpected happened: Tin whiskers were implicated as a cause of unintended acceleration in Toyota vehicles. I had convinced myself that software must be to blame, but suddenly a seemingly plausible alternative arose. I understood tin whiskers well enough to believe that they could explain at least a portion of the failures, yet tin whiskers were just mysterious enough that I didn't question whether or not they might explain all of the failures.

Then I failed. I stopped paying attention after I heard about the tin whiskers. I didn't consider the likelihood of software bugs vs. failures due to tin whiskers. I didn't follow through on making recommendations for mechanical fail-safe (which could prevent fatal accidents regardless of the root cause of the problem). I didn't notice when Toyota denied that tin whiskers caused unintended acceleration. I never went back and reviewed the notably weak software analysis results of the NASA report that first implicated tin whiskers. I ignored the fact that the United States government stopped investigating the problem.

This week I read that a court of law found Toyota's faulty software to blame in a case of unintended acceleration. A software audit for the plaintiff revealed that coding standards for safety-critical software were not followed and that the software is buggy and incredibly complex. The audit even identified a particular failure mode in which a driver could press harder on the brake pedal with no effect, which is as close to a "smoking gun" as we could hope to see. The case clearly indicates negligent software development and deployment practices on the part of Toyota.

This shouldn't have happened if the automotive engineers were appropriately skeptical of software. This shouldn't have happened if the executives were appropriately skeptical of software. This shouldn't have happened if the software engineers were appropriately skeptical of software.

At the very least, the software engineers should have known better. If I were developing software that could kill someone in an error condition, I would feel a moral obligation to tell people about the potential for error. However, as everyone in the information security community knows, developers tend to overestimate the quality of their own code, and very few software developers are skilled bug hunters.

Unfortunately the software source code still has not been made available to the public. We have to trust the analysis of the plaintiff's expert witness (or trust Toyota) to understand how the software works. The details from the expert witness that have been reported, however, seem very credible to me. The jury found in favor of the plaintiff, so Toyota failed to effectively argue against the analysis.

I'm pretty confident in agreeing with the analysis, but it would be nice to be able to verify. If the software were open source, that would be possible. In fact, if the software were open source, others could have done the same analysis years ago and likely would have been able to fix bugs and save lives. How many people will have to die before we decide that open source is as important for safety as seat belts?

I am deeply sad for the people who died in automobile accidents for years before Toyota's negligence was revealed, I am sad for the people who will die in future accidents, and I am sad and ashamed that I never followed through on my own suspicions about the bugs at the heart of the problem.

Appearance on The Amp Hour

In case further evidence is needed to demonstrate that I am a terrible blogger, I submit this: I had a wonderful time as a guest on Episode 161 of The Amp Hour and forgot to mention it here for nearly eight weeks! We discussed HackRF, Daisho, Ubertooth, wireless security, and how I came to the world of open source hardware from a background in information security. Thanks for having me on the show, Chris and Dave!

HackRF is on Kickstarter

I launched HackRF on Kickstarter today. I hope you'll take a look, pledge your support, and spread the word. Thanks for your support!

HackRF LEGO Car

In the Hacker Lounge at Open Source Bridge last week, the well-stocked LEGO table caught my eye. In particular, I spotted an antenna protruding from the pile, and I followed it down to a radio-controlled LEGO car platform! The controller was quickly located, a battery replaced, and I found that it worked pretty well.

The controller was clearly marked with a sticker indicating operation at 27 MHz (FCC ID: NPI71646). That would have been my first guess anyway as it is a very popular frequency for radio-controlled toys. Since several of us were having a HackRF party, I decided to see if I could control the car with my HackRF Jawbreaker.

After verifying that the car worked with the original controller, I recorded several waveforms with the hackrf-transfer utility. I made eight separate recordings, one for each active controller state: forward, backward, left, right, forward/left, forward/right, backward/left, and backward/right.

The recordings were quite clean even though 27 MHz is below Jawbreaker's official operating range (30 MHz to 6000 MHz). In fact, I had captured some apparently good recordings of NFC transactions at 13.56 MHz just the day before. The major drop-off in performance I've observed on Jawbreakers I've tested has been just below 10 MHz.

The first HackRF transmission I tried was by building a small flowgraph in GNU Radio Companion to replay the captured waveforms with my Jawbreaker one at a time. With the car's controller switched off, I was able to make the car move with a simple replay! The best waveform worked at a distance of up to 20 meters even though I put very little effort into cleaning up the waveform or adjusting the power level.

Although I didn't have much time left before I had to catch my flight home, I wanted to see if I could synthesize control transmissions in software on my laptop instead of replaying captured waveforms (that included received noise and minor defects such as quantization and DC offset).

The first step toward synthesizing control transmissions was to analyze the captured waveforms. I found that each transmission consisted of a series of pulses at 27.145 MHz. The pulses were all at the same power level. Each pulse lasted one of two durations and was followed by a pause of consistent length. It looked like On-Off Keying (OOK) with data encoded in the number of consecutive short pulses.

Each transmission featured a repeated pattern of four long pulses (each 1.875 ms long, separated by 0.625 ms pauses) followed by some number of short pulses (each 0.625 ms long, separated by 0.625 ms pauses). The repeated pattern continued for as long as the controller was held in a particular state. The number of consecutive short pulses depended on the state of the controller:

• forward: 10 short pulses
• forward/left: 28 short pulses
• forward/right: 34 short pulses
• backward: 40 short pulses
• backward/left: 52 short pulses
• backward/right: 46 short pulses
• left: 58 short pulses
• right: 64 short pulses

That's as far as I got.

HackRF Beta Distribution

I've been working day and night to test, rework (You don't mind a few scorch marks, do you?), and ship HackRF beta units over the last four weeks. It has been a bigger job than I planned on, but the end is near. I expect to ship the last of the beta units before the end of June. I will have shipped a total of 500 units with more than 200 of those going to people who signed up for the waiting list.

The main reason that it has taken so long is that there has been more testing and rework required than I expected. The test procedure I gave to the contract manufacturer wasn't good enough, mostly because it performed RF tests over the air instead of over a cable with fixed characteristics. Since changing the procedure to operate over an RF cable with an attenuator, I am getting very consistent results. Unfortunately those results aren't always positive, so I've had to do a lot of rework. Plus, I've had to spend a great deal of time running the tests at my kitchen table.

Allergy warning: cats have climbed into boxes full of HackRF Jawbreakers!

I've fallen a bit behind on email while doing all this work, but many of those messages contain frequently asked questions about beta distribution that I will list here:

Q: How many people registered for the beta and how many beta units will ship?

A: I received a total of 2288 registrations. Over 400 units have shipped already. A total of approximately 500 units will ship. About 225 of those will go to people on the waiting list (those who registered without a valid beta invitation code). I wish I could give a board to all 2288 of you, but unfortunately supplies are limited. Still, I am proud to have accomplished such a large give-away of open source hardware.

Q: What are my odds of receiving a Jawbreaker?

A: If you registered with a valid beta invitation code, a beta unit should have been shipped to you already (100%). If you registered without a code, you will receive a Jawbreaker only if you were among the first 11% or so of people who registered. If you heard about beta registration from the GSG-announce mailing list, irc (#hackrf on freenode), or by following me on twitter and acted quickly, you have a good chance of getting a board. If you signed up later without a code, you probably will not get a board.

Q: Will I receive a confirmation email even if I do not get a beta unit?

A: Yes. If you included a valid email address with your registration you will receive an email either way. If a beta unit is shipped to you, I will send you an email that day. As soon as beta supplies are exhausted I will send an email to everyone still on the waiting list letting you know that you will not receive a unit.

Q: How are beta units shipped?

A: I'm shipping all beta units via USPS First-Class Mail or First-Class Package International Service. I realize that this isn't the speediest service for international beta testers and that time in customs can vary greatly, but keeping the cost low is part of how I am able to ship so many total beta units.

Q: What if my Jawbreaker fails?

A: Unfortunately I expect some hardware failures in the field. Even units that passed my improved test procedure might fail in the future. I've already seen (and replaced) one such unit that had a weak solder joint that failed after being shipped to a beta tester. I can't guarantee you a working beta unit, but I will do my best to repair or replace units that fail. If you suspect a hardware failure or have any other technical concerns, post your question or test results to the hackrf-dev mailing list.

Q: When can I buy a HackRF board?

A: I will make an announcement about commercial availability soon. If you want to be among the first to hear about it, sign up for the GSG-announce mailing list.

Giving Away HackRF

The HackRF project has been open source from the very beginning. Even before we started the project, Jared Boone and I wanted to have an open source hardware platform for Software Defined Radio (SDR). Our early prototype designs were published in our repository along with every step of our hardware and software development, and we used open source development tools including KiCad and GCC.

We felt that the world needed an open source hardware design for SDR. GNU Radio had been around for several years, leading a thriving community of open source software development for SDR, but no general purpose SDR hardware designs were available under an open source license. Both Jared and I had started our own businesses devoted to open source hardware development because we felt strongly that open source is simply the right thing to do, and we thought that an SDR peripheral would be an important contribution we could make to the open source hardware and SDR communities.

More than a year later, I am sitting in my lab testing the first sample Jawbreakers from the factory while hundreds more are being assembled and tested. Jawbreaker is the HackRF beta design, and I'm getting ready to ship beta units to as many people as possible. It is a USB-powered SDR peripheral that can transmit or receive virtually any radio signal from 30 MHz to 6 GHz, a range of operating frequencies even wider than our original, ambitious goal.

More than 500 Jawbreakers are being produced right now, and I plan to give nearly all of them away. It is incredibly exciting to be giving people actual hardware in addition to giving away the design! As far as I know, this is the largest beta give-away of any open source hardware project to date. We are thankful for the support of the DARPA Cyber Fast Track program that enabled us not only to develop HackRF in the first place but to produce and distribute so many beta units.

If you would like to participate in the beta program and receive your own Jawbreaker, you can register today. It's free! I distributed beta invitation codes to the attendees of ToorCon 14 and the 2012 GNU Radio Conference last fall. Each of those codes may be used now to register for a spot at the top of the beta list. There are more Jawbreakers than codes, so you can also get on the waiting list for additional units even if you do not have a code. I don't know how many codes will be redeemed, but there is a good chance it will be less than 100%. In order to be fair to the people on the waiting list and to avoid having a large pile of unused Jawbreakers, I established a deadline for the use of invitation codes. The deadline (20 May 2013) is approaching rapidly; if you have any friends who were at ToorCon 14 or the 2012 GNU Radio Conference, this would be a good time to remind them to use their codes!

Benjamin Vernoux, one of the HackRF developers, sent me an enclosure he designed for Jawbreaker, and it fits very nicely. It is based on the Sick of Beige case design from our friends at Dangerous Prototypes. I will not be shipping enclosures with the beta units, but you can download the design and either order one for yourself or make one on your own laser cutter. Don't have a laser cutter? Maybe it's time to make some new friends at your local hackerspace!

Introducing Daisho

At TROOPERS13, Dominic Spill and I presented Introducing Daisho, Monitoring Multiple Technologies at the Physical Layer (video, slides). It was the first public presentation about Daisho, a new project to build an open source hardware platform for in-line monitoring of several different wired communication media at the lowest possible layer. The project targets high speed communication technologies (Gigabit Ethernet, SuperSpeed USB 3.0, and HDMI in particular) for which limited tools exist today.

A basic principle of Project Daisho is that we want to monitor communication media at the physical layer or as close to the physical layer as we are able to achieve. Since any monitoring platform is capable of reconstructing activity at the monitored layer or higher, we think that security applications will be best served by monitoring at the lowest possible layer.

The platform is designed to be used as a pair of circuit boards that work together. (If you look up "daisho" you'll find that it is a word for a pair of swords; our Daisho is a pair of boards.) The mainboard consists primarily of an FPGA and a SuperSpeed USB 3.0 port for connecting to a host computer. The front-end module has a pair of transceivers and connectors for a particular target communication medium. Each target technology will have its own front-end module. Data arriving at one connector on the front-end module are passed to the FPGA on the mainboard and then exit the other connector on the front-end module. This man-in-the-middle architecture allows us to perform in-line monitoring and should also permit future active applications including injection or modification of transmissions on the target medium.

Dominic and I are joined on this project by Marshall Hecht, Jared Boone, Mike Kershaw, and Benjamin Vernoux. It is a big project, and we are thankful to have support from DARPA's Cyber Fast Track program.

The project is entirely open source hardware and software, and it has many potential applications beyond monitoring of communication systems. We're especially excited to be producing the world's first open source USB 3.0 device core for implementation of SuperSpeed USB with a transceiver IC and FPGA. (The USB 2.0 functions are already working!)

Register for the HackRF Beta Test

It is now time to register for the HackRF beta test. Invitation codes that I distributed at ToorCon 14 and at the 2012 GNU Radio Conference may be redeemed for a HackRF Jawbreaker by registering for the beta test. If you do not have a code but would like a beta unit, register without a code and you will be placed on a waiting list for excess units.

I expect the beta units to ship by the end of May. Thanks for your patience, everyone!

Jawbreaker Components Ready to Ship

The last components needed for the HackRF Jawbreaker beta production are now ready to ship to China for manufacturing. Unfortunately some additional delay caused us to run into Chinese New Year (bane of electronics designers), so the parts will not be shipped until after the extended holiday. This means that assembly will start around the end of February. I should have the finished boards in March.

Meanwhile work continues on the software. We have fixed a few bugs and now are able to operate at 16 million quadrature samples per second (and still hoping for a little more). Currently, thanks to Benjamin Vernoux and helpful denizens of our IRC channel, we are fixing some bugs in libhackrf on Windows. Although our primary development focus is on Linux, we hope to support other popular operating systems too.

The delay has given me time to focus on some other projects as well. It is going to be a fun year!

Funtenna!

I just watched Hacking Cisco Phones: Just because you are paranoid doesn't mean your phone isn't listening to everything you say, an excellent presentation by Ang Cui and Michael Costello at 29C3. I particularly liked that they coined the term "funtenna" to describe the potential capability of malware using the off-hook switch in a VoIP phone as an antenna to transmit data over RF.

I appreciate that they credited me with the idea, but I would like to set the record straight. I met Ang and Michael at a Cyber Fast Track event a couple months ago, and they approached me with the idea of exfiltrating data from the phone by toggling a GPIO pin on the embedded CPU at radio frequencies. My only contribution was looking at the hardware and suggesting that the wire extending to the off-hook switch was probably the best candidate antenna for the hack.

Although it hasn't been implemented yet, I think the idea has merit. I don't know how fast a GPIO pin can be toggled on the platform, but the CPU operates at something like 800 MHz. That makes it very likely that the maximum GPIO toggle rate is at least in the tens of MHz, maybe even over 100 MHz. I don't know the resonant frequency of the wire extending to the off-hook switch, but it is probably a few hundred MHz. If my guesses are close, then it is likely that the funtenna could be used to transmit data a short distance, perhaps through a wall or two. It isn't a very good radio, but it should work to some extent. Even a short range wireless transmission is very interesting when it originates from unmodified hardware not intended for wireless operation.

With Ang and Michael's approval, I would like to formalize the definition of "funtenna" a bit: A funtenna is an antenna that was not intended by the designer of the system to be an antenna, particularly when used as an antenna by an attacker. In the case of the Cisco phone, the funtenna could be used to transmit data from the phone. In certain systems, it may be possible to use a funtenna to receive radio signals as well. (I even know of some people working on a way to inject data into an untouched device using nothing but a high power radio signal; it is a very limited capability but theoretically possible.) The field of emission security studies unintentional radio emissions that leak data, and I would call any radiating element (a cable with poor shielding, for example) that leaks useful or sensitive information a funtenna.

Whenever I crack open an electronic device for the first time, I now look for potential funtennas. Maybe you will too. :-)