Comment from Ralph Langner
Time: April 22, 2008, 4:00 pm

Good judgement, Kevin. It appears to me too that this type of attack could reasonably only be carried out by an insider — who wouldn’t need to bother with reverse engineering anyway.

BTW, I recognize some new blog authors along with you… I — and perhaps other blog readers too — would appreciate if you could introduce yourself shortly — in case you haven’t done so already and I just missed it.

Comment from Jake Brodsky
Time: April 22, 2008, 4:11 pm

The ControlLogix line of PLCs from Rockwell Automation have comments embedded in the program itself, and the device names, arrays, and other stuff and data structure members are all named however you’d like to.

It’s downright easy to read one of those programs. The rest of Larsen’s presentation is plausible –if you have the right background. Thankfully, that kind of background is not commonly taught in schools. Chances are that a couple of school-kids with a radical political grudge won’t have the experience or wetware to pull this off.

Comment from Dale Peterson
Time: April 22, 2008, 4:45 pm

The section of the presentation I found interesting and somewhat new to this space was the “Classes of Physical Attack”. In this section he describes how someone with control of the system could cause physical damage to the equipment. The classes listed where inertial attacks, exclusion attacks, resonance attacks, wear attacks, surge attacks and latent abilities. One or more examples are provided for each class.

Ralph - brief intros of Kevin and Daniel are here: http://www.digitalbond.com/index.php/2008/04/07/offensive-security-team/

Comment from Kevin Lackey
Time: April 22, 2008, 5:43 pm

Jake,
If I were to dump the file off of the ControlLogix plc would I get all of that data (device names, structures etc), and how much would it depend on the engineer having actually entered data into the comment fields?

I ask because I am aware of some work on decompiling logic files from a couple of plcs with the end goal of trying to determine the system structure. The data extractable from the ladder logic file was very limited, as the engineer had used very generic names like p1, p2 etc and no comments. Now this may not be the case for all flavors of plcs and their associated logic files. And as I am only aware of this for a couple of plcs my exposure may be a little limited as to what can or can’t be extracted from your average ladder logic file.

Thanks,
Kevin

Comment from Ralph Langner
Time: April 23, 2008, 2:05 am

Some things to consider…

1. You can’t download symbolics from any type of PLC (even though Jason speaks of “the PLC”). I am aware, however, that Rockwell has made this a well advertised feature of the ControlLogix — a good example of a vendor introducing IT related functionality without bothering much about security.

2. If engineers are commonly not good in something, it’s structuring code and WRITING COMMENTS. Usually this hits the fan when some PLC program needs to be modified but the originator has left the company. Surprise! None of his fellows is able to make sense of the code. Now someone wants to tell me that some hacker is able to do the trick? Give me a break.

Comment from Jake Brodsky
Time: April 23, 2008, 9:50 pm

Ralph, I will admit that I’ve seen a fair amount of poor code as an engineer. However, it is not universal. My code has all sorts of comments buried in it and it has reasonably descriptive names. The beauty of the ControlLogix line is that you can suck the program, with most of the comments back out of the controller just in case you’re not the original developer. For example, you might be a technician trying to figure out why a mixer isn’t stopping when everyone is expecting it to. Frequently, this is due to a broken instrument or a defective power supply.

It is possible to encapsulate a program so that it can’t be read. However, most plant people seem to think the greater risk is not having the source code when you need to make diagnostics with it. So they don’t often encapsulate a program or strip the comments or tag names.

One point of confusion among programmers is that they may not know the ISA’s point naming conventions. For example, PSH-582 might be very significant to the engineer because they know that the 500 series of devices refers to a specific process, the 80 part refers to a specific loop, and the 2 refers to a specific instrumentation point. The letter P stands for Pressure, S stands for switch, H stands for High.

If you were working on that plant, PSH-582 would make perfect sense. However, if you’re a programmer in an office 20 miles away who may not have the benefit of the P&ID prints, it would look cryptic.

Comment from amino world
Time: April 25, 2008, 10:13 am

i thought security thru obscurity went out of style a while ago…

hackers do pretty impressive work reverse engineering stuff from binaries… consider the exploits developed _after_ patch tuesday, extracted from the patches themselves! (i’ve long maintained that assembly code is remarkably similar to the simple if-then rungs in uncommented ladder.) a skilled programmer with time on his hands can figure out what a PLC is trying to do from a ladder logic ‘dump’, esp with all of the swell help available on the web, and counting on his lack of engineering degree and/or vendor training is false hope indeed.

of course, he probably has some nice operator screens to help him, since he drove past the HMIs on the way to grabbing the PLC dump, so he may not be as far from discovering the best way to harm equipment from the attention given to it in the ladder, esp after breaking the ISA naming code. finding a modbus command to write “good/OK” status to the PSH points isn’t very hard, is it?

Comment from Frank Marcus
Time: April 25, 2008, 1:01 pm

Adding to amino and jake’s comments…

