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!

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. :-)

Announcing the HackRF Beta

Jared Boone and I had the honor of presenting the keynote at ToorCon 14 over the weekend. In our talk, HackRF: A Low Cost Software Defined Radio Platform, we described our project to build a low cost, open source, wideband, portable Software Defined Radio peripheral. You can watch video of the presentation or download the slides.

In addition to introducing HackRF to the ToorCon audience, we announced the HackRF beta test program. Thanks to DARPA's Cyber Fast Track (CFT) program, we are able to build a few hundred HackRF Jawbreakers and will distribute them to ToorCon attendees as soon as they are completed (hopefully around December). Each attendee of ToorCon 14 (and also the recent GNU Radio Conference) received a unique beta invitation code that can be redeemed for a Jawbreaker as soon as the hardware is ready to ship.

Jared and I are very excited to be able to give away so many beta units. I'm not sure if any open source hardware project has had such a well funded beta program, but we think that giving away hardware in exchange for feedback (and hopefully some code) is a good trade in keeping with open source ideals.

If you have an invitation code, look for an announcement on the HackRF page around December telling you how to redeem your code for a Jawbreaker. I know there are many of you out there who wish you had an invitation code, and I'm sorry that our funding for the beta program is finite! The redemption system, once it is live, will include a way to sign up for a waiting list if you do not have a code. There will probably be some extra beta units that we will distribute to as many on the waiting list as we can.

My hope for the beta program is to validate HackRF Jawbreaker, resulting in a well-tested open source design that anyone can build or modify. I also plan to release a commercial HackRF product (similar to Jawbreaker) that will be available for purchase after the beta.

Thanks for all the kind words of support at ToorCon and since!

Programming Pink Pagers in Style

After two and a half years of programming the IM-Me by soldering wires to the test points in the battery compartment, I finally got around to making a GoodFET/IM-Me spring pin adapter. I call it GIMME. Now I can install my spectrum analyzer application or any other firmware onto an IM-Me by simply removing the batteries and pressing the GIMME against the test points while the attached GoodFET does all the tricky stuff. GIMME is designed with KiCad. You can find the design files in the contrib directory of the GoodFET repo.

To mark this occasion, I decided it was high time to post the video from my talk with Travis Goodspeed at ToorCon 12, Real Men Carry Pink Pagers. It was probably the most fun I've ever had giving a talk at a hacker con. Maybe it was the song. Maybe it was the bourbon in pink shot glasses. Maybe it was the total lack of preparation resulting from Travis injuring himself the day before. Maybe it was the ridiculous T-shirt Nick DePetrillo made me wear. (I still haven't figured out how to get him back. I don't believe it is possible to embarrass the man.)

With ToorCon 14 coming up, I decided to have several GIMME PCBs made to give away. If you see me at the con this weekend and would like one, just ask. I also took it upon myself to make some GoodFET41 boards since Travis won't be around being his usual Johnny Appleseed of open source hardware. Plus, I will have a GIMME and GoodFET available to borrow, so bring that IM-Me that has been sitting in a drawer with factory firmware!

Introducing HackRF

I'd like to take a moment to properly introduce the project that is consuming most of my time this year: HackRF, a software radio peripheral. Software radio or Software Defined Radio (SDR) is the application of Digital Signal Processing (DSP) to radio waveforms. It is analogous to the software-based digital audio techniques that became popular a couple of decades ago. Just like a sound card in a computer digitizes audio waveforms, a software radio peripheral digitizes radio waveforms. It's like a very fast sound card with the speaker and microphone replaced by an antenna. A single software radio platform can be used to implement virtually any wireless technology (Bluetooth, GSM, ZigBee, etc.).

Digital audio capabilities in general purpose computers enabled a revolution in the sound and music industries with advances such as hard disk recording and MP3 file sharing. Today's computers are fast enough to process radio waveforms in similar ways, and the radio communications industry is going through the same sorts of changes. One critical advance has yet to take place, and that is the availability of low cost tools enabling any computer user to take part in the revolution.

HackRF project goals:

• transmit and receive
• operating frequency: 100 MHz to 6 GHz
• maximum sample rate: 20 Msps
• resolution: 8 bits
• interface: High Speed USB
• power supply: USB bus power
• portable
• open source hardware and software
• low cost

