Vulnerabilities Not News to Experts

(This article was originally published on the Findings From the Field blog.) Last week's announcement by Luigi Auriemma of 35 unpatched ICS vulnerabilities is no surprise to SCADA/ICS experts. If anything, the surprise in the list of vulnerabilities is that all of them were implementation flaws rather than the more serious design flaws evident in many products. Most industrial sites maintain that their hardened perimeters are doing a good job of protecting the "soft interior" of their control systems. They are mistaken. There are enormous numbers of unpatched security vulnerabilities in control system software - most undiscovered and un-announced. Thus far few people are looking for ICS vulnerabilities - there is little profit in finding them. Many who find vulnerabilities use the Coordinated Disclosure process, but there is a large population of skillful investigators who believe strongly in Full Disclosure. Expect a steady dribble of these vulnerability announcements - indefinitely. Common Vulnerabilities Luigi's list of vulnerabilities is pretty typical of my own experience of leading control system software development teams. Of the 35 vulnerabilities, we have: 14 buffer overflows 13 integer overflows 2 memory corruption 3 reading/writing arbitrary files 1 executing arbitrary files with arbitrary arguments 2 other When my own people made these mistakes, it was generally "sloppiness." People simply weren't paying attention to security - they were worried about getting the features implemented, making them reliable without slowing the product down, and getting the features released on time. They weren't worried that every packet they read from the network might be from an adversary, or that every user on the system might be one. Even less did most developers think about least-privilege or other ways of designing security in to products. Very few PLC's in use today require credentials to reprogram or re-flash them. Many designs still in use have client software authenticate users, not server-side software. Most communications protocols in use in control systems are not encrypted, nor do they use strong authentication to prove the message came from the machine and user it should have come from. Few control system components have the extensive auditing features needed to create and centrally archive audit logs to record who did what, and so deter insider attacks. All the data I have indicates that there are an enormous number of vulnerabilities in control system products of various vintages waiting to be discovered, and it gets worse. As Luigi points out, he found these 35 vulnerabilities in about 10 days, with no prior knowledge of control systems or of these vulnerabilities. All he had was access to a copy of the software to test. This suggests that other security investigators with a bit of talent and elbow grease can also find easily-exploited vulnerabilities. I think Dale Peterson's warnings about posting poorly-secured demo executables on the internet are well-founded. The closest approximation to good news here is that there is little economic motivation for investigators to find and publish vulnerabilities in control systems. Yes, they get some press for a while, but the press is fickle. Once there is a steady stream of these announcements, the press will find something "new" to write and talk about. This is why I conclude there is going to be a steady stream of these announcements for the forseeable future, but not a flood of them. Perimeter Protections Industrial sites which follow security best practices have patch programs and apply security updates and patches as frequently as is practical. The remainder, when they think about security at all, think about perimeter protections - firewalls specifically. The thinking is that if the perimeter is sufficiently hardened against attack, the business can tolerate a "soft interior" to the control system. In practice, perimeter firewalls for control systems are notoriously porous. A majority of them still allow all outbound connection requests, all the way out to the internet. Most firewalls are configured to allow "all business-essential communications." What is considered business-essential? Generally anything the business needs to reduce costs. As a result, an enormous number of kinds of connections are allowed through most ICS firewalls. In practice, a large majority of control system firewalls present little resistance to penetration-testers, much less someone with a motive to do real harm. Looking Forward There is a lot of work to be done here. Vendors need to step up and make their systems more secure - secure by design as well as secure implementations. Vendors need to become responsive to discovered vulnerabilities and patch them promptly. Vendors with programs to reward investigators for Coordinated Disclosure of vulnerabilities buy themselves opportunity to patch their products before vulnerability description are released to the public. While this is happening, customers need to look at ways to mitigate these vulnerabilities. Much stronger perimeters are a first step. Patch programs keep control systems current with vendor-supported protections. Host Intrusion Prevention Systems (HIPS) can harden the "soft interior" of control systems. HIPS protect both against vulnerabilities not yet patched, and against vulnerabilities which have not yet been announced. Compliance management, intrusion detection systems and central logging / security event management systems all help too, with different aspects of security. Control system security vulnerabilities will continue to be announced - there are simply too many of them not to expect a steady stream of announcements. Toolkits for penetration testing and exploits are starting to reflect these announcements as well. Owners and operators of industrial sites need to take steps to ensure these announced vulnerabilities and toolkits are not threats to the safe and continuous operation of their sites. Further Reading Dale Peterson has an interview of Luigi Auriemma - nice insight into the motives of a Full-Disclosure security researcher. PJ Coyle has some interesting ideas for the Full Disclosure / Coordinated Disclosure debate.