Here’s how hackers can compromise your network via routers that aren’t protect with IoT device security
Intro
Security for the “Internet of Things” (or IoT) is still relatively new to a majority of organizations. Understanding IoT firmware security will help protect against device attacks that target weak networked devices like IP cameras, routers, smart meters, medical equipment, and more. For the sake of this blog, we’ll define an IoT device as any piece of hardware that connects to any kind of a network.
Currently, there are two approaches to protecting IoT vulnerabilities: Network Security and Device Security. Both approaches provide protection on different levels, while Network Security constantly monitors the network and protects against attackers gaining control over the network laterally.
What is IoT Device Security
IoT Device Security generally refers to an on-device installation in order to protect the device. Typically, manufacturers install a software package on the device itself which allow the entire security suite to stem from metrics and instrumentation techniques that run on the device. It protects against attacks trying to gain control over the device, and transitively, the network.
CP<R> have recently published papers that showcase several vulnerabilities found on IoT devices like a hacked fax machine, a ransomware-infected DSLR camera, or even an instance where an attack achieved complete control over a smart lightbulb hub (video: https://www.youtube.com/watch?v=4CWU0DA__bY). All of these examples involved deep, intricate exploitation techniques that found vulnerabilities in the device firmware and allowed attackers to gain full control over these devices.
In the video below, you can see a real-world example of Check Point IoT Protect Firmware working with an off-the-shelf router with a zero-day vulnerability in it, leveraging the Check Point Nano-Agent technology.
As an organization, security is only as strong as its weakest point. It is important to understand that even an innocent router can be a vulnerable point of access in the network. Leaving network devices unmanaged can compromise the entire network and allow attackers lateral movement within the network.
To demonstrate this, we will show how a hacker can infiltrate a commercial off-the-shelf router via an IoT exploit to gain control of a network. Using the control gained over the router, the hacker can gain control over additional assets in the internal network. In this specific case, the hacker obtains the feed from an internal security IP camera.
The vulnerability exploited is CVE-2020-10923, reported 28 Jul 2020. It is a stack-based buffer overflow in the software update process. As for security features: ASLR not enabled but stack is not executable.
The vulnerable function is abCheckBoardID(). It receives an arbitrarily-sized user input from the network interface. It is pretty easy to see how the parsing logic unpacks the big-endianed (lines 26 – 28 and 32) size field from the user input, finally using it to copy from the user input itself. Unfortunately, there are no size checks prior to the memcpy() call (line 35), resulting in a potential stack-based buffer-overflow for sizes larger than 140 bytes (variables allocated in line 15).
A full exploit is easy to find with a simple search: https://github.com/grimm-co/NotQuite0DayFriday/tree/master/2020.06.15-netgear. Although it initially crashed the router for every exploitation attempt, it did not work fully out-of-the box and some modifications were necessary to make the exploit script fully functional.
The exploit sends a padded packet with a length of 0x400 and a call to a ROP gadget. A quick lookup for this ROP gadget is revealed to be at 0x3cfb4.:
Now, all that’s left is to make sure that an arbitrary command is located at the top of the stack and overflow the return address with the ROP gadget address. Eventually, the exploit packet looks something like this:
The first four bytes are the marker, representing the packet start (line 20 in the code above), followed by the big-endian encoding for 0x400 as size. Following this is the buffer content (char s[140] defined at line 15), ending with the content for registers r4-r11 popped from the stack. This is then followed by the rop_gadget, spawning a telnetd instance exposing a shell.
After modifications and execution, the exploit grants the attacker root access to the device:
Nano-Agent: Install and Protect
As seen above, the exploit script is quite simple. Once triggered, it guarantees a 100% success rate. However, we are in the business of protection, not exploitation. So, let’s use the exploit to harden and protect the device against these types of vulnerabilities (and more).
The first step is to generate a hardening file for the vulnerable httpd server. This is done using the Infinity Next cloud app:
Using the above API, the hardening script sends the httpd binary for scanning in the cloud app and generates a scanId. This scanId can be used to query the scan status as well as download the analysis file.
Once scan finishes, download the hardening file using the scanId:
Analyzing the assembly with the hardening file reveals that the hardening service detected the potentially vulnerable function abCheckBoardID and decided to harden it, marking several of its instructions as instructions that require hooking and instrumentation:
In this case, the prologue hook will record the lr value and safely store it in a per-thread shadow stack. Upon executing the epilogue hook (right before executing the actual instruction in offset 0x1cf18), the Workload Protection will check the current stack value that is going to be popped to pc and verify it matches the value stored in the prologue hook on the shadow stack.
On the device, running the nano-agent installer ./install-cp-nano-agent.sh, using a token generated in Infinity Next, initiates the Nano-Agent installation process, which in turn downloads and installs the IoT Workload Protection:
Then, running the hardened httpd initiates the hardening process:
Now, once again running the exploitation leads to the prologue and epilogue hooks triggering the epilogue hook that detects deviation in the control flow. It is clear to see the Workload Protection detected the exploit’s attempt at branching to 0x3cfb4, to execute rop_gadget like demonstrated before.
Finally, the log is detected and sent to Infinity Next where all devices are managed.
Conclusion
Unfortunately, there is no way around the fact that IoT devices will continue to be inherently vulnerable. This is due to the simple fact that device manufacturers are proficient in making these device work as intended, for convenience. However, their expertise is within their field of work, while security expertise is often a completely orthogonal field.
If you build embedded consumer and Internet-of-Things (IoT) devices, the expanding threat landscape requires you to protect your customers from cyber attacks with out-of-the-box firmware security.
From IP cameras and smart elevators, to routers, medical devices and industrial controllers, Check Point IoT Protect Firmware provides on-device runtime protection against zero-day cyber attacks – serving as the most powerful line of defense for your IoT devices. If you want to learn more about IoT firmware security and how you can protect your network from IoT device attacks, check out our web page.