There have been some exciting developments in the world of low cost software radio hardware in recent months, but the HackRF project will go much further. A key advance will be the ability to transmit as well as receive radio signals, and HackRF will also enable operation at higher frequencies, including the popular 2.4 GHz band. Most importantly, HackRF is an open source project, so people will always be able to use and modify the hardware design and software in the future. We are being very careful to only use electronic components with published documentation (no NDAs!) and to avoid software libraries without open source licenses. This means more work for us, but we think that it will be worth it in the long run.

Speaking of us, I should mention that I have some help on this project. My primary partner in this effort is Jared Boone of ShareBrained Technology (who has already written a bit about some of our development challenges). We've had some additional help from a few other people who hang out in #hackrf on chat.freenode.net, notably Benjamin Vernoux.

Ultimately, the HackRF project aims to produce a single device that meets the goals above, but right now it consists of multiple development boards that connect together. The microcontroller, USB interface, and power supply are on the largest board called Jellybean. The Intermediate Frequency (IF) transceiver, Analog to Digital Converter (ADC), Digital to Analog Converter (DAC), and clock generator are on a board called Lemondrop. Most recently, a wideband front-end called Lollipop is being tested. HackRF is based on a dual conversion architecture with a high IF (between 2.3 and 2.7 GHz), allowing us to take advantage of the excellent capabilities (per size, cost, and power consumption) of a wireless transceiver IC.

I have used software radio techniques for wireless security research for years, and I teach a workshop each year at ToorCon San Diego to help more people in the information security community become familiar with the technology. Both for my own use and to promote wireless security research, I have long dreamed of building a low cost, portable platform. Now, with support from DARPA's CFT program, I am finally able to make this project a reality.

Personally, I want a single device that can fit in my laptop bag, that doesn't require a bulky power supply, and that I can use to hack on whatever wireless systems I encounter. I'm hoping it will be about the size of a portable USB hard drive, and it will probably end up with a retail price in the neighborhood of $300, higher than technology-specific solutions like Ubertooth One but much less than any software radio transceiver on the market today.

The project is going well, and we are likely to meet most or all of the goals. If there is one we miss, it will probably be the operating frequency range. 100 MHz to 6 GHz is quite ambitious! At the very least, we will produce a platform that allows operation over a wide range including both the 2.4 GHz and 900 MHz bands.

HackRF is being developed on github. Documentation is coming together slowly on the wiki.

Bluetooth for Bad Guys

Criminals have been skimming debit and credit card information by tampering with point of sale terminals, PIN pads, gasoline pumps, and ATMs for quite a while now. The first time I heard of Bluetooth being used in such cases was from this SparkFun Electronics news blurb a couple years ago. Malicious hardware installed in a Canada retailer's PIN pad intercepted customer data and transmitted it via Bluetooth to the attacker's device, perhaps a laptop in a nearby parking lot. At the time it seemed like a clever use of the technology by a Canadian ne'er-do-well but probably not the start of a trend. I was wrong.

As Joshua Wright recently pointed out, Visa is informing merchants about similar crimes that took place around the same time in Utah. Skimmers have also been found in Florida and elsewhere. Just this week, customers of Lucky Supermarkets in California found out that a similar attack was the reason their bank accounts were recently drained. This isn't just one clever crook; this is a criminal industry at work.

The technical reasons that Bluetooth is an attractive technology for this application are nicely outlined in Joshua's article, but we wouldn't see so many actual attacks were it not for commercial availability of Bluetooth skimmers sold on the criminal underground. There is an industry producing hardware for crime just as there is an industry producing software for crime.

How can you protect yourself as a customer? The best advice I can think of is to consider the liability of payment methods. There is a reason I like to carry some cash. There is also a reason I strongly prefer to use a credit card over a bank debit card. With a credit card (in the US, at least), the financial institutions and merchants bear most of the burden of liability. As long as I check for unauthorized transactions before paying my bill every month, I don't have much to worry about. Once, many years ago, someone emptied my checking account. I figured out what had happened and managed to convince my bank that the bank's own misguided security practice had allowed it to happen, but guess who bore the burden of a zero balance until that was resolved?

