High-Profile Cyber Attacks Should Serve as a Wake-Up Call for IoT Security
Three major security events have occurred in the past two months that have made the technology community — and the media — take notice. The first was a sustained DDoS attack on Krebs on Security, a high-profile and influential website run by veteran security blogger Brian Krebs. The attack was the biggest ever seen, at 620Gbps, and after three days of — successfully — defending it, Akamai, the provider that hosted Krebs on its platform pro bono, announced that it would have to pull the plug due to the ongoing cost of resisting the attack. Krebs on Security was offline for a week before Google stepped in with an offer to host the site through its Project Shield program. Aside from the volume of the attack — which was around double the previous record, seen earlier this year — the notable thing about the Krebs attack was the apparent use of a botnet boosted to more than a million devices by the co-opting of compromised security cameras, routers, DVRs, and other Internet of Things (IoT) devices.
The second event, which flew under the radar of many media outlets, followed soon after the Krebs attack and actually eclipsed it in scale, as French hosting company OVH suffered a 1Tbps attack. The company posted details of the attack online, which included evidence of a botnet comprising more than 145,000 compromised CCTV cameras. According to security experts, two types of Linux malware have been discovered recently that target IoT devices — Luabot and Bashlite. Security experts from Flashpoint and Level 3 Labs have been researching the Bashlite malware and found that it has already infected more than a million devices. Of these, almost 96% were IoT devices (and of those, 95% were cameras and DVRs), around 4% were home routers, and a tiny remainder were Linux servers.
The third major event, in October, hit the servers of Dyn, a U.S. company that manages part of the internet's DNS infrastructure. This time the attack reached a strength of 1.2Tbps, and sites such as Twitter, CNN, Netflix, Reddit, and Spotify were intermittently unreachable during the attack, which came in three waves over the course of a single day. The main botnet behind the attack was identified as the Mirai botnet, the same one that hit Krebs on Security, comprising tens of thousands of IoT devices infected with the Mirai malware. Ultimately, however, Dyn was able to fend off the majority of the attack and keep most of its services running for a lot of the time.
So, three separate attacks, three separate targets or groups of targets, a number of organizations suffering interrupted operations and the cost incurred by the battle. But the internet wasn't broken, and [e]commerce remains alive and well. What have we learned?
First of all, three separate attacks in just over a month tells us that cybercriminals have a new toy and are excited to play with it, and we should expect more of these attacks. Organizations from across the IT spectrum — IoT device manufacturers, service providers, hosting companies, etc. — will need to take more steps in the future to make sure they are not enabling such attacks through weak protection of their products, or through lack of defensive capabilities for their services.
Secondly, hackers don't like it when law and order comes knocking on their door. The Krebs attack may have been provoked by a series of articles he posted, culminating in a piece about the arrest of two teenage Israeli hackers behind a $600,000 DDoS-for-hire operation called vDOS. Some of the attacks on Krebs' own site came with the string "freeapplej4ck", a reference to one of the hackers that was arrested.
Nevertheless, it seems like actual arrests in such cases are extremely rare, and this raises another issue: given the apparent increase in [easily] compromised IoT devices, could the manufacturers be held liable if their devices are used in an attack?
In terms of DDoS attacks, liability claims are unlikely. The first DDoS attacks were registered in around 1999 and have been a regular occurrence since then, but lawsuits addressing the compromised machines that made up the botnets would be almost impossible, since they would have to identify all the machines that were used in an attack, as well as what, how, and when were the vulnerabilities that allowed every individual PC to be breached (could be MS Windows, Office, Internet Explorer; Oracle Java; numerous Adobe products and platforms, etc.). Who audits those PCs to try and find out how and when each was compromised (ignoring the fact that the cost of detecting and auditing a single PC could exceed the cost of ordering a DDoS attack on the darknet)? What if a botnet comprised machines breached via 100 different vulnerabilities? Which vendor do you sue — all of them at once? And then, what if the vendors claim they had released patches for the vulnerabilities that the end users simply had not applied — do you start suing end users as well? Good luck! That raises another issue: Vendors could conceivably argue for different outcomes depending on whether these are zero-day or known vulnerabilities. And should legislators be looking at establishing legal grace periods for device vendors to fix zero-day vulnerabilities?
Excuse the tangent, but I wanted to point out the difficulty of taking any kind of legal action against the unwitting owners of devices that were used in an attack. It is a bit like trying to sue VW because somebody stole a Golf and used it as a getaway car in a robbery.
Now, back to IoT… obviously, the situation is not totally synonymous with compromised PCs. Typically, such devices will have a far more limited set of SW installed, likely embedded OS plus a limited set of applications necessary for operations and management of the device. So, a less epic task in terms of determining the entry point/vulnerability, but, in any case, HW and SW liabilities would have to be disentangled and questions of patching and SW/firmware updates would need to be resolved. For tens of thousands of devices used in a DDoS attack this is impractical, but for a unique event (say a hacked car going off the road) there would be a much stronger case.
So where to begin in terms of encouraging or enforcing requirements for more stringent security to be built into connected devices? We can already see some indicators of how or where this might come from: In February of this year, ASUS settled charges from the U.S. Federal Trade Commission over numerous security flaws and inadequacies in its home routers and the cloud services used by those routers. The proposed settlement includes a requirement for ASUS to establish and maintain a comprehensive security program that would be subject to independent audits for the next 20 years. Thus, not only is the commission pushing for a resolution around the current products of ASUS, but it is also taking steps to ensure that security becomes, by design, a core principle of future ASUS products for years to come. And where one vendor — or regulator — leads, others are likely to follow. Regarding the attacks on Dyn, researchers at security firm Flashpoint found that a huge proportion of the compromised surveillance cameras came from Hangzhou XiongMai Technologies, a Chinese hi-tech manufacturer. The company is now recalling up to 10,000 of its webcams.
To come full circle, the DDoS attacks that prompted this analysis have raised awareness of the risks and implications of releasing IoT devices with inadequate security. With or without concrete cases of loss or system compromise, governments and other regulatory bodies are likely to become increasingly active in terms of penalizing manufacturers that produce insecure devices. In cases where liability is easier to determine — for example, if a specific medical product or a car is hacked and causes damage or injury — then companies will face certain legal repercussions. Nevertheless, regardless of the "direct" or "indirect" connection of devices to incidents or outcomes, the interconnectedness of more and more systems underlines the reality that all producers should take the security of their connected devices very seriously from the start, in terms of design, conception, best practices, testing, patching, and updating.