DDoS Revived – IoT Based Botnets

By Staff Contributor on December 22, 2016


dyn-dns-ddos-attack-heat-map

Just as ISPs, hosting companies, businesses, and even consumers were beginning to close down the vulnerabilities that enable computers to become zombies – botnets – a new class of hosts arrives. Always online, Internet-facing, with hardcoded (often in the firmware) default passwords, the smart thermostat, webcam, digital video recorder, or consumer router-zombie is here.

This rather scary fact played out in a major way on October 21, 2016, when Dyn, a company that provides core Internet services for a variety websites was struck by a DDoS attack which caused a wide-spread service interruption throughout the United States and parts of Europe. If you missed it, you likely don’t use Twitter, Okta, SoundCloud, Spotify, Reddit or any of the other services connected to Dyn, and you may not have been directly impacted by this Internet outage of sorts… at least not this time.

dyn-dns-ddos-attack-heat-map

Botnets and IoT Devices vs. General Purpose Machines

The fundamental challenges with DDoS botnets have historically been that they are difficult to predict, you need to be able to move upstream to block the traffic, and it causes your network team to be bombarded by data that overwhelms staff and your management systems just when you need them the most. Well, needless to say, that doesn’t change with this new zombie class. But there are, however, a number of key differences when compared to the way this type of vulnerability presents itself when compared to an exploit carried out on general-purpose machines. Here’s a quick look at how they stack up against one another:

  1. IoT technologies are mostly consumer devices, and many users are not equipped to identify and remediate these risks.
  2. A number of the compromised devices gave the user the allure of being secure (you could change the credentials on the http/https access) while leaving the telnet, ssh, ftp ports wide open.
  3. The devices are not easily remediated. We don’t have patch management for IoT, the passwords are stored in firmware, most devices are not behind a firewall that can block vulnerable ports on their behalf, many were manufactured overseas so a recall or replacement is not an option.
  4. You can see a list of a number of the devices identified as being used in the attack here:

    https://krebsonsecurity.com/wp-content/uploads/2016/10/iotbadpass-pdf.png

 

How should we be thinking about this?  How do we protect our infrastructure and ensure we are not contributing to the pool of zombies?  Is there any guidance on IoT security?

What does NIST say about IoT Security?

Thinking about these issues, I was initially excited when I read an article stating NIST had released guidance on how to “secure IoT devices”.  Unfortunately, it is a 257 page document, and defines a whole new discipline called “Systems security engineering” which “contributes to a broad-based and holistic security perspective and focus within the systems engineering effort. This ensures that stakeholder protection needs and security concerns associated with the system are properly identified and addressed in all systems engineering tasks throughout the system life cycle

You can read the whole thing here http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf

IoT Risk Management Checklist

While this effort by NIST is laudable, it doesn’t really help an organization without an extensive formal process to reduce risk while still maintaining business agility.  In an attempt to be practical, here is my proposal for an IoT Risk Management Checklist.  All criticisms, suggestions, comments welcome.

  1. Don’t be a contributor to the zombie horde:
    • Work with IT to make sure new devices, even simple things like vending machines, only use authenticated https to communicate outside the organization.
    • Block outbound telnet, ssh, ftp from all but IT/Security controlled devices with a business need.
  2. Check with your ISP to make sure you have a defined protocol for dealing with a DDoS attack
  3. Rank order your critical SaaS applications and have a business continuity plan if they are taken down with a DDoS.
  4. Do you allow remote access from home users? Monitor that connection for tunneled telnet, ssh, ftp or other protocols that might be part of a DDoS attack.

All IT and Security pros know that we can’t protect from every risk, but we can be good internet citizens and avoid making the same mistake twice.

Photo credit: thenextweb.com

Related Posts

Leave a Reply