When I’m having trouble finding a topic for a blog post, I often look for articles about recent security failures in IoT (Internet of Things) products. I’m rarely disappointed. For example,
- A moderately complicated vulnerability in a digital signage product that consumers typically connect to the Internet without changing the default password. This is a privilege escalation vulnerability that gives the attacker full administrative access to the device. The vendor is apparently in the process of addressing the vulnerability, but it’s almost certainly up to the consumer to apply a firmware update. Many of the people who bought this device probably won’t apply, or even be aware of, the update.
- INTERNET-CONNECTED HOT TUBS. Yes, a company made what was probably a last-minute decision to add a remote control feature to their hot tubs. But, predictably, they didn’t secure the feature, so it’s possible for your neighbor to operate your hot tub via Wi-Fi. They could run it at full blast and leave you with an unwelcome electric bill, or they could make the temperature so low that you won’t want to use it. There’s even a way to do those things remotely through the tub’s internet connection to a cloud service (although the attacker wouldn’t know whose hot tub they’re controlling).
The one that was most interesting to me was about some GPS-enabled smartwatches for children, products that are supposed to give parents a sense of security. The researcher found a serious vulnerability by using software called an intercepting proxy. An intercepting proxy is software that you run on your computer, and if you configure your web browser to send its traffic through the proxy, you can use the proxy to alter any part of the web traffic. This is very useful for identifying vulnerabilities in web applications. ZAP and Burp Suite are great examples of intercepting proxies. I use both of them in my own work.
In the case of the smartwatches, the researcher used a proxy (looks like he was using burp) to inspect the requests to the web application a parent might use to control their child’s smartwatch. The researcher found that a parameter of a web request corresponded to the user’s access level. When he used the proxy to change that parameter from a 1 to a 0, the web application gave him administrative access, as though he were a high-ranking employee of the company that produces and markets the smartwatch. The researcher found that he could view and alter the data of tens of thousands of other consumers of the product. This vulnerability was especially troubling, because children were the potential victims. The vendor has since addressed this problem.
Exploiting this particular vulnerability wasn’t quite as easy as changing something in the URL visible in the address bar of the user’s browser, but it was close. The web application gave too much trust to the request coming from the browser without verifying that the user was authorized for that level of access. This kind of programming error is easy to make, and it is potentially devastating.
If you’re looking for a believable bit of jargon for a story you’re writing about a security researcher, you could say that she used an intercepting proxy to discover an authentication control defect in a web application.