Stackoverflowin: The Story of How IoT Broke the Internet

Image

Recently, an incident commonly referred to as “stackoverflowin” swept social media. On February 4, 2017, a 17-year-old hacker from the UK using the alias ‘stackoverflowin’ decided on a whim to do some printing. He printed quite a bit. In fact, he printed so much that it started to trend on Twitter. That’s because he printed to every open printer on the Internet. This incident turns out to be a perfect way to tell the story of bad security and how the Internet of Things (IoT) broke the Internet. To tell this story, we first need to understand some of the technical details of how the ‘attack’ was carried out. It was fairly simple. Here are the steps:

1. Find all the printers on the Internet that will let you print to them.

To do this, an attacker would want to find every device on the Internet that has one of the common printing ports open. These ports being open means that anyone can talk to the printer over (typically) either RAW or LDP (Line  Print Daemon). RAW and LPD are both protocols for handling print requests over a network. This is a process similar to how your computer finds printers on your local network but applied to all of the Internet. There are many tools an attacker could use to do this – doing so would take anywhere between a few hours and two days.

2. Print to the printers you find.

I will not get too deep into the weeds on how this is done, but here is a high level overview of how this works on a low level. An attacker could send a print request using either RAW or LPD. All that is required to do this is for an attacker to send an LDP or RAW packet to the printer with what they want the printer to do. The printer then translates this into an image that it can print. For the sake of time an attacker would likely script the process of sending  print requests by sending the same print request to a list of printer. This would likely be done with a short program written in a scripting language like python. For those of you who are curious about how hard this would be to make, such a script would be about 10 lines of python.

3. That’s all. No really, that’s all.

Let’s recap. An attacker can print to ~200,000 printers by finding all web-connected printers and writing a 5-line script. That’s it. An attacker only has to send between 200,000 and 400,000 requests to print to every printer on the Internet, and doing so would take around 15 minutes. Now onto the important questions...

Why does this matter, and how does this break the Internet?

When you have something like a door lock, we accept some degree of insecurity, and that is fine. We all can sleep well with the understanding that if someone really wanted to, they could pick the lock of our front door, but that actually happening is very uncommon. We have this level of insecurity; not everyone's home is broken into all the time. Well, it would seem that we have copied how we think about physical security to how we think about cybersecurity, and in so doing, we’ve ignored some of the key differences between the two. The key point where cybersecurity is different from physical security (why your webserver has to be more secure than your door) is that your door is not accessible by everyone everywhere all the time with little accountability. However, a world where anyone, anywhere – with very little accountability – could try to pick your front door and law enforcement was ill-equipped to find the perpetrator would require far-better locks. In short, you don’t want to put your front door on the Internet unless you’re are very sure it is secure or don’t care about what’s behind that door. In the case of stackoverflowin, these extremely insecure doors ended up on the Internet open to anyone to attack. While they were not attacked, simply used, it is certainly indicative of the reason we should all be wary of IoT. The Internet of Things puts millions of devices with poor security on the Internet with little opportunity for said devices to be patched. (When was the last time you patched the firmware on your router?) In short: services like LPD/RAW were not built to be put on the Internet per se and as such are not very secure. IoT and hardware-specific software are perhaps some of the least secure things on the Internet. Take printers, for example. There are a number of known, public vulnerabilities in common implementations of LPD dating back to 1999 that affect or affected most or all major vendors. This means that any motivated attacker who can print to a printer can likely execute code on that same printer. An apt observer may look at this and suggest that people should simply password protect their printers. As it turns out, you can’t; there is no way to do this because authentication is not a part of the LPD protocol. Why? The people who developed LPD in 1990 never thought it would end up on the public Internet. However, this is about more than just the single device. When you have a vulnerable device on your network that is exposed to the Internet, this gives an attacker a foothold in your network. Exploits like these have been widely used across the Internet. If you’ll recall the (Target) breach, the attackers gained access to the company's internal network via a printer. In short, if someone can print to your printer, they can probably control it. This leaves open the following question: why are all these printers not in a massive botnet (that we know of)? The short answer is that there are far easier targets and lower hanging fruit than printers. The main reason that we currently do not see massive botnets of printers is because there is an accidental security through diversity. Of the 200,000 printers that can be accessed, there are probably 25 different brands. Although there are likely many vulnerabilities in all of these implementations of LPD/RAW, it’s just not that easy to make a botnet out of these. An attacker would have to find the firmware for all of these printer versions, decompile it, poke around for flaws, and write an exploit for each of the printer versions. All of this could take months or even years. Right now, the most powerful of botnets are variants of Mirai, an IoT botnet. The way Mirai originally spread was by scanning the whole of the Internet for anything running SSH or telnet. These are both things that allow an authenticated party to control a device using (commonly) bash or something similar (zsh, etc). Once these scanners have found a device running SSH or telnet, they try to login with common default credentials that are commonly left on devices by vendors. If the scanner successfully logs in, it uploads a small program to the machine. This program checks in with a command-and-control (C&C) server and subsequently runs commands it receives from the C&C like HTTP flood, UDP flood, SYN flood, and a myriad of other means of DDoS.

