IoT Agenda

Apr 12 2017   12:23PM GMT

What we can learn from the Mirai botnet attack

Ted Myers Profile: Ted Myers

Tags:
Botnet
DDOS
Internet of Things
Internet protocol
iot
iot security
IP
IP security
security in IOT

A serious distributed denial-of-service (DDoS) Mirai botnet attack was launched recently. More than 100,000 IP-addressable devices were hijacked to target Dyn, which provides the domain name system (DNS) for the internet which, in turn, disrupted major services such as Twitter, Amazon, Reddit and Spotify. Mirai is open source and easily available, and exploits users that fail to change default factory passwords which, unfortunately, is an extremely common occurrence.

The Mirai attack has been taken as a wake-up call. The scale of the attack is compelling government to scrutinize internet of things security. As stated in a letter from Sen. Warner to the Federal Communications Commission, Federal Trade Commission and Department of Homeland Security:

“Because the producers of these insecure IoT devices currently are insulated from any standards requirements, market feedback or liability concerns, it is deeply concerning that a ‘tragedy of the commons‘ threatens the function of the internet, as the security so vital to all internet users remains the responsibility of none.”

The Mirai attack interfered with the operation of the internet, but worse attacks are possible — especially as the number of IoT devices increase exponentially into the hundreds of billions as predicted. Just a brief sampling of the mayhem if nefarious agents are able to take control of IoT devices:

  • Disruption of critical infrastructure, telecommunications, transportation and the power grid
  • Controlling temperatures of perishable devices or cause servers to overheat
  • Aiding criminals in performing physical break-ins by turning off cameras and opening and closing doors
  • Hijacking medical devices (such as heart implants) to injure or even kill

The old paradigm: Talk to strangers, but be careful

Let’s start with an analogy: We tell our children not to talk to strangers. At its most basic level, the Mirai attack is an example of what happens when devices have the capability of interacting directly with other devices or “talking to strangers.” However, this peer-to-peer communication is how the internet works. Internet Protocol is a key communication protocol, or common language, to enable this direct interaction; IP is the language that allows computers to interact with each other and the wide range of other components that comprise the Internet.

There has been a tremendous amount of resources in securing these interactions in an ever-escalating landscape of security threats. The economy of scale of the internet justifies this IT investment as both business and consumers benefit tremendously from the computers, laptops, tablets and smartphones provided by this form of connectivity.

But there are significant problems with unmanaged, peer-to-peer connectivity with many of IoT devices. Some recent quotes regarding IoT security:

  • “A lot of these [IoT] devices are being made by people who don’t have a lot of experience building reliable software,” said Hong, a co-founder of Wombat Security Technologies. “Embedded devices continue to operate for years after their last software patch, and can even outlive the demise of their manufacturer.”
  • This suggests that those who designed these IoT devices assumed that the local area networks they’ll be installed on were secure. That’s an error, because research over the past several years has showed that if there’s anything worse than the security of IoT devices, it’s the security of consumer routers.”
  • The idea that enterprises can somehow control whom to let in is going to go out the window, Chiu said. “Companies will have to just assume the bad guy is already there,” and respond accordingly.

And, it’s not just the Mirai attack that underscores these sentiments. Just recently it was announced that Philips Hue smart light bulbs were hacked. These light bulbs rely on peer-to-peer communication via the Zigbee protocol and hackers were able to exploit that link to “set an LED light strobe pattern that could trigger epileptic seizures or just make people very uncomfortable.” This demonstrates once again how difficult it is to get security right even for a large company that uses standard cryptographic techniques to protect a major product.

Should we continue to view IoT devices as a direct extension of our Internet, or should we start viewing these devices differently and attempt to significantly reduce the space of threat vectors?

The new paradigm of managed connectivity: Interact with your parents

There is a growing number of IoT devices today, but that number is going to climb exponentially into the hundreds of billions over the next several years. It is worth some significant rethink of accepted security practices.

A managed approach is defined when IoT devices communicate securely with the application that often resides in the cloud. It is well understood in the industry how to secure a link between the cloud and an arbitrary device (including IoT devices). This eliminates the dimensionality of direct interaction between:

  • IoT devices and traditional Internet connected devices (the cause of the Mirai attack), or
  • Between any arbitrary set of IoT devices (the cause of the Philips Hue hacking). Past, present and future in an environment of continuous hacking.

