Tampilkan postingan dengan label nordic. Tampilkan semua postingan
Tampilkan postingan dengan label nordic. Tampilkan semua postingan

Rabu, 31 Agustus 2011

Remotely Exploiting the PHY Layer

or, Bobby Tables from 1938 to 2011



by Travis Goodspeed <travis at radiantmachines.com>

concerning research performed in collaboration with

Sergey Bratus, Ricky Melgares, Rebecca Shapiro, and Ryan Speers.



20110808_001



The following technique is a trick that some very good neighbors and I present in Packets in Packets: Orson Welles' In-Band Signaling Attacks for Modern Radios (pdf) at Usenix WOOT 2011. As the title suggests, Orson Welles authored and implemented the attack in 1938 as a form of social engineering, but our version acts to remotely inject raw frames into wireless networks by abuse of the PHY layer. As that paper is limited to a formal, academic style, I'd like to take the opportunity to describe the technique here in my people's native language, which has none of that formal mumbo-jumbo and high-faluttin' wordsmithin'. This being just a teaser, please read the paper for full technical details.



The idea is this: Layer 1 radio protocols are vulnerable injections similar to those that plague naively implemented SQL websites. You can place one packet inside of another packet and have the inner packet drop out to become a frame of its own. We call the technique Packet-in-Packet, or PIP for short.



As I've mentioned in my article on promiscuously sniffing nRF24L01+ traffic, every modern digital radio has a Layer 1 form that consists of a Preamble, followed by a Sync, followed by a Body. The Body here is Layer 2, and that is the lowest that a normal packet sniffer will give you. (Keykeriki, Ubertooth, and GoodFET/NRF give a bit more.)



In the specific case of IEEE 802.15.4, which underlies ZigBee, the Preamble consists of the 0 symbol repeated eight times, or 00000000. The Sync is A7. After that comes the Body, which begins with a byte for the length, a few bytes for flags, the addresses, and some sort of data. Suppose that an attacker, Mallory, controls some of that data, in the same way that she might control an HTTP GET parameter. To cause a PIP injection of a Layer 2 packet, she need only prepend that packet with 00000000A7 then retransmit a large--but not unmanageably large--number of times. I'm not joking, and I'm not exaggerating. It actually works like that.



Below is a photograph of the first packet capture in which we had this technique working. The upper packet capture shows those packets addressed to any address, while the lower capture only sniffs broadcast (0xFFFF) messages. The highlighted region is a PIP injection, a broadcast packet that the transmitter intended to only be data within the payload of an outer packet.

20110808_003



How it works.



When Alice transmits a packet containing Mallory's PIP to Bob, Bob's interpretation can go one of three ways, two of which are depicted in the diagram below. In the first case, as shown in the left column, Bob receives every symbol correctly and interprets the packet as Alice would like him to, with Mallory's payload sitting harmlessly in the Body. In the second case, which is not depicted, a symbol error within the Body causes the packet's checksum to fail, and Mallory's packet is dropped along with the rest of Alice's.



802.15.4 PIP



The third interpretation, shown above in the right column, is the interesting one. If a symbol error occurs before the Body, within the Preamble or the Sync, then there's no checksum to cause the packet to be dropped. Instead, the receiver does not know that it is within a packet, and Mallory's PIP is mistaken as a frame of its own. Mallory's Preamble and Sync will mark the start of the frame, and Mallory's Body will be returned to the receiver.



In this way, Mallory can remotely inject radio frames from anywhere on the network to which she can send her payload. That is, this is a PHY-Layer radio vulnerability that requires no physical access to the radio environment. Read the WOOT paper for complications that arise when applying this to IEEE 802.11, as well as the conditions under which a PIP injection can succeed on every attempt.



War of the Worlds



In 1938, Orson Welles implemented a similar exploit as a form of social engineering in order to cause panic with his War of the Worlds (mp3, transcript) performance.



Recall that PIP injection works by having the victim miss the real start of frame marker, then fraudulently including another start of frame marker inside of the broadcast. As per the FCC requirements of his time, Orson begins with a real start of broadcast marker:



ANNOUNCER: The Columbia Broadcasting System and its affiliated stations present Orson Welles and the Mercury Theatre on the Air in The War of the Worlds by H. G. Wells.



(MUSIC: MERCURY THEATRE MUSICAL THEME)



ANNOUNCER: Ladies and gentlemen: the director of the Mercury Theatre and star of these broadcasts, Orson Welles . . .



