Thursday, October 27, 2016

Because They Can: Spawning of the IoT DDoS

Authored by: Keely Richmond, Sr. Cybersecurity Engineer

On September 13, 2016, the website of a US-based Cybersecurity Journalist (Brian Krebs) was hit by a DDoS attack that knocked his site offline. The resulting investigation uncovered a type of DDoS attack different in composition and scale than that of the typical DDoS attack.  In fact, this type of DDoS attack had only been seen in the wild a handful of times—the earliest known detection: April 2016.

Two pieces of malware (similar, but different), Mirai and Bashlight, were used to enslave enough Internet of Things (IoT) devices to launch a 620Gbps DDoS attack for the sole purpose of silencing a journalist whose articles threaten the livelihood and freedom of criminals.

As expected, an IoT DDoS attack sustaining 620Gbps got the attention of all types of people and organizations and the internet was soon riddled with a flurry of partial facts and theories about who, how, why, and what might be next. 

Then it happened again! 

On September 20, 2016, approximately 150,000 IoT devices (primarily DVRs and CCTVs) were enslaved to launch a 1.1Tbps DDoS attack against OVH (a French hosting company service provider). The target: Minecraft servers. The culprit: Mirai.

By September 30, 2016 the creator of Mirai decided to cut bait and released the monster (source code) into the public domain for anyone to use. This put distance between them and the source code, making the job of law enforcement more difficult because the code was now in the “possession” of virtually everyone. It also put a very powerful weapon in the hands of anyone with a moderate level of technical prowess and malicious intent.

At the same time the source code was published, the list of IoT devices targeted by Mirai (with default login credentials for each) was also published. This accomplished a few things:
  • Put the manufacturers and vendors of those devices on notice that their equipment needs to be secured or securable
  • Informed consumers (at least those who read tech news) of the lurking vulnerabilities in their homes and small businesses
  • Provided a seed list to anyone who wanted to give that source code a test drive
  • Made IoT vulnerability a hot topic for Cybersecurity specialists and service providers 
  • Caught the attention of legislators—domestic and foreign

In addition to releasing the Mirai source code, its creator touted that it had been able to enslave 380,000 IoT devices before the scrutiny following the OVH attack made such endeavors too risky. 

And then…it happened again!

On October 21, 2016 the US-based DNS provider, Dyn, was the third known victim of Mirai. The metrics of the attack have not been released to the public, but speculation puts the volume of the DDoS at 1.2Tbps. The Dyn attack impacted millions of people in the United States and Europe. Traffic destined for sites such as Twitter, Amazon, PayPal, and Netflix could not be resolved if public DNS providers (such as Dyn or Google) were used. Cisco’s OpenDNS, however, held steady because it uses smart caching.

Via a Twitter post, a hacking group called New World Hacker has claimed responsibility for the initial Dyn attack. Their motivation was simply to prove they could do it. Shortly after the attack by New World Hacker ceased, the hacker group Anonymous is said to have performed a second wave of the attack. The participation of both groups is unconfirmed at this time as the Department of Homeland Security continues to investigate.

The Mirai source code had been in the public domain for less than one month when the attack on Dyn was launched.

Now What?

"Perfection is not attainable. But if we chase perfection, we can catch excellence.”- Vince Lombardi


Devising a security strategy for IoT devices is challenging. Not all devices are created equally.  Some are patchable, some are not.  Some have configurable login credentials, some do not.  Some are “smart”, some are not. 

For Subscribers (End Users)
The recommendations offered by researchers are limited and responsibility falls squarely on the owner of the IoT device.
  • Purchase and implement IoT devices that require the password be changed upon initial setup. 
  • If possible, change the default login credentials. Unfortunately, not all devices allow the login credentials to be changed.
  • Upgrade the device firmware as new versions are released. Be mindful, however, that a firmware upgrade may reset all login credentials back to default.
  • Configure your router to point to OpenDNS for DNS resolution.
  • Disable UPnP on routers
  • If the device resides behind a firewall…
    •  Disable unnecessary ports. The Mirai attack looks for devices listening on telnet (especially ports 23 and 2323), SSH, HTTP, SMTP, etc. It’s not realistic to block those ports outright, but limiting their use to specific IPs is a good idea.
    • Monitor traffic on port 48101. Port 48101 is commonly used for the transport of malware.
    • Segment all IoT devices to a specific VLAN and restrict outbound traffic from that VLAN.

 As with any project, we must use the right tool for the job.  Relying on subscribers to build and secure their private networks isn’t the right tool for this job. 

