SCADAMiami, Florida - A no-holds barred presentation at the S4 Conference laid bare the woeful state of security for many industrial control systems that power the world’s critical infrastructure. Organizers have also cooperated with security scanning firms Rapid7 and Tenable to release modules for the Metasploit and Nessus products that can test for the discovered security holes.

The talk presented the findings of “Project Basecamp,” a volunteer-led security audit of leading programmable logic controllers (PLCs). The audit found that decrepit hardware, buggy software and pitiful or nonexistent security features make thousands of PLCs vulnerable to trivial attacks by external hackers that could cause PLC devices to crash or run malicious code.

Dale Peterson, CEO of SCADA security firm Digital Bond Project Basecamp to FireSheep, the browser plugin that laid bare vulnerable Web sessions. That demonstration , at the 2010 TorCon Conference, highlighted weaknesses in the security of Web sessions that had been discussed within security circles for years and made it easy for even non-technical users to hijack user sessions on Facebook, Gmail and Twitter.

“We were looking for a firesheep moment in PLC security,” Peterson told the audience of ICS security experts.

They got one. The project assembled some of the top ICS security researchers, including Dillon Beresford, an independent researcher who has uncovered security holes in Siemens Simatic systems, as well as Ruben Santamarta, an independent security researcher based in Europe, Reid Wightman, an ICS security consultant at Digital Bond, Jacob Kitchell of the firm Industrial Defender, as well as two researchers who chose to work anonymously.

The group tested PLC devices from a number of different vendors.

Programmable Logic Controllers are a kind of general purpose computing system that are used to control a wide range of mechanical systems – from water pumps to elevators to building ventilation systems. PLCs are designed for a wide variety of inputs and outputs and can operate in rugged environments. The Stuxnet worm, which targeted a uranium enrichment facility within Iran, was programmed to modify the behavior of PLCs manufactured by the German firm Siemens that were being used to operate highly sensitive centrifuges within the Iranian facility in Natanz.  

The devices tested by the Basecamp Project included the D20 PLC by GE, The Modicon Quantum by Schneider Electric, Rockwell and Koyo Electronics. Each device was tested using a number of additional attack vectors. Researchers attempted to upload custom firmware or so-called “ladder logic” for the device, looked for back door accounts, weak authentication, undocumented features that could be exploited and fuzzed each device for vulnerable services.

The results were not encouraging.

“It’s a blood bath mostly,” said Wightman of Digital Bond. “Many of these devices lack basic security features.”

While the results of analysis of the various PLCs varied, the researchers found significant security issues with every system they tested, with some PLCs too brittle and insecure to even tolerate security scans and probing.

The D20 ME PLC by GE – a widely deployed industrial system – fared the worst. Wightman’s analysis of the device, which retails for around $15,000, revealed that the D20 relied on both hardware and firmware that was more than two decades old and was rife with hidden “back door” administrative accounts, remotely exploitable vulnerabilities and absent any security controls. Among other things, the D20 allows any attacker who knew the IP address of a device and the proper command to download the device’s configuration file. That file, in turn, can be used to obtain account usernames and passwords for accessing its administrative interface.

The D20 also fared poorly when it came to “fuzzing” – testing to uncover exploitable software vulnerabilities. Wightman found buffer overflow vulnerabilities associated with many of the services running on the D20. Attempts to scan the device using conventional tools, such as Nessus, caused the device to crash.

Those attempting to test the device should use “kid gloves,” he said, because the D20 was so prone to unexpected crashes.

Wightman called the results of the tests “shameful,” and that statements from GE suggest that fixes for any of the issues raised are unlikely, because of the age and fragility of the hardware used in the device.

GE wasn’t the only vendor whose products missed the mark. An analysis of the Koyo DirectLogic PLC revealed a weak, 8 byte password implementation and no password timeout to protect against brute force login attempts. Furthermore, an integrated Web server lacked any authentication protections at all, meaning that any user who could access the DirectLogic PLC could access the integrated Web server, modifying the IP address of the device, changing e-mail alert settings and so on.

