Sunday, November 5, 2017

Surleyspawn NSA's tool - nRF24L01+ sniffer - part 1

nRF24 sniffing

The wireless 2.4GHz Nordic Semiconductor nRF24L01+ chip (or nRF24 for short), which I'm experimenting with for wireless domotica applications, does however not support promiscuous mode, which in theory makes it impossible to capture network traffic between different nodes on a network.
Some time ago I stumbled upon a blogpost by Travis Goodspeed, in which he explains how reducing the wireless network address length of an nRF24 (together with some other tricks) allows capturing traffic not directly addressed to this chip.
After reading his blog and some more google'ing around I started thinking of building a 'simple' network sniffer for nRF24 traffic. I faced following requirements & challenges:
  • Based on commodity, cheap hardware
  • Traffic capturing for network with known parameters (channel, baudrate, base address)
  • Analysis using Wireshark network protocol analyzer
  • Possibility to analyze protocols which use the nRF24 for transport in their network

Packet formats

A regular packet is sent on air by the nRF24 in the following format (supposedly; it's not in the datasheet):
Regular nRF24 packet
Every message starts with a preamble, which the radio uses to identify incoming packets. The target node address follows and can be specified as 3 to 5 bytes (according to Travis Goodspeed a length of 2 is also accepted by the radio, though defined as invalid in the datasheet). Then comes the fixed-size payload, followed by an optional CRC to check the integrity of the message after reception. The CRC is calculated over the whole message, excluding the preamble and the CRC itself. The radio must be told upfront what the length of the payload will be, as a regular packet contains no indication of the length.
When a message received matches the receiver address of the radio and the CRC is found valid or disabled, the radio will store the payload in an internal FIFO for reception by the host (microcontroller or whatever connected to the nRF24 using SPI).

The nRF24L01+ modules support a mode called 'Enhanced Shockburst' which has a number of advantages over regular usage (incomplete):
  • Payload lengths can be set dynamically and are part of the message
  • The receiving node can automatically send an acknowledge to the sender to indicate that the message has been received correctly. The sender will automatically retry transmission a number of times when the acknowledge is not received within a configurable timeout (Nordic calls this "Automatic packet transaction handling")
Enhanced shockburst messages are sent over the air in the following format (from the datasheet):
Enhanced Shockburst nRF24 packet
As you can see a 9 bit packet control field has been added which stores the payload length (in bytes), a packet identifier (PID) to detect retransmissions and a flag to suppress sending acknowledge packets on a per-packet basis. The CRC is no longer optional.
As with the regular packets, a message received must match the receiver address of the radio and the CRC must be valid to have the payload stored in the internal FIFO, otherwise the message will be discarded.

Many (all?) wireless sensor applications based on the nRF24L01+ I've seen so far run the radio in Enhanced Shockburst mode.

Promiscuous reception

When building a wireless network of many nodes you choose a single RF channel which all nodes will operate on. Furthermore each node shall have a unique address within the network (unless you're only broadcasting). Each node can have an arbitrary address, but normally you choose a base address which is identical for all nodes, and a node address which is unique for each node. Combined these form the address:

Address consisting of 4 byte base address and single byte node address
This example addressing scheme (4+1) is used by the MySensors library and allows 255 unique nodes to be addressed (node 255 is used for broadcast addressing).

Should the nRF24 support promiscuous addressing, then the base address would have to be configured in the chip and it should be instructed that the node addressing consists of 1 byte. The nRF24 would then start listening for messages. All messages with matching base address and valid CRC would then be stored...

But the nRF24 does not support promiscuous listening. With some trickery we can however instruct it to capture all messages for a certain base address, including the ones with invalid CRC's !

The following configuration of the nRF24 sniffing radio is required:

  • Set the nRF24 receiver address to just the base address
  • Disable Enhanced Shockburst
  • Disable CRC checking
  • Configure a fixed payload size
The first 3 items will cause the nRF24 to capture anything that matches the base address of the network we're sniffing. As Enhanced Shockburst is disabled, the radio will not determine the payload size from the message anymore and we just have to store a fixed amount of data starting from the Node address. We just fake the message received is a regular packet, while in fact it is an Enhanced Shockburst packet!
CRC checking has to be disabled of course, as the nRF24 doesn't know the payload length anymore and CRC calculation would fail, rejecting all messages.
The process is illustrated by the image below (again, taking the 4+1 addressing scheme as an example):

Capture Enhanced Shockburst packet as regular packet
The payload received will start with the node address the packet was transmitted to, so effectively we've created a promiscuous listening nRF24!
As the nRF24 will no longer dissect the packet for us, we'll have to do it ourselves (actually let Wireshark do it for us). The original length of the payload should be extracted (the 6 bit payload length), the full address recreated and CRC calculated over the data received. When the CRC is invalid the message can be marked, which gives us a nice indication of the link quality. As the nRF24 header is not a multiple of 8 bits, all payload & CRC bytes will be bit-shifted directly adjacent to the packet control field. This is inconvenient when inspecting the raw bytes in a packet, but Wireshark will solve this nicely for us.


Limitations

There are however some limitations to this method which you should be aware of:

  • The maximum length of a payload is limited by the nRF24 to 32 bytes. As we 'shift' the reception of the payload towards the start of the packet and also want to include the CRC in the payload, the effective size of payloads captured will go down by a number of bytes. The amount depends on the number of bytes in the node address, the fixed packet control field and the length of the CRC.
  • When fixed payload size of the sniffer is set to a value (much) larger than the actual payload size in the packet, then subsequent packets might be missed. When the nRF24 is still capturing the fixed size payload and a new packet arrives, this will not be detected. A good example for this are the auto-acknowledge packets which can be enabled in Enhanced Shockburst mode. After the target node receives the packet (and it will know the real size of the payload a lot faster than the sniffer will) it switches its radio from receiving to transmitting mode in only 130us. Then it sends out the acknowledge packet. Reception of 32 bytes at 1Mb/s takes 32*8us = 256us, so acknowledge of a short message will definately be missed. For acknowledge packets this isn't much of a problem as the transmitter will retry to send the identical message when no acknowledge was received and we will know it missed the acknowldge.
  • This method works well for Enhanced Shockburst packages, as they have the payload size embedded in the message. For regular messages the length will have to be known or can be determined by testing different lengths until the CRC matches. With CRC disabled the payload size can only be guessed.
  • The addressing scheme must use a base address in the high address byte(s), and node address in the low byte(s), as explained.

What's next

In the next parts of this series I will dive deeper in the hardware and software required to create the sniffer and give some nice usage examples. Furthermore a Wireshark dissector for the MySensors protocol will be presented.

at No comments:

Networking chips only accept messages directly addressed to them (or when broadcasteded), but most also support a so-called promiscuous mode. This mode allows the networking chip to capture all network traffic on air/on the wire and is used to monitor all network traffic, not just the traffic addressed to our node....

at No comments:

Flush+Flush: A Fast and Stealthy Cache Attack Research on cache attacks has shown that CPU caches leak significant information. Proposed detection mechanisms assume that all cache attacks cause more cache hits and cache misses than benign applications and use hardware performance counters for detection. In this article, we show that this assumption does not hold by developing a novel attack technique: the Flush+Flush attack. The Flush+Flush attack only relies on the execution time of the flush instruction, which depends on whether data is cached or not. Flush+Flush does not make any memory accesses, contrary to any other cache attack. Thus, it causes no cache misses at all and the number of cache hits is reduced to a minimum due to the constant cache flushes. Therefore, Flush+Flush attacks are stealthy, i.e., the spy process cannot be detected based on cache hits and misses, or state-of-the-art detection mechanisms. The Flush+Flush attack runs in a higher frequency and thus is faster than any existing cache attack. With 496 KB/s in a cross-core covert channel it is 6.7 times faster than any previously published cache covert channel.

at No comments:

It look like a spy, it walks like a spy, it dresses like a spy, it talks like a spy...maybe its a spy!

RJ45 to RJ45 Ethernet Cable Coupler F-F Metal Shielded from ScanFX


Features• Shielded RJ45 CAT5e Coupler
• Metal Housing
• To connect two network cables to each other Cat5e certified (networks up to 100 MBit) Wired 1:1
• Connections: RJ45 connector to RJ45 connector
• Specification: CAT 5e

at No comments:

Spook in Your Network: Attacking an SDN with a Compromised OpenFlow Switch - NSA's FIREWALK Software defined networking (SDN) and OpenFlow as one of its key technologies have received a lot of attention from the networking community. While SDN enables complex network applications and easier network management, the paradigm change comes along with new security threats. In this paper, we analyze attacks against a software-defined network in a scenario where the attacker has been able to compromise one or more OpenFlow-capable switches. We find out that such attacker can in suitable environments perform a wide range of attacks, including man-in-the-middle attacks against control-plane traffic, by using only the standard OpenFlow functionality of the switch. Furthermore, we show that in certain scenarios it is nearly impossible to detect that some switch has been compromised. We conclude that while the existing security mechanisms, such as TLS, give protection against many of the presented attacks, the threats should not be overlooked when moving to SDN and OpenFlow.

at No comments:

Video eavesdropping- RF - NSA's RAGEMASTER

at No comments:

To enable real-time instant messaging on such a system, removable media must be replaced with unidirectional data transmission lines. This assumes asynchronous data transmission over mediums such as UDP packets over Ethernet, or asynchronous serial communication. But how is unidirectionality guaranteed? Running only a listener program on receiver computer is not high assurance: malware that propagates to that system can trivially add sender functionality to establish a return channel. The answer is to remove the return channel on hardware level. This is not easy: features such as auto MDI-X make it impossible to enforce unidirectional UDP transmission over Ethernet. A more simple transmission protocol is required and for that, serial interfaces like RS232 and UART fit perfectly. While serial interfaces most likely have more than just rule-based limitations on Tx/Rx pin assignment, more assurance should be sought. To guarantee unidirectional behavior, a simple hardware device called data diode is required in between sending and receiving serial interface. Data diode is a device that takes advantage of the laws of physics to limit the direction of data flow. The data diode used in TFC is a slight modification to the design by the pseudonym Sancho P. (Earlier data diode designs are based on the work and paper by Douglas W. Jones and Tom C. Bowersox on RS232 data diodes.)


This data diode makes use of two transducers that form a unidirectional gateway. On sender side, depending on whether the output bit is one or zero, the high or low signal from serial interface's Tx-pin turns the LED inside the HCPL7723 optocoupler on and off. The state of the LED is detected by the optocoupler's photodiode, and the reproduced signal is then amplified by the optocoupler's TIA and finally fed into the Rx-pin of receiving serial interface.
This optical gap is guaranteed to be one way, because while LEDs show a weak photoelectric effect, photodiodes (excluding Ternary and quaternary GaAsP photodiodes) do not emit light.
The hardware configuration that combines data diodes with split TCB has impressive security guarantees. It sets a one-time price tag on endpoint security. As long as transmitter computer doesn't output sensitive data (due to programming error or pre-existing malware), the entire system remains secure against remote key exfiltration with malware. The malware can not propagate from networked computer to transmitter computer, and malware that propagates to receiver computer is unable to exfiltrate data.
at No comments:

BADUSB 2.0 USB MITM POC. BadUSB2 is an INLINE hardware implant giving it the stealth of a hardware keylogger but far more capabilities as mentioned above

HARDWARE NEEDED:
x1 Linux build (tested on default install of Ubuntu 14.04)
x1 Windows XP/7 (our target)
x2 Facedancers
x3 USB type A-male to USB Mini-B cables
x1 USB Keyboard (tested on HP & Genius brands)
Implemented Proof of Concept Attacks:
+ Eavesdrop. Once the keyboard has been registered to the target all keystrokes are captured to the ‘/tmp’ folder.
+ Modify. Weaponised code could use regular expressions to modify user keystrokes in order to defeat one-time-passwords. In this POC we simply annoy the user 🙂
+ Replay. The POC code will automatically detect ‘ctrl-alt-delete’ and assume it is a login session. It stops recording once the ‘enter’ key is pressed. Ay any time the ‘replay’ command can be given to automatically authenticate to the workstation.
+ Fabricate. Start/Run or generic commands can be issued to the target operating-system just as if you were at the keyboard.
+ Exfiltrate. I’ve implemented a PowerShell exfiltration POC that uses the ‘morse code’ technique (LEDs) to exfiltrate data. Using custom HID output reports is faster but MS Windows restricts read/write access from Win 2K. In short, this is a very rudimentary POC, and did I mention very slow!
BadUSB. I did not actually implement a POC for this. The Facedancer has plenty of example code that can be used to fake USB peripherals to the host, but it would be nice to implement some of the BadUSB “Kali Nethunter” type attacks here.
Usage:
at No comments:
Subscribe to: Posts (Atom)

Man in the Rain