Why SCADA Implementation Vulnerabilities Are More Important Than Lack Of Security Controls In SCADA Protocols
When we get on our soapbox and stress the importance of identifying and fixing what we believe our widespread implementation vulnerabilities in SCADA devices and applications we frequently hear “everyone knows the SCADA protocols have no security so what is the point of worrying about implementation vulnerabilities.” You will even see this in many of the blog comments.
Sure the lack of security in Modbus TCP, DNP3, OPC, ICCP and other protocols is important. This problem typically manifests itself in any user that can access a device via a SCADA protocol can often read or write to the SCADA device since neither the source or data is authenticated. Some protocol implementations, such as ICCP servers, only allow users to read values, and there are a number of protocols that are in the process of adding security controls to address this deficiency.
Implementation vulnerabilities are much more serious. Here is a simple parallel statement to the why worry argument we hear – “why bother patching Microsoft vulnerabilities when we know the SCADA protocols have no data or source authentication?”
Most of the SCADA security community understands why patching Microsoft vulnerabilities is so critical. An attacker with access can scan a network, identify Microsoft vulnerabilities, get a free tool like Metasploit, and take control of the computer. The attacker can than launch attacks from this new beachhead using a simple pivot feature. Maybe even more likely is a worm that exploits the vulnerability finding its way into the control center network and compromising unpatched systems.
We have the same situation with SCADA protocol stack implementations. These stacks can and do suffer from a variety of vulnerabilities commonly found due to poor software design and coding practices. Perhaps the most serious and exposed SCADA protocol stacks are those that are used to exchange information with business partners, such as ICCP, or those used to exchange information between the corporate network and control center network, such as OPC, as shown in the diagram below.
In this diagram, an attacker from the corporate network or business partner network would be able to reach the OPC or ICCP server using those protocols, even with a least privilege ruleset. Once this server on the DMZ is compromised the attacker would launch attacks on servers in the control center, often these are similar OPC or ICCP servers.
This concern is why we have four papers and presentations on implementation vulnerabilities in SCADA protocols and devices at S4. Two of the talks are on OPC (previewed here and here), another talk is from Matt on ICCP, and the fourth talk is detail on the Wurldtech Security Achilles test tool and methodology which I’ll preview this week.
Control system vendors are going to need to step up the security of the software design and coding as well as security QA. If vendors need help they should check out the new effort by CERT to document Secure Coding Requirements and Recommendations. (hat tip: The Art of Software Security Assessment blog)
Author: Dale Peterson
Posted: January 8th, 2007 under Uncategorized.
Comments: 3
Comments
Comment from Matt Franz
Time: January 8, 2007, 6:52 pm
Some other differences between implementation and protocol design issues:
- Exploit Outcome - protocol design issues result in at least data theft, modification but are less likely to result in denial of service or execution of arbitrary code (system/os compromise) than is the case with implementation flaws. This is the difference between modifying a register on the PLC vs. getting a debug shell on a VxWorks based PLC (or causing a PLC to send messages to all the PLCs it talks to)
- Accountability - protocol design issues aren’t a concern of the asset owner, right? You can blame the vendor or standards body and asset owner is off the hook. With implementation issues there are clear owners of the problem. Vendors to fix the flaws and release patches and for asset owners to apply the patches, upgrade firmware, etc.
- Timeframe for fix and resolution - standards issues may take years or never happen period for a variety of excuses (supposed lack of market demand for security, inadequate hardware, etc.) while vendor bug fixes can be in days, weeks, months
- mdf
Comment from Ralph Langner
Time: January 10, 2007, 11:09 am
Good point on the timeframe, Matt. Asset owners, standard bodies and vendors will spend several years on defining new, secure protocols. Then owners will wait another couple of years to see which one of several competing approaches will be publicly adopted before deciding on and using a particular protocol (”only do what everybody else is doing”).
My estimate is that it will take us another ten years until secure SCADA protocols will actually be used. In the meantime, so much could be achieved by bug fixing.
One other issue that I think is worthwhile to address besides secure protocols and interface bugs is application functionality that claims to provide security, but is so poorly designed that you don’t know if to laugh or to cry. Take authentication methods for embedded Web servers, for examle. It took us less than one day to crack the authentication routine of a leading PLC manufacturer just because of poor design. By exploiting this vulnerability, an attacker can obtain a listing of all accounts and passwords as configured on the PLC, which usually will work on other systems as well. The asset owner, however, believes he is secure, as access to the PLC is authenticated. If there was no authentication at all, the owner would at least have reason to think about protecting his assets.
Comment from Ahmed Masud
Time: January 16, 2007, 9:34 am
Both Matt and Ralph make valid points: I would like to add my thoughts to theirs…
There are several issues that have lead to the status-quo and what continues to dictate the lack of security in systems to date.
Traditionally, security has been viewed as “a nice add-on” but typically the functions (especially wizzy-bangy ones) have been the sales person’s dream and what has swayed decision makers.
I would like to differ on one point: Saying that protocols are a vendor only issue and that THEY can be blamed for it is again a symptom of prevalent “pass the buck” approach towards security. The responsibility lies on both sides and should exceed the minimalist approach.
It must be made mandatory for vendors to provide security functions preferably using open standards (which is not necessarily open source although that has advantages). Users MUST demand security and to assess using appropriate pen-testing and vulnerability-assessment that it exists. There are products and services available to do both at a very proficient level today.
Adding security layer on top of existing protocols and to existing systems is quite possible and feasible today. While it may not trivial, it is not particularly difficult. Mature wrapping technologies exist today to do so in a Real-Time friendly and a highly scalable fashion without affecting the operations of existing systems both at the operating systems level and at networks level. Application layers can also be protected using appropriate Trust wrappers.
Why is it not done then? Well, vendors don’t do it for fiduciary reasons. Hey, it is expensive to have a security Q/A team that keeps on making development and to-market cycles 20% longer (sheesh!). It is expensive to hire developers who know how to program securely (sprintf has buffer overflows? Duh! what’s a “buffer overflows”?). More over vendors just enjoy the revenues from support services of legacy systems and will milk that cow until she’s dry and then sell you the license for maintaining the carcass.
Users don’t do it because of their own reasons: Comfort with the functionality of existing systems. Lack of training to assess security risks and threats at the level comparable to existing risks and threats, socio-political reasons no one else is getting rid of their cow carcass, are we allowed to?
Any how, just to sum up: Users should DEMAND security from themselves and their vendors, and vendors should supply it. Technologically, it is definitely achievable today. Cost wise, well there will be cost involved (resources, training and reassessment). A good vendor not only will make it affordable, it may even make things more efficient. For example, it would cut down the cost of maintenance and insurance.
Ahmed.
Write a comment