How can you protect yourself if you are a retailer or financial institution? This is a much more difficult problem. For starters, you should read Joshua Wright's article and the Visa bulletin. Josh has some nice things to say about my Project Ubertooth, but he also has some criticisms, mostly pointing out features yet to be developed. The first item on his wish list is frequency hopping, something I am working on now. He also points out the need to improve Bluetooth device fingerprinting, an area of research that has been advanced in recent years primarily by JP Dunning.

When I read about real life attacks on retailers and customers, sometimes I imagine how I could use technology to catch the crooks. Frankly, it would be hard, and it would be especially hard to deploy tools that would allow more investigators to do the same. Bad guys are using Bluetooth (and potentially other wireless technologies). We need Bluetooth tools for the good guys too.

I guess, if there is a lesson to be learned from all this, it is that hardware security matters. If an attacker can get in between a user and a system, the security of the system will fail in almost any case. Advocates of the Bring Your Pwn Device (BYOD) trend might want to pay attention. (That was an honest typo, but I decided to keep it!)

comments on SP 800-121 Rev 1 draft

The following is an email I sent to NIST in response to a request for comments on the draft Guide to Bluetooth Security (NIST Special Publication 800-121 Rev. 1).

Thank you for your efforts to produce and update SP 800-121! Although I have some criticisms, your document is important and unique.

My principal concern about the guide is that the recommended practices are too weak to support the safe use of Bluetooth. Looking at the SP 800-153 draft (Guidelines for Securing Wireless Local Area Networks), I see several recommendations listed in the Executive Summary that would be just as applicable to Bluetooth:

"When planning WLAN security, consider the security not only of the WLAN itself, but also how it may affect the security of other networks."

"Have policies that clearly state which forms of dual connections are permitted or prohibited for WLAN client devices, and enforce these policies through the appropriate security controls."

"Ensure that the organization's WLAN client devices and APs have configurations at all times that are compliant with the organization's WLAN policies."

"Perform both attack monitoring and vulnerability monitoring to support WLAN security."

"Conduct regular periodic technical security assessments for the organization's WLANs."

My second concern is that it is unclear how to implement many of the recommendations. Unfortunately this is more a problem with Bluetooth itself and the available tools than with your document. Along with others in the information security community, I am working to develop Project Ubertooth into a tool that will bridge the gap as much as possible, but more needs to be done.

Third, I have some specific comments and criticisms:

It is incorrect to say that Frequency Hopping Spread Spectrum (FHSS) provides even "a limited level of transmission security." Other features of Bluetooth provide security benefits. FHSS provides interference avoidance.

It is easy to overstate the security benefits of power control. I suggest eliminating discussion of transmit power from the document.

Good job on citing some important work! (Spill/Bittau, Wool/Shaked)

Where you state, "If that device remained discoverable, its location could be tracked by an adversary", it should be corrected to state that discoverability is not required. See Spill/Bittau and this blog post:

http://ossmann.blogspot.com/2011/07/discoverability-is-not-mitigating.html

Table 4-1 is an important contribution that I will recommend to many people.

Section 4.2 "Bluetooth Threats" seems weak. The list of threats is disjointed, inconsistent, and in places dated.

Thank you again for your contribution. I hope you find some of these comments helpful.

Sincerely,

Michael Ossmann
Great Scott Gadgets
mike@ossmann.com
http://greatscottgadgets.com/

Power over Ethernet and the Throwing Star LAN Tap

Since handing out hundreds of Throwing Star LAN Tap printed circuit boards as business cards at DEF CON, I've received a number of interesting questions about the device in my email. A couple people were hoping to use Throwing Stars to monitor connections that use Power over Ethernet (PoE). When I designed the current version of the Throwing Star LAN Tap, I decided to pass all eight conductors through from J1 to J2 (the target ports) even though this necessitated the addition of two filtering capacitors. I did this primarily to support RS-232 monitoring (a feature that I imagine is very rarely used), but I also thought that having eight conductors might be handy for other things such as PoE. It wasn't until recently that I actually verified PoE capability, however.

PoE allows a device to be powered by direct current (DC) running over an Ethernet cable that may also be used for communication. It is popular for VoIP telephones, IP security cameras, wireless access points and other network-connected devices that are commonly deployed at multiple locations within a building. There are several different ways that PoE has been implemented over the years, but most devices these days follow the IEEE 802.3at-2009 standard or its similar predecessor, IEEE 802.3af-2003. I looked at these standards and also at the most common non-standard implementations and found that they are all compatible with the Throwing Star LAN Tap.

