Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
12/5/2016
09:00 AM
Troy Dearing
Troy Dearing
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Reality Check: Getting Serious About IoT Security

The Department of Homeland Security is fully justified in urging security standards for the Internet of Things.

In an effort to curtail a new and disturbing cyberattack trend, the Department of Homeland Security has placed Internet of Things (IoT) device manufacturers on notice. The recent proclamation clarified how serious the agency is about the issue and how serious it wants corporate decision makers to be. In short, the DHS "Strategic Principles for Securing the Internet of Things" acknowledges the gravity of the current climate and the potential for greater harm by encouraging security to be implemented during the design phase, complete with ongoing updates based on industry best practices.

How this effort could affect upcoming product releases is yet to be seen, but these questions remain: How secure must products be before delivery to consumers? Will the liability of insecure Web devices translate to a burden for consumers unaware of proper security? This uncertainty could cause problems for those who produce or use IoT devices.

This move by the DHS was necessary. The recent Dyn DDoS attack made the susceptibility of these devices clear, and the sheer destructive potential makes the risks impossible to ignore.

An IoT Experiment
To determine the severity of the problem, I wanted to see how quickly an IoT device would be attacked once it was connected to the Internet. Would a user who bought an IoT webcam or printer have enough time to set up and securely configure the device before an attacker would compromise the device?

To help me answer this question, I had a couple of choices; I could 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. This technique of luring attackers to monitor their efforts and techniques is known as a honeypot. Researchers have been using honeypots for years to study the way attackers gain access to a vulnerable device, as well as what they do after the exploit. I opted for the honeypot route, but it had to be set up just right.

The vast majority of the devices targeted by Mirai are running a stripped-down version of the Linux operating system, developed for multiple architectures (MIPS, ARM, x86, etc.). These machines 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 more than 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 saw when Mirai was made public.

I opted for a Debian Linux distribution, with BusyBox available just in case. I configured the honeypot to have the same ports open that these devices generally have — 23 and 80. After the configuration was complete, including setting up the same credentials seen in the recent attacks, it was time to find out how long people would have to secure a new IoT device that was connected to the Internet.

It turns out they wouldn't have much time at all. In less than 10 minutes, the honeypot was hit with 13 brute force attacks. After an hour of being online, it had been attacked 551 times, with more than 10 unique attackers having interacted with the honeypot. I continued to monitor all activity for the rest of the week. When I finally shut down the honeypot, it had been subjected to 2,665 brute force attacks and more than 108 sessions where there was an attempt to gain access. Some of those sessions resulted in malware being downloaded.

The Evolution of Mirai
The analysis of the malware wasn't 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 had repurposed it and made minor tweaks — and here it was sitting on my IoT honeypot. This was a reminder that we shouldn't focus on a single signature when looking for follow-on attacks; if I had only looked for binaries that should have been downloaded by Mirai, I could have missed these new threats.

Based on my experiment, it's obvious that the DHS directive was needed. More must be done by device manufacturers to provide a modicum of security before release.

What Users Can Do
Fortunately, there are ways to ensure that network devices stay under user control:

  • Change default passwords. The devices compromised by Mirai had default credentials still in place, many of which consisting of the username "admin" or "root," and the password "admin" or "password." Users should ensure that any device deployed to their network has the default password changed.
  • Disable remote administration. By default, many devices allow for remote administration outside of the internal network. Administrative tasks should be performed internally if possible.
  • Keep firmware up to date. Because of the recent attacks, manufacturers are expected to release firmware updates to products to close down security holes, preventing subsequent attacks. By default, these devices require user interaction to apply these firmware patches. Make sure that before 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.

Related Content:

 

Troy Dearing (Gunnery Sergeant, Retired) joined Armor as a senior ethical hacker, bringing 20 years of expertise in IT and cybersecurity to the Threat Resistant Unit (TRU). Before joining Armor, Troy was a computer network operator for the NSA, where he was tasked with ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
CharityWright
100%
0%
CharityWright,
User Rank: Apprentice
12/6/2016 | 11:58:46 AM
Great Report!
Troy, great work man! So happy to see your work published here on DarkReading. The security world will benefit from your knowledge and experience. I really love that you set up an IoT honeypot to evaluate the time it takes to get hit. Many organizations are struggling to get a grip on Mirai and Bashlight malware. Thanks so much for your insight and recommendations!
Mark.Baugher
100%
0%
Mark.Baugher,
User Rank: Author
12/6/2016 | 8:35:55 AM
Is DHS the right agency to regulate security?
Great article, thanks!  Both Schneier and Krebs have called for regulation of devices that connect to the Internet - or any network since practically all connect to the Internet.  This raises the questions of who and how.  Krebs thought a UL type of organization is a promising approach.  Such testing and certification can be voluntary or mandatory, but I favor the latter.  Who should do iis a difficult question given the anti-privacy bias of the US government.  It's hard to trust any government agency to regulate a cyber-security function when leading government organizations in this space want to mandate backdoors in hardware and software.  There is a trust issue.

Don't get me wrong, the DHS is doing some good work in this area such as NCATS, the National Cybersecurity Assessment and Technical Services, https://www.us-cert.gov/ccubedvp/federal.  In pursuing NCATS for my company's products, I encountered some pushback from a couple of our most knowledgeable security engineers.  This is understandable given the role of the NSA and other government agencies in subverting the security of US-made networking products.  The blowback of these activities, many of them revealed by Edward Snowden, continues to plague US businesses.  For example, I recently had a European customer tell me that AWS was not suitable so long as US engineers have access to datacenters serving their customers.

Regulation of network gear is indeed necessary and overdue, but how to regulate and who will do it remains a problem.

 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...