Industrial Control Software Easily Hackable 194
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."
Re:Professionalization of software (Score:2, Interesting)
A nice idea in theory, but you're dealing with security. A field that reinvents itself every 3-6 months.
Judging from the average "standardized" guideline, the moment the final draft is getting its last changes it will be outdated by about 2 generations. So you now have the choice, either be accurate and give attention to detail and be about 3-4 years behind the attackers, or be vague and spotty and have everything pass because they can somehow fudge it.
We're not talking about approving technology where your "enemy" is physics and bugs in programs that wait for you and has no chance to strike until you employ your technology, because only then flaws in your programming or your physics will manifest. Your enemy is a human attacker who will strike today, given a chance, and who doesn't care that you need a few more years to get through approval.
Re:Yup (Score:5, Interesting)
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.
Licensing. It's all about licensing. (Score:5, Interesting)
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:Enter Kaspersky (Score:4, Interesting)
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.