Ralph, I’m not sure if you recall but we met at S4 earlier this year. Do you remember Dave Aitel’s keynote? He said, the goal of an attacker is “total information dominance”. I found that insightful and when I looked around the room, I’m not sure how many others understood what me meant. Maybe I didn’t either, but here goes.

What Dave is referring to is that someone who is serious about taking control of your network (like Kevin is doing) to do unauthorized things will not follow the first route he finds, or the path of least resistance, to his goal host. He will try to be clever and subtle, scout out as much information as possible, learn the “lay of the land”, identify what hosts are out there, match up to the attacker’s knowledge base of exploits, do research for more, etc, etc. The hacker that doesn’t get caught is the one that knows more about your network than you do, and he has more time than you do.

As you pointed out Ralph, the barrier to entry to actually interact with control devices without a ton of expert knowledge is very high. However, not insurmountable. Kevin, how long did you work on your project until you felt like you knew enough to for your presentation?

In my humble opinion, its the “it’ll never happen to me” attitude that caused IT a huge amount of headache until they changed their perspective and started to hammer their own stuff before the bad guys did. See Microsoft’s SDLC (also the keynote at S4) for an example of this process.

It’s probably not the first problem I’d try to tackle, and some authentication and non-repudiation mechanisms could probably help mitigate the threat without changing the controllers themselves, but now that I’ve seen Kevin’s work its on my radar and when I design mitigation solutions I’ll be thinking about this. As an industry we are moving to converged IP network that are somewhat reminisicent of the data/IPSec converagance that is happening/happened big time in the US and, well, we’re heard of VOIP in Canada

Just my 2 cents. Please, discuss and debate.

Cheers,
Frank.

Comment from Kevin Lackey
Time: April 25, 2008, 2:49 pm

Frank,
The presentation isn’t mine, it was by Jason Larsen, who is one of my ex-colleagues from INL (now at IOActive) and who is one of the foremost researches in the SCADA hacking realm.

The main gist of what I posted was not meant as a critique but merely to clarify that in order to use the ladder logic to pinpoint areas of an attack, quite often the ladder logic files themselves contain insufficient data, without correlating the data with HMI screenshots or the engineering project from the engineering workstation.

Kevin

Comment from Ralph Langner
Time: April 27, 2008, 5:08 pm

Jake, I wouldn’t have expected anything else from YOU. However, let me tell you that in respect to the population that I operate in, you are about three sigmas out on the good side. The software branch of my business, which has to do with MES middleware, regularly encounters this situation: “This PLC program can’t be touched because the guy who wrote it has left the company, and nobody else can handle it”. This way, Zombie programs that had rightfully deserved to die long ago continue to live a half-life in the shadow, fighting innovation and reusability. As for the encapsulation, many engineers are very good at unintentionally obfuscating code, up to the point where they no longer understand the code themselves. Don’t get me wrong, this is not meant as criticism, as I am well aware that the environment where such engineers lives in prohibits good coding practices.

Frank and amino, good arguments that give me an opportunity to make my point. I am not favoring security by obscurity. I also enjoyed Dave’s keynote at S4. It gave me a new insight on what really drives hackers (i.e., the need to demonstrate superiority). Anyhow, at the end of the day, we need to determine the most relevant threats for the assets under consideration. If I got Jason’s reasoning right, he asserts that (very condensed) there is a threat by hackers causing significant physical damage by re-engineering ladder logic for high energetic devices. Although this might be true in a theoretical sense, I debate that such a threat is realistic, and it is certainly not imminent. I assume that every security professional who does risk assessments will determine soft spots that had slipped the asset owner’s attention. However, we determine such soft spots only with full cooperation from the asset owner’s process engineers. Only if you put together the IT & networking stuff with the physical & chemical stuff and the logistics & economics stuff, a new picture surfaces which might include some big vulnerabilities where the asset owner’s experts say “oops…”. This is not what I call obscurity. They just didn’t ask the right questions. Questions that a highly motivated and skilled inside attacker might ask, and that can only be answered by insiders throughout the organization.

Hackers, on the other hand, are outside attackers who are motivated by, you name it, the need to demonstrate superiority. So here we have a scenario where an outsider breaks into a facility, downloads PLC code, re-engineers the ladder logic, modifies it, and launches a sophisticated attack involving big iron that he has probably never seen in action, or even seen on a photograph. He does all this because he hasn’t anything better to do, and because it improves his ego. — I don’t say that it’s impossible, I just say that it doesn’t fit the hacker profile as I understand it. The effort is so huge, the chance for success is so slim, and the risk of a police officer knocking on his door a week later is too big. In the context of threat modeling, I couldn’t attribute any realism to such a scenario. If you want to demonstrate your superiority, there are much more appealing ways, hackers. As a matter of fact, the guy who would actually pull of such an attack would no longer reasonably be called a hacker, but a terrorist, criminal, nut case, or whatever the specifics would indicate.