​The single software component that contained the vulnerability of the camera, was used by the manufacturer not only in the firmware of the one camera model that we exploited, but also throughout the manufacturer's product line affecting more than just cameras. Furthermore, that same "design" (including the vulnerable component) was repeated by other manufacturers to make devices of all kinds (even desktop software)...all potentially vulnerable to the same bug.

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.

At the annual RSA conference this year, on April 19th, our CTO, Stephen Ridley, and our VP of Research, M Carlton, will take the stage to demonstrate the first ever purely IoT-based lateral attack. We intend to show how it’s possible to daisy chain several compromised IoT devices together -- without touching a traditional computer -- to ultimately get to a company’s “crown jewels”.​ ​(Click here to read Wired's coverage of this attack)

Lateral attacks between different types of IoT devices have been referenced but never before publicly demonstrated. Worms that spread from PLC to PLC (programmable logic controller) are a threat to manufacturing, and botnets that spread from camera to camera have had a huge impact in the last few years. However, attacks taking over a network, device by device, has remained largely within the sphere of pundits and hypothetical discussions.​

Lateral attacks are known to take place in traditional IT environments, which include employee workstations, networks, servers, etc., and are typically well secured. In these attacks computers and networks are compromised, which then allows a hacker to gain access elsewhere, like a server.  Unlike those attacks, we hop from IoT device to IoT device -- no workstations touched -- to gain access to a Networked Attached Storage (NAS) device (yet more IoT) that contains sensitive information.

Our research is an integral part of Senrio culture that informs our approach to addressing IoT security problems. Demonstrating the ability to hopscotch across IoT devices without touching an IT end-point helps us illustrate the very real and persistent risks associated with IoT devices that are in use in a wide range of industries and enterprises today. 

We've had quite a summer thus far. Here seven quick updates:  
​(cue the Bananarama "Cruel Summer" instrumental)

Be sure to check out our photo gallery of the IoT Hacking Village event!

To see the exploit in action, check out our video on Vimeo. For full technical teardown, click here.

Summary
Given the increasingly vital role IoT plays in modern life, we strive to improve the state of IoT security and share the knowledge we gain through our research with IoT manufacturers and users.

Our latest discovery was found in an Axis Communications security camera — the M3004 model. Axis Communications is one of the largest manufacturers of security web cameras globally. In fact, while passing through LAX last week, we saw one of the vulnerable models in use at the airport.

After about a day of analysis, we discovered a stack buffer overflow vulnerability (CVE-2017-9765), which we’re calling Devil’s Ivy*. Devil’s Ivy results in remote code execution, and was found in an open source third-party code library, from gSOAP (more on that later). When exploited, it allows an attacker to remotely access a video feed or deny the owner access to the feed. Since these cameras are meant to secure something, like a bank lobby, this could lead to collection of sensitive information or prevent a crime from being observed or recorded.

Axis informed us that Devil’s Ivy is present in 249 distinct camera models, the exception being three of their older cameras. Once we verified Axis’s fix prevented our exploit from working, Axis quickly began releasing patched firmware and prompting partners and customers to upgrade.

THE IMPACT GOES FAR BEYOND AXIS

The impact of Devil’s Ivy goes far beyond Axis. It lies deep in the communication layer, in an open source third-party toolkit called gSOAP  (Simple Object Access Protocol). gSOAP is a widely used web services toolkit, and developers around the world use gSOAP as part of a software stack to enable devices of all kinds to talk to the internet. Software or device manufacturers who rely on gSOAP to support their services are affected by Devil’s Ivy, though the extent to which such devices may be exploited cannot be determined at this time. Based on our research, servers are more likely to be exploited. But clients can be vulnerable as well, if they receive a SOAP message from a malicious server.

We recently discovered two vulnerabilities in TP-Link’s WR841N V8 router that we exploited to obtain custom code execution on the router. After working closely with the vendor to patch the router’s firmware, we are disclosing the details of our work. 

Our team conducts research into networked embedded devices in order to improve our product and spread security knowledge among the embedded device manufacturing and security communities. The WR841N is the  same router model we use to teach students about hardware hacking in our classes, and the focus of our JTAG Explained blog post. During the process of our research into this router, we found a logic flaw in a configuration service which allowed us to circumvent its access controls and reset the router’s credentials (CVE-2017-9466). We then used our increased access to gain code execution by exploiting a stack overflow vulnerability available through the configuration service. 
​
In this proximity-based attack, we used a smartphone’s hotspot capability to reset the router’s credentials by taking advantage of a protocol that had been removed from the firmware for newer hardware models. Unfortunately, although older models may no longer be supported, they often remain in critical positions. Fortunately, TP-Link agreed to remove the configuration service from this model once we brought the issue to their attention.

We are sharing the details, step by step, in case our work sparks any ideas or discussion regarding proximity-based attacks, unsupported versions, logic flaws in encryption, or vulnerable configuration services. 

​Click here to skip to the full technical details, or read on for a high level summary of our work.

Watch a hardware prep video preview below! 

Our trainings sell out pretty quickly (they are popular and unfortunately, there are limited seats) so if you're interested in participating, sign up below to get details before we make them available publicly! 

Imagine you are handed this device and asked to get root on it as quickly as possible. No further information is given. Where would you begin?  (If you just want to see the router get rooted, jump down to "Mounting an Attack: Rooting a Home Router" ;-)

Since you have the device in your hands, you might try directly attacking the hardware. However, if you've never done any kind of hardware hacking, getting started can be intimidating. In this post, we are going to talk about the fundamental information you need to know to use JTAG for hacking hardware. We'll also go over a quick example to illustrate the power of direct hardware access. ​

​JTAG is a common hardware interface that provides your computer with a way to communicate directly with the chips on a board. It was originally developed by a consortium, the Joint (European) Test Access Group, in the mid-80s to address the increasing difficulty of testing printed circuit boards (PCBs). JTAG has been in widespread use ever since it was included in the Intel 80486 processor in 1990 and codified as IEEE 1491 that same year. Today JTAG is used for debugging, programming and testing on virtually ALL embedded devices. 

In our last post we talked about a vulnerability discovered in the D-Link DCS-930L Cloud Camera. Since then the Senrio Research Team has been working closely with the D-Link Security Incident Report Team. Below we disclose technical details of our efforts.