The Department of Homeland Security has fired a shot across the bow of any company that releases IoT products capable of being harnessed for malicious cyber attacks. Yesterday’s proclamation brought tremendous clarity to how serious the agency is about the issue and how serious they want manufacturers to be.  In short the DHS “Strategic Principles for Securing the Internet of Things (IoT),” pulls no punches

How this effort could impact upcoming product releases is yet to be determined but the question remains just how secure must products be prior to delivery to consumers? Will the liability of insecure web devices translate to a burden for consumers unaware of proper security steps? This has the potential to open a can of worms for those who produce or use IoT devices.

There is no question this move from the DHS is not with merit. The recent Dyn DDoS attack made the susceptibility of these devices crystal clear, and the sheer magnitude and destructive potential makes it impossible to ignore.

Proving the Point

To demonstrate the severity of this incident, I wanted to see just how quickly an IoT device would be attacked once it was placed on the internet. Would a user who bought an IoT webcam or printer have enough time to setup and securely configure the device before an attacker would compromise the device?

To help me answer this question I had a couple of choices, purchase an insecure IoT device and monitor the activity targeting it, or I could configure a virtual device that would appear to an attacker to be a vulnerable IoT device fresh out of the box and ripe for the taking. This technique of luring an attacker to monitor their efforts and techniques is known as a “honeypot.” Researchers have been utilizing honeypots for years to study the way accessed is gained to a vulnerable device, as well as actions on the box post exploit. I opted for the honeypot route, but it had to be setup just right to work for my experiment.

The vast majority of the devices targeted by Mirai are running a stripped-down version of the Linux operating system, developed for multiple architecture (mips, arm, x86 etc.). These machines of limited resource generally run a tool called BusyBox, “The Swiss Army knife of embedded Linux” as developers refer to it. This single binary allows for the execution of over 300 commands, cutting down on the space required of an operating system on an embedded device. Space isn’t an issue for a honeypot, but it was important to have executables that are used by the code we have seen when Mirai was made public.

I opted for a Debian Linux distribution with BusyBox available just in case. I configured it to have the same ports open that these devices generally have — 23 and 80. Once the configuration was complete, to include setting up the same credentials witnessed in the recent attacks, it was time to test my theory and start timer to answer just how long would someone have to secure a new IoT device that was put on the internet.

It turns out they wouldn’t have much time at all, in less than ten minutes it was hit with 13 brute force attacks! After an hour of being online it had been attacked 551 times, with over 10 unique attackers having gone interactive on the honeypot. I continued to monitor all activity for the rest of the week. When I finally shut it down it had been subjected to 2665 brute force attacks and over 108 interactive sessions.  Some of those sessions resulted in malware being pulled down.

The Evolution of Mirai

The analysis of the malware was not what I expected, I was hoping to see the Mirai source code, but it was new code based on Mirai. It had only been a few days from the release of the source code and someone already repurposed it and made minor tweaks, and here it was sitting on my IoT honeypot. This was a reminder that we should not focus on a single signature when looking for follow-on attacks, had I only looked for binaries that should have been pulled down by Mirai I could have missed these new threats.

Based on my brief experiment it is quite obvious that the DHS directive is dead-on and extremely necessary.  More must be done by device manufacturers to provide a modicum of security prior to release. Users should not be expected to beat a hacker to securing their device. As we have seen with the scope of these attacks users are oblivious to the threat posed by insecure web-enabled devices.

Ideally, this DHS decree will serve as incentive to secure their devices; however, these vulnerabilities will continue to be an issue in the near term, as well as for devices already in the market.

What users can do:

Fortunately, there are ways to ensure that network devices stay under user control:

1) Change default passwords – The devices compromised by Mirai had default credentials still in place, many of which was a username of “admin” or “root,” and the password of “admin” or “password.” You should ensure that any device deployed to your network has the default password changed.

2) Disable remote administration – By default many devices allow for remote administration outside of the internal network. Administrative tasks should be performed internally if at all possible.

3) Keep firmware up to date – With the major headlines from the recent compromise of so many devices manufacturers are expected to release firmware updates to products to close down security holes to prevent subsequent attacks. By default, these devices require user interaction to apply these firmware patches. Ensure that prior to installing the latest firmware you back up the current working firmware and have it locally in case the update fails, so you aren’t left with a broken device.