Researcher Publishes Industrial Complex Hack 190
snydeq writes "Security researcher Kevin Finisterre has published code that could be used to take control of computers used to manage industrial machinery, potentially giving hackers a back door into utility companies, water plants, and even oil and gas refineries. The code exploits a flaw in supervisory control and data acquisition software from Citect. The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection. Finisterre, however, sees the issue as indicative of a 'culture clash' between IT and process control engineers, who are reluctant to bring computers off-line for patching due to the potential havoc wreaked by downtime. 'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"
Re:Disconnected from reality (Score:5, Interesting)
You make a fair point but what happens if one of those machines does fail? Believe me, I've had triple redundant power supplies fail on me before it will happen.
The IT world believe in redundancy and so too I would have thought does the industrial world where uptime has to be 100%. Rebooting your Exchange server should not result in any downtime if email is considered mission critical.
So if there are redundant control systems in place why can't individual machines be brought offline and patched as necessary?
The only argument I can see that holds water here is that an update could theoretically break the tool but if it is properly redundant then it won't come back online when you're done and the problem stops there until the node can be replaced or updated.
Re:Disconnected from reality (Score:3, Interesting)
Why does a box running a CNC machine need internet access?
After I was caught playing solitaire on a CNC lathe (working one summer in a factory), the engineers thought it would be a good idea to network all the windows controlled CNC machines so they could do remote monitoring and updates. They were mechanical engineers, not IT guys ... and They didn't bother with any security, and so I could browse their 'mshome' workgroup with read/write access. I always wondered what sorts of havok I could have caused ...
This ain't the IT department people ... (Score:1, Interesting)
I work in the Industrial Network Security sector.
This guy has not won any favors here.
The Industrial network sector is not like the typical IT department where an exploit is found and a fix can be pushed out within days.
For industrial networks, even if a patch were immediately available, some companies would not be able to fully deploy the patch to all their facilities for 1-2 years.
Re:Well (Score:1, Interesting)
Re:Disconnected from reality (Score:4, Interesting)
I have done quite a bit of work in the scada area in the past. What we had was the machine network physical separated from everything.
A serial link was used to query the scada system and recorded all the interesting points.
There was no way to write to the scada system via the serial link. That system then dumped the data to sql databases, where it was then queried by the internal web server and provided lookups and pretty pictures for those that dont really need to know, but want to.
The webserver was then on the office network, but could also be accessed by dialup, the office network was not internet facing.
Think that is a bit more secure due to the fact that we actually took 10 minutes to think of a method that would be
He doesn't get it ... (Score:4, Interesting)
He's attempting to lay blame for these infrastructural issues at the feet of the engineering staff. What he doesn't understand is that engineering systems have very different operational requirements from running a server farm or a few thousand desktops. Engineers avoid IT like the plague, because IT people will come down on engineering systems like a ton of bricks, enforcing arbitrary company-wide standards regardless of the damage they do. For example, if you have a timing-sensitive real time process running on a PC, it may not be wise to put the Symantec Antivirus pig on that particular box. Yet I've seen that happen, usually without the person in charge of that equipment even being notified. Afterwards, everybody wonders what happened with something goes seriously wrong with a production process. IT's attitude in such cases is usually "we followed company policies. Not our fault." The hell it wasn't.
The reality is that IT misguided or ignorant departments are frequently a far bigger danger to process control and real-time data acquisition systems than any number of Chinese crackers. That's because they rarely make the slightest effort to accommodate the needs of the technical staff, and have often gone to extreme lengths to have upper management approve utterly Draconian policies that MUST be applied to ALL computers.
Engineers are often justifiably leery of having IT involvement in any of their projects. The consequence of that, of course, is that now you have people with no specific security training implementing remote communications. Of course, a lot of these problems could be ameliorated with some simple requirements such as "all off-site communications MUST be secured with a VPN" or something similar.
Ultimately, what it comes down to is communications being handled by conscientious, well-trained individuals that are open-minded and willing to accommodate the special needs of engineering systems. I can't tell you how rarely I've seen that happen.
Re:Why ... (Score:3, Interesting)
Plain fear mongering (Score:2, Interesting)
Re:Why ... (Score:5, Interesting)
If an engineer can get eyes on without disrupting operation (talking over the phone), then he might be able to avert a problem.
What if the machine is part of a chemical plant?
Same as above.
As an engineer in both instances, you would probably move more than an hour away.
Since there are usually junior engineers on at night it can be very helpful to have a senior engineer with eyes on. It wasn't until I had 10 years of experience before I realized that I didn't have the knowledge or experience to handle an emergency during my first 5 years.
And the powers that be wouldn't think of paying for someone that had more experience to be there.
So some of the accidents that occur at night which are blamed on people being tired are due to them not having enough experience.
I agree that more money and security are needed.
But very few managers get paid extra for spending more money.
The worst I've seen is where a controller was connected to a phone line. That controller had about 20 chemical reactors tied to it. Another controller also had a phone line and it had 4 reactors tied to it. But before this sounds really dramatic, if someone had hacked in they probably could have done some damage to the reactors, but it would not have caused a danger to humans.
The worst I saw (safety/security) was where someone had installed pipelines carrying caustic chemicals without using a double-walled pipe (Yeah, Electrical Engineers are the same as Chemical Engineers). Yep , sure enough they had a leak. Luckily no one was injured. Some equipment was trashed, but they had insurance.
The funniest was when the insurance guys came and wanted it to be turned on to confirm that it wasn't working. The engineer told him that he highly recommended that the equipment not be turned on. He actually showed them the fuzzy crap that was growing on the controller boards. He and another guy went and gathered five fire extinguishers, put those at their feet and told them to pull out the big red button and to press this button to start it up, if they really had to. Then told them they would be waiting outside. The insurance guy turned popped out the emergency stop button. The robotics went nuts and white flashes could be seen from the vents of the controller panel. Never got to the power on button. Experiment lasted about 3 sec. Insurance agent nearly drove the Emergency off button into the panel.
There were 3 more systems and they decided that they could just look at the fuzzy stuff on the control cards. Didn't need to turn them on after all.
So considering all the trouble we had with keeping safety standards in check, I'd say good luck with handling getting money for proper security costs.
And they finally did double-wall their chemical lines and eventually it became a legal requirement. So from then on there wasn't a problem with getting chemical lines double-walled and properly labeled, not with just the yellow caution tags, but with flags. Flags weren't a legal requirement, but they are cheap.
Re:Well (Score:2, Interesting)
Re:Why ... (Score:3, Interesting)
And when stuff goes poof, the CEO gets a golden parachute, and writes a nice goodbye letter to the company staff.
Of course people then say, "See that's why a good CEO is worth $$$$$$$$", yes that's true, the funny thing is companies keep paying bad CEOs a lot too rather than have stuff like a "probation period" or having the $$$$ linked to what happens to the company 3 years later.
Re:super lock down does not work that well and aft (Score:3, Interesting)
Then I assume that you are not familiar with RBAC systems like SELinux built in the kernel. In a "dangerous" environment where 1 minute of downtime is equal to 100k$'s, lockdown is the only way to go. Running as root or equivalent should never be allowed, period.
We can lock even root down to console-only access and have the user-servers loaded up from netboot and nsf mounted drives from the user-server. Roles based upon who the user is will grant access to what they need to do, and nothing more. All actions will be logged, and all critical decisions will be logged to a recording server. Why wouldn't we want to have users use dumb terminals? 2 commands can kill their session and lock them out.
Viruses will not exist, as we can literally prevent the user from executing anything, even in their home environment. Root, with other than console access, is yet another user.