What can you do with this?

These bots are mostly only used to execute DDoS attacks, which are typically pretty powerful due to their scale. One such attack was credited with taking all of Liberia offline. (There is some contention as to whether the country was fully offline, but everyone agrees there was a significant impact on connectivity from the area.) Previous to this, the same botnet was used to attack DynDNS. DynDNS is a company that manages DNS (how your computer knows where a given domain lives) for many large companies. This attack resulted in roughly half a day of downtime or inoperability for a number of large sites like Twitter, The New York Times, Spotify, Reddit, PayPal, Netflix, and others. As time goes on, we are seeing more and more of this style of attack, hundreds of thousands of compromised hardware products being used to generate massive DDoS attacks. And this is likely only the beginning. We are currently seeing within black hat communities a vicious fight over control of these devices. There are new strains of malware that try to maintain exclusive control of a machine by killing other instances of malware, as well as malware trying to disable SSH and telnet so nobody else can get into a device. Some criminal entrepreneurs look at this and see opportunity in the form of scarcity; they see a commodity that is in demand with dwindling supply. This is how an industry is formed. For instance, around black hat forums and markets, there has been a new trend of selling “Private” Mirai bots that instead of being obtained through password guessing (ultra low fruit) are obtained by IoT device vulnerabilities (low hanging fruit). This style of IoT botnet is an emerging technology and an en emerging criminal industry. Currently, we are seeing a trend towards larger and larger attacks as this industry grows. It is not unreasonable to think that attacks will continue to become larger and more damaging. Therefore, we have the titular phrase, “IoT broke the Internet.” With that said, we can now discuss the structural security issues in many IoT devices that lead to them being so frequently vulnerable to simple exploits, as well as how these structural issues can be fixed.

What’s wrong with IoT?

The most useful aspect of IoT insecurity is understanding how these devices came to be so insecure. In my experience talking to people in the IoT industry, there seems to be five major reasons that are commonly brought up as to why IoT devices are so frequently insecure.

1. IoT devices are just that: devices.

IoT devices are hardware innovations and are made by hardware companies; the software and firmware just makes it run. There is little thought put into software and firmware of a device as long as it runs on the hardware and the UI is pretty.

2. Vendors don’t really care about security.

If you’re even in a room with a plurality of IoT security researchers and you ask them how they feel about hardware vendors, you will primarily hear a string of expletives, but in between these obscenities, you will hear that vendors don’t care about security. I’ve heard from many researchers and experienced myself (more on that in a moment) that hardware vendors don’t care about vulnerabilities until they get some sort of public attention. Even then, vendors are often hostile.

3. Vendors can’t fix vulnerabilities.

