We all know by now that IoT is vulnerable, and after our survey of vulnerable remote configuration services last year, we began to pursue the actual repercussions of those vulnerabilities. After we published Devil’s Ivy and CVE-2017-9466 last summer, we decided to tackle the problem of “then what?” After an attacker compromises a camera or gains control of a router, what happens next? If a company’s valuable data is in a secure location, does it matter if an attacker compromises its Nest thermostat?
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.
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 set up a small network containing IP security cameras, basic networking equipment, and a Network Attached Storage (NAS) unit. We installed an Axis camera with an older firmware version still vulnerable to Devil’s Ivy to serve as our initial attack point. We approached this in as realistic a manner as possible, only exposing ports 443, 80, and 22 to our attacker. This restricted our attack in a real way, but did not have a profound impact on the difficulty of the attack.
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.
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
IP security cameras are often exposed to the public internet. Last summer, a Shodan search turned up about 14,700 Axis cameras alone. This year that number is down to around 4,400, a vast improvement likely due to increased user education and tools available to security view feeds remotely. That still leaves several thousand Axis cameras available remotely, but there are many tens of thousands more left exposed from other vendors.
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.
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.
This camera could be watching anything. A company lobby, a hallway, or an office, for example. In particular, we thought of the security cameras prevalent in the front foyers of businesses, set up to watch not only those entering and exiting the building, but also the front desk workers at their computers. If those guards entered passwords, an intruder viewing the feed could easily collect their finger strokes and decipher the credentials.
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.
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
Once on the camera, we still didn’t have access to the rest of the network because the router prevented the camera from talking to any other device on the network. However, we did have access to the router itself. The camera came with a variety of Linux command line tools, including ‘ip’, ‘netcat’, and ‘curl’, all of which we put to good use. This is not unusual, many devices run on embedded Linux and contain a variety of networking and debugging tools used during development and for diagnosing problems in the field.
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.
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.
Having obtained the router’s address, we used curl to get the http headers from the router’s webserver. More often than not, these headers contain a device’s full model number in the basic realm field, and occasionally the firmware version as well. This TP-Link router only returns its highest level model number, but that gave us enough information to move on to determining if it was vulnerable.
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.
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
To exploit the router from the camera, we used netcat again to send the malformed message to the router’s service. This exploit involved two stages. The first stage gained initial code execution and called home for the second piece of code to run. This allows for more flexibility, as we were initially restricted in the values of characters we could send, and avoids any size restrictions. We set up a netcat listener on our home computer to serve the second stage to the router, which, after executing the second stage, connected back again with a remote command line interface.
The main pitfall with this exploit is that if it fails, it cannot simply be run again, as the service crashes and will not start again until someone restarts the router. For an attacker with stable remote access, time, and patience, this isn’t a problem. The service also crashes the webserver, which would eventually prompt whoever next tried to access the web interface to restart the router. For an attacker in a hurry, say where physical proximity or time constraints are involved, a failure here may mean going home empty handed. This exploit worked most of the time, but anywhere there are long network latencies and multiple calls home, an attacker may run into problems.
Step 4: Circumventing the Rules
With access to the router’s command line, we used ‘iptables’ to forward traffic entering the router on a certain port to the ssh port of the NAS. We needed two rules for effective communication, one to forward traffic to the NAS and a second to change the source of the responding traffic to the router IP. After inserting these rules at the top of the rule chain, we were able to connect to the NAS from the camera with the command ‘ssh -p 5678 [NAS-username]@[routerip]’.
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.
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
After using the stolen credentials, we had a commandne interface on the NAS that gave us full access to the filesystem. We were able to explore each users’ home folder and read all unencrypted files. These devices are designed to store information shared between a group of users, and could contain sensitive and proprietary information, such as employee lists and financial data.
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.
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.
Automation
This attack relied on having a human in the loop, deciding and guiding each step. Part of that was intentional, we wanted to see how simple we could make a lateral attack between devices. We experimented with automation though, using a python script to receive information and send new stages of shellcode based on the responses.
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.
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 chose to interact with the built-in command line of each device because it was the simplest way to control the device and move to the next stage. However, many parts of this attack could have been executed in 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.
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.
Conclusion
This attack strings together exploits from device to device, but does not require a particularly knowledgeable or sophisticated attacker. IoT exploits are increasingly available publicly, along with instructions on putting them into action. They are built into tools like Metasploit and available on Github. These kinds of public exploits may only grant an attacker access to the command line tools available on the minimalistic embedded operating systems running on these devices. As we have shown here though, these basic tools are more than sufficient to conduct a lateral attack.
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.
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.
RSS Feed