Extra-Large Denial Of Service Attack Uses DVRs, Webcams

Brace yourselves. The rest of the media is going to be calling this an “IoT DDOS” and the hype will spin out of control. Hype aside, the facts on the ground make it look like an extremely large distributed denial-of-service attack (DDOS) was just carried out using mostly household appliances (145,607 of them!) rather than grandma’s old Win XP system running on Pentiums.

Slide from <a href="http://slideplayer.org/slide/906693/">this talk</a> by Lisa Plesiutschnig
Replace computers with DVRs. Slide from this talk by Lisa Plesiutschnig

We can argue all day about whether a digital video recorder (DVR) or an IP webcam is an “IoT” device and whether this DDOS attack is the biggest to date or merely among them, but the class of devices exploited certainly are not traditional computers, and this is a big hit. Most of these devices run firmware out of flash, and it’s up to the end user (who is not a sysadmin) to keep it up to date or face the wrath of hackers. And it’s certainly the case that as more Internet-facing devices get deployed, the hacker’s attack surface will grow.

Why did the DDOS network use these particular devices? We’re speculating, but we’d guess it’s a combination of difficult-to-update firmware and user “convenience” features like uPnP. To quote the FBI “The UPnP describes the process when a device remotely connects and communicates on a network automatically without authentication.” You can see how this would be good for both the non-tech-savvy and hostile attackers, right? (Turn off UPnP on your router now.)

We alternate between Jekyll and Hyde on the IoT. On one hand, we love having everything in our own home hooked up to our local WiFi network and running on Python scripts. On the other hand, connecting each and every device up to the broader Internet and keeping it secure would be a system administration headache. Average users want the convenience of the latter without having to pay the setup and know-how costs of the former. Right now, they’re left out in the cold. And their toasters are taking down ISPs.

