March 20, 2019

Posts Comments

Fast Web-based Attacks to Discover and Control IoT Devices

June 21, 2018 by

By Gunes Acar, Danny Y. Huang, Frank Li, Arvind Narayanan, and Nick Feamster

Two web-based attacks against IoT devices made the rounds this week. Researchers Craig Young and Brannon Dorsey showed that a well known attack technique called “DNS rebinding” can be used to control your smart thermostat, detect your home address or extract unique identifiers from your IoT devices.

For this type of attack to work, a user needs to visit a web page that contains malicious script and remain on the page while the attack proceeds. The attack simply fails if the user navigates away before the attack completes. According to the demo videos, each of these attacks takes longer than a minute to finish, assuming the attacker already knew the IP address of the targeted IoT device.

According to a study by Chartbeat, however, 55% of typical web users spent fewer than 15 seconds actively on a page. Does it mean that most web users are immune to these attacks?

In a paper to be presented at ACM SIGCOMM 2018 Workshop on IoT Security and Privacy, we developed a much faster version of this attack that takes only around ten seconds to discover and attack local IoT devices. Furthermore, our version assumes that the attacker has no prior knowledge of the targeted IoT device’s IP address. Check out our demo video below.

[Read more…]

Filed Under: Privacy Tagged With: , ,

Pragmatic advice for buying “Internet of Things” devices

March 8, 2017 by

We’re hearing an increasing amount about security flaws in “Internet of Things” devices, such as a “messaging” teddy bear with poor security or perhaps Samsung televisions being hackable to become snooping devices. How are you supposed to make purchasing decisions for all of these devices when you have no idea how they work or if they’re flawed?

Threat modeling and understanding the vendor’s stance. If a device comes from a large company with a reputation for caring about security (e.g., Apple, Google, and yes, even Microsoft), then that’s a positive factor. If the device comes from a fresh startup, or from a no-name Chinese manufacturer, that’s a negative factor. One particular thing that you might look for is evidence that the device in question automatically updates itself without requiring any intervention on your behalf. You might also consider the vendor’s commitment to security features as part of the device’s design. And, you should consider how badly things could go wrong if that device was compromised. Let’s go through some examples.

Your home’s border router. When we’re talking about your home’s firewall / NAT / router box, a compromise is quite significant, as it would allow an attacker to be a full-blown man-in-the-middle on all your traffic. Of course, with the increasing use of SSL-secured web sites, this is less devastating than you’d think. And when our ISPs might be given carte blanche to measure and sell any information about you, you already need to actively mistrust your Internet connection. Still, if you’ve got insecure devices on your home network, your border router matters a lot.

A few years ago, I bought a pricey Apple Airport Extreme, which Apple kept updated automatically. It has been easy to configure and manage and it faithfully served my home network. But then Apple supposedly decided to abandon the product. This was enough for me to start looking around for alternatives, wherein I settled on the new Google WiFi system, not only because it does a clever mesh network thing for whole-home coverage, but because Google explicitly claims security features (automatic updates, trusted boot, etc.) as part of its design. If you decide you don’t trust Google, then you should evaluate other vendors’ security claims carefully rather than just buying the cheapest device at the local electronics store.

Your front door / the outside of your house. Several vendors offer high-tech door locks that speak Bluetooth or otherwise can open themselves without requiring a mechanical key. Other vendors offer “video doorbells”. And a number of IoT vendors have replacements for traditional home security systems, using your Internet connection for connecting to a “monitoring” service (and, in some cases, using a cellular radio connection as a backup). For my own house, I decided that a Ring video doorbell was a valuable idea, based on its various advertised features, but also if it’s compromised, nobody can see into my house. In the worst case, an attacker can learn the times that I arrive and leave from my house, which aren’t exactly a nation-state secret. Conversely, I stuck with our traditional mechanical door locks. Sure, they’re surprisingly easy to pick, but I might at least end up with a nice video of the thief. I’m assuming that I have more to risk from “smash and grab” amateur thieves than from careful professionals. Ultimately, we do have insurance for these sorts of things. Speaking of which, Ring provides a free replacement if somebody steals your video doorbell. That’s as much a threat as anything.