In this paradigm, IoT devices can communicate with each other, but they simply do so through the secured cloud.

Extending the “don’t talk to strangers” analogy, this means that IoT devices (“children”) have access to all the information they need, and provide all the information that they have, but only under the constant supervision of the secured application (“parents”) that often lives in the cloud.

As with most things, this will not be the optimal solution for all devices, but we believe there is a compelling argument made that a managed approach will be the right approach for most devices.

Most IoT devices should not support IP

Many will find the following statement controversial: Most IoT devices should not support Internet Protocol. There is a fair amount of IP zealotry in the market and to them that statement will amount to heresy. Some folks in the IP camp will correctly argue that managed connectivity is the way to go for IoT devices, but that IP will inherently support such an architecture.

Let’s extend one more time the “don’t talk to strangers” analogy: parents can tell their children not to talk to strangers or they can go one step further and not let their children be unsupervised in the park where the strangers lurk. Most IoT devices are analogous to young children — simultaneously unreliable in carrying out the marching orders of not talking to strangers, and very much at risk of harm by talking to these strangers.

The title of this post sums it up well: IoT/IoE: When It’s Got an IP Address, It Will Get Hacked. Mirai, for example, supports the following attacks on IP-enabled devices:

  • SYN flooding
  • UDP flooding
  • Valve Source Engine query-flooding,
  • Generic Routing Encapsulation flooding
  • ACK-flooding (including a variant intended to defeat intelligent DDoS mitigation systems, or IDMSes)
  • Pseudo-random DNS label-prepending attacks (also known as DNS ‘Water Torture’ attacks)
  • HTTP GET attacks
  • HTTP POST attacks
  • HTTP HEAD attacks

Not supporting IP shuts down an enormous space of attack vector. In other words, if a managed approach securely locks the IoT device, then not supporting IP is analogous to throwing away the key.

The urgency around the Mirai approach attack is causing governments to ask some tough questions around the suitability of today’s IP approach for IoT devices. In the letter from Sen. Warner to the FCC, FTC and DHS, the following questions are probing around additional required features of IP connectivity as well as introducing new legislation to combat security vulnerabilities:

  • Would it be a reasonable network management practice for ISPs to designate insecure network devices as “insecure” and thereby deny them connections to their networks, including by refraining from assigning devices IP addresses? Would such practices require refactoring of router software and, if so, does this complicate the feasibility of such an approach?
  • Should manufacturers have to abide by minimum technical security standards? Has your agency discussed the possibility of establishing meaningful security standards with NIST?

The direction of these questions seems to backtrack IP away from its fundamental concept of open peer-to-peer connectivity for which it was designed, and to introduce additional complication. Complicated protocols that continue to address security concerns is warranted for the devices that truly need the peer-to-peer functionality that IP enables. But temperature sensors, dog trackers, environmental monitoring stations, glucose monitors, chemical/nuclear sensors, water meters, electric meters, valve actuators and perimeter alarms do not need to browse the internet or directly make orders on Amazon. They need reliable, robust and secure communications for the role that they play in the broader ecosystem. IoT devices need simplicity, not complication. And yet that appears to be the direction if these IoT devices continue on this IP everywhere trajectory.

Recommendations

We recommend a pragmatic view is to identify those devices that benefit sufficiently from the open connectivity that IP offers, against the vulnerabilities that open connectivity like IP creates.

To IoT device makers: If you do not absolutely require services that IP provides, talk only to your parents and lock that down by not supporting IP in your device. Be able to confidently say “there is no way my device was hacked from a peer device,” and “there is no way my device hacked another peer device.” You will also enjoy the benefit of being outside the scope of government and regulatory scrutiny as they continue the battle against potentially catastrophic, and ever-evolving IoT attacks at IP vulnerabilities.

To IoT data stakeholders: If you do not absolutely require services that IP provides, set up your application in the secured cloud, force that as the only path of communication with your device and insist that these devices do not even support IP. The stakes are too high for your application. And you do not want these devices being used to compromise other devices — whether your own devices or others’ devices. You will also enjoy the benefit of being outside the scope of government and regulatory scrutiny as they continue the battle against potentially catastrophic, and ever-evolving IoT attacks at IP vulnerabilities.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: