Project Basecamp
Locks had “long life” and names written on them.

I had a chance to chat with former Project Basecamp lead Reid Wightman about the Tofino/SCADAHacker IDS rules related to his exploit scripts. It was in conjunction with a soon to be released ioActive webinar on the CoDeSys issue. (btw, the webinar includes an intro to Project Basecamp/PLC security by me and then Reid digging into the CoDeSys security problems.)

The IDS rules were part of a whitepaper announced in the Tofino blog article Address SCADA Security Vulnerabilities Now, Not Later. The first thing you need to realize is these IDS rules detect legitimate activity by an HMI or engineering workstation. An attacker doesn’t find a vulnerability to attack the PLC, he uses a product feature. So even if these signatures were 100% effective detecting the activity, they could not discriminate if it is legitimate or illegitimate activity.

The signatures released were easily circumvented. Reid said it took 15 seconds. Perhaps that is hyperbole, but clearly it was only a couple of minutes. Here is Reid from an email: I documented my code saying, “These packets probably aren’t necessary.” Those are the packets that Joel is detecting on. I commented them out, and it turns out they aren’t necessary.  I can just plain not send any of the packets except those absolutely necessary to send a command, and everything still works.  I’ve evaded the detection entirely by just commenting out a few lines of code.

This highlights the danger of writing an IDS rule to detect specific attack code rather than fully understanding the vulnerability. Not a slam on Joel & Eric, we have had and probably still have some attack rules rather than vulnerability rules in Quickdraw. Just realize a moderately skilled attacker will modify the attack to avoid the IDS.

One other small point — not all CoDeSys implementations use TCP/2455. In fact, our Wago uses TCP/1200. So check your device before implementing the current or future IDS rules. —————

There are two big picture points that need to be stated and clarified.

  1. Address SCADA Security Vulnerabilities Now, Not Later is correct in headline but wrong in content. Addressing the vulnerability should be getting a commitment from your vendor for an upgrade plan to add basic security / authentication / integrity to the PLC or other device. Addressing the vulnerability now is putting together a plan and budget to upgrade or replace your insecure by design PLCs. Throwing up some mostly ineffective compensating controls is not addressing security vulnerabilities. I can’t resist pointing back to my friend Eric Byres’ demonstration of this insecure by design PLC issue back in 2002/2003. Back then even I was pointing to compensating controls. I learned my lesson. We need to put the emphasis and resources on fixing the real problem, and not pretend these compensating controls are even close to adequate.
  2. ICS / SCADA Security IDS Rules Are Important Detection Measures – The fact that the initial rules were ineffective does not mean that IDS is not an important attack detection measure. Digital Bond published the first SCADA IDS rules as part of a DHS research project, and we are still a big believer that they are an important part of a monitoring and attack detection program. Quite frankly Joel and others have pointed out that the Quickdraw IDS rules have not been maintained and updated as they need to be. We are in discussions to rectify that problem and will be making an announcement in January prior to S4. It is a net plus that Joel, Eric and others are putting these out there for people to test and improve.

Image by ironypoisoning