For Service Providers

What tools are available upstream from the subscriber, at the service provider level?
  • DDoS mitigation tools (e.g. Arbor) are effective in monitoring and alerting as bandwidth usage thresholds are exceeded.
  • Ensure your IPS malware signatures are up-to-date. Because the Mirai source code was released, it will be fairly easy for vendors to write a signature.
  • Implement OpenDNS to ensure your DNS traffic is scrutinized with the most up-to-date rules in the industry and to take advantage of smart caching.
  • Use the published list of IoT vendors to seed a DENY rule that restricts traffic from those specific device types. This is feasible, but tricky because blocking all outbound traffic would also prevent those devices from pulling firmware upgrades from their manufacturers.

DDoS attacks are just one of the nefarious acts for which IoT devices are being used. An article published by Brian Krebs on October 13, 2016 explores how they’re also being used to turn consumer-grade routers into SOCKS proxy servers, anonymizing the source of suspect traffic.  Use of these hijacked routes are then offered for sale on the dark net to further the spread of various forms of cybercrime. 

What’s Next?

Device Recall
The IoT devices favored by Mirai use components built by a China-based company named XiongMai. In a statement issued on social media , XiongMai said it would be issuing a recall on millions of devices—mainly network cameras. Details of the possible recall are unknown at this time.

Growth
Per Gartner Research, there will be 6 billion IoT devices at our fingertips and on our networks by 2018. New and existing communications standards such as Wi-Fi, Bluetooth Mesh, Low Power WANs, Narrow Band IoT, and ZigBee will grow in usage as the footprint of “things” expands and smart homes grow into smart cities. 

Standardization
Encouraging or regulating the manufacturers of “things” to adhere to basic security practices is key to standardizing how those “things” can be monitored and managed on our networks.

The European Commission, in an effort to enhance the European Union’s telecommunication laws, is developing requirements to standardize security for IoT devices. At this time, there’s no indication of how security for an IoT device will be defined, measured, or monitored. Though not subject to EU regulations, we will benefit if they are successful in enforcing standardization.

CCI Systems’ Recommendations

CCI Security Engineers have studied the three recent IoT DDoS attacks and devised two lists of recommendations (one for the owners of the IoT devices and one for their service providers), each stated earlier in this article under the “Now What?” section. Ideally, the two lists should be deployed in concert, but it is not realistic to expect subscribers to have the technical knowledge to perform the recommended steps nor for the service provider to have the access or ability to monitor the security measures of privately owned networks.

Cybersecurity = Risk Management! 
  1. Employ security best practices.
  2. Design and implement enforceable security policies. 
  3. Review and incorporate the National Institute of Standards and Technology (NIST) Cybersecurity Framework into your Security Strategy.
For more information regarding your network security, or to discuss the recent DDoS attacks, reach out to us! We’ve got the expertise and know-how to keep your network protected.

References

ABC7News. 2016. ABC7News. Oct 23. Accessed Oct 24, 2016. http://abc7news.com/news/hackers-claim-responsibility-for-massive-cyber-attack/1569209/.
Akamai. 2016. Akamai. Sep 30. Accessed Oct 12, 2016. http://www.akamai.com.
Gartner. 2016. Gartner. Oct 12. Accessed Oct 12, 2016. http://www.gartner.com.
Krebs, Brian. 2016. KrebsOnSecurity. Sep 30. Accessed Oct 12, 2016. http://www.krebsonsecurity.com.
McCarthy, Kieren. 2016. The Register. Oct 21. Accessed Oct 24, 2016. http://www.theregister.co.uk/2016/10/21/dns_devastation_as_dyn_dies_under_denialofservice_attack.
NIST.gov. n.d. NIST.gov. https://www.nist.gov/cyberframework.
Savage, Marcia. 2016. Network Computing. Oct 12. Accessed Oct 12, 2016. http://www.networkcomputing.com/applications/attackers-exploit-weak-iot-security/1139771366.
US-Cert. 2016. USCert. Oct 14. Accessed Oct 14, 2016. https://www.us-cert.gov/ncas/alerts/TA16-288A.
Zeifman, Igal, Dima Bekerman, and Ben Herzberg. 2016. Incapsula. Oct 10. Accessed Oct 12, 2016. https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html.
ZigBee. 2016. ZigBee. Oct 12. Accessed Oct 12, 2016. http://www.zigbee.org.

No comments:

Post a Comment