Last updated at Tue, 06 Feb 2024 21:47:24 GMT
The rise of the Internet of Things
We spend a lot of time monitoring our corporate networks. We have many tools to detect strange behaviors. We scan for vulnerabilities. We measure our exposure constantly. However, we often fail to recognize the small (and sometimes big) Internet of Things (IoT) devices that are all around our network, employees, and employees' homes. Somewhat alarmingly – considering their pervasiveness — these devices aren't always the easiest to test.
Though often difficult, it is technically possible to find and identify some of these IoT devices via their Ethernet side connection. But that doesn't always give us a full picture of the risk these devices present to consumers or organizations. When assessing only Ethernet connected devices you can miss the wireless world that can have a major impact on the security of your organization. Wireless systems often control alarm systems, surveillance monitoring, door access, server room HVAC controls, and many other areas.
Which leaves us with one very critical question: how do you really determine the risk of these devices?
Let's start with the basics:
- What do these connected devices do?
- What is the range of exposure of these devices?
- Does the device have wireless capabilities?
Traditionally, we often perform perimeter scans of our 802.11 wireless networks to ensure our Access Points are secure and the network bleed isn't too large. We can monitor these Access Points (APs) to create overlap in case one goes down or gets interference from a nearby kitchen microwave.
However, if you're asking yourself, “but what about the rest of the wireless spectrum?” that's exactly the position we found ourselves in.
Radio, radio, everywhere
Chances are your company and employees are already using many other radio frequencies (RFs) outside of the standard 802.11 network for various reasons. Perhaps you have a garage door with a wireless opener? Company vehicle key fobs? Not to mention RFID card readers, wireless security systems, Zigbee controlled lights, or HVAC systems.
What are the ranges for these devices? Are they encrypted or protected? What happens when they receive interference? Do they fail in a closed or open state?
The inability to effectively answer these questions (easily or even at all) is the very reason we are releasing the RFTransceiver extension for Metasploit's Hardware Bridge, and why we think this will be a critical tool for security researchers and penetration testers in understanding the actual attack surface.
Now, security teams will be able to perform a much broader assessment of a company's true security posture. They will be able to test physical security controls and better understand when foreign IoT and other devices are brought onto the premises.
Sunlight is the best disinfectant
Much of the activity undertaken in the name of security research can be contentious, divisive, or hard to understand. This is certainly true of RF testing, an area of research becoming both more prevalent and increasingly necessary as we see more and more technologies leveraging RF communications.
The most common criticism of any technology created for the purpose of security testing is that bad guys could use it to do bad things. The most common response from the security research community is that the bad guys are already doing bad things, and that it's only when we understand what they're doing, can effectively replicate it, and demonstrate the potential impact of attacks, that we can take the necessary steps to stop them. Sunlight is the best disinfectant.
This is the logic behind Metasploit, as well as what drives Rapid7's extensive vulnerability research efforts. It is also the reasoning behind the RFTransceiver. We strongly believe that RF testing is an incredibly important – though currently often overlooked – component of vulnerability testing. We believe that failing to test the usage of radio frequency in products puts people and organizations at risk. We also believe the importance of RF testing will continue to escalate as the IoT ecosystem further expands.
To provide an example of this kind of testing, in 2016, Rapid7's Jay Radcliffe disclosed vulnerabilities in Johnson & Johnson's Animas OneTouch Ping insulin pump. The popular pump has a blood glucose meter that serves as a remote control via radio frequency in a proprietary wireless management protocol. Communications between the pump and the remote control are sent in cleartext, rather than being encrypted. This creates an opportunity for an attacker with the right technical skills and resources, opportunity, and motive to spoof the Meter Remote and trigger unauthorized insulin injections.
While Jay considered the likelihood of an attacker exploiting these vulnerabilities in the wild to be quite low, it could seriously harm a patient using the technology. Fortunately, Jay's research uncovered the problem and he was able to work with Johnson & Johnson to notify patients and advise them of ways to mitigate the risk. Without RF testing, these vulnerabilities would have continued to go unnoticed, and patients would not have the opportunity to make informed choices to protect themselves.
How it works
Just one quick author's note before we get into the ‘how-to' portion. Rapid7 does not sell the hardware required to perform RF testing. The required hardware can be found at any number of places, including Hacker Warehouse, Hak5, or any electronics store that carries software defined radios or RF transmitter hobbyist equipment.
With the RFTransceiver, security pros have the ability to craft and monitor different RF packets to properly identify and access a company's wireless systems beyond Ethernet accessible technologies.
The first RFTransceiver release supports the TI cc11xx Low-Power Sub-1GHz RF Transceiver. The RFTransceiver extension makes it possible to tune your device to identify and demodulate signals. You can even create short bursts of interference to identify failure states. This release provides a full API that is compatible with the popular RfCat python framework for the TI cc11xx chipsets. If you have existing programs that use RfCat you should be able to port those into Metasploit without much difficulty. This release comes with two post modules: an Amplitude Modulation based brute forcer (rfpwnon) and a generic transmitter (transmitter).
How to use RFTransceiver
Using the new RFTransceiver extension requires the purchase of an RfCat-compatible device like the Yard Stick One. Then download the latest RfCat drivers, included with those drivers you will find rfcat_msfrelay. This is the Metasploit Framework relay server for RfCat. Run this on the system with the RfCat compatible device attached.
Then you can connect with the hardware bridge:
RFTranceiver Usage |
---|
$ ./msfconsole -q
msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > run [*] Attempting to connect to 127.0.0.1... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-02-16 20:04:57 -0600 [ ] HWBridge session established [*] HW Specialty: {"rftransceiver"=>true} Capabilities: {"cc11xx"=>true} [!] NOTICE: You are about to leave the matrix. All actions performed on this hardware bridge [!] could have real world consequences. Use this module in a controlled testing [!] environment and with equipment you are authorized to perform testing on. [*] Auxiliary module execution completed msf auxiliary(connect) > sessions Active sessions =============== Id Type Information Connection 1 hwbridge cmd/hardware rftransceiver 127.0.0.1 -> 127.0.0.1 (127.0.0.1) msf auxiliary(connect) > sessions -i 1 [*] Starting interaction with 1... hwbridge > status [*] Operational: Yes [*] Device: YARDSTICKONE [*] FW Version: 450 [*] HW Version: 0348 |