ORSON WELLES: We know now that in the early years of the twentieth century this world was being watched closely by intelligences greater than man's and yet as mortal as his own. We know now that as human beings busied themselves about their various concerns they were scrutinized and studied, perhaps almost as narrowly as a man with a microscope might scrutinize the transient creatures that swarm and multiply in a drop of water. With infinite complacence people went to and fro over the earth about their little affairs, serene in the assurance of their dominion over this small spinning fragment of solar driftwood which by chance or design man has inherited out of the dark mystery of Time and Space. Yet across an immense ethereal gulf, minds that to our minds as ours are to the beasts in the jungle, intellects vast, cool and unsympathetic, regarded this earth with envious eyes and slowly and surely drew their plans against us. In the thirty-ninth year of the twentieth century came the great disillusionment.

It was near the end of October. Business was better. The war scare was over. More men were back at work. Sales were picking up. On this particular evening, October 30, the Crosley service estimated that thirty-two million people were listening in on radios.




That introduction is two minutes and twenty seconds long, and it was scheduled to begin while a popular show on another station was still in progress. Many of the listeners tuned in late, causing them to miss the Sync and not know which show they were listening to, just as in a PIP injection! What follows is thirty-eight minutes of a first act, without a single word out of character or a single commercial message from a sponsor. The play begins in the middle of a weather report, followed by repeated false station and show announcements, a few of which follow.



We now take you to the Meridian Room in the Hotel Park Plaza in downtown New York, where you will be entertained by the music of Ramón Raquello and his orchestra.

From the Meridian Room in the Park Plaza in New York City, we bring you the music of Ramón Raquello and his orchestra.

Ladies and gentlemen, we interrupt our program of dance music to bring you a special bulletin from the Intercontinental Radio News.

We are now ready to take you to the Princeton Observatory at Princeton where Carl Phillips, or commentator, will interview Professor Richard Pierson, famous astronomer.

Good evening, ladies and gentlemen. This is Carl Phillips, speaking to you from the observatory at Princeton.

Just a moment, ladies and gentlemen, someone has just handed Professor Pierson a message. While he reads it, let me remind you that we are speaking to you from the observatory in Princeton, New Jersey, where we are interviewing the world- famous astronomer, Professor Pierson.



By repeatedly lying to the listeners about the station and the program, Welles was able to convince them that they were listening to legitimate news broadcasts of an alien invasion. Ensuring that the listener missed the starting broadcast announcement breaks the encapsulation that was intended to prevent such confusion, just as a PIP injection relies upon the start of frame to be missed in order to break OSI model encapsulation.



How the hell did this happen?



This class of vulnerability is a really, really big deal. An attacker can use it to inject raw frames into any wireless network that lacks cryptography, such as a satellite link or an open wifi hotspot. Not only that, but because the injection is remote, the attacker needs no radio to perform the injection! Not only that, but this vulnerability has sat unexploited in nearly every unencrypted digital radio protocol that allows for variable frame length since digital radio began! So why did no one notice before 2011?



Packet in Packet injection works because when Bob forwards a wrapped string to Alice over the air, he is trusting Mallory to control the radio symbols that are broadcast for that amount of time. The potential for abusing that trust wasn't considered, despite communications experts knowing full well that sometimes a false Sync was detected or a true Sync missed. This is because a symbol error in the Sync field causes the packet to be implicitly dropped, with the same behavioral effect that would be had if the error were later in the packet and it were explicitly dropped. Except when faced with a weaponized PIP injection, nothing seems strange or amiss. Sync errors were just a nuisance to communications engineers, as we security guys were staying a few layers higher, allowing those layers of abstraction to become boundaries of competence.



That same trust is given in wired networks and busses, with the lesser probability of missing a Sync being the only defense against PIP injection. Just as PIP has shown that unencrypted wireless networks are vulnerable even when the attacker is not physically present, I expect wired networks to be found vulnerable as soon as an appropriate source of packet errors is identified. Packet collisions provide this in unswitched Ethernet networks, and noisy or especially long links might provide it for more modern wired networks.



If I've not yet convinced you that this attack is worth studying, I probably won't be able to. For the rest of you, please print and read the paper and extend this research yourself. There's a hell of a lot left to be done at the PHY layer, and it might as well be you who does it.



Thank you kindly,

--Travis Goodspeed









Minggu, 06 Februari 2011

Promiscuity is the nRF24L01+'s Duty

by Travis Goodspeed <travis at radiantmachines.com>
extending the work of Thorsten Schröder and Max Moser
of the KeyKeriki v2.0 project.

NHBadge and a Keyboard

Similar to Bluetooth, the protocols of the Nordic VLSI nRF24L01+ chip are designed such that the MAC address of a network participant doubles as a SYNC field, making promiscuous sniffing difficult both by configuration and by hardware. In this short article, I present a nifty technique for promiscuously sniffing such radios by (1) limiting the MAC address to 2 bytes, (2) disabling checksums, (3) setting the MAC to be the same as the preamble, and (4) sorting received noise for valid MAC addresses which may later be sniffed explicitly. This method results in a rather high false-positive rate for packet reception as well as a terribly high drop rate, but once a few packets of the same address have been captured, that address can be sniffed directly with normal error rates.

