Researchers have demonstrated how to breach Internet of Things (IoT) devices through firewalls, without the need for any kind of software vulnerability.
Typically, hackers breach IoT devices by obtaining their IP addresses and exploiting firmware vulnerabilities. This works well against organizations that, due to ignorance, disregard, delay, or genuine inability, can’t apply patches in time to protect themselves. Businesses that don’t expose their devices to the Web and patch diligently can rest easy knowing that hackers don’t have a way in.
Or maybe not. In an upcoming presentation at Black Hat Europe in London, Nanjing University of Posts and Telecommunications master’s candidate Jincheng Wang and independent security researcher Nik Xe will propose an entirely new model for taking over IoT devices. In their proof of concept (PoC), an attacker can breach devices en masse without any vulnerabilities present, or even any IP addresses — and it works just as well against intranet devices.
The key is cloud management — leveraging the trust between devices and the cloud vendors that oversee them.
How IoT Devices Authenticate to the Cloud
How can you prove that you are you on the Internet? If you’re on a government or finance website, it might require a slew of personal information and officially issued identifying documents. A dating app might require a biometric face scan. On a social media forum, you can just take a selfie with today’s newspaper.
Now imagine an IoT device deployed at an organization — a router, if you wish — managed through a cloud platform. How can that device prove that it is itself to the cloud server that oversees it? Devices designed for specific, narrow functions have no sophisticated ways of authenticating, so IoT cloud servers can work only with the static data that distinguishes them from other devices: namely, their serial number (SN) or MAC address.
This was the starting point for Wang and Xe’s PoC. If cloud servers authenticate IoT devices using their SNs or MAC addresses, an attacker would need just two pieces of information — the number or address, and how the server derives an authentication credential from it — in order to impersonate a device to the server.
Getting an SN or MAC address isn’t always challenging. Some manufacturers expose them through network interfaces, Wang reports, because “many manufacturers still do not treat serial numbers or MAC addresses as sensitive information,” and sometimes they’re exposed by Wi-Fi access points, as “when an app binds a device within a local network, it typically retrieves the SN or MAC address through specific local service ports. Since most manufacturers do not restrict these interfaces, the same endpoints can often be accessed from the public Internet, allowing anyone to obtain the device’s unique identifiers remotely.”
These identifiers can also be brute-forced. SNs usually follow a standard pattern derived from the device type, model, etc., and then only the last handful of characters might be unique to any particular device. And half of a MAC address is simply an IEEE-assigned manufacturer’s code — only the latter few bytes are unique to any device.
To round out the impersonation, an attacker can extract and analyze the cloud communication logic stored in a targeted device type’s firmware, and reverse engineer the operations that the vendor performs to transform the identifier into a credential.
The Risk to Organizations
With its unique identifier, and the operations used to authenticate it to its cloud server, an attacker can impersonate any targeted device to a cloud platform.
At this point, Wang explains, “this impersonation will compete with the victim’s legitimate cloud management channel, thereby bypassing the binding authentication enforced by the app or the cloud platform. Then, by disconnecting the impersonated channel, the attacker stops competing with the legitimate connection and allows the victim’s original channel to recover.” As a result, the attacker can establish a session that allows them to communicate administrative commands through the cloud service, which then relays their commands to the actual device being impersonated. That holds even if the real device being impersonated runs behind a firewall, or even if it’s totally disconnected from the wider Web within an intranet.
The only way to prevent this kind of attack, the researchers say, is to fundamentally change how IoT devices authenticate to cloud management services. For example, cloud management platforms can implement checks for when device IP addresses change, and require additional authentication in such cases. Or, better, device credentials can be generated using more than just an SN or MAC address: “They can create a random number as a UUID, and this number is binded with the [cloud management] app instead of a serial number or MAC address that is easy to brute force. This number would be random, and unknown to attackers,” Wang says.
Though his attack model is new, Wang adds, “commands sent by attackers through the cloud are hard to distinguish from the normal traffic. With this attack model, tracing the attackers is difficult, and any incident can create a big reputation or legal risk for manufacturers, so they tend to quietly fix issues rather than disclose them. So the lack of public, large-scale cases does not necessarily mean [similar attacks] are not happening.”
He thinks that “these cloud channels are still widely overlooked. They affect many devices, are hard to patch, and any attackers [and] any attacks through them are extremely difficult to trace.”