Industrial Control Software Easily Hackable

jfruh writes "CoDeSys, a piece of software running on industrial control systems from hundreds of vendors, has been revealed to be easily hackable by security researchers, giving rise to a scenario where computer hacking could cross the line into the physical world. Worse, many of these systems are unneccessarily connected to the Internet, which is a terrible, terrible idea."

Comments

Not such a bad idea...

[jmerlin]

Worse, many of these systems are unneccessarily connected to the Internet, which is a terrible, terrible idea.

Now you're just being paranoid. Instead, you should develop an artificially intelligent system to defeat would-be attackers and malicious software. That sounds like the best idea.

- Skynet

Yup

[50000BTU_barbecue]

Having recently switched fields from high-end telecom gear to industrial machinery, I can confirm this. The industry works with what hardware they know. I last worked in the field two decades ago, and now I see the same Cutler-Hammer contacts, the same Schadow switches, the same Schroff and Rittal metal works, the same Panduit wire ducts, the same Oriental motor drives, the same Allen Bradley PLCs... Oops, that PLC now has an ethernet port? The PLC looks the same as before, a grey box covered in screw terminals, but apparently it must have changed from a 6809 running GRAFCET to some sort of modern porous monstrosity needlessly running a 64 bit OS with so much unverifiable code.

It's not necessary.

Re:Yup

[hjf]

I like to compare the problem in this industry to Powerpoint presentations. If you ever attend a university lecture, you'll see the professor, who is an engineer, doctor, master's, Ph.D or whatever. He has 5 degrees, hundreds of certifications, and thousands of hours of experience in the field or in front of a class. Yet, he cannot be bothered to invest a few hours of his time in learning *GOOD* powerpoint skills. And don't even get me started on "getting your computer hooked up to the projector".

In the automation industry it's the same thing. A very clever engineer, real genius sometimes, comes up with mechanisms you wouldn't even dream of, and designs a machine as big as a building, that works perfectly. The problem is, it's the same guy who programs the PLC, and he likes to do it in Ladder diagram (which has its advantages. I do ladder and i admit it has the benefit that you can "see" the program, and not get losts in semicolons and braces). But, like a rookie programmer, he disables security, releases in debug mode, uses default passwords, and many other "bad practices" that could be easily solvable if he bothered to spend a few hours to learn to think as a software guy. Sure, disabling your firewall isn't harmful if you're testing for a few minutes. But "i can't find the problem so the only workaround i found was to disable the firewall" is pretty much what happens with these guys.

Re:Yup

[inasity_rules]

On the other hand when the SI password protects the PLC so another SI can't get in and fix the system(because the first SI is now out of business), now we can get in and do it without re-engineering the whole system. Sometimes low security has benefits.

90% of the security we implement is air gap. Once someone has physical access to the control panel, you've lost anyway, they could start swapping wires and pulling relays if they wanted. If the system must be on a network, we put it on physically separate network, with at most one SCADA PC on both(because the client demanded it). Still, you can set up a nice secure(ish) system, and two weeks later the client's IT department has screwed it up completely.

The major catastrophe you're waiting for is actually surprisingly unlikely. Sure a malicious person could cause a lot of damage, but from what I have seen people are more interested in stealing stuff than blowing it up. Why go to all the effort of destroying the mill on the goldmine when you could go to all the effort of smuggling gold out? They'd rather get on the internet to check their facebook, and once they realise the control PC is not on the internet they don't care anymore.

Re: the Challenger Disaster?

[dgharmon]

"Did professional engineers prevent the Challenger Disaster?"

No, nor did they cause it, what did cause the disaster was political interference, such as the decision to manufacture the solid booster rockets in another state, necessitating them being made from segments bonded together with O-rings .. ref

Re:Professionalization of software

[Anonymous Coward]

"Did professional engineers prevent the Challenger Disaster?"

No, they did not. They tried like hell to prevent it, they were quite certain there was going to be an issue, because they knew the seals failed with lower temperatures, and seals had failed at temperatures not as extreme as on that day, so they were pretty certain there would be a problem and tried to stop the lunch. Sadly, it was not the engineers who were ultimately responsible for that launch, but folks more worried about bad PR.

So, what was your point?

Licensing. It's all about licensing.

[Anonymous Coward]

