Attacks/Breaches
10/13/2016
10:30 AM
Daniel Riedel
Daniel Riedel
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

IoT Default Passwords: Just Don't Do It

The rise of the Internet of Things makes the use of default passwords especially perilous. There are better options.

Earlier this month, an underground forum released the code for the Mirai malware, which lets attackers hijack the thousands (and counting) of Internet of Things devices that are used to carry out distributed denial-of-service attacks.

Panic ensued.

Of course it did. This hack means that everyone can now view the code that allowed someone using the name Anna-senpai to harness 380,000 bots via weak telnet connections. Let's ignore for now that in 2016 there is absolutely no reason to have telnet on any IoT device.

That aside, much of the subsequent hand-wringing over default password damage control missed the one glaring thing that manufacturers, startups, and providers can do to prevent this sort of devastating vulnerability: Don't use default usernames and passwords in the first place.

The most common reasons for using default usernames and passwords boil down into a few key arguments (when you leave out "we've always done it this way," which I won't even dignify with a response because I know if you're reading this, that's not an argument you care about).

Users should reset the username and password when they get a device. Philosophically, they should. In reality, do they? No, they don't. This is putting your device security into the hands of human nature, which runs directly counter to high security by always looking for the path of least resistance.

It costs more. Let's be real: It probably will cost more up front. But the more important question is whether that investment is worth preventing a likely future debilitating attack on your network, your company, your customers, and your brand. Cyberattackers are becoming more sophisticated by the second, and as the Dark Reading audience knows, we've passed the time for "if" and moved into "when" as it relates to being attacked. It's a common argument for any cybersecurity investment, but it bears repeating because so many organizations will want their team to stick with the username/password formula.

It takes more time. Again, that's true. But the good news is that the technology exists today to make default passwords on IoT devices obsolete. It's not even a herculean undertaking; your engineers could implement the fixes below in a matter of weeks:

  • Fix 1: Tie device security to a globally unique identifier, or key that would be a different code for each device ensuring that someone can’t guess the password for the device. This isn't ideal, but it's miles better than the admin/password approach.
  • Fix 2: Generate a one-time password that a user is forced to reset as part of setting up a device. If there is a reliance on the user anyway to reset a password, at least make it mandatory.
  • Fix 3: Create a shared certificate that is used with the device that needs to pair with the IoT device in question, perhaps using the "trust on first use" principle (which locks the device to the network or application upon first use) or Apple/Android's authentication platform. Similar approaches could be devised through OAuth, public key infrastructure, or other key exchanges, which give the ability to create a handshake upon installing the device.
  • Fix 4 (and the best, in my opinion): We build an industry standard for IoT authentication that is tested by the best minds in the world in infrastructure, security, and manufacturing. As IEEE points out, several of its standards address security elements that are applicable to IoT devices. These include IEEE P1363, a standard for public key cryptography; IEEE P1619, which addresses encryption of data on fixed and removable storage devices; IEEE P2600, a standard that addresses the security of printers, copiers, and similar devices; and IEEE 802.1AE and IEEE 802.1X, which address Media Access Control Security (MACsec).

Linksys has at least made headway with its WPA2 passwords being unique on each device. So the market is learning, but not fast enough.

The bottom line is that IoT isn't going anywhere. We'll soon live in a world with billions of devices that will do everything from watch your cat to measure your REM sleep. With a little effort, your organization can be at the forefront of protecting these devices, all while breaking the seemingly endless cycle of username and password vulnerability.

Related Content:

Daniel Riedel is the CEO of New Context, a systems architecture firm founded to optimize, secure, and scale enterprises. New Context provides systems automation, cloud orchestration, and data assurance through software solutions and consulting. Daniel has experience in ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, you were supposed to display UNICODE characters!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] Assessing Cybersecurity Risk
[Strategic Security Report] Assessing Cybersecurity Risk
As cyber attackers become more sophisticated and enterprise defenses become more complex, many enterprises are faced with a complicated question: what is the risk of an IT security breach? This report delivers insight on how today's enterprises evaluate the risks they face. This report also offers a look at security professionals' concerns about a wide variety of threats, including cloud security, mobile security, and the Internet of Things.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.