Don't Look Now, but Mirai Just Changed Security

On October 21, 2016, Domain Name Servers (DNS) provider Dyn (News - Alert) came under attack by two large and complex Distributed Denial of Service (DDoS) attacks against its managed DNS infrastructure. The attack technique used against Dyn was first used several weeks earlier and actually had its source code released four weeks prior to the Dyn attack, allowing several botnets to incorporate the code. In this case, those botnets consisted of IoT devices, including printers, IP cameras, residential gateways and Machine to machine (M2M) routers, etc. The attack, known as Mirai, scanned for vulnerable devices it could compromise using a short list of 62 common default usernames and passwords. Many IoT devices never had their default passwords changed, making it easier for attackers to crack those logins and incorporate those devices into the botnet.

The immediate result of the attack was that Dyn received malicious look-up requests from millions of IP addresses (high-volume floods of TCP and UDP (News - Alert) packets, both with destination port 53), flooding the company’s Internet directory servers and making major Internet platforms and services, including Twitter (News - Alert), Spotify and Netflix unavailable for portions of the day to large numbers of users in Europe and North America.

The long-term result of the Mirai attack is that IoT device manufacturers must now rethink their security posture, shifting from the position that security is ultimately the customer’s job to one of making IoT devices more secure out of the box. This shift in device security responsibility is also partially due to the fact that mobile carriers do not consider security testing a primary responsibility. Although they do test for dropped connections, radio hand-offs, retry backoffs, and other characteristics that affect the health of their network, they stop short of testing cell radio firmware for security, due to the expense. This shouldn’t come as a complete shock, considering that the more data that moves across their networks (even hacker/malware data), the higher the revenue for carriers. For these reasons, security is likely to remain the responsibility of the entity designing, manufacturing and integrating these devices.

Situational Analysis
With Mirai, it became clear that the real IoT security threat isn’t that hackers could steal data from an IoT-enabled appliance, a smartwatch, or a connected car, etc. The real IoT security threat is that a huge number of IoT devices will be compromised and used to form botnets capable of launching large scale attacks on critical parts of the internet.

Botnets that seek to compromise computers and servers are not as effective since those devices are routinely offline and can’t be harnessed for an attack. That’s not true of an IoT device – in fact, not only are they always on and connected, they are not always engaged in sending or receiving data, making them excellent assets to be used for DDOS attacks. In fact, even if the device is engaged for its primary purpose, a DDOS attack can still leverage the device – the result will simply be increased bandwidth usage during the time that the compromised device sends malicious requests.

An IoT device-driven DDOS attack raises the specter of IoT devices being harnessed by individuals who don’t particularly care about the contents of your fridge or which NFL game you are recording - they just want the massive internet-connected processing power that millions of connected IoT devices can provide.

Best Practices

• Change default passwords: Given the attack vector that Mirai used, it’s clear that one area Device OEMs can make design decisions to increase security is with respect to passwords. The days of leaving the default password unchanged are over, so manufacturers must either force users to change passwords or create a “default” passwords that are unique to each individual IoT device.

• Don’t allow insecure ingress protocols: Mirai malware contains “killer” scripts that remove other worms and Trojans, allowing Mirai to maximize its use of the infected host device. But Mirai also goes one step further and closes processes that are used for remote ingress attempts, like Telnet, SSH, and HTTP.

• Secure remote management tools: Efficient, cost-effective method of remotely monitoring, updating and managing connected devices. Users can set performance parameters for healthy devices and create reports and alarms for suspicious activity. Using a remote manager that incorporates PCI (News - Alert)-DSS and other relevant security certifications in the cloud such as HIPAA and NIST allow users to define a device profile, assign the profile to all devices in a group, and monitor and auto-remediate any variances. The best remote management tools can also restrict incoming traffic to only allow SSL connections, eliminating unencrypted TCP connections.

• Firmware updates: Firmware updates must be completed securely (authentication) and automatically, or at a minimum, users must be notified/prompted when a new firmware update is available.

• Packet encryption: This consists of basic encryption, such as FIPS-197/AES, to protect messages from unauthorized viewing or malicious changes. This method is easy to implement and use, especially in conjunction with private keys. ?

• Message replay protection: Encrypted packets are enhanced with data fields that vary in a way known to the recipient (which could be as simple as a date stamp). The recipient enforces a rule that messages are only accepted once or in a sequence. This prevents recorded, but not necessarily decrypted, messages from being resubmitted at a later time ?

• Public Key Exchange:  One of several methods can be used to select and combine two large numbers; the recipient is then sent one number and the resulting combination. The recipient can then derive a session key that is known to the sender, establishing a channel to encrypt/decrypt traffic. The sender and receiver don’t need prior knowledge of one another and manual configurations can be minimized. 

• Transport layer security: Transport layer security provides a standard framework for Public Key Exchange and encryption to secure traffic between devices. This is more appropriate for systems where communication occurs in IP sessions such as TCP.  ?

• Wi-Fi protected access: If a terminal device uses Wi-Fi (802.11) for communication, the WPA2 suite of standards can secure the communication channel. Generally, beyond the reach of smaller systems unless specialized Wi-Fi-dedicated coprocessors are present. For certain applications on larger OS-based (e.g., Linux) systems, WPA2 can be an attractive option. ?

Conclusion
Given enough time, money and expertise any system can be hacked, and security threats to IoT devices will become more common. Unfortunately, IoT solutions can’t simply implement a strong password over a TLS connection – the most common approach for Internet applications. These solutions require a different approach, one that requires the identification and mitigation of the unique security risks presented by millions of intelligent, connected devices.  

The unique security requirements and challenges of IoT applications are mostly due to resource limitations. However, there are some basic methods, including default password changes, locking down protocols, and the use of secure remote management tools, among others, that are compatible with the unique needs of intelligent, connected devices.

Security is always a balance between economic cost and benefit, dependent upon the value of assets on the one hand and the cost of security features on the other. The key is to design a system that deters attackers by making it economically impractical to compromise the system – essentially making it an unattractive proposition.