Twisted pair Ethernet cables consist of eight wires arranged into four pairs. In some cases two of those pairs are unused. Each pair carries a differential signal with one wire carrying the inverse of the signal on the other wire; when one goes high, the other goes low. This is an alternating current (AC) signal.

What all of the PoE schemes have in common is that they introduce a DC bias between one pair and another. In the figure to the left, the purple and green lines represent the voltage on one pair and the blue and orange lines represent the voltage on a second pair. In each pair, the AC component (the rapidly changing difference in voltage between the two wires) is relatively small. This is the signal that carries network data. From one pair to the second pair there is a larger voltage difference, the PoE DC bias.

The Throwing Star LAN Tap provides a DC path for all eight conductors between the target ports, J1 and J2, but it only extends a subset of those conductors to the monitoring ports, J3 and J4. This is done in such a way that Power over Ethernet on the target network can pass through the tap but does not extend to the monitoring ports. It's almost like I meant to do that. :-)

Spread Spectrum Clock Generation, Emission Security, and You

The following is a transcript, more or less, of a short talk I gave at ToorCon Seattle 2011. There was no video made of the presentation, so I'm doing this instead. The talk was a preview of some research into how spread spectrum clock generation affects the risk of eavesdropping on unintentional Radio Frequency (RF) emanations from electronic devices.

Probably half of you are sick of hearing me talk about Project Ubertooth and the other half will be, so today I'm talking about something completely different: clocks. Not the kind of clocks you hang on a wall but periodic electrical signals that drive the timing of digital electronics and the circuits that produce those clock signals. Every digital electronic device has a clock. When you talk about your fancy, new, 3.0 GHz computer, you are referring to the clock frequency.

A traditional clock signal looks like this. The top graph shows how the voltage changes over time. The timing is fairly consistent. If you plot the signal in the frequency domain, the bottom graph, you get a sharp spike at the clock frequency. Note that I am ignoring harmonics here and have zoomed in on the region around the fundamental clock frequency.

