As previously noted, attacks that take over a network, device by device, has remained largely within the sphere of pundits and hypothetical discussions. So we have tended to think about lateral attacks as being solely within the realm of sophisticated attackers, but as we explored this project in more depth, we came to realize that this kind of attack requires very little technical knowledge.
While we are not aware of publicly available exploits for the vulnerabilities we discovered, products like Metasploit allow those with a basic knowledge of networking and the Linux command line to do some damage without writing a single line of code. After exploiting a first device, an attacker can use the additional access to take over the rest of the network, exploiting device after device.
Setting the Stage
We connected the camera to a TP-Link router vulnerable to CVE-2017-9466, which you might find in a small business or home office environment. When we released this vulnerability last year, we used a proximity-based attack, but noted that it was possible for an attacker to exploit it without proximity by using a rainbow table. That would need to be the case here, as our attacker would literally be on the other side of the country, and could be on the other side of the world.
We built out the network from the router, preventing any device from talking directly to any other device as a reasonable security precaution you might find on an Operational Technology (OT) network. We also added some simulated company information on the NAS device as the goal for the attack, including a list of employees’ names and personal information, as well as company financials and sales data.
Step 1: Exploiting the Camera
As described in our previous work, we exploited Devil’s Ivy to gain custom code execution, then reset the camera to its factory default settings. We visited the webserver to set a new root username and password which allowed us to view the feed and ssh into the camera.
In this scenario, the camera was installed on the ceiling of a small office through which we could watch the keystrokes of an office employee as he goes about his work and logs into the NAS sitting next to him.
Step 2: Detecting the Router
We used the command ‘ip route’ to get the default gateway IP address. If ‘ip’ or an alternative were not available on the device, we could have also attempted to ping common router addresses, but that would have risked giving our position away. For a discussion of more advanced solutions, see the later section on Shells & Shellcoding.
In the real world, an attacker might check a database of exploits and see that there is an available exploit for this model, but only if it runs an older firmware version. Determining what firmware a device is running can be difficult. However, TP-Link’s patch for the vulnerability we discovered in its tddp service removed the entire service from the device. This meant that the easiest way to check if the router was vulnerable was to test the service for a response.
Since the camera did not have any scripting languages installed, we copied the message to the camera as a text file, then used netcat to send it to the router and receive the response. We sent the response back to our home computer for processing. Not only did the router’s response tell us that the service was running, and therefore vulnerable, but it also gave us the router’s credentials.
Because the plaintext version of the responses from the service were predictable and encrypted with a key that relied on the device credentials, we were able to compare the response to a rainbow table we generated, and discover the username and password. After getting a match, we had all the information we needed to exploit the router.
Step 3: Compromising the Router
Step 4: Circumventing the Rules
If we were to run a packet capturing program on the NAS like Wireshark, this would look like the NAS was only communicating with the router. While routers don’t typically ssh into devices, traffic must go through the router in order to reach devices, so this is far less likely to set off any alarm bells than simply allowing the camera direct access to the NAS.
Step 5: Accessing the NAS
We used scp to exfiltrate the files from the NAS to the camera, and then scp again to exfiltrate them home. If these files had been encrypted with a secure algorithm and good password, we would have had more trouble accessing their information. It’s possible that we could have stolen the keys in the same way we obtained the NAS credentials, but it’s also unlikely that the files would have been encrypted. Because files stored on a NAS are intended for multiple people to access them, assigning secure passwords that everyone will remember becomes much more of a hassle. However, securely encrypting files is a simple thing that could help prevent an attack like this.
For example, instead of interacting with a command line on the camera, we executed code that would immediately attempt to ID the router and respond home with the model number. In response to the model number, the script found shellcode in its database that the camera could run to request the encrypted string from the router. After receiving the encrypted string and determining the credentials from the rainbow table, the script sent the camera the exploit code for the router and set up a listener to respond with the intended second stage when the router called home.
Automating this attack avoids human error. Even a typo can give a hacker away, for example by forgetting to specify the correct port on the router (something we did multiple times). They can also be useful in the case of attempting access to a device. In a scenario where we could not see an employee enter their password to the NAS, we could instead write a script to try common usernames and passwords until it got in or exhausted its list. In this way, an attacker could systematically attack each device on a network with very little effort.
However, a script could also result in a lower chance of success and less stealth. Scripts are not prepared for unexpected responses that would not phase a person. For example, an unexpected response from the router’s webserver could cause a script to fail, whereas we would simply attempt the request again for a proper response.
Shells & Shellcode
We could have chosen to do more of this outside of the command line if we were not trying to keep it as simple as possible. This would still allow access to programs like ssh and scp which would be available on the camera through syscalls like system() and execve(), but would also allow for lower level tinkering. If netcat had not been available on the camera, it would have been much easier to send packets using assembly code.
One alternative to writing shellcode for devices with an embedded OS is to write programs that can be be uploaded and executed on the device. The hurdle to jump here is determining the compiler and identifying all the necessary libraries for the compiler. Though ultimately highly useful, this takes more effort than simply interacting with the device’s command line interface and we chose not to pursue that path for this scenario.
This project taught us that every IoT device on a network occupies a critical position, even though it might seem to have a small impact. Each device granted us more access to the network and more information about the company. From the camera, we could watch what it was meant to protect. This granted us access to the NAS and ultimately to the company’s vital information. The router, while lacking functionality to allow us to connect directly to the NAS, granted us permissions to change network settings and forward traffic from the camera to the NAS. Although the NAS was reasonably well secured, the protections were insufficient to prevent an unskilled, though determined, attacker from walking off with the company’s crown jewels.