The Modicon Quantum PLC turned up a raft of problems including serious buffer overflows in an embedded HTTP server and an FTP server buffer overflow that was documented a decade ago. The device was also rife with hardcoded backdoor administrative accounts – 12 in all.

To help push changes, the researchers also collaborated with security firms Rapid7 and Tenable to create modules to test for vulnerable PLCs.

Rapid7 on Thursday announced new modules targeting General Electric’s D20 PLCs. One would  allow Metasploit Framework users to connect to the embedded TFTP server on the D20 and download the configuration file for the device, then parse the plaintext username and password values for the PLC users from it. A second module would demonstrate an asynchronous backdoor functionality in the D20 via the TFTP interface that would allow anyone who could connect to the TFTP server to issue a command by writing to a special location on the filesystem. 

Tenable announced seven new plugin modules for its Nessus scanner for the GE D20, Schneider Modicon Quantum and SEL 2032 SCADA PLCs or controllers. Tenable said the new plugins will identify insecure PLC configurations that would allow an attacker to take control of a critical infrastructure such as the electric grid, an oil pipeline, a chemical manufacturing plant or water treatment plant. 

The presentation received a rousing response from the audience, many of whom are industrial control security experts who have long warned, quietly, about the woeful state of software security in the industry. But not everyone was enthused. Kevin Hemsley of ICS-CERT questioned Peterson about the decision to go public with the Project’s findings before notifying vendors.

But organizers argued that most of the security problems they discovered were features and design flaws that have long been known to manufacturers, not hidden software vulnerabilities.
“We’re talking about backdoors and the TFTP service. A large percentage of these vulnerabilities the vendor already knows about and has chosen to live with, so this is not news to them,” said Peterson of Digitalbond.

The best way to avoid uncomfortable diclosures, he suggested, is to do a better job making secure products.

“The truth is that whoever finds the (security flaws) gets to decide what to do with them,” Peterson of Digital Bond responded. Peterson also took a jab at Siemens and the Department of Homeland Security for applying last minute pressure on security researcher Dillon Beresford to cancel a talk at TakeDownCon about a similar collection of undisclosed holes in Siemens PLC products. Beresford eventually gave the talk at the Black Hat Briefings. “We heard about DHS and Siemens visiting Dillon in Houston. Maybe we just wanted a Good night’s sleep,” said Peterson.

Hemsley of ICS-CERT said that vendors were notified of the Basecamp Project’s findings and that ICS-CERT and the vendors would be working on addressing the issue. While declining to comment specifically on the group’s work, Hemsley said that he was concerned that many of the flaws concerned hardware-based and design flaws that would be much more difficult to address than software based vulnerabilities. 

“That’s my concern,” he said. 

Categories: Critical Infrastructure, Government, Hacks, Vulnerabilities