About twenty years ago, some guys in Kentucky had this idea to modulate the frequency of a clock over time. They called the technique Spread Spectrum Clock Generation (SSCG). A spread spectrum clock signal looks something like this. The frequency of the signal varies over time. If you look at the signal in the frequency domain, the bottom graph, you see a plateau over a range of frequencies instead of a narrow spike. (If you are familiar with spread spectrum communication systems, note that I'm talking about something only vaguely related.)

SSCG became popular, first with PC manufacturers and more recently for other electronic devices. The technique is used for one and (as far as I know) only one reason: to make it easier to pass electromagnetic compatibility (EMC) testing required by the FCC and other regulatory bodies around the world. EMC regulations are intended to limit RF emissions of electronic devices in order to avoid harmful interference to radio systems and other neighboring electronics. SSCG doesn't do anything to reduce the radiated power of such emissions; it simply shifts their frequencies around so the EMC test equipment doesn't register too high a power level at any one frequency. The electronics manufacturers are playing a shell game with their clock frequencies in order to evade detection.

A few of you may have seen a recent blog post of mine, If it isn't open, it didn't happen. In it I proposed a citation boycott: scientific works not open to the public shouldn't be considered to have been published at all and should not be cited. Well, I'm about to break my own boycott. Actually I am declaring an exception, an exception for ridicule: It is okay to cite a non-open scientific work if the citation is made for the purpose of ridiculing said work.

About ten years ago, there was growing concern that SSCG might be bad for electromagnetic compatibility. It was clear that the practice resulted in electronic devices that produced higher overall radiated emissions. Plus people were starting to get the idea that wideband interference from devices with spread spectrum clocks could be worse for radio signals than narrowband interference from traditional clocks, even when comparing the two at the same radiated power level. In response, Harry G. Skinner and Kevin P. Slattery of Intel published a short paper called Why Spread Spectrum Clocking of Computing Devices is Not Cheating. It is a truly awful paper. The authors, Intel, and the IEEE should all be embarrassed to have their names on it. It features bad theory, bad analysis, bad experimentation - just about everything that could be wrong with scientific literature is evident in this biased piece of garbage. I will limit myself to pointing out just one fallacy in detail.

The authors claim that concern over the wide bandwidth of SSCG emissions is misplaced because the emissions aren't actually wide at all. If you configure your test equipment the way the FCC requires, then the emissions appear to cover a wide range of frequencies. This doesn't tell the whole story, they say.

They propose looking at the emissions over shorter windows of time. A quick snapshot would show a signal that is actually narrowband, similar to the frequency spike produced by a traditional clock. Subsequent snapshots show that the signal is still narrow but shifted to different frequencies. (Click the graph for sophisticated and professional-looking animation.)

To some extent, the authors are correct, but they conveniently leave out a rather important detail. If you look at the signal the way the FCC requires, you see a wideband emission consisting of power at various frequencies under the regulatory limit.

If, however, you look at the signal the way the authors propose, you see a narrowband emission that exceeds the regulatory limit. You can't have it both ways, guys. You either show that the signal is wide, averaged over a range of frequencies, or you reveal that the radiated power exceeds the legal limit and that your spread spectrum clock is exploiting a loophole in the peculiarities of the FCC test specification.

Amazingly enough, this unscientific trash seems to be pretty much the last word on the subject. I think it is time for fresh eyes to look at spread spectrum clock generation. I've been looking at it for a little while and have developed two hypotheses.

Hypothesis #1: The increasing prevalence of spread spectrum clock generation is detrimental to the operation of a wide variety of radio systems. SSCG is becoming popular not just in PCs but in smartphones, LCD panels, and other high speed electronic devices. It is required by interface standards such as SATA and SuperSpeed USB. As more and more of these devices are deployed (probably billions per year), the noise floor is raised for everyone trying to use the radio spectrum. This hypothesis is hard to test, so I'm skipping it.

Hypothesis #2: Devices with spread spectrum clock generation are more susceptible to eavesdropping than those without. I'm talking about emission security, the problem that electronic devices tend to unintentionally emit radio signals that can reveal otherwise secret information. Someone might be able to discover the password for your bank account, for example, by monitoring radio signals produced by your computer.

There are two reasons I think SSCG results in an increased susceptibility to eavesdropping. The first is that SSCG devices produce stronger emissions. This is almost by definition: the reason SSCG is deployed in the first place is to get away with emissions stronger than those that would be permitted from a device without SSCG. The second is that SSCG emissions feature spread spectrum signatures that make it easier for an eavesdropper to pick the signals out of the noise. This will be a little more difficult to demonstrate, but techniques from the field of digital radio communication could be applied to the problem.

In the coming months I will attempt to test hypothesis #2. I'll start by analyzing the waveforms produced by popular spread spectrum clock generator integrated circuits, and then I will apply the knowledge gained to the problem of eavesdropping on consumer electronic devices. If you are interested in helping with this research, I would love to hear from you!

Discoverability is Not a Mitigating Factor

Four years after BlueSniff: Eve Meets Alice and Bluetooth by Dominic Spill and Andrea Bittau, people are still saying that Bluetooth vulnerabilities can be mitigated by turning off discoverability. If there is one thing that should have been learned from all of the Bluetooth security research done over the last few years, it is that a non-discoverable device is no safer than a discoverable one, but perhaps this message has been buried too deeply in technical presentations. Let me try to make this point clearer.

A discoverable Bluetooth device is one that is willing to respond to an inquiry, a single packet transmitted by any device looking for others. When you tell a device to "find new Bluetooth devices" it transmits a large number of inquiry packets and waits for responses. A discoverable device's inquiry response contains information including the device's address (BD_ADDR). This address can then be used by the inquirer to initiate a connection between the two devices.

Since most Bluetooth vulnerabilities can only be exploited once a connection is established, people used to recommend turning off discoverability. The reasoning was that, without a way to learn the target's address, an attacker would be unable to connect to the target and exploit any vulnerability. This idea that it is possible to keep a Bluetooth device address secret is completely wrong.

Turning off discoverability is like hiding the SSID of an 802.11 network. It prevents people from casually or accidentally connecting to your Bluetooth device. It might be worth doing for this reason alone, but I no longer recommend it as a security practice. Turning off discoverability does nothing to thwart skilled attackers. Worse, it creates a false sense of security and makes it harder for the good guys to notice that Bluetooth devices are in use.

A BD_ADDR is a 48 bit number (it's a MAC address) that is unique to a particular Bluetooth device. It consists of three sections, the 16 bit Non-Significant Address Part (NAP), the 8 bit Upper Address Part (UAP), and the 24 bit Lower Address Part (LAP). In order to connect to a target, an attacker needs only the UAP and LAP.

LAP sniffing is easy. Every Bluetooth packet contains the LAP in cleartext. Spill and Bittau showed how to sniff LAPs with a USRP for about $1000. Now it can be done with an Ubertooth One for about a tenth of that price. It can even be done using Travis Goodspeed's method for promiscuous sniffing with lower cost platforms. LAP sniffing has always been easy, but now the tools and methods are more well known.

The UAP is only slightly more difficult for an attacker to learn. Project Ubertooth and gr-bluetooth include software that implements automatic UAP determination based on passive observation of just a few packets. The function is integrated into the Ubertooth Kismet plugin. Even without this method, it isn't hard to figure out the 8 bit UAP. In Hacking Exposed Wireless, Second Edition, Joshua Wright showed how to determine the UAP with a simple brute force attack.

Turning off discoverable mode doesn't make your Bluetooth device any more secure. If your security model depends on secrecy of the BD_ADDR, you are doing it wrong.

And, by the way, frequency hopping doesn't help you either.

Throwing Star LAN Tap

Not long after I designed the 5-in-1 Network Admin's Cable several years ago, I built the first Throwing Star LAN Tap. It is a simple cross of CAT5 cable spliced together to permit in-line monitoring of Ethernet connections. As a passive (unpowered) device, it is limited to sniffing 10BASE-T and 100BASE-TX, and each sniffing connector monitors only the network traffic going in one direction. You just insert it in-line on a target Ethernet connection (between a computer and a switch, for example), and then you can use monitoring tools like tcpdump or Wireshark on a computer attached to one or both of the sniffing connectors. The sniffing ports are receive-only, so there is no danger of your monitoring station accidentally transmitting packets onto the wire.

Despite its limitations, the device has come in handy countless times over the years. It is small enough that I can keep it in my backpack all the time. To sniff traffic in both directions, you have to monitor on two ports, but you'd be surprised how often sniffing just one direction at a time is sufficient for monitoring and troubleshooting tasks.

In 2007, Jason MacPherson wrote to me describing his extension of the Throwing Star LAN Tap design. (Alas, the link he sent is now broken.) He didn't bother with the throwing star form factor, instead opting to build his device in a box. The cool thing he did was to use the complete pinout of the 5-in-1 cable (all eight conductors) such that his tap could be used for monitoring either Ethernet or RS-232 serial connections. Why didn't I think of that?

Ever since then I've thought about building a new throwing star using Jason's approach. Another improvement I've had in mind is to switch from male RJ-45 plugs to female sockets. Although the male version is nifty and tiny, it invariably must be used with two or three couplers. Plus the tabs eventually break off the plugs, which is particularly annoying when they are attached to a very carefully spliced device.

Within the past year I've learned how to design printed circuit boards, so I decided to try building a female throwing star. There was one new problem I had to solve: how to handle 1000BASE-T (Gigabit Ethernet). Because 1000BASE-T signals travel in both directions simultaneously on each individual wire, it is impossible to build a passive tap for the technology. To properly tap 1000BASE-T, you need an active device such as a powered LAN tap or a switch with a monitor port. In a pinch, though, it is nice to be able to pull something out of your bag to get the job done, so I opted to make my throwing star compatible with 1000BASE-T in the only way I could, by breaking 1000BASE-T:

Since 1000BASE-T uses two more pairs of conductors than 10 or 100 Mbit Ethernet, I bypassed each of those extra pairs with a 220 pF capacitor. (Disregard the erroneous 22 pF marking in the photos.) This filters out the high frequency signals of 1000BASE-T, forcing the target devices to revert to 100BASE-TX which can then be monitored. The capacitors don't adversely affect lower frequency RS-232 signals, so all eight conductors function when monitoring serial connections. Sure, it's an ugly hack, but it's an ugly hack that fits in your pocket.

I figure that most folks who are interested in Bluetooth monitoring have occasion to sniff Ethernet from time to time, so I'm getting a bunch of kits produced, and I'll drop one into each reward package sent to backers of Ubertooth One on Kickstarter at the $100 level or higher. I'll also include a bare PCB with the $15 and $30 reward packages. I'm thinking about handing out PCBs as business cards at hacker cons, but I can't decide if it is a really good idea or a really bad idea. What do you think?

Open source design files are here.

Update: Throwing Star LAN Tap Kits are now available.

Project Ubertooth: Building a Better Bluetooth Adapter

Video of my presentation, Project Ubertooth: Building a Better Bluetooth Adapter, at ShmooCon 2011 is now online. You can download the entire video in high quality from shmoocon.org or watch it in your web browser. In the presentation, I demonstrated Ubertooth One, the world's first open source, widely available, low cost Bluetooth test tool, and I described my two year design journey starting as an electronics novice. This was one of the most fun talks I've ever given, and I want to thank ShmooCon for making it happen and everyone who attended for participating. I'm making the slides available, but, as is typical of my presentation slides, they really don't stand alone.

Shortly before the presentation, I was interviewed by Hak5. The interview covered a lot of ground and included quite a bit of discussion beyond the content of the presentation.

At ShmooCon I announced the start of a pledge period on Kickstarter to fund an initial production run of Ubertooth One boards, and the pledge goal was met in just four days! There is still time remaining in the pledge period for anyone who would like a board. Thank you to everyone who has pledged support!

Bluetooth Keyboards: who owns your keystrokes?

I gave a talk at ShmooCon 2010 on the security of Bluetooth keyboards and mice. After a restoration of the ShmooCon archive, the full video is once again available. I have also published the slides and such.

Most of my previous Bluetooth work had been done using software radio techniques requiring somewhat costly hardware. For this talk I focused on what is possible for both attack and defense using low-cost off-the-shelf Bluetooth equipment. It turned out that quite a lot of interesting things were possible that had not been demonstrated before. Even so, many essential capabilities such as passive monitoring remained out of reach without more expensive hardware which is why I've since turned my attention to Project Ubertooth.

Ubertooth Zero, a preview

Last weekend at ToorCon 12 I unveiled Project Ubertooth, something I've been working on for more than a year. The goal of the project is to produce a low cost 2.4 GHz wireless development platform suitable for Bluetooth sniffing (among other things). If you are familiar with previous work on Bluetooth monitoring, then you know that good tools are expensive. Commercial equipment costs $10,000 or more, and even the open source solution requires a hardware investment of at least $1000.

In my talk, Ubertooth Zero, a preview, I demonstrated Bluetooth sniffing for the first time with Ubertooth Zero, my first prototype hardware model. The platform is based on the Texas Instruments CC2400 wireless transceiver paired with NXP's LPC1758, an ARM microcontroller with USB. You can build an Ubertooth Zero for less than $50 in parts. The hardware design and host code are published in the svn repository at http://ubertooth.sourceforge.net/, and firmware will follow as soon as possible (probably a couple weeks). Everything is open source.

Over the coming weeks I'll be working on the next model, Ubertooth One, which I hope to have available in early 2011. It will be compatible with the Ubertooth Zero software but will have an improved RF front end, comparable to a Class 1 Bluetooth device. I hope to produce Ubertooth One commercially, making it available to those who don't want to solder 0402s, but rest assured that the product will remain fully open source. I'm also working on firmware, host software, and documentation so that the platform will be easier to build and use.

I would love to hear from you if you decide to build an Ubertooth Zero. Keep in mind that this is a preview release with much work still undone. So far I've built three working boards, one of which fetched $275 in Sunday night's ToorCon Foundation auction, supporting technology education in developing countries. I have three more that I hope to get working soon, and then I'll start work on Ubertooth One.

So far I have implemented only single channel Bluetooth monitoring. The device sits on a single channel and receives a small subset of packets from all Bluetooth devices in range (the target devices use frequency hopping, so they only transmit a small percentage of their packets on that particular channel). This is sufficient to provide a good survey of Bluetooth activity. With some work on software in the future, the platform should be capable of hopping along with a target, receiving every packet on that piconet. Once that is working, it should be possible to use the Ubertooth platform for raw frame injection, an important capability that has been out of reach of wireless security researchers since Bluetooth's introduction. The platform could also be used for several non-Bluetooth functions such as spectrum monitoring or 802.11 FHSS

ToorCon was a blast, as always. Thanks to everyone who attended the Software Defined Radio Workshop, Real Men Carry Pink Pagers, and the Ubertooth talk. Thanks to Travis for making our talk so much fun. Thanks to Dominic for making the trip from London. Thanks to George, Tim, and David for putting on a great con and making me feel so welcome. Thanks to all the friends, both old and new. Thanks(?) to Nick et al. for embarrassing the hell out of me. Thanks to Laen for running the DorkbotPDX PCB service. Most of all, thanks to Jared Boone who couldn't be at ToorCon but who has supported my effort to develop Project Ubertooth more than anyone.

ShmooCon live!

I'm giving a talk on Bluetooth keyboard security at ShmooCon this year. Live video of the talk will be provided. My talk will be at 3:00 PM EST on Saturday, February 6th in the Break It! track.

KillerBee on a budget

At ToorCon 11, Joshua Wright handed out a pre-release version of his KillerBee framework, a set of tools for analysis of 802.15.4 and ZigBee wireless networks.

KillerBee requires a particular hardware device, Atmel's AVR RZUSBSTICK, an inexpensive USB dongle with a programmable microcontroller. Many of the KillerBee functions require custom firmware (written by Joshua) to be flashed onto the stick. While most Atmel products feature In-System Programming (ISP) which can be done with a low-cost programming device, the RZUSBSTICK unfortunately only provides a JTAG header for programming, and the JTAG debugger/programmer costs about $300.

The good news is that ISP can be used to program the RZUSBSTICK. The bad news is that it requires some tricky soldering to get it working. With a little guidance from those who have gone before me and SparkFun's excellent surface mount soldering tutorials under my belt, I was able to attach a 10-pin ISP header to my RZUSBSTICK and successfully flash it with the KillerBee firmware.

There are two kinds of AVR ISP headers, a 6-pin and a 10-pin version. I chose the 10-pin variety because my programmer has a 10-pin connector, but a simple adapter can allow you to use either. Both varieties use the same 6 signals: GND, V_CC, RESET, SCK, MISO, and MOSI. I connected them with colored wire (28 or 30 AWG wirewrap wire) as follows:

signal	color	header pin	source
GND	black	4,6,8,10	JTAG header pin 2
VCC	red	2	JTAG header pin 4
RESET	white	5	JTAG header pin 6
SCK	purple	7	AT90USB1287 pin 11
MISO	brown	9	AT90USB1287 pin 13
MOSI	orange	1	AT86RF230 pin 22

I ran all six wires through the unused holes of the (unpopulated) JTAG header in order to provide some strain relief. Those connections to the individual chip pins are fragile! From there I ran them across the back of the board to a 10-pin header glued to the end of the stick.

My serial programmer works great when connected to an on-board serial port on an old PC, but its bit-banging technique is incredibly slow (about 3 bits per second) and unreliable when connected to a USB/serial adapter. I believe that trying to use it via USB was the cause of death of an ATtiny85 while working on a previous project. Anyway, with a good serial port, AVRDUDE does a fine job programming the RZUSBSTICK over ISP:

avrdude -c ponyser -p usb1287 -P /dev/ttyS0 -U flash:w:kb-rzusbstick1.hex

Now to find some target devices. . .

worst malware analysis ever

Symantec has decided that Lose/Lose is a trojan. It is, in fact, a video game that deletes files. The game's web site warns that the game deletes files. The game itself warns the player that it deletes files. There is nothing whatsoever malicious about a program deleting files after warning the user that it will delete files.

Why does Symantec (oh, Trend too) think this is malware? Because "there’s nothing stopping someone with more malicious intentions from modifying it slightly and then passing it on to unsuspecting users, causing significant damage to a computer." By that logic, rm should be considered malware because it could be modified (say, by renaming it) to delete files contrary to a user's expectation. Frozen Bubble must be malware too, because it could easily be modified to delete files!

ToorCon workshop

I'll be running a software radio workshop at ToorCon in October. It will be similar to the workshop at ToorCamp but with more electricity and less volcanic ash! With a more pleasant environment and more structured lessons, a greater amount of material will be covered.