Your home interior. Unlike the outside, I decided against any sort of always-on audio or video devices inside my house. No NestCam. No “smart” televisions. No Alexa or Google Home. After all the hubbub about baby monitors being actively cataloged and compromised, I wouldn’t be willing to have any such devices on my network because the risks outweigh the benefits. On the flip side, I’ve got no problem with my Nest thermostats. They’re incredibly convenient, and the vendor seems to have kept up with software patches and feature upgrades, continuing to support my first-generation devices. If compromised, an attacker might be able to overheat my house or perhaps damage my air conditioner by power-cycling it too rapidly. Possible? Yes. Likely? I doubt it. As with the video doorbell, there’s also a risk that an attacker could profile when I leave in the morning and get home in the evening.

Your mobile phones. The only in-home always-on audio surveillance is the “Ok Google” functionality in our various Android devices, which leads to a broader consideration of mobile phone security. All of our phones are Google Nexus or Pixel devices, so are running the latest release builds from Google. I’d feel similarly comfortable with the latest Apple devices. Suffice to say that mobile phone security is really an entirely separate topic from IoT security, but many of the same considerations apply: is the vendor supplying regular security patches, etc.

Your home theater. As mentioned above, I’m not interested in “smart” devices that can turn into surveillance devices. Our “smart TV” solution is a TiVo device: actively maintained by TiVo, and with no microphone or camera. If compromised, an attacker could learn what we’re watching, but again, there are no deep secrets that need to be protected. (Gratuitous plug: SyFy’s “The Expanse” is fantastic.) Our TV itself is not connected to anything other than the TiVo and a Chromecast device (which, again, has a remarkably limited attack surface; it’s basically just a web browser without the buttons around the edges).

I’m pondering a number of 4K televisions to replace our older TV, and they all come with “smarts” built-in. For most TV vendors, I’d just treat them as “dumb” displays, but I might make an exception for an Android TV device. I’ll note that Google abandoned support for its earlier Google TV systems, including a Sony-branded Google TV Bluray player that I bought back in the day, so I currently use it as a dumb Bluray player rather than as a smart device for running apps and such. My TiVo and Chromecast provide the “smart” features we need and both are actively supported. Suffice to say that when you buy a big television, you should expect it to last a decade or more, so it’s good to have the “smart” parts in smaller/cheaper devices that you can replace or upgrade on a more frequent basis.

Other gadgets. In our home, we’ve got a variety of other “smart” devices on the network, including a Rachio sprinkler controller, a Samsung printer, an Obihai VoIP gateway, and a controller for our solar panel array (powerline networking to gather energy production data from each panel!). The Obihai and the Samsung don’t do automatic updates and are probably security disaster areas. The Obihai apparently only encrypts control traffic with internet VoIP providers, while the data traffic is unencrypted. So do I need to worry about them? Certainly, if an attacker could somehow break in from one device and move laterally to another, the printer and the VoIP devices are the tastiest targets, as an attacker could see what I print (hint: nothing very exciting, unless you really love grocery shopping lists) or listen in on my phone calls (hint: if it’s important, I’d use Signal or I’d have an in-person conversation without electronics in earshot).

Some usability thoughts. After installing all these IoT devices, one of the common themes that I’ve observed is that they all have radically different setup procedures. A Nest thermostat, for example, has you spin the dial to enter your WiFi password, but other devices don’t have dials. What should they do? Nest Protect smoke detectors, for example, have a QR code printed on them which drives your phone to connect to a local WiFi access point inside the smoke detector. This is used to communicate the password for your real WiFi network, after which the local WiFi is never again used. For contrast, the Rachio sprinkler system uses a light sensor on the device that reads color patterns from your smartphone screen, which again send it the configuration information to connect to your real WiFi network. These setup processes, and others like them, are making a tradeoff across security, usability, and cost. I don’t have any magic thoughts on how best to support the “IoT pairing problem”, but it’s clearly one of the places where IoT security matters.