This is a little bit less common but still somewhat frequent and gives a good view of how IoT software is made. Oftentimes, vendors simply outsource their software production to third-parties in a one-time contract with limited support. This means that in order to fix a vulnerability, they would have to set up a new contract. This comes with a lot of bureaucratic baggage and is not cheap, per se. (Story time: One encounter I had with these kinds of issues is when I found a bug in an IP camera. I reported the bug when I found it, which was about two years ago, and got no response after numerous attempts to contact the vendor. When I began writing this article, I decided to report and publicly disclose the vulnerability, so I could learn more about how IoT companies deal with security issues. After disclosing the bug, I almost immediately received an email from the vendor asking me for help unpacking its own firmware. Our correspondence concluded with the vendor explaining to me why it felt the bug was a non-issue and was not going to fix it.)

4. Patching.

Even if a vendor cares about a vulnerability, they may not be able to fix it. Even if a vendor can fix a vulnerability, they might not fix it. Even if a vendor does fix a vulnerability, they probably don’t have over-the-air patching. Nobody wants to spend 20 minutes of their day patching their toaster, lightbulb, router, dishwasher, etc. if it’s running fine. If a device does not automatically update without any user interaction, that device is likely never going to be updated.

5. Services running on a device facing towards the world.

Finally, and most importantly, IoT devices have Internet-facing functionality that is accessible to everyone. The point of the Internet is to move, process and transform information. To do this, we have software that takes in information, does something to it, and returns something. This is what mostly all software does. For this reason, (And this is a vast oversimplification.) most vulnerabilities in software come from being able to give a piece of software data formatted in such a way as to make the program do something it should not. The more ways an attacker can give a program data and the more the program processes the data, the more susceptible it is to being broken and subsequently exploited. Put simply: The more functionality an unauthenticated party has access to, the greater likelihood of a vulnerability. Thus, if we want to make more secure systems, we want to have less surface area that can be accessed by unauthenticated parties. Take the Netgear R6000 and R7000 routers, for example. They run web servers that are largely accessible to anyone anywhere. This means that if there is a vulnerability anywhere in the web server Netgear built, anyone anywhere can control your router. In the case of the Netgear R6000-R7000, there was a vulnerability discovered in 2016 that allowed anyone who could interact with the router's web server to execute bash commands on the router. This can be done by (this is not a joke) sending a request to the router with a semicolon in the url.

Given these issues, how do we fix this?

There is a simple solution to all the issues brought up above. To avoid issues like this, IoT vendors should really be looking towards an API-based model; they should have their devices phone home to a centralized place managed by the vendor. This fixes issues 4 and 5. Indeed, it makes it trivial for a vendor to do automatic updates because the infrastructure to communicate with every device already exists. This also fixes the issue of there being attackable surface area that anyone anywhere can attack. When you have a device that is sitting out on the Internet, you have a device that can be attacked by anyone anywhere. When you have a device that communicates back and forth with a centralized mothership, you have a device that only can be attacked by the centralized mothership that it is communicating with. This means that we also (mostly) solve for the first three issues, it doesn't really matter if a device has a vulnerability if only the company selling it can exploit it. (It’s not optimal, but it’s certainly an improvement.) Now this sounds very simple to do, and for a large company it is. So, why doesn’t everyone do it? The main reason that you don’t see this structuring of IoT devices and their infrastructure is cost. From a business perspective, just looking at maximizing profits and minimizing costs, it’s almost foolish to have a model like the one I just described. The reason for this is that IoT companies are selling you a small computer that can do everything they need it to. There is no reason to spend lots of money hosting infrastructure that the end user can host on the device you’re selling them with little added friction for them. The result of this is that vendors save money but at the cost of contributing to botnets and giving attackers potential footholds into their customer's network. As it stands, if it’s reasonable and cheap to have the device host the infrastructure, a company likely will. These kinds of decisions are cost-centric. With IoT vulnerabilities often leading DDoS attacks that affect many many people, this seems to be a case where a company’s bad security practices end up costing the world as a whole. Many would suggest that such a scenario would necessitate government intervention. While I am not a policy person, I would say that bills like the recently introduced "IoT Cybersecurity Improvement Act of 2017" seem like a step in the right direction towards changing the cost-benefit analysis for companies that make insecure products.  

Image

About the Author: Nick McKenna is a student researcher who has had an interest in cyber security for the past five years. Nick likes seeing how things work and trying to break them. If you have any questions, you can contact Nick here. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.