In March this year, a curious issue was discovered on the Miele Professional PG 8528, a professional medical washer, that caught the attention of news outlets: “The corresponding embedded webserver "PST10 WebServer" typically listens to port 80 and is prone to a directory traversal attack;” the security flaw statement revealed, “therefore, an unauthenticated attacker may be able to exploit this issue to access sensitive information to aid in subsequent attacks. A Proof of Concept is GET /../../../../../../../../../../../../etc/shadow HTTP/1.1."
Having operated a washer professionally in a former life (a dishwasher not a medical washer), I can personally tell you that my peers and I would occasionally troll each other by altering the hot water setting at closing or during shift changes, thereby torturing the openers with a higher need for vigilance.
This flaw begs the question: why is the washer on the Internet? Answer: because the washer is now a computer, and it costs very little to put another computer on the Internet.
So why is the washer a computer? Because the washer was always a computer.
Even the ancient constantly-breaking-down dishwasher I operated in the mid-90s (mostly by hitting it with a large metal ladle because it was too hot) was, in fact, a computer. It had a tiny 4-bit microcontroller that set the duration for a wash cycle and the water temperature. Had WiFi been available I’m sure someone on the grill line would have found a way to remotely change the temperature mid-shift just to mess with us.
Today history repeats itself. The type of bug in the CVE, or Common Vulnerabilities and Exposures Identifier, listed above was very common in late 90s and early 2000s-era web applications. The flaw’s commonality was a result of two factors.
First, most designers of systems and programs did not fully understand the proper way to isolate application processing space from system resources. Second, the glory of the first Internet boom was happening and insecure computers, web servers, and application were being connected to the Internet at an astonishing rate. Back then, CodeRed and Slammer were the result of putting indefensible computers onto the Internet too fast. Thankfully the majority of folks back then were only dealing with mostly curious Y2K-era hackers.
Since then nation states, organized crime, and many others have entered into the fray. They’ve invested time and resources over the last 20 years to get better at exploiting those systems. Conversely, many device manufacturers have not spent the last 20 years creating fast patching systems, modernizing the principles of hardening, or implementing the Secure Development Lifecycle (SDL) as part of their product cycle. Instead, they've focused on making a better washers and other devices.
As a result, we are spinning around both surprised that 2000s era computers with the same kinds of bugs keep showing up on the Internet, but more importantly trying to defend 2000s era computers from a 2017 level Internet.
To keep moving forward in closing the gap between our personal lives and the Internet, we're going to have to keep testing things as if they are about to face the hackers of their era and not from two decades past. This is just the way it is.
Of course, we should all want a tomorrow filled with computers and devices connected to the Internet making our lives easier, more connected, and safer. To build a safer more connected tomorrow we are going to have to change how we build devices today. Here are four ways our industry can attack this issue right now:
Treat every device as you would any other computer
This is key. You’ll develop an appreciation of the vulnerable nature of your devices if you remember they are, at heart, computers. And you’ll think of that computer when making decisions about the device, how to integrate it into the network, what steps to secure it, what requirements you want from the vendor for maintenance, security, and life cycle. Tesla makes a computer that happens to be a car. Roomba makes a computer that happens to be a vacuum cleaner. Apple makes a computer that happens to have a phone application installed.
Understand that devices will face the same kind and level of attack as other computers on the Internet
Just because you don’t store sensitive information or electronic money inside your dishwasher’s computer, yet, doesn’t mean it’s not exposed to attack. Motives are as numerous as the number of attack surfaces – no fridge is exempt. Most devices are not specifically targeted. Attackers treat them like any other resource and they are exploited in mass to be resold as part of botnets or specific attacks. Recently the computer that controls a casino fish tank was exploited and then used to send data from the casino internal network.
Integrate the SDL into the design of devices early in the creation process
We’ll get much closer to a safer interconnected world once more manufacturers integrate secure development lifecycle and robust DevSecOps frameworks into their testing and development. Security should be part of the design process, not an afterthought: integrate SDL best practices into your product design and creation processes. Companies that have adopted the SDL into their development life cycle have seen improvements in their product security and an overall reduction of threats. As a result of the SDLC there were “91% fewer vulnerabilities observed in SQL Server 2005.”
Always be forward looking. Anticipate and expect attacks from nefarious actors in the future
Once you start considering multiple attack vectors and approaches, you can start anticipating new attacks before they appear. And once you anticipate them, you can prepare for them and help shape the security landscape rather than get trapped in it. Having a solid understanding of how your devices extend your network and what they need to be managed helps you anticipate where attackers will move to in the future. In the case of Target not understanding how different devices extended their network allowed attackers to pivot in through their HVAC system.
Let’s welcome the interconnected future, and we should all do our part to ensure that safety and security play a primary role in the development of ideas into needful devices apps and services. In this way we all have a hand in limiting the dangers posed by nefarious (and sometimes sudsy) threat actors.