Security for “Internet of Things” devices is a topic of growing importance, at home and in the office. These devices offer all kinds of great features, whether it’s a sprinkler controller paying attention to the weather forecast or a smoke alarm that alerts you on your phone. Because they deliver useful features, they’re going to grow in popularity. Unfortunately, it’s not to possible for most consumers to make meaningful security judgments about these devices, and even web sites that specialize in gadget reviews don’t have security analysts on staff. Consequently, consumers are forced to make tradeoffs (e.g., no video cameras inside the house) or to use device brands as a proxy for measuring the quality and security of these devices.

Filed Under: Uncategorized Tagged With: , ,

Who Will Secure the Internet of Things?

January 19, 2016 by

Over the past several months, CITP-affiliated Ph.D. student Sarthak Grover and fellow Roya Ensafi been investigating various security and privacy vulnerabilities of Internet of Things (IoT) devices in the home network, to get a better sense of the current state of smart devices that many consumers have begun to install in their homes.

To explore this question, we purchased a collection of popular IoT devices, connected them to a laboratory network at CITP, and monitored the traffic that these devices exchanged with the public Internet. We initially expected that end-to-end encryption might foil our attempts to monitor the traffic to and from these devices. The devices we explored included a Belkin WeMo Switch, the Nest Thermostat, an Ubi Smart Speaker, a Sharx Security Camera, a PixStar Digital Photoframe, and a Smartthings hub.

What We Found: Be Afraid!

Many devices fail to encrypt at least some of the traffic that they send and receive. Investigating the traffic to and from these devices turned out to be much easier than expected, as many of the devices exchanged personal or private information with servers on the Internet in the clear, completely unencrypted.

We recently presented a summary of our findings to the Federal Trade Commission, last week at PrivacyCon.  The video of Sarthak’s talk is available from the FTC website, as well as on YouTube.  Among some of the more striking findings include:

  • The Nest thermostat was revealing location information of the home and weather station, including the user’s zip code, in the clear.  (Note: Nest promptly fixed this bug after we notified them.)
  • The Ubi uses unencrypted HTTP to communicate information to its portal, including voice chats, sensor readings (sound, temperature, light, humidity). It also communicates to the user using unencrypted email. Needless to say, much of this information, including the sensor readings, could reveal critical information, such as whether the user was home, or even movements within a house.
  • The Sharx security camera transmits video over unencrypted FTP; if the server for the video archive is outside of the home, this traffic could also be intercepted by an eavesdropper.
  • All traffic to and from the PixStar photoframe was sent unencrypted, revealing many user interactions with the device.

Traffic capture from Nest Thermostat in Fall 2015, showing user zip code and other information in cleartext.

Traffic capture from Ubi, which sends sensor values and states in clear text.

Some devices encrypt data traffic, but encryption may not be enough. A natural reaction to some of these findings might be that these devices should encrypt all traffic that they send and receive. Indeed, some devices we investigated (e.g., the Smartthings hub) already do so. Encryption may be a good starting point, but by itself, it appears to be insufficient for preserving user privacy.  For example, user interactions with these devices generate traffic signatures that reveal information, such as when power to an outlet has been switched on or off. It appears that simple traffic features such as traffic volume over time may be sufficient to reveal certain user activities.

In all cases, DNS queries from the devices clearly indicate the presence of these devices in a user’s home. Indeed, even when the data traffic itself is encrypted, other traffic sent in the clear, such as DNS lookups, may reveal not only the presence of certain devices in your home, but likely also information about both usage and activity patterns.

Of course, there is also the concern about how these companies may use and share the data that they collect, even if they manage to collect it securely. And, beyond the obvious and more conventional privacy and security risks, there are also potential physical risks to infrastructure that may result from these privacy and security problems.

Old problems, new constraints. Many of the security and privacy problems that we see with IoT devices sound familiar, but these problems arise in a new, unique context, which present unique challenges:

  • Fundamentally insecure. Manufacturers of consumer products have little interest in releasing software patches and may even design the device without any interfaces for patching the software in the first place.  There are various examples of insecure devices that ordinary users may connect to the network without any attempts to secure them (or any means of doing so).  Occasionally, these insecure devices can result in “stepping stones” into the home for attackers to mount more extensive attacks. A recent study identified more than 500,000 insecure, publicly accessible embedded networked devices.
  • Diverse. Consumer IoT settings bring a diversity of devices, manufacturers, firmware versions, and so forth. This diversity can make it difficult for a consumer (or the consumer’s ISP) to answer even simple questions such as exhaustively identifying the set of devices that are connected to the network in the first place, let alone detecting behavior or network traffic that might reveal an anomaly, compromise, or attack.
  • Constrained. Many of the devices in an IoT network are severely resource-constrained: the devices may have limited processing or storage capabilities, or even limited battery life, and they often lack a screen or intuitive user interface. In some cases, a user may not even be able to log into the device.  