Comments (16)

  1. anon
    1

    these “researchers” should have contacted the vendors, instead of playing PR games with ICS. incredibly stupid show of irresponsible disclosure.

    “”The truth is that whoever finds the (security flaws) gets to decide what to do with them,” Peterson of Digital Bond responded.” <– okay, so this jackass justifies whatever he does with “finders keepers” and lives in a world where his actions have no consequences. that makes sense.

    also, before you go speading fud, let’s find out how many of these devices are really online and exploitable.

    the last bunch of supposedly online SCADA devices posted to pastebin and trumped up to be critical infrastructure were a bunch of non-exploitable HVAC and lighting systems. oh. boy.

  2. Anonymous
    3

    I feel like I’m reading an article on The Onion, ’cause this kind of “security” is really that unbelievable. Really.

  3. Paul Roberts
    4

    Just a note that there was a separate presentation just on finding vulnerable systems. Although not all are publicly accessible, many (as in tens of thosuands) are, using free services like the Shodan search engine. – Paul.

  4. Anonbuster
    5

    these “researchers” should have contacted the vendors, instead of playing PR games with ICS. incredibly stupid show of irresponsible disclosure.

    “”The truth is that whoever finds the (security flaws) gets to decide what to do with them,” Peterson of Digital Bond responded.” <– okay, so this jackass justifies whatever he does with “finders keepers” and lives in a world where his actions have no consequences. that makes sense.


    Wow.  You wanna call names?  I bet you think you’re a “responsible security person”.  I guess that researchers should let GE ignore well-known vulns for ANOTHER DECADE?!?!?!  How do YOU justify the fact that you’re so ignorant of the fact that this had to happen in order for some of these security issues to ever be fixed in the first place?!?

  5. NoBackRubNeeded
    6

    Your list is very optimistic, but very UNrealistic.  Many of the vulnerabilities that you incorrectly refer to as 0days have been known to the vendors for a DECADE as reported by numerous sources…which proves that your list is merely a fairy tale.  Maybe this public data dump will finally scare enough people in the industry to create a situation where FUTURE true 0days can be divulged in a similar fashion that you describe, but the schmucks at GE had been ignoring these disclosed vulnerabilities for years and “responsible disclosure” was failing miserably.

    Sorry if being truthful hurts your sense of professionalism.

  6. Anonymous
    7

    Okay, do share the numerous sources that reported the vulnerabilities were known by the various vendors. 

  7. Anonymous
    8

    This is getting attention from vendors… anyway…

    When designing a SCADA system, engineers need to examine what devices are secure, and how to secure their systems. Assume malice, then determine how to ensure that attacks fail. there are products developed for security on the market.

     

     

  8. NoobSlapper
    9

    Read 3 or more recent articles on SCADA security (or the lack thereof) and you will see a significant majority of them discussing the fact that vendors have been ignoring security bugs for many years.  Don’t ask the other guy to provide the sources FOR you…do your own research if you really care to seek the truth.

  9. Anonymous
    10

    As the article says, most of these problems were design problems (e.g lack of authentication, backdoors, short passwords) and previously discovered bugs, not things the vendors didn’t know about.

  10. Anonymous
    11

    I think Stuxnet should be sufficient proof that this isn’t all FUD. It’s true that most of these systems aren’t going to turn up in your Google results with a big “click here to hack me” button. But if, for example, anyone on your LAN can destroy your physical infrastructure, that’s still pretty bad.

  11. Anonymous
    12

    What’s irresponsible is that the vendors didn’t proactively look for this stuff beforehand.  Or, they did and they didn’t want to fix it or disclose it.  They deserve to be spanked publicly because it’s probably the only thing that will get the holes patched.

    If you believe that the vulnerabilities were unknown to the true exploiters and the ICS disclosure is disseminating this for the first time, you are mistaken.  The people who are in the business of attacking PLCs already knew about the vulns.

  12. Anonymous
    13

    No one on this side is ignorant of vuln software or of challenges in getting vuln fixed, friend. Looks like you need some feedback and a back rub. Here is a list:

    1. contact ICS-CERT with the vuln/exploit

    2. (or) try to sell it to ZDI

    3. contact the vendors with the vuln report and demand timely fixes (making assumptions about who knows what is not okay)

    4. contact the orgs owning and using the systems, tell them that their systems are vulnerable because of GE’s irresponsible handling of the vulnerability. tell them that they need to demand that GE fix their systems. they are easier to find than the 0day.

    Dropping weak SCADA 0day sucks. Someone else will have to take care of the back rub.

  13. Anonymous
    14

    Every shodan-“exposed” system that anon posted on pastebin over the past few months has been air conditioning and generally extremely low value/nuisance targets.

  14. Anonymous
    15

    Getting attention, just like a four year often acts out in the wrong way to get attention. Nice.

  15. Anonymous
    16

    Great suggestion, but no one is being asked to do my own research for me. Mine is quite nice.

    Truth schmuth. You miss the point. I think you are mis-understanding the term “sources” here. He was asked to back up his statement that the vendors already have been properly notified by his “numerous sources”. He failed to present that info, and it’s probably because they were never properly notified. Instead, the strong potential that he valued his own PR opportunities over the risk he increased for SCADA customers remains. 

    And no, I don’t defend the systems vendors for completing ignoring their responsibilities in building secure SCADA. Their stuff is shameless.

Comments are closed.