The day kicked off with two complementary OPC Exposed Presentations.
Session 7 – OPC Exposed, Part I by Lluis Mora of Neutralbit
Lluis’s paper looked at OPC server implementation vulnerabilities. He detailed some of the 24 test cases he ran against 75 different OPC servers and summarized the results. 33% of the OPC DA servers tested were vulnerable to at least one of the test cases.
The paper and presentation grouped the test cases into categories and calculated some summary results. For example, 22.67% were vulnerable to server handle poisoning, 10.66% were vulnerable to overflows, 4.8% were vulnerable to type conversions, and no servers failed the blob poisoning tests.
Again let me stress these are implementation vulnerabilities, not some flaw in the OPC specification. The immediate reaction is typically OPC has no security or OPC uses DCOM. Both true statements, but they do not address what we believe is even the more important, and heretofore ignored in the SCADA security community, of implementation vulnerabilities.
Equally important is to realize that 50 of the OPC servers passed the test. So some vendors are following secure coding practices to a greater degree than others. There is a big caveat here. The coverage of Lluis’s 24 test cases is a very small percentage of the attack surface.
I was very pleased to see that Lluis and Neutralbit submitted 25 advisories to US-CERT and CERT/CC for processing. The coordination centers will now work through there process of validating the vulnerability, working with the vendor, and determining if and when disclosure is warranted. Typically US-CERT will not issue a vulnerability note until after a patch is available.
Session 8 – OPC Exposed, Part II by Ralph Langner of Langner Communications
Ralph’s paper and presentation focused on denial of service attacks against OPC servers. His contention was why try something subtle if a simple, brute force attack could bring them down. He focused on three areas:
1) Resources exhaustion through client connections
2) Memory exhaustion through group names
3) CPU overload through new client threads
Much like with Lluis’s testing, the results varied by vendor implementation and even more by the underlying OS. The problems demonstrated the lack of even basic secure coding practices in certain vendors.
Ralph also included some interesting results with OPCenum and a man-in-the-middle utility.
Session 9 – SCADA Event Correlation by Ron Gula, Tenable Network Security
There is a lot of security related data not being used today to detect attacks including SCADA application logs, firewall logs, IDS, and operating system logs. Project LOGIIC tried to tackle this, and we believe they had some success. But no results that could help the community have been published.
I asked Ron to take some logs we had available, some scenarios and create scripts that would allow a Security Event Management (SEM) product to aggregate, correlate and detect these meta events. He included five scripts in the paper and detailed more in the presentation.
We did receive some feedback that the presentation was too commercial, but this is my fault because I asked him to do this. The scripts are written in TASL which is Tenable’s language and the screen shots were from Tenable’s product. I didn’t see anyway to show this capability and the relative ease to implement whatever you are trying to aggregate and correlate in a SEM without using a specific product.
The community should view this as a resource. This and many other scripts to detect attacks are available on the Tenable site and elsewhere. Any decent programmer can take these TASL scripts and convert them to PERL or some other scripting language. You can decide if you like Tenable, ArcSight, Netforensics, ActiveWorx, Cisco, … At some point you will need to determine what you want to collect and correlate and these scripts are the first SCADA specific scripts that are publicly available.
Lunch
Unfortunately it was a bit threatening outside so lunch was inside, but still with a nice view.
Session 10 – Automated Testing of SCADA Protocols by Nate Kube of Wurldtech Security
We wanted to see what was behind the well publicized Achilles test platform for SCADA controllers. Nate did just that and gave most of the audience a first glimpse and education on attribute grammars.
I think the key benefit this approach provides is some objective measure of coverage which is critical for testing and security assurance. While Lluis, Ralph and Matt demonstrated implementation flaws in OPC and ICCP. They did this based on their expertise in determining test cases and all were quick to point out they were providing a small amount of protocol coverage. This concept of coverage warrants more work and discussion.
Nate ended the paper and presentation with some common failure results in controllers tested to date. For example, he pointed out that many still fail from derivatives of the old IP Land attack.
Session 11 – N-Secrecy Authentication Response to Graduated Threat Levels in SCADA Networks by James Graham, University of Louisville
Dr. Graham’s authentication algorithm was designed specifically for SCADA systems, and it is difficult to explain in a short blog entry. Perhaps the most interesting and pertinent facet is a two stage authentication where the header provides a quick first pass authentication followed by authentication of the body.
This approach may allow faster processing of the message and a number of pre-processing and post-processing options like AGA-12 was trying to address.
Session 12 – SCADA Honeynets: How to Build and Analyzing Attacks by Landon Lewis of Digital Bond
Landon introduced the SCADA Honeynet and went into detail on how the various services, ftp, http, snmp, telnet, modbus, etc., were provided and customized. Examples of what an attacker would see and how the attacker could interact with the SCADA Honeynet were demonstrated in screen shots. A brief review of the architecture using VMware was described to show the ease of deployment.
The second part of the presentation described the two environments SCADA Honeynets are deployed in today and some of the results. To date, attacks have not been targeted at the Modbus TCP port, and the attacks on more common ports like ftp and http have been automated and unsuccessful. We are especially interested in finding out when SCADA device default credentials are added to common password lists used in attacks.
Aftermath
We scheduled S4 to end on a Thursday so it was easy to extend for a long weekend in South Florida. The weather changed dramatically on Friday. It was cooler, low 70’s, sunny and low humidity. More typical than the 85 degrees we had for the event.
Many took advantage and were staying the weekend and a few intrepid souls went down to South Beach for some very late nights / early mornings.