DNP3 Vulnerabilities Part 2 of 2 – Why DPI Firewalls Might be Industry’s Only Hope
In last week’s Practical SCADA Security blog, I discussed how the new vulnerabilities discovered in DNP3 SCADA masters are carving big holes in the NERC’s concept of the Electronic Security Perimeter (ESP). Dale Peterson started the ball rolling in his blog “Why the Crain/Sistrunk Vulnerabilities are a Big Deal”. Then Darren Highfill posted a blog explaining that the vulnerabilities don’t even require the attacker climb a fence. DNP3 serial links connect millions of physically insecure pad and pole-mounted devices. Accessing just one of those devices opens the door to a system wide attack. Since there is no way that every one of these devices can be inside the perimeter, the concept of NERC’s ESP is fatally flawed.
Is this a potential backdoor into the power grid? Image Courtesy of United States Department of Labor.
Please Don’t Throw Out the Baby with the Bath Water
Darren is a great asset to the industry, as demonstrated by the careful analysis he has put into how an attacker might find a way in to a system via a remote pole or pad mounted device. But as I hinted last week, I think that Darren makes a technical error in his blog.
When I noticed it, I tried to post a comment on Darren’s site, but he had closed the blog to comments. So instead I decided to respond via our blog. Here is my comment to Darren:
Hi Darren
Great article. These are serious attack scenarios and the industry needs to deal with them immediately. To me, the key take-away is not that there are security issues in DNP3 Masters, but the fact that these types of attacks expose a problem in all ICS protocols.
Now I disagree with your statement: "Put all the deep packet inspection on it you want – you won’t find a signature." My experience is that Deep Packet Inspection (DPI) is a valid defense in these scenarios – in fact it may be one of the only.
Forget the Signatures
DPI firewalls don't use signatures. Intrusion Detection Systems (IDS) like Snort might, but any good DPI firewall uses packet validity analysis that determines if a packet is malformed in any way. At Tofino Security we call that “Sanity Checking” of the packet stream.
For example, one of Adam Crain’s vulnerabilities occurs when a start value in the DNP3 message is greater than the corresponding end value. This tends to break applications, because it violates a common implicit assumption that the master has asked for at least one measurement. And that creates loops with a negative count.
Now a good DNP3 implementation would ensure that end values in any message are always greater than the starting values, discarding messages that do not comply. But as Crain shows, we have some bad DNP3 implementations out in the real world. So we need either a patch or a compensating control.
While You Are Waiting for the Patch
One solution is a good DNP3 DPI firewall*. Well designed, it would ensure that end values are greater than the starting values. If this isn’t the case, the firewall should drop the packet REGARDLESS of data content. Thus no matter what the attacker puts in his/her payload, or how he/she tried to obfuscate it with techniques like NOP slides, the firewall’s checks will detect and block the attack. If the attacker uses a valid pair of values in the packet, then the exploit fails because the vulnerability requires the end value to be less than the start value to create the negative counter problem.
Certainly DPI firewalls are not the silver bullet to fix all security issues. For example, if there is some sort of yet unknown vulnerability strategy that is based on some obscure combination of invalid fields that are not checked in a DPI implementation, then the attack might be successful. But the key point is that the entire class of vulnerabilities has to be unsuspected. If the DPI firewall’s designers can even imagine that a vulnerability is possible, then hopefully they can design a check for that general class of attack. They definitely do not design for a specific instance or exploit signature like a traditional IDS would – that is a proven waste of time.
So in closing, your scenario analysis is great work Darren. Just be careful when you say a technology will or won't address the problem. Some times.
Regards,
Eric
Good Test Tools Make for Better ICS Security
To close this blog, I would like to point out that the above is one reason that fuzzers like Adam’s are so useful. If Adam can think of a way to fuzz a packet, then DPI firewall designers can think of a way to detect and block that packet, regardless if a vulnerability has even been discovered. Think of it as security that is focused on vulnerability prevention rather than exploit detection.
So the fact is, unless we want to cut the communications between the Master and RTU, DPI firewalls are probably industries only choice today. Either that, or end users could wait until every possible vulnerability in their SCADA products has been discovered by researchers like Adam and then fixed by the vendors. Given our progress so far, I am not counting on the second option.
*Full Disclosure: Unfortunately Tofino Security doesn’t make a DPI firewall for DNP3 yet, but we are working on it.
Related Content to Download
|
Technical Briefing Kit - "Understanding Deep Packet Inspection for SCADA Security"
|
Related Links
- Webpage: ICS-CERT DNP3 Implementation Vulnerability
- Webpage: Tofino Modbus TCP Enforcer LSM
- Digital Dond Blog: Why Crain/Sistrunk Vulns Are A Big Deal
- UtilSec Blog: Exactly Where Are All Your Field Assets, Anyway?
- Blog: DNP3 Vulnerabilities Part 1 of 2 - NERC’s Electronic Security Perimeter is Swiss Cheese
- Blog: SCADA Security & Deep Packet Inspection – Part 1 of 2
- Blog: SCADA Security & Deep Packet Inspection – Part 2 of 2
- Blog: Patching for SCADA and ICS Security: The Good, the Bad and the Ugly
- Blog: Securing SCADA Systems: Why Choose Compensating Controls?
Add new comment