SCADA Cyber Security Problems – Just How Common are the Programming Errors?

The discovery of SCADA-security issues by Luigi Auriemma and Siemens PLC weaknesses by NSSLabs this year is interesting from a software-engineering point of view. Having been active in the development of industrial controllers, embedded devices, PLCs and machines, I have experienced the other end of the cyber security problem – not how vulnerabilities must be stopped, but the ease with how they are created.

Auriemma has tried to find the source of the SCADA leaks by disassembling the code and finding the root cause of all 34 leaks. It is interesting to read that the “Buffer Overflow” error is one of the most common. It is so common that it is listed as #3 in the “Mitre TOP-25 most dangerous programming errors” list (No. 1 and 2 are website programming errors).

Asleep in Programming 101?

This is discomforting – a programming error every student should learn to avoid in a “Programming 101” course is a major source of cyber security problems in over a million SCADA installations worldwide. One of the SCADA packages targeted by Auriemma has so many buffer overflow errors in the networking components that I suspect the code containing buffer overflows was probably written by one programmer; a programmer who made the same mistake multiple times.

Or Stuck on the Happy Path?

This does not surprise me at all. Most industrial, embedded and PC software is written in C (or C++), and this language is very susceptible to buffer overflow problems. Many programmers only code the “happy path” and do not consider “impossible” scenarios.

For example, in the code that handles the communication between neighboring SCADA stations, the programmer “knows” that SCADA station “A” sends (let’s say) 25 bytes of data to station “B”. How does the programmer know that? Because he / she wrote that code too. So the code that handles the incoming data on SCADA station “B” is written with a buffer of exactly 25 bytes, to store incoming messages in before processing them. Why waste memory in allocating larger buffers? That’s not needed; no one would send more. Why write less efficient code doing sanity checks? That was valid reasoning at that time.

Now times have changed. It cannot be relied upon that only SCADA station “A” is at the other end of a network connection. Now hacker “H” might be the one sending the messages. The hacker sends “B” a few extra bytes, on purpose. Suddenly SCADA station “B” has a buffer-overflow problem and the hacker has an exploitable vulnerability.

Why does such code exist? Why is such code still there? Simply, because it has been there for decades. Perhaps written by someone in the 90’s, the particular piece of software always worked correctly and there was never a need to change it. In that era, CPU’s were slow and memory was tight. Nobody knew of hackers and there was no need to defend against them, so there were many good reasons to write “efficient” and “fast” code.

The identical code was included in every new release of the product, year after year. Nobody may have looked at those few lines of code for years at end, stored somewhere between millions of other lines of code for that same product. But as of 2011, times have suddenly changed.

Vendors – Please Find Your Bugs before the Bad Guys Do

The vendors have fixed most of the Auriemma / NSSLabs leaks, but does this mean that there aren’t any more? We don’t know, but, since the researcher community has just started looking for them, I’ll bet a few bucks that there are many, many security holes just waiting to be found! Maybe it is time for the vendors to start finding them before the bad guys do.

This article is a special guest contribution by:

Rob Hulsebos Industrial Network Expert and Owner of Enode Networks info@enodenetworks.com

Note:  Rob is the “Dutch Profibus expert” cited in the Symantec article that identified that frequency converters are the target of Stuxnet.

Practical SCADA Security thanks Rob for this article.

Note from Eric Byres:

In a spooky bit of prescience, Rob submitted this blog to us in the middle of last week. Twenty four hours later, McCorkle and Rios’ Derbycon 2011 presentation “100 bugs in 100 days: An analysis of ICS (SCADA) software” was posted on the Internet. Their goal had been to identify as many ICS software vulnerabilities as possible within 100 days. Unfortunately, the results exceeded their expectations – they found 100 serious flaws in 75 SCADA products from 48 different ICS/SCADA vendors. Rob’s prophecy of “many many more security holes just waiting to be found” has unfortunately come to pass.

Related Links

Information about Secure Development Lifecycle (SDL) Processes and Certification

• SCADA Security Requires Software Security Assurance
• Honeywell Leads ICS and SCADA World with First ISASecure Certification
• Demanding Software Security Assurance from Industrial Automation Suppliers

Other Practical SCADA Security Articles on Security Vulnerabilities in SCADA and ICS

• Stuxnet Lesson: Is SCADA/Control Field Device Firmware the Next Malware Target?
• More SCADA Security Threats: Where There’s Smoke, There’s Fire
• The Italian Job – Multiple SCADA / ICS Vulnerabilities Go Public
• Siemens PLC Security Vulnerabilities – It Just Gets Worse
• Digging for Facts on the Siemens S7-1200 PLC Security Vulnerabilities, Part 1/3
• Siemens S7-1200 PLC Security Vulnerabilities, Part 2/3
• Protecting Siemens S7-1200 PLCs against Security Vulnerabilities, Part 3/3

Subscribe to the "Practical SCADA Security" news feed