46 thoughts on “Extra-Large Denial Of Service Attack Uses DVRs, Webcams

  1. Things with absolutely no security where compromised and used in a DDOS attack…. hold on let me apply my shocked face. The thing that really sorta floors me is that the people manufacturing these devices didn’t A) See this coming or B) Just didn’t care.

    1. That sounds so easy…

      Go read abut UPnP and weep. You thought you had all of your IoT things behind your router? What do you do when they say “I need UPnP to work properly?

      And if you allow it, they can remote-control the firewall on your router, poking holes in it. Unless you are savvy enough to close that off.

      And since the default is “allow” (otherwise the user is back next day at the shop with “don’t work”) and your IoT things are wifi these days… they might even be creating mischief through your neighbor’s router, who knows.

      This should be *so* expensive for the manufacturers that they become willing to take some part of the responsibility. Even if that means cutting a bit back on user convenience.

      1. The real crazy UPnP loophole is that it allows a device to open a firewall request *on behalf of another device*, in other words “Hey I’m 192.168.0.10, go ahead and open 0-65535 for 192.168.0.1, .2, .3, etc” is perfectly legal UPnP behavior.

      2. > What do you do when they say “I need UPnP to work properly?”
        I return the product? Random devices get firewalled off from pretty much everything except what _I_ think they need to talk with to do their job. If they need more than that, well, I find them defective and return them.
        “Normal” users? They just plug them in and suffer…

    2. B is the correct answer.
      It cost money to make it safe for us.
      What should be happen is the hackers should be attacking them. To tech them a lesson.
      That would be cool. If they do that, then they can use all my devices.

    1. It’s speculation at this point, but yeah. Similar systems. There are payloads in Metasploit for the aforementioned Hikvision DVRs, and there are probably a few more brands out there that are vulnerable and widely distributed.

      The trick with the Internet is that if you’ve cracked one, you’ve cracked them all. It’s hard, but not impossible, to wrangle up a network of hundreds or thousands if it’s all scripted, right?

    2. They probably wrote the payload for a couple of popular platforms, then just ran a port scanner on public IPs to find compatible hosts. Basically just a simple shell script away from having a massive botnet.

    1. I agree with you. This is to blame the messenger. Someone(ISPs or a kind of organisation) will have to start to scan the network and contact the users, informing they are using faulty devices, hackers are already scanning for a long time. See, if they do this when you download a movie though Torrent, why not do the same thing for the security of the Internet?

      1. I think routers should automatically perform these scans and alert the user. But even then, who would know what to do about it? Most people have a hard time getting an AP to talk to their devices and when they do, don’t spend time thinking about anything beyond.

        The biggest problem with security is ignorance — ‘home network security audit’ isn’t something anyone has ever heard of. The one device that everyone buys that has anything to do with security is the router. It should be built robustly, with standards that companies will have to adhere to if they want their on-LAN device to reach the wider Internet. I think this is the only way to force manufacturers (of the non-router hardware) to develop secure devices.

      2. Horses for courses.

        I *strongly* disagree. This UPnP stuff is for making things convenient which shouldn’t be possible in the first place. The IoT fridge telling my firewall to poke a hole in itself? You must be kidding.

        And yes, for a knowledgeable person it should be possible to set up UPnP in a more or less secure way (disclaimer: I never tried), but that’s *exactly not* UPnP’s target group! As a knowledgeable person I *know* what IoT gadgets are on my home network and whether and how they’re supposed to talk/listen to the Intertubes. UPnP is supposed to “solve” the problem that Joe/Jane User has no clue *and trusts the “manufacturer”* (of the firewall device, which trusts the manufacturer of the IoT thingie, etc”).

        A diabolical variant on “chain of trust”. My new TV/lightbulb/dildo poking holes in my firewall like there is no tomorrow. But… should the firewall manufacturer configure their stuff to “deny by default” people would buy the other one, because the lightbulbs “work”.

        No, I stay by my stance: a big part of the responsibility is on the IoT manufacturers, another big part on the edge device’s manufacturers and another on those idiots (Microsoft et al) who came up with UPnP.

  2. I blame router manufacturers for this. They’re selling a security appliance. They ought to be secure by default. I should be able to run UPnP on my internal network all I want and there should be no attack surface presented outside that network.

    This is not rocket science. Statefull firewalls have been a thing for almost 25 years now if not longer.

    1. “there should be no attack surface presented outside that network.” — That’s the whole point behind UPnP! You’re complaining that you want UPnP, but then you say next that you don’t want UPnP!

        1. Technically, UPnP is a system for autodiscovery and configuration/use of services, and on a router the service provided by UPnP is opening of ports — often the only reason to even have UPnP on a router. You *can* disable UPnP, ie. the service for opening of ports, on your router and still have UPnP working on your local network; one is not dependant on the other.

  3. Unless someone uses as a similar approach to spam the device owners with patronisingly unsubtle l33tsp34k messages like “B00000, 1 4M 4 5P000000000KY GH05T H4UNT1NG Y0UR T04STER 4ND 0R R3FR1G3R4T0R!” all day, every day until all these devices are thrown away or returned to the shop as defective this probably isn’t going away, is it?

  4. oh a simple fix would be to have all devices patched since its likeley each device is running on a timed or acivated script such meaning that when hundreds of people wake up and say start a batch of coffe it trigggers a line of data towards an point of attack. further more ech device is seperate from another allowing the attack to continue even if one of the many is taken out and or disconnected. with back doors set forth by the manufacturers loading such language intothe devices is never very hard.

  5. Ummm, maybe it’s just me. The root IP address for any given site is assigned by IANA,right? and the IP is translated by Internet Domain Name Services (DNS). I don’t understand why they can’t on a DOS attack reassign an IP base address to an alternate and push a new DNS entry for both the primary DNS and the BDS internationally, or even use the equivalent of NAT to reassign the IP address space – just on a larger scale, it might take a little while to re-propagate, but it’s better than having a site down for 24 hours. Obviously, it’s been a few years since I have dealt with this in business – but isn’t that essentially how the system works? Certainly in an intra-net you can change the base with an alias entry in the PDC/BDC server, so, why can’t they automatically switch when they are being hammered with service requests that are designed to take down a site? Then the only way a DOS would work then is if the originating device used DNS services instead of an actual I.P. address. And as I understand it – most use the actual IP addresses, since the code to render the IP through DNS would be somewhat larger, require additional requests, and for a discrete device I’m not sure you could easily smash that code into it. And you could deny requests for DNS translation for discrete devices I suppose. On the other hand – I might just be full of sh*t, it’s really possible.

      1. Yes, I get that – but when you are losing tens of millions of dollars an hour and time is important, it might be faster when you don’t actually know how long an attack will last or where it is coming from (in the case of DOS – it’s coming from everywhere usually). I only do the comparison since I was involved with large data centers at multiple locations (both primary and fail-over) and that’s what we do for fail back on network failures through our data centers (or did while I was working). And it was a network that was all across the U.S., tens of thousands of users, and international too; I just don’t know the propagation time for say national vs. worldwide (obviously larger, but the national I would think would be more traffic depending on the target company, and more important). So what is the newest method for redirecting or blocking traffic on a DOS attack?

        1. You have a better understanding of DNS/NS than most people but there are some aspects of the infrastructure that underlays the internet that seem different from your expectations.

          The first thing that is different is that like the internet, the DNS/NS structure is an infrastructure but is different in that it was NOT designed to be a traffic carrier like HTTP so it’s load carrying capacity is comparatively very small.

          The second difference is that the DNS/NS infrastructure acts like a big cache in order to achieve the low traffic carrying capacity that it was designed for. For this reason it’s not uncommon to see refresh periods of a week or several days before changed information is updated through the cache.

          The third difference is that DNS/NS if hierarchical and has a chain of authority, in fact the *master* record has a variable called Start of Authority (SoA) and from there record authority can delegated many times.

          Propagation times are dictated by variables in the DNS/NS system like REFRESH and TTL in zone files on the DNS servers, it’s not a geological feature but there are also those sysadmins that do not adhere to the RFC specifications that state these requirements.

          And lastly, even giving consideration to all the above, intelligent DNS, if set up correctly would be hugely beneficial in mitigating the effects of DDOS and DrDOS attacks just as you have mentioned but the barrier that is preventing that from occurring is that too few people actually understand how DNS/NS works completely and can identify it weak points.

          1. Problem is my understanding is 6 years old – I’m guessing a lot has changed. You have laided out a good explanation of the problem, thanks. The 2nd one I’m guessing is the biggest problem – to mitigate response times the cache of data most likely hurts responsive reactions to these types of attacks, although not unexpected given the size. Propagation would seem to be a very long time under your explanation. Unfortunate – they should try to adhere more to a single standard if they could (obviously, hard to control). I know we had very specific guidelines in our data centers on setup parameters so we could get these things to trickle down over a few hours. This was for Arcelor-Mittal Steel, which has 430,000 employees worldwide, so you can imagine just how may intranet-nets are connected together.

  6. I’ve always wondered how much cheap IoT gear was really a form of Trojan horse. We have electrical device certification for protecting against RF pollution but not TCP/IP pollution, so there is your problem right there.

  7. Some more info if interested…Guessing this is a continuation of the security camera issues that have been known since at least early 2013, and not just cheap models sourced directly from China but popular home security ones like Swann sold at Costco, Frys, etc…

    http://console-cowboys.blogspot.com/2013/01/swann-song-dvr-insecurity.html
    http://gizmodo.com/5979528/tons-and-tons-of-security-cameras-are-wide-open-to-hackers
    http://www.extremetech.com/extreme/147064-18-brands-of-security-cameras-are-susceptible-to-easy-hack

    Level 3 Threat Research published an article a month before the tweet referenced about their observations of DDoS attacks using a million strong botnet, 96% of which were IoT (95% cameras & DVRs) defvices: http://blog.level3.com/security/attack-of-things/

    I’ve played around with one of the Cavalry branded ones, i.e. chinese direct; obtained at the local thrift store a few months ago. Root access didn’t require a hack, a blog entry, or even the admin guide…it was helpfully printed on a label on the wall mount itself in a place that I think could be read with little effort even when mounted to the wall. It also looks identical to one that D-Link currently sells but I’ve been unwilling to shell out $120 to Frys and deal with store returns just to find out for sure. So even though the 2013 issue was patched by some manufacturers, it makes one wonder how many are still out there or still being sold.

    Finally, DefCon this year had a talk about MQTT issues for true “IoT” device concerns : https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Lucas-Lundgren-Light-Weight%20Protocol-Critical-Implications.pdf

  8. I am a CCTV installer and HKvision is very popular system , to make customer happy I need to open ports 80\554\443\8800 ; the IP cameras are working just the same and connected directly to the POE network so each one is an actual stand alone server with a unique address so Even without UPNP once you scan internet address and enter you get an admin screen and the default is admin / 123456 or admin 000000 , most of installer change the admin password , now to update the firmware you just click on advanced configuration / system then you can enter remote ftp file location. you do not need to be super hacker to slave DVR and 32 cameras with simple firmware update . I think that even the Iphone / android remote viewers and the DDNS trackers are hosted on the Chinese servers .

  9. I would start by making sure ISP can mitigate the issue right now by doing the following .
    a) Service provider ip scan all internal ip’s if find port 80 with the hikvision login screen , tag all IP’s then sinkhole all request to this port -re-transmit out to request with a webpage saying ” port 80 is not supported ” this will prevent most of hacking from happening
    b) block DDNS servers or make new reliable and safe US based one for US customers
    c) check how the remote mobile phone apps are working, and make sure data is not leaked out to remote servers

Leave a Reply to Mike SzczysCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.