Slashdot Mirror


IoT Devices Are Secretly Phoning Home (thenewstack.io)

An anonymous reader writes: A popular internet-enabled security camera "secretly and constantly connects into a vast peer-to-peer network run by the Chinese manufacturer of the hardware," according to security blogger Brian Krebs. While the device is not necessarily sharing video from your camera, it is punching through firewalls to connect with other devices. Even if the user discovers it, it's still extremely hard to turn off. Krebs notes that the same behavior has been detected in DVRs and smart plugs -- they're secretly connecting to the same IP address in China, apparently without any mention of this in the product's packaging. One security researcher told Krebs the behavior is an "insanely bad idea," and that it opens an attack vector into home networks.

8 of 196 comments (clear)

  1. "insanely bad idea" by Bruce66423 · · Score: 3, Interesting

    Depends on your perspective, doesn't it? If you are aiming to ensure that a cyber attack by the People's Liberation Army on the Imperialists will do a lot of damage, it seems like a GREAT idea...

  2. If you think by Ol+Olsoc · · Score: 3, Interesting

    That Internet of Things phoning home is some sort of secret, you've been living under a rock the last few years. Phoning home is what they are designed to do. It's the core principle of the IoT.

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  3. No need to phone home. by fyngyrz · · Score: 3, Interesting

    And it is completely, absolutely, 100% unnecessary.

    o Plug in not-yet configured device.

    o Shortly thereafter, it accepts DHCP configuration. Now it has an IP.

    o Then it vomits out a tiny UDP (broadcast) packet every 60 seconds or so that says "I'm a WackyWidget and my IP is Yad.daY.yad.daY"

    o You start app, it listens for the UDP packet, when it hears it, it begins comm via TCP at the IP identified in the UDP broadcast. UDP broadcasts then cease until, or unless, the TCP (and possibly the DHCP) connection is dropped, in which case, begin again at whatever step is needed.

    That's it. That's ALL of it. You need nothing more for an IP camera, a smart power plug, a smart lightbulb, an aquarium controller, the garage door opener, etc., etc., ad infinitum.

    If you THEN want to expose WackyWidget to the WAN, you could enable that separately.

    If you were out of your damned mind.

    If you haven't yet figured out that "the cloud" is nothing but a way to take/get things from you -- money, data, ownership of media, etc. -- then you really need to look at all this harder.

    --
    I've fallen off your lawn, and I can't get up.
    1. Re: No need to phone home. by techabuse · · Score: 4, Interesting

      I own a few Chinese IP cameras i bought for experimenting, and no two of them work with the same app/P2P cloud bullshit/whatever. They do, however, all expose Telnet and SSH to the world. There's no way I'd let them anywhere near the WAN because they're all running Linux on a decently snappy ARM SOC and phoning home. Can you say beach head?

    2. Re:No need to phone home. by Theaetetus · · Score: 3, Interesting

      And it is completely, absolutely, 100% unnecessary.

      o Plug in not-yet configured device.

      o Shortly thereafter, it accepts DHCP configuration. Now it has an IP.

      o Then it vomits out a tiny UDP (broadcast) packet every 60 seconds or so that says "I'm a WackyWidget and my IP is Yad.daY.yad.daY"

      o You start app, it listens for the UDP packet, when it hears it, it begins comm via TCP at the IP identified in the UDP broadcast. UDP broadcasts then cease until, or unless, the TCP (and possibly the DHCP) connection is dropped, in which case, begin again at whatever step is needed.

      That's it. That's ALL of it. You need nothing more for an IP camera, a smart power plug, a smart lightbulb, an aquarium controller, the garage door opener, etc., etc., ad infinitum.

      If you THEN want to expose WackyWidget to the WAN, you could enable that separately.

      If you were out of your damned mind.

      If you haven't yet figured out that "the cloud" is nothing but a way to take/get things from you -- money, data, ownership of media, etc. -- then you really need to look at all this harder.

      That's a really long and condescending way to say "I don't understand how subnets work". While it may work fine on your household network, this camera is designed to be accessed over the public internet. Most people don't need to check security cameras that are in the same room as them.

  4. Re:Not new by Dutch+Gun · · Score: 4, Interesting

    Agreed. This doesn't surprise me one bit. Maybe the name gives it away... you know... that these Things communicate over the Internet?

    I'm going to take a potentially contrary position, though, and argue that if a device is internet enabled, it absolutely should be phoning home on a regular basis, and for very good reasons. The recent glibc library vulnerability only helps to validate my opinion, in fact, which is that it's absolutely inevitable that serious vulnerabilities will be found in ANY internet-facing device, and so these devices MUST be able to automatically update themselves. What's more, manufacturers should be responsible for providing security updates for a reasonable product lifetime - otherwise, they're no longer fit to stay connected, and essentially must be discarded in order to keep your network secure.

    I'm sure there are those who would argue against such a policy, but these are *consumer* devices, and we damn well know by now that a typical consumer will never update the firmware on their own device. We now accept that browsers must self-update in order to remain secure, and we're just now grappling with the notion that OSes must do it too. Frankly, anything that's internet-facing needs to be treated the same way. The manufacturer must take responsibility for this. Otherwise, we're going to have billions of tiny infection vectors that will last as long as the devices do, which could be decades. Look at how much of a problem this is for old desktops, servers, and routers sitting on the internet, spewing botnet-controlled traffic because they've never been updated. Granted, this has to be done in a secure manner, so that MITM attacks are not possible, but it's absolutely possible to do it right.

    Of course, we all know what's really going to happen, which is that these companies with absolutely no clue how to do internet security are going to get many thousands of people infected through these crappy little internet-enabled gizmos, and the people who get infected with the Zeus banking trojan or crypto-ransomware will be outraged, and articles will be written, and eventually things *may* improve slightly. I'm sure as hell not going to be one of the early-adoption suckers.

    --
    Irony: Agile development has too much intertia to be abandoned now.
  5. Re:Not new by Anonymous Coward · · Score: 4, Interesting

    Then they don't work. Some have to have a 24/7 Internet connection, and if it gets cut, the devices turn off. I'm just waiting for everything out there, be it fridges, TVs, and anything else to either follow suit, or have a 3G antenna, so it has its own private pipe to tattle user info on.

  6. Re:Not new by mlts · · Score: 4, Interesting

    Perhaps an even better thing would be to go to a hub and spoke topology? That way, devices can communicate with the center hub (or hubs, if redundancy is desired), and if there is a fix, the hub asks for it on behalf of one device, caches it, so other devices can use that same fix without issue. It is basically what happens when devices communicate through an access point, but the devices would use a low power, low range protocol as opposed to Wi-Fi, or even opening themselves for attack by touching the Internet directly. Plus, with a hub and spoke, an IDS/IPS mechanism can be places so if one device starts behaving suspiciously that is out of the design parameters (nmapping everything it can find), its connection gets dropped, and life goes on. As an added bonus, an attacker would either have to be physically nearer to intercept the low power protocol, or would have to attack the hardened hub (which could run on fairly modest hardware and use virtual machines to separate the firewall instance from the instance that deals with the devices.)