I was doing some electrical work at an oil refinery up north in Canada about 5 years ago. I wasn't specifically attached to their control systems or PLCs, though since the electrical was intertwined with a bunch of the automation I naturally knew all the guys who were taking care of that portion of the project since we were required to collaborate together.

On one particular day, I entered the facility as usual and was heading to an unfinished section to check out some conduit. On my way there I noticed a CAT5 cable stretched across a walkway, disappearing into a stairwell. This was so incredibly absurd and suspicious that I just had to see what the hell was going on, even though something in my head told me I didn't want to know. I traced the cable back to the management office where it was plugged into one of the network switches. Okay, weird- follow it back in the opposite direction, all away across the plant- after about 80 meters there was a hub/repeater dangling over a walkway rail plugged into the wall and another CAT5 cable stretching off into the oblivion. Following the second extension cable led me to a set of PLCs and a group of the control guys throwing vulgar insults at an Allen Bradley PLC unit.

Turns out the PLC was a "new" model. Instead of handling the licensing through a floppy disk (!) like all the old units did, this one used some sort of a proprietary activation scheme that had to run over the friggin' internet before the PLC would actually do anything. The CAT5 cable I'd traced about 180 meters across the plant going back into the office internet connection was setup to allow this process to complete, since they had apparently failed to do it earlier when the system was OOTB but not yet hooked up.

They eventually got it all working, but it took them about 5 hours of fiddling to get the damned thing working properly.

Shit like that is the reason why things are hooked up to the internet, sometimes improperly. I know there's certain requirements for remote monitoring and such, and that should all be done over an isolated, encrypted VPN- but then you've got licensing bullshit like this that expects to phone home to a random server on the internet with little or no fire walling in-between. There's no reason for it otherwise- apart from the PLC guys wanting to make sure you're licensed and all paid up, god forbid anyone should buy a second hand PLC and reprogram it to do something useful again.

-AC

Re:Yea

[ColdWetDog]

Actually works better if you read it as 'clown' services.

Re:no need for internet connectivity

[gman003]

My father works in an industry that uses a lot of PLCs and such. This is what he's told me:

Quite often, even though the PLCs run on their own locked-down OS, the console to manage it is just a standard Windows desktop. Kind of logical - it's just to display what's going on, maybe issue manual commands, but it doesn't "run" the system. And they're *designed* to be connected only to the LAN, not have any physical connection to the Internet. But quite often, he comes into an installation site and sees that they've plugged that desktop into the Internet, just because it had a port for it (or so the techs monitoring it 24/7 can relieve the boredom, against all procedure). So they end up connected to the internet just because the off-the-shelf desktop the blinking-lights-display runs on has an Ethernet port.

He's also told me pretty much everyone keeps the default password. Three fucking characters.

Would it terrify you to know that many of the sites he works at are power plants, both coal and nuclear? He doesn't touch the "functional" parts, but it still says bad things about their approach to security.

It's more about lack of knowledge

[WebCowboy]

The CAT5 cable I'd traced about 180 meters across the plant going back into the office internet connection was setup to allow this process to complete, since they had apparently failed to do it earlier when the system was OOTB but not yet hooked up.

Assuming it was all Rockwell/Allen+Bradley gear then it was undoubtedly the FactoryTalk Activation system they were struggling with, and they were undoubtedly unqualified to be doing the work they were assigned to do (disclosure: I am a former Rockwell Automation employee so I have familiarity with the subject, but apart from that I do not speak on behalf of any employer past or present here).

First and foremost, Allen+Bradley(AB) PLCs don't need activations, so the licensing really isn't relevant to this story. AB makes a crap-pile of profit on that hardware the moment they've sold you the box--activation makes no sense. What DOES need to be activated (and is what creates profit for the Rockwell Software division) is the RSLogix programming software, without which the PLC is as useful as a doorstop. So unless they were completely clueless they'd have just taken their laptop into the office and activated their software then come back, rather than break all sorts of IT, security and safety rules stringing out 180m of CAT5 and a spare switch to get internet. The same goes for their drives--the drive units don't need activating but DriveTools software on the programming laptop may have.

That said, there may have been an industrial PC like a VersaView or third-party unit running the Rockwell HMI software and was bolted into the cabinet with un-activated software for some reason, but Rockwell/AB have thought of that...

