December 3, 2015 By Douglas Bonderud 2 min read

Sharing is a positive force. Parents teach it to children, managers teach it to staff and new technology initiatives depend on it; public cloud computing wouldn’t be possible without the ability to share and redistribute resources on demand. But as reported by Threatpost, sometimes sharing can also do more harm than good: Researchers have now discovered that thousands of embedded devices — routers, gateways and modems, to name a few — share cryptographic keys, opening up a new avenue for man-in-the-middle (MitM) attacks.

Share and Share Alike?

In a study of more than 4,000 devices from 70 manufacturers, researchers from SEC Consult discovered startling consistency: Almost 600 unique private keys were shared and reused across devices. Of the 580 shared, 230 were actively in use, accounting for 9 percent of HTTPS hosts (150 certificates shared among 3.2 million hosts) and 6 percent of secure shell (SSH) hosts. In total, over 900 products from 50 vendors were identified as vulnerable.

What’s more, while devices made by the same company were shown to reuse private keys, those same keys were also found in devices made by competitors — meaning keys were either deliberately shared, leaked or simply repurposed by OEMs working with different vendors. Since these keys are hard-coded into firmware, it’s not simply a matter of resetting the device and trying again; this state of affairs is effectively permanent.

So what’s the problem here? According to InfoWorld, if attackers can steal private keys and then intercept a connection attempt, they can co-opt the user’s public key and force embedded devices to talk with their machines instead. And since SSH sign-ons typically occur only during the first-ever login attempt, cybercriminals could set themselves up as the go-to connection. By capturing encrypted HTTPS traffic and then applying the right private key, it’s possible for malicious actors to extract usernames, passwords and other forms of authentication.

Sharing these keys makes the problem much worse — attackers have a much higher chance of successfully repurposing keys from one device to grant access on another. While companies have been quick to release warnings and advisories, there’s no quick fix here, although they rightly point out that it would require direct network access for attackers to launch a MitM attack on these embedded devices. The SEC researchers recommended that vendors change default cryptographic keys before hard-coding their firmware in addition to turning off any remote access features on their network.

Perception and Reality of Embedded Devices

So how did it come to this? How did vendors allow their devices to use and reuse keys without a thought to the potential consequences? A recent CNBC article offered some clarity: When asked, 36 percent of consumers admitted they had shared the password to their online banking account, yet most users gave themselves an A for following cybersecurity best practices.

In other words, there’s a disconnect between perception and reality. Cybersecurity is somehow viewed as a matter of perspective rather than hard-and-fast rules. For vendors and OEMs, the sentiment seems to be that they were only embedded devices and, given the relatively complex nature of carrying out a MitM attack, sharing secure keys wasn’t really a problem — they still deserve an A for cybersecurity, right?

Attackers are now more than willing to go the extra mile if it gives them unfettered access to corporate networks, especially if companies aren’t actively searching for threats in a specific area. Bottom line? Embedded devices aren’t in a class alone when it comes to IT security. Best practices must be shared across all potential access points.

More from

Unpacking the NIST cybersecurity framework 2.0

4 min read - The NIST cybersecurity framework (CSF) helps organizations improve risk management using common language that focuses on business drivers to enhance cybersecurity.NIST CSF 1.0 was released in February 2014, and version 1.1 in April 2018. In February 2024, NIST released its newest CSF iteration: 2.0. The journey to CSF 2.0 began with a request for information (RFI) in February 2022. Over the next two years, NIST engaged the cybersecurity community through analysis, workshops, comments and draft revision to refine existing standards…

What should Security Operations teams take away from the IBM X-Force 2024 Threat Intelligence Index?

3 min read - The IBM X-Force 2024 Threat Intelligence Index has been released. The headlines are in and among them are the fact that a global identity crisis is emerging. X-Force noted a 71% increase year-to-year in attacks using valid credentials.In this blog post, I’ll explore three cybersecurity recommendations from the Threat Intelligence Index, and define a checklist your Security Operations Center (SOC) should consider as you help your organization manage identity risk.The report identified six action items:Remove identity silosReduce the risk of…

Obtaining security clearance: Hurdles and requirements

3 min read - As security moves closer to the top of the operational priority list for private and public organizations, needing to obtain a security clearance for jobs is more commonplace. Security clearance is a prerequisite for a wide range of roles, especially those related to national security and defense.Obtaining that clearance, however, is far from simple. The process often involves scrutinizing one’s background, financial history and even personal character. Let’s briefly explore some of the hurdles, expectations and requirements of obtaining a…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today