Companies that make supervisory control and data acquisition (SCADA) and industrial control software are still dangerously lax when it comes to application security and vulnerable to attack, according to a researcher from security firm Tenable Inc. who warned that the use of coded administrative “backdoor” passwords of the type used by the Stuxnet worm isn’t uncommon.
Speaking at the ToorCon Security Conference in San Diego, Jeremy Brown, a vulnerability researcher at security firm Tenable said that many SCADA software vendors lag far behind other IT firms in vulnerability research and lack even a basic awareness of modern security principles.
Despite the recent, high profile Stuxnet worm, which made headlines around the world by targeting Siemens industrial control system (ICS) software used in power plants and other critical infrastructure, SCADA vendors are not receptive to vulnerability reports from security researchers and often lack the internal processes to properly handle and address vulnerabilities discovered by outside researchers, Brown said.
In a world of near constant scrutiny of high profile operating systems and applications and real time security updates, the world of SCADA and ICS software still operates largely on assumptions made decades ago: that SCADA and ICS systems aren’t of interest to malicious hackers, and that SCADA systems are isolated from the public Internet and, therefore, safe.
“Security is more often an add-on rather than a core component of SCADA systems,” Brown said. “These are systems that are designed for long term deployments, in which software updates often require hardware updates.”
As an example, Brown related a recent experience trying to report a remotely exploitable, stack based buffer overflow vulnerability in the BACNet building automation software by the firm SCADA Engine. That software, which runs on a variety of Windows platforms, is used to control heating, cooling, lighting and security systems in large buildings. After notifying the vendor and e-mailing a copy of his findings to the security contact at the firm, Brown found himself having to explain the concept and implications of the remotely exploitable vulnerability to an unreceptive audience.
“Please don’t waste my time,” was the response Brown received from SCADA Systems, he said in his presentations. That led to a public disclosure of the hole and an alert from ICS_CERT, the Industrial Control Systems Cyber Emergency Response Team, which was published on September 21. The hole was fixed by SCADA Engine within days of that alert, Brown said.
That experience isn’t unusual, Brown said, noting the work of researchers like Kevin Finisterre of SNOSoft, which has also tried to raise the alarm about SCADA security vulnerabilities with industry players.
Despite the flood of attention that the Stuxnet worm brought to the issue of SCADA security, lax practices are still common, including the use of hard coded credentials – a glaring security hole that was exploited by Stuxnet. Brown said that he has discovered another such hole in software by a well-known SCADA vendor, though he declined to discuss the hole in much detail.
Brown warned that holes in SCADA systems aren’t hard to come by. He has developed a prototype of a Metasploit-style framework, dubbed SploitWare, for testing a number of zero day holes he has discovered in SCADA software. A similar tool may already have been developed by parties interested in compromising critical infrastructure, including nation-state sponsored hackers and criminal groups interested in extortion.
SCADA vendors need to assume that their software is accessible from the Internet – if not directly, then indirectly. With SCADA security smarts in short supply, the industry also needs to educate itself on the art of software security assessment and follow the lead of consumer and enterprise software vendors by devoting resources into testing their software for vulnerabilities before it is released, Brown said.
