Note: This originally appeared as part of ISACA GWDC’s IoT Security Conference in April, 2018. Original link to content here.
Executive Summary
Nominally IT-focused threats such as the recent series of wormable, disruptive malware variants from WannaCry through OlympicDestroyer will increasingly impact Internet-of-Things environments. The combination of rapid, automated propagation with multiple capabilities for accessing vulnerable systems – whether through exploit or credential capture – provide adversaries with multiple routes to spread through a target network to reach IoT devices typically not exposed to direct attacks. This significant increase in attack surface will make previously isolated IoT systems – especially critical IoT devices such as Industrial Control Systems (ICS) and medical devices – more readily accessible to infection events. By adopting a whole-network, defense-in-depth approach, asset owners and defenders can reduce their threat surface from such attacks. Examples include greater segmentation of networks to limit automated malware propagation, and identifying critical nodes required to access IoT deployments as candidates for extra security hardening. Through this approach, the problem of increasingly virulent, self-propagating malware impacting IoT devices will not go away, but defenders can appropriately shape the environment to reduce risk.
Introduction
The public conception of Internet-of-Things (IoT) related malware typically starts and ends at low-level worms such as Mirai and BrickerBot. While certainly a cause of concern and a source for some disruption, defenders and asset owners assume that more sensitive systems in the IoT space – industrial control system (ICS) equipment, medical devices, and other operational technology – are immune to such attacks for various reasons: the systems are simply more robust, and they are assumed to be ‘unreachable’ from typical infection vectors. Unfortunately, current events prove these assumptions to not only be false, but dangerously misleading. More specifically, recent malicious worm variants possess the capability to bridge alleged ‘airgaps’ to reach sensitive IoT systems, and further retain the functionality to cause significant damage and disruption.
This paper will review the current threat landscape with respect to self-propagating malware with the potential to impact critical IoT systems. Special attention will be provided to the underlying methodologies on what makes these threats uniquely worrisome for high-value IoT networks, such as ICS environments, and the root vulnerabilities that enable such activity. After providing an overview of the threat environment, the discussion will conclude with examples and advice on how to secure these environments and mitigate the risk posed by wormable malware in the IoT environment.
The Threat Environment
When considering the IoT threat environment, most practitioners think of malware like Mirai. Mirai is wormable malware that takes advantage of weak, hard-coded credentials in IoT devices to create a ‘botnet’[1]. Notable uses for this botnet include various distributed denial of service (DDoS) attacks, leveraging a large infection footprint to generate overwhelming amounts of network traffic on specified targets. While concerning and certainly disruptive, Mirai depends upon its hardcoded credential list for functionality: well-designed and maintained devices are not susceptible to the attack as they do not share the hard-coded authentication used for the malware’s spread. Additionally, Mirai is wholly dependent upon target devices being directly accessible: vulnerable nodes are Internet-connected and directly reachable from infected hosts. Another popular example of IoT-impacting malware is BrickerBot, which essentially works the same as Mirai in searching for default credentials, except with an intention to render infected devices unusable.[2]
The overall result is that while Mirai and subsequent variants are concerning, they remain so for only a subset of IoT devices: ‘Small Office-Home Office’ (SoHo) routers, IP cameras, and low-grade consumer IoT equipment. While potentially worrisome when marshalled together as part of a botnet, none of these impacted categories of devices truly controls or impacts a vital service. As a result, Mirai, while disruptive, is a fundamental nuisance rather than an existential threat.
Much more concerning than Mirai are worms usually associated with IT network infections, such as WannaCry, NotPetya, BadRabbit, and most recently OlympicDestroyer. Rather than simply replaying hard-coded, default credentials, these events deployed two primary means to spread: exploits targeting vulnerable versions of the Server Message Block (SMB) protocol, and credential capture and replay. The significant aspect to these is flexibility: the ability to compromise a large number of machines by taking advantage of operational dependencies and weak security practices while also enabling infection of ‘intermediate’ hosts to achieve deep network penetration to more sensitive IoT devices.
MS17-010 is the Microsoft designation for the vulnerabilities that fueled WannaCry and provided one means of propagation for NotPetya.[3] The vulnerabilities in question are associated with the ‘Shadow Brokers’ leak of alleged NSA tools, with three specific exploits tied to the vulnerability: ETERNALBLUE, ETERNALCHAMPION, and ETERNALROMANCE. All three target vulnerabilities in version 1 of the SMB protocol to achieve remote code execution – albeit with the possibility of causing system instability leading to a ‘blue screen’.[4] Although patched by Microsoft prior to the WannaCry event, slow patch application resulted in significant spread and system impacts.
NotPetya, BadRabbit, and OlympicDestroyer changed the pattern for disruptive or destructive worm propagation by adding either a secondary mechanism to MS17-010 exploits, or avoiding them altogether. The technique employed by these examples focused on credential re-use within the environment. While OlympicDestroyer started with a list of environment credentials within the binary – similar to Mirai – all three examples also incorporated a more robust means of capturing authentication information: embedding a version of the popular ‘Mimikatz’ tool to dump Windows credentials from memory.[5] Once acquired, these are employed to spread to connected systems, assuming that credentials are re-used within the network. Since Mimikatz dumps authentication information for all users that have logged into a machine since its last reboot, the possibility of including users for multiple workstations or administrators that access multiple machines is quite high, and makes this technique uniquely powerful to spread throughout a network.
Risk to IoT
Thus far this paper has considered general threats to the network environment – whether through exploit or credential capture. When viewed through the lens of IoT environments, especially critical IoT systems such as ICS or medical deployments, the concerns noted thus far become far more significant. Whereas the primitive propagation methods deployed by worms such as Mirai would – hopefully – fail in more robust (and critical) networks such as ICS, the spreading mechanisms used in WannaCry or OlympicDestroyer are sufficiently flexible and durable to proliferate easily within embedded system environments.
Aside from unique risks, IoT environments also face unique challenges and vulnerabilities when faced with these type of infection vectors. These challenges roughly break into two general concerns: first, the lack of flexibility and poor responsiveness to apply security patches to the environment; and second, the continued prevalence of hard-coded or default vendor authentication credentials on IoT devices. The former is worrisome with respect to exploits, while the latter provides unique opportunities for ‘living off the land’ network pivoting.
IoT devices are typically designed to serve a specific function with little variation for the duration of the device’s lifespan. In the case of ICS and other specialized embedded systems, these devices are designed to very unique and limiting specifications, making software or other updates difficult if not impossible to perform. The result is that today’s IT network ‘zero day’ becomes an IoT ‘forever day’: vulnerabilities that, although patched by current IT systems, remain exploitable due to the inability to apply patches to embedded IoT systems. Thus, while the general Windows landscape mitigated the threats posed by the MS17-010 exploits by simply applying the patch, many critical IoT systems remain vulnerable due to an inability to patch the operating system.
Ease of maintenance and assumptions concerning deployment and use result in many manufacturers leaving either hard-coded, immutable credentials on IoT devices or including vendor accounts that are not well documented by administrators. Superficially, this is similar to the Mirai case where dictionary attack fueled consumer IoT device exploitation. However, more robust malware, such as NotPetya or more recently OlympicDestroyer, includes another mechanism to propagate: the capability of capturing stored credentials on infected hosts via password ‘dumping’ programs such as variants of the publicly-available Mimikatz tool. This added functionality provides worms the ability to further spread by harvesting credentials from the target network. While these credential theft programs typically require administrator privileges to execute, the tendency for many IoT devices (and users) to run under local administrative privileges combined with credential re-use across the network for convenience provide an effective means to overcome this barrier.
Used independently or in conjunction with each other, these two mechanisms for automated malware propagation pose significant risks to IoT environments, even when they are physically and logically isolated from more exposed IT networks. One initial access is gained to the IoT enclave, the inherent vulnerabilities and weaknesses described above may result in rapid, nearly unchecked spread to all networked devices within the network.
To illustrate this via brief case studies, ICS networks typically feature multiple links to general IT networks to facilitate remote administration or data transfer for business intelligence purposes. Should a self-propagating malware variant similar to those described thus far begin spreading through the IT network, it may also compromise one of these IT-ICS network links to ‘bridge’ the two nominally separate networks. For example, an engineer’s PC may become infected, resulting in loss of credentials with malware identifying past remote connections to an ICS device. The combination would allow the malware to ‘jump’ to the ICS network. Alternatively, a business intelligence server linked to an ICS data historian – leveraging a legacy version of the SMB protocol for data transfer – may become compromised on the IT side, with the (vulnerable) SMB connection then used to pivot to the ICS network. In both cases, a theoretically isolated and segmented network becomes compromised through legitimate, operationally-necessary communication links. Once in the ICS network, the weaknesses described earlier lead to a rapid spread to other vulnerable devices resulting in a potential large-scale impact.
Subsequent damage and disruption depends on the malware and its payload. The WannaCry ransomware worm resulted in system encryption and operational loss in various operational environments, such as auto manufacturing plants.[6] The NotPetya destructive attack caused over $200 million in damages and lost operations to the shipping giant Maersk.[7] Although not directly IoT related, the more recent OlympicDestroyer malicious worm threatened to disrupt the 2018 Winter Olympic Games Opening Ceremony by spreading through the impacted network and rendering systems non-functional.[8]Irrespective of ultimate payload, any malware variant deploying this type of technique for propagation can be significantly disruptive, if not catastrophically so depending on the nature of impacted operations.
Defense and Mitigation
While the current situation with respect to IoT-related defense against virulent, self-propagating malware with destructive impacts appears bleak, asset owners and defenders do have options to either mitigate these threats, or at least put their security personnel on better footing. Many of the underlying vulnerabilities that cause this type of infection event to be so dangerous to embedded system environments simply cannot be dealt with short of dramatic changes in vendor practices and network re-architecture. However, by applying a defense-in-depth approach and identifying critical nodes linking initial infection vectors in the IT or business network with IoT systems in separate enclaves, defenders can design and implement sustainable defensive plans to reduce the impact of this type of malware.
First and foremost, while modern device design and implementation makes complete isolation of IoT devices – even critical ones such as ICS equipment or medical devices – nearly impossible, such devices need not have complete and unfettered network connectivity. Designing and implementing proper network segmentation, allowing only necessary protocols through enclave firewalls (and only in the required directions), and adding traffic monitoring or blocking capability on ‘choke-points’ connecting these enclaves to the rest of the network will significantly reduce an organization’s attack surface
Once this critical step is applied – whether through physical design or logical implementation through VLANs – defenders can then focus on the resulting traffic ‘choke-points’ as focal points for defense, monitoring, and hardening. The earlier example citing an ICS data historian compromised through and SMB link to a business intelligence server provides a useful case study: the ICS device may not be amenable to patching, but more than likely the IT device it communicates with can be patched. Identifying this IT node as a critical ingress route to the vulnerable ICS network can prioritize resources to patch these critical linking systems. Taking this action will effectively protect the vulnerable systems further down the network by preventing propagation in the first place.
By adopting a conception of IoT network defense that accepts and embraces links and dependencies on the IT or business network, defenders can build out a robust defense-in-depth posture to protect otherwise vulnerable devices. Rather than waiting for patches, updates, or other items which may never appear, network defenders can take the initiative by designing and implementing their networks to protect IoT devices even from highly automated and virulent attack vectors. The same steps that will protect operations-critical embedded systems from the next WannaCry or OlympicDestroyer are additionally beneficial as they will effectively shield these resources from more dedicated and advanced attackers. Essentially, viewing the IoT security problem as part of an overall IT security issue and addressing as such ensures that IoT devices are completely understood with respect to their weaknesses, while appropriate controls are put in place throughout the network to ensure their survival.
Conclusion
The threat landscape for IoT devices, especially mission-critical IoT systems, continues to increase in terms of scope and capability. Legacy software, architectural decisions made for a ‘less connected’ environment, and continued adversary interest will make IoT security a difficult problem for the foreseeable future. Yet while IoT security, especially in the face of rapidly-spreading, automated malware, will remain difficult, it is not impossible.
Network owners, defenders, and administrators retain a number of options to harden and improve security within the sphere of IoT deployments. Some options, such as implementing more robust enclaves for IoT devices with few touchpoints to standard IT environments, may be difficult to execute quickly, but their payoff is immense toward enhancing operational security. In the interim, greater flexibility afforded by standard IT deployments can be utilized to improve defenses and prevent infections from entering the network before they can worm their way to IoT devices for maximum impact.
Overall, the IoT security problem requires defenders to think about defense more broadly than single-host hardening. IoT devices – from cheap consumer products through complex ICS gear – will remain problematic for simple security tasks such as applying software updates and implementing endpoint protection. Instead of viewing this as the root of a fundamentally unsolvable problem, defenders instead must push the bounds of defense for IoT systems out beyond the devices themselves to encompass network and host routes leading to IoT enclaves. Applying a more thorough, whole-network, defense-in-depth posture ensures not only better protection for IoT devices, but more sound and capable defense for the entire managed network.
FOOTNOTES
[1] Leaked Mirai Malware Boosts IoT Insecurity Threat Level – SecurityIntelligence
[2] BrickerBot Is a Vigilante Worm That Destroys Insecure IoT Devices – TechCrunch
[3] Microsoft Security Bulletin MS17-010 – Microsoft
[4] NSA-Leaking Shadow Brokers Just Dumped Its Most Damaging Release Yet – Ars Technica
[5] Mimikatz Overview, Defenses, and Detection – SANS Institute
[6] Renault-Nissan Is Resuming Production After a Global Cyberattack Caused Stoppages at 5 Plants – Business Insider
[7] NotPetya Ransomware Attack Cost Shipping Giant Maersk Over $200 Million – Forbes
[8] OlympicDestroyer Takes Aim at Winter Olympics – Cisco Talos