The legacy licensing system used utility software called "EVMove" and relied on "master disks" (towards the end you could set up a USB flash drive) and in the field this was a royal pain in the ass--floppies and their drives are far too sensitive for such an environment, and USB memory sticks are terrible to manage and secure. Thus the development of the FactoryTalk Activation internet service-based scheme. Though it requires the internet the end system does not need to be connected to activate. The easy "wizard" way sends a "host ID" (the ethernet MAC address or some such number) from the end device to Rockwell via the internet. However, you can actually write down the mac address, or generate the hostID file on the target machine, then go to an internet-connected computer and type the hostID into a secure web form or upload the hostID file. The website then generates a license file that you can save to removable media or a laptop/portable machine to take over to the target machine physically, thus preserving the air gap (and making the method more similar to the old EVMove floppy method).

I do agree that licensing/DRM/activation is a big problem that costs end users millions of dollars globally (above and beyond the actual purchase cost of the products). It adds complication and downtime and confusion and contributes exactly zero value to its users. One might argue about its value to the vendor as well--FactoryTalk activation and many other similar schemes are just as trivial to circumvent as CoDeSys' ladder logic runtime for hackers, and adds the burden of extra support costs from the honest users it keeps honest. But the problem in industrial automation is bigger than that. The problem is that the world in general moves faster than industrial control systems can keep up, and the people who have "experience" honed their skills in the mid 1990s or earlier and haven't kept up. In the meantime, PHBs of the world in management and government demand of them far more than they are capable of delivering.

It used to be that refineries/factories/etc were content with paper chart recorders where operators and plant managers could peruse them if something came up to troubleshoot. Then came data recorders where you could plug in a serial cable or transfer via floppy to a computer for more deta

Re:Enter Kaspersky

[Interfacer]

Speaking as the system administrator for a large DCS system: the OS will be no good without a complete redesign of the application level software. The problem is not really the OS, but the fact that in order to make everything work together 'automagically', there are hardcoded service accounts, and much of the app executables (which are often executed with system permissions) are writable because the entire installation folder is writable. And of course, the controllers that do perform all control actions use a protocol whose only real claim to security is obscurity.

And from what I can tell, the system I manage is fundamentally no different in that regard from DCS or SCADA systems from other vendors. While it is true that a secure-by-design would be a good place to start, the main problem atm is that the application architecture is hopelessly insecure.

Re:Just an Iranian terrorist attack

[Opportunist]

Necessity is the mother of invention. That, or an article in the business newspaper your boss reads.

My solution to that problem was simply to subscribe to the same magazines my boss reads, peruse them for articles supporting my case and getting him to read it. Not only will he listen to them more than to you, he'll also think that you read "relevant" magazines and start listening to you, at least from time to time.

I know it's silly. hey, it's management!

Re:Enter Kaspersky

[gweihir]

Even if they could do it, very few ICS admins would switch to it. Most people there are responsible for stability as their most important attribute - and that means running a solution that has proven itself over and over and over again. Related to this concern is downtime: often times these plants are running 24x365 schedules, controlling furnaces that keep ovens full of molten iron from freezing solid, which could destroy the oven. Shutting down a production line takes time and planning to prevent damage, and every minute that line is down, they are not making money.

Indeed. What they actually need to do is to really isolate these control systems in the hard sense. I.e. no ports network, data import only manually, data export via CD-R or the like, clear message to employees that connecting any USB media, Laptops, etc. will result in immediate termination, ...

It can be done, even if it may require some people to suffer first, as Iran found out. They did execute the people that imported Stuxnet via USB drive. My guess is they will not have that problem again anytime soon.

When there is a credible threat, they look at addressing the threat on an individual basis. Firewalls between the controller and the LAN. Epoxy in the USB ports. A locking cabinet around the CD-ROM drive. But replacing the core of the factory, on an unproven software package, just "in case" a hacker might target them? Not terribly likely.

This is not enough. Firewalls are insufficient. They need to implement real isolation, i.e. only an isolated net may be used and that has to be very heavily protected. It will take quite some time for them to find out how to do that, although competent IT security people could tell them today. The problem is that they are asking the wrong questions and are looking for IT experts that understand their business, instead of looking for competent IT security folks.