Complicating matters, a user has limited control over the IoT device, particularly as compared to a general-purpose computing platform. When we connect a general purpose device to a network, we typically have at least a modicum of choice and control about what software we run (e.g., browser, operating system), and perhaps some more visibility or control into how that device interacts with other devices on the network and on the public Internet. When we connect a camera, thermostat, or sensor to our network, the hardware and software are much more tightly integrated, and our visibility into and control over that device is much more limited. At this point, we have trouble, for example, even knowing that a device might be sending private data to the Internet, let alone being able to stop it.

Compounding all of these problems, of course, is the access a consumer gives an untrusted IoT device to other data or devices on the home network, simply by connecting it to the network—effectively placing it behind the firewall and giving it full network access, including in many cases the shared key for the Wi-Fi network.

A Way Forward

Ultimately, multiple stakeholders may be involved with ensuring the security of a networked IoT device, including consumers, manufacturers, and Internet service providers. There remain many unanswered questions concerning both who is able to (and responsible for) securing these devices, but we should start the discussion about how to improve the security for networks with IoT devices.

This discussion will include both policy aspects (including who bears the ultimate responsibility for device insecurity, whether devices need to adopt standard practices or behavior, and for how long their manufacturers should continue to support them), as well as technical aspects (including how we design the network to better monitor and control the behavior of these often-insecure devices).

Devices should be more transparent. The first step towards improving security and privacy for IoT should be to work with manufacturers to improve the transparency of these IoT devices, so that consumers (and possibly ISPs) have more visibility into what software the devices are running, and what traffic they are sending and receiving. This, of course, is a Herculean effort, given the vast quantity and diversity of device manufacturers; an alternative would be trying to infer what devices are connected to the network based on their traffic behavior, but doing so in a way that is both comprehensive, accurate, and reasonably informative seems extremely difficult.

Instead, some IoT device manufacturers might standardize on a manifest protocol that announces basic information, such as the device type, available sensors, firmware version, the set of destinations the device expects to communicate with (and whether the traffic is encrypted), and so forth. (Of course, such a manifest poses its own security risks.)

Network infrastructure can play a role. Given such basic information, anomalous behavior that is suggestive of a compromise or data leak would be more evident to network intrusion detection systems and firewalls—in other words, we could bring more of our standard network security tools to bear on these devices, once we have a way to identify what the devices are and what their expected behavior should be. Such a manifest might also serve as a concise (and machine readable!) privacy statement; a concise manifest might be one way for consumers to evaluate their comfort with a certain device, even though it may be far from a complete privacy statement.

Armed with such basic information about the devices on the network, smart network switches would have a much easier way to implement network security policies. For example, a user could specify that the smart camera should never be able to communicate with the public Internet, or that the thermostat should only be able to interact with the window locks if someone is present.

Current network switches don’t provide easy mechanisms for consumers to either express or implement these types of policies. Advances in Software-Defined Networking (SDN) in software switches such as Open vSwitch may make it possible to implement policies that resolve contention for shared resources and conflicts, or to isolate devices on the network from one another, but even if that is a reasonable engineering direction, this technology will only take us part of the way, as users will ultimately need far better interfaces to both monitor network activity and express policies about how these devices should behave and exchange traffic.

Update [20 Jan 2015]: After significant press coverage, Nest has contacted the media to clarify that the information being leaked in cleartext was not the zip code of the thermostat, but merely the zip code that the user enters when configuring the device. (Clarifying statement here.) Of course, when would a user ever enter a zip code other than that of their home, where the thermostat was located?

Filed Under: Uncategorized Tagged With: , , , ,