As proof of concept, I present a promiscuous sniffer for the Microsoft Comfort Desktop 5000 and similar 2.4GHz wireless keyboards. This vulnerability was previously documented at CanSecWest by Thorsten Schröder and Max Moser, and an exploit has been available since then as part of the KeyKeriki v2.0 project. My implementation differs in that it runs with a single radio and a low-end microcontroller, rather than requiring two radios and a high-end microcontroller. My target hardware is the conference badge that I designed for the Next Hope, running the GoodFET Firmware.

Part 1: or, Why sniffing is hard.

nRF24L01 Die

Radio packets usually begin with a preamble, followed by a SYNC field. In the SimpliciTI protocol, the SYNC is 0xD391, so the radio packets will begin with {0xAA,0xD3,0xD91} or {0x55,0xD3,0x91}. The AA or 55 in the beginning is a preamble, which is almost universally a byte of alternating 1's and 0's to note that a packet is beginning, followed by the SYNC field which makes sure that the remainder of the packet is byte-aligned.

In the case of the Nordic radios, there is no SYNC pattern unique to the radio. Instead, the MAC address itself serves this purpose. So an OpenBeacon packet will begin with {0x55, 0x01, 0x02, 0x03, 0x02, 0x01} while a Turning Point Clicker's packets will begin with {0x55, 0x12, 0x34, 0x56}. The preamble in this case will be 0x55 if the first bit of the SYNC/MAC is a 0 and 0xAA if the first bit is a 1. To make matters worse, the chip does not allow a MAC shorter than three bytes, so previously it was believed that at least so many bytes of the destination address must be known in order to receive a packet with this chip.

Moser and Schröder solved this problem by using an AMICCOM A7125 chip, which is a low-level 2FSK transceiver, to dump raw bits out to an ARM microcontroller. The ARM has just enough time to sample the radio at 2Mbps, looking for a preamble pattern. If it finds the pattern, it fills the rest of register memory with the remaining bits and then dumps them to the host by USB. In this manner, every prospective MAC address can be found. Once the address is known, KeyKeriki places that address in its second radio, an nRF24L01+, which is used to sniff and inject packets.

A similar solution is used in Michael Ossmann's Project Ubertooth sniffer for Bluetooth. See that project's documentation and Ossmann's Shmoocon 2011 video for a more eloquent explanation of why sniffing without a known SYNC is so hard.

Part 2: or, Sniffing on the cheap.
My trick for sniffing promiscuously involves a few illegal register settings and the expectations of background noise. You can find code for this in the AutoTuner() class of the goodfet.nrf client.

First, the length of the address to sniff must be reduced to its absolute minimum. The datasheet claims that the lowest two bits of register 0x03 are responsible for address width, and that the only valid lengths at 3 bytes (01b), 4 bytes (10b), or 5 bytes (11b). Setting this value to 00b gives a 2 byte match, but when checksums are disabled, this results in a deluge of false-positive packets that appear out of background noise.
nRF Address Width

Second, it is necessary to begin receiving before the SYNC field appears, as the Nordic chips drop the address of incoming packets, leaving only the payload. By looking at the noise returned when the address is at its shortest length, it is clear that background noise includes a lot of 0x00 and 0xFF packets as well as 0xAA and 0x55 packets, which are likely feedback from an internal clock. What then would happen if the address were to be 0x00AA or 0x0055?

What happens is that noise activates the radio a bit early, which then syncs to the real preamble, leaving the SYNC field as the beginning of the packet payload! This is because the preamble and SYNC do not need to be immediately adjacent; rather, the SYNC can be delayed for a few bytes from the preamble in order to allow for longer preambles in noisy environments.

As a concrete example, an OpenBeacon packet looks something like the following. The SYNC field is 0x0102030201, so the packet will be cropped from that point backward. 0xBEEF is all that will be returned to the application, with everything prior to that cropped.
nRF24L01+ Promiscuous Mode

By making the address be 0x0055 and disabling checksums, that same packet will sometimes be interpreted as shown on the bottom. The preamble will be mistaken for a SYNC, causing the real SYNC value to be returned as the beginning of the payload. In that way, I am able to determine the SYNC/MAC field without any prior knowledge or brute force exploration.

This does depend upon the preamble being preceded by 0x00, which occurs often in background noise but is not broadcast by the attacker. So the odds of receiving a packet, while significantly worse than we'd like, are much better than the 1/2^16 you might assume. In experiments, one in twenty or so real packets arrive while a significant number of false positives also sneak in.

Recalling that the MAC addresses are three to five bytes long, and that radio noise is rather distinct, it stands to reason that noise can easily by separated from real packets by either manually checksumming to determine packet correctness or simply counting the occurrences of each address and taking the most popular. You will find an example log of OpenBeacon packets and false positives at http://pastebin.com/8CbxHzJ9. Sorting the list reveals that the MAC address 0x0102030201 is the most popular, which is in fact the address used by OpenBeacon tags.

Rather than rely on packet dumps and sorts, there is an autotune script that identifies network participants and prints their MAC addresses. Simply run 'goodfet.nrf autotune | tee autotune.txt' and go out for a coffee break while your device is transmitting. When you come back, you'll find logs like the following, which has identified a nearby OpenBeacon transmitter.

goodfet.nrf autotune

As low data-rate devices require significantly more time than high-rate devices to identify, such devices will either require undue amounts of patience or a real KeyKeriki. In the case of a Nike+ foot pod, I'm resorting to using loud hip hop music to trigger the sensor, which is left inside a pair of headphones. My labmates are not amused, but it is a great way to reveal the radio settings when syringe probes aren't convenient.

Part 3: or, Sniffing a keyboard effectively.

Having a class to identify channels and MAC addresses is most of the problem, but there are remaining issues. First, the packets themselves are encrypted, and that cryptography must be broken.

Fear not! We won't need to do any fancy math to break this cryptography, as the key is included at least once in every packet. Moser and Schröder's slides explain that the packet's header is cleartext, while the payload is XOR encrypted with the MAC address.
XOR Crypto!

Applying an XOR to the proper region yields decrypted packets such as the following. Because these contain USB HID events, key-up HID events quite often include long strings of 0x00 bytes. When XOR'ed with the key, those zeroes produce the key, so some packets contain the XOR key not just once, but twice!
MSKB5k Traffic

Finally, the USB HID events need to be deciphered to get key positions. Mapping a few of these yields meaningful text, with bytes duplicated in the case of retransmissions and omitted in the case of lost packets. Disabling checksums will allow the dropped packets to be converted to a smaller number of byte errors, while tracking sequence numbers will prevent retransmitted keys from being displayed twice. Regardless, the results are quite neighborly, as you can make out the sentence typed below in its packet capture.
NHBadge Key Sniffer

Part 4; or, Reproducing these results.

All of the code for this article is available in the GoodFET Project's repository, as part of GoodFETNRF.py and its goodfet.nrf client script. The hardware used was an NHBadge12, although an NHBadge12B or a GoodFET with the SparkFun nRF24L01+ Transceiver Module will work just as well.

To identify a nearby Nordic transmitter, run 'goodfet.nrf autotune'. Keyboards can be identified and sniffed with 'goodfet.nrf sniffmskb', while a known keyboard can be sniffed and decoded by providing its address as an argument, 'goodfet.nrf sniffmskb aa,c10ac074cd,17,09'. The channel--0x17 in this case--will change for collision avoidance, but channel hopping is slow and resets to the same starting channel. Identification of the broadcast channel is faster when the receiver is not plugged in, as that causes the keyboard to continuously rebroadcast a keypress for a few seconds.

All code presently in the repository will be refactored and rewritten, so revert to revision 885 or check the documentation for any changes.

Conclusions

Contrary to prior belief, the nRF24L01+ can be used to promiscuously sniff compatible radios, allowing for keyboard sniffing without special hardware. It's also handy for figuring out the lower levels of the otherwise-documented ANT+ protocol, and for reverse engineering vendor-proprietary protocols such as Nike+.

Additionally, it should be emphasized that the security of the Microsoft keyboards in this family is irreparably broken, and has been since Moser and Schröder published the vulnerability at CanSecWest. (It's a shame, because the keyboards are quite nicer than most Bluetooth ones, both in pairing delay and in battery life.) Do not purchase these things unless you want to broadcast every keystroke.

While I have not yet written code for injecting new keystrokes, such code does exist in the KeyKeriki repository and would not be difficult to port. Perhaps it would be fun to build stand-alone firmware for the Next Hope badge that sniffs for keyboards, broadcasting Rick Astley lyrics into any that it finds?

Please, for the love of the gods, use proper cryptography and double-check the security your designs. Then triple-check them. There is no excuse for such vulnerable garbage as these keyboards to be sold with neither decent security nor a word of warning.

Meraih Jackpot Besar: Strategi dan Tips Bermain Slot dengan Agen Slot Gacor

  Meraih Jackpot Besar: Strategi dan Tips Bermain Slot dengan Agen Slot Gacor Halo, para pecinta judi online! Apakah Anda sedang mencari car...