Gas refineries at Defcon 1 as SCADA exploit goes wild Gasoline refineries, manufacturing plants and other critical facilities that rely on computerized control systems just became more vulnerable to tampering or sabotage with the release of attack code that exploits a security flaw in a widely used piece of software. The exploit code, published over the weekend as a module to the …
Please tell me that you don't work in the industry. Here is my perception of you:
"In an ideal world energy would be free, food would be free, software would be free, everything would be free free free, love would unite us, and peace would rule the world." *gag*
Ok, now that I've gotten that out of my system... Guess what, I do work in the industry and a LOT of SCADA systems are on networks linked to the outside world. Why - ummm - oh I don't know - because corporations, municipalities, etc. like to pull the data collected via those SCADA systems for an wide variety of business purposes (think MES/ERP, Feed Stock Supply, Production Analysis, etc).
Hopefully, if implemented by a decent integrator and well supported by decent IT staffs, said SCADA systems are well segregated from the outside world via a variety of security enhanced switches, routers, firewalls, etc. Unfortunately, staff members change, networks evolve, and holes open that were not anticipated by the original implementation plan.
Therefore, in a realistic world, non-crap software vendors fix their holes when security researchers initially inform them of them. (In my preferred / rational world) intelligent software vendors don't wait until after security researchers have yanked down their software's shorts to display their diminutive privates...
Poison, because you deserver to consume some, if your plan is falling back to just trusting safety systems to save your ass if someone malicious gaines control of your process rather than holding the software vendor responsible.
Sincerely,
Giggles The Clown
Yes, you are both right. Any idiot how puts any sort of very sensitive system on a public network deserves to be flogged around the fleet. But anyone who says that that should be the only line of defense should be in line behind them.
We have to both ensure that these systems are never publicly accessible AND protect them as if they were. Defense in depth. I known, a worn out catch phrase from right after the turn of the century.
With credit to Rob Rosenberger.
"Two of the more common means for gaining unauthorized control include wireless access points and internet-facing controls designed to save organizations money by allowing employees remote access, according to Core Security, which discovered the bug early this year."
The only SCADA-related hack attacks I've read -- and I do pay attention to this sort of thing -- involve skilled insiders. The so-called disgruntled employees that PHBs fear day after day. They don't involve flaws in SCADA controlled systems, nor do they involve flaws in whatever subsystems it uses.
And when did ODBC, a decade-old technology, become fashionable as an attack vector? ODBC doesn't even use IP, so it's not at fault for "modified packets." An ODBC database driver may or may not use IP to talk to the host database, but ODBC isn't going to know if its host database is remote or local or on some dude's clipboard.
There are far more important problems for security experts to tackle besides killing another messenger.
After the lambasting Ted Dziuba gave to Google Chrome, I think Ted needs to sit in a boardroom with Dan Goodin here, and hand Dan a clue. He's needed one for several articles, now.
Refineries don't run on SCADA systems. Pipelines and terminals do, but not refineries. The equipment that controls refineries is very specialized and expensive so crafting an attack is unlikely. PC's are in the mix now but they don't directly control much of the process. Dedicated controllers are what are actually hooked to the final control elements in most cases. Standalone networks are common and when there are connections to other networks firewalls are used. You don't check your email from a control system network and you sure as heck can't surf the web.
SCADA security:
- SCADA lifecycles are extremely long and deployed systems are rarely patched;
- Many SCADA end-users are on tight budgets and won’t hear about a defence in depth security protocol or even patching;
- Most systems don’t have any kind of protocol in place to even support patching – and the ones who must run 24x7 are particularly difficult to patch (no test servers exist; the hardware perhaps isn’t even made anymore – quite a bit of this stuff is out there running on Unix, Windows NT, Linux, BSD, DOS, OS/2 (really!) and even Windows 3.1 (really, really!!);
- The whole controls world loves things with 20+ year lifetimes – it is horribly expensive to upgrade;
- These people operate in a distinct environment from IT – a control system has up-time as its No.1 priority to support process operability and safety – security is absolutely not a top priority (I’m not saying here it should not be a priority, but even if you were monitoring your network and you had an unexpected traffic spike or whatever you can’t just go shutting things down);
- It is quite normal for a SCADA system to be supported by one or more third-party firms (e.g., System Integrator) – we go to sites, we plug in our laptops, do our bit for King and Empire and go home – this is a two-way street for picking up malware, trojans, bots or whatever (certainly the good integrators do their homework and have fairly clean laptops – but I’ve seen viruses come in from Fortune 500 company control networks) – one of the reasons to have to plug-in with our own kit is that run-time versions are deployed and engineering versions may not even exist with a lot of clients.
Also, SCADA is just the beginning. Out there every little thing you can think of in automation - not just critical infrastructure - can hang off a network.
Why not have SCADA monitor it's network or whatever and if it detects abnormal activity just turn of remote access and completly isolate itself. So basically you have remote access but if there's anything weird it locks it down until it's investigated or until the monkey hits the button to turn it back on.
As for public facing interface... Use VPNs and so forth and always require both parties have this on a non public facing machine.
In many cases, it's next to impossible to update production automation systems. There is always the question of how much does it cost when something brakes because of the update.
Also, production lines often run ten to fifteen years, getting support and/or replacement parts is often difficult if not next to impossible.
I hope you don't think that connecting these systems DIRECTLY to the outside world is a good idea, has nobody heard of abstracting away direct access to limit severely what can be done remotely?
What about the following setup
SCADA system is on a network, the ONLY connection to the internet, is through a server who's job is ONLY to read the data, never to set, change, upload. It has a web server, which every 1 second, outputs through a WRITE ONLY port, data from the system.
Don't allow incoming connections, a single attempt to open a different port, shuts down the server and locks out the internet, all TCPIP communications with the server are disabled.
Any data received on the port the SCADA is sending data out, will result in a network lockdown.
Then, preuse all the data you want, safe that you've just limited about 99% of all possible infections, what are you going to do now?
A single byte shuts down the connections and locks it down, requiring a reconnection by an engineer onsite.
So how are you going to hack, crack, infect that?
So, I dont think the OP is a moron, I think maybe you are.
SCADA is just the tip of a very messy iceburg, the number of times I have seen (or heard) an engineer being told to just switch-off DCOM security or switch-off that annoying firewall and get that distributed database working or get OPC traffic working ASAP... after all, it's closed network, what could happen...I wonder if the engineers working on the ISS thought the same?
I can reassure parties on both sides of the chickenwire that nobody will 'burn' in the event of a (software) penetration.
SCADA *is* used at gas refineries, I should know, I've installed and operated these things years ago. However, the Oil and Gas industry is not always as high tech in these matters and actually has a healthy distrust of non-mechanical safety systems (rightly so). The worst-case of software failure would mean an ESD (emergency shut down) and everything would need to be restarted. There are no inherent processes in a gas refinery that depend solely on software to maintain *safety*.
Luckily for us all, the law prevents them being constructed in such a manner.
So everyone chill, at worst, you may have to endure a cold shower in the morning....
BTW I don't work in the petrochemical industry anymore, nor have I for many years. I'm a regular Open Source hugging hack these days. ;P
Bean-counters don't care about security, all they care about are costs.
I could tell you about the Building Society whose UK HQ is "protected" by a door entry system which runs without encryption, is easily faked, door logs easily edited, generally secures the building with a BETA product that the marketing guys never let the techs finish. They just sold the insecure test version!!
OR there is the Health and Safety software I used to install for another client. Installed in everything from big banks to local councils. From the Fire and Police service to big Fastfood companies. This time it was the unexperienced programmers who requested the SQL Server to be setup with default passwords, and the externally facing website to be configured with FULL write access to ALL files!!!
There are just not enough security guys in this business. And when they are employed, it is a huge battle against weird "don't care" attitudes from both inexperienced premadonna developers and brainless salesmen.
Send in the BOFH.
COLD SHOWERS!!! COLD F**CKING SHOWERS!!! THIS IS 2008, NOT THE 1930's I DONT WANT YOUR SHIT SYSTEMS BREAKING SO I HAVE TO ENDURE 2 DEGREE WATER, WTF IS THE MATTER WITH YOU, YOU ARE MENTALLY ILL, I CANT BELIEVE WHAT YOUR SAYING, YOU MUST BE A TERRORIST, IF I FIND YOU IN THE STREET, I'LL GUT YOU LIKE A FISH111!!!!one
COLD SHOWERS IS THE LEAST OF YOUR PROBLEMS NOW YOU TERRORIST SCUM!
What I find entertaining is that Citec have already been hacked and had one of their systems shutdown (I think the first in the world) Mind you this was by a disgruntled employee who was convicted and served about 2 years in jail. The system was controlling water systems (fresh and sewage) for Maroochy Shire in South Queensland Oz. I know this as I worked there for a time and was told all about it as the guy was into his first few months in jail, so new ears to an old story in the Instrument dept.
This was the dept that looked after the SCADA system. When they found out that I used to work on control systems in the UK, I was kept away (sort of) from the system (stranger danger). Until they crashed it and NT4.0 and could not reboot the machine, didn't have the discs, licenses for windows, Citec, etc. then cap in hand to me to rebuild it. The manager for the water system had cancelled their support contract with citec as it was "Not worth the money, it has never failed."
Oops.
I have worked on real control systems in fine chemical and pharmaceutical industries, heavy metals, oil and gas and my favorite plant in Grimsby that makes paint/tablet whitener.
When these boys connect to their control system to the intra-net it is through a gateway, switches and other things that go bump in the night, Ranjan Acharya and Chris Thomas are correct in what they say, these two must have a lot to do in the industry. I have walked away from this side and gone back to Instrumentation, more money in it. I do miss it as setting up new systems was great, but supporting PDP11 DEC controllers did get a little tiring. These are still in use.. On ya Fischer and Porter. Great system even if it is older then me!
Peter
Why the hat and coat? I already left.
I work in the field, and I have to agree with Ranjan. The people who use SCADA don't give a flying crap about security. Less than that, even. Typically, they ask me to make the software ask for a password before un-greying the database modification button, and that's it. Sometimes, not even that. Sometimes they actively ask me to disable security features if they mean having to click one more button to get at some functionality. God forbid adding security features that would actually cost money to implement, the very idea is laughable. Patching is damn near impossible as the system is supposed to run 24/7, but that's fine because noone wants a security patch anyway. And yeah, some (lots, actually) of this stuff runs on operating systems that are full of holes that will never be patched on account of said operating system having been officially dead for 10 years.
The only saving grace is that safety systems on the PLC or on the actual machines will prevent a real disaster; a PLC tends to be considerably tougher than a computer, and you can't hack an engine temperature sensor hardwired to cut off the power supply. The worst that could happen on the systems I worked with would be monetary damage due to waste of time.
Thanks for the nice words, but you're really wrong, I've never worked in your industry at all, but common sense and knowledge of these things goes a long way when trying to design such systems.
what I was saying, was my plain old common sense, I am talking from the point of view from someone who builds websites for a design company in barcelona and programs software applications. I'm no security pro, but what I'm seeing, is that if this web gig doesnt turn out to earn so much money, I can go into security consulting and probably do a dammed sight better than most people I am hearing about (disregarding "The other steve's" obvious comment about dropping bad connections instead of locking down the reporting network, which I thought about already, but I'd hit the send button by then)
Thanks peter, good luck with the instrumentation :D
"is that the best you've got to something I wrote in less than a minute"
And probably less than a minute to think about, and therefore not worth much more than a minute to respond to.
And how many minutes, do you think, would it take someone to drive out to some remote piece of equipment at a shit swilling plant in the middle of the night to reset some piece of equipment which has locked itself down because someone only spent a minute thinking up a cool plan with a great big gaping flaw in it which they didn't notice until someone else pointed it out to them ? Somewhat illustrative of the problem under discussion, I feel.
Anyway, you don't want to get into a _protracted_ flame with me, September through December I hibernate under a duvet with a laptop and a bad attitude and only venture out in to the cold to obtain further supplies of date expired Red Bull, smuggled east European Marlboro and discount priced Chilean Merlot. Shit, sometimes I don't even open the curtains until February, depending on the weather and the quality of the Merlot. You on the other hand, surely have better things to do with your time.
you have a two-gate system.
Gate one is between the SCADA system and the gateway computer to the outside Internet.
Gate two is between the gateway computer and the Internet itself.
When one gate is open, the other is hardware-closed. Simple.
You post the data not in real-time, but in batch. Every so often, you close the gate to the Internet, you open the gate from SCADA to the gateway computer, you transfer all the necessary data, then you close the gate between the SCADA and the gateway computer, then you open the gate between the gateway and the Internet. You make the gates hardware, so there's no software to exploit.
Voila. At no time is the SCADA interface directly accessible from the Internet, but the data from the system is, via the gateway computer, at regular intervals. Safety is restored, and the system is not directly hackable. Only by spread of time-delay viruses onto the gateway could remote control be taken, and daily imaging could make that virtually impossible. Combine it with multiple gateway computers running in a cycle, you could re-image each gateway after it accesses the Internet, and make such time-delay virus attacks impossible (as long as you re-flash the BIOS too).
As you see, there are ways to do anything...you just have to think first, not react first. Any CERT will tell you that.
Here is a scenario I have seen. A manufacturing tool often has its critical control implemented by a plc or embedded controller but uses a pc to exchange mfg related data with. Someone ships a tool with a virus on that pc. It is installed on the factory network and eventually brings down some windows servers that run software needed to know how to move from station to station.
The tool itself finishes it process and waits patiently for the next task, which doesnt arrive till the mess is cleaned up.
Deeply disappointed in the lack of comments on this 'Director of Penetration' fellow.
Customers want the world.
Some want remote diagnostics (well if your system is on an oilrig or in the middle of nowhere, its not so easy to get a support engineer to go look at it).
Other than a dedicated fiberoptic line to the place, you have to use a VPN over the 'net or configure firewalls and intelligent switches to limit the traffic.
And you can't just stick a patch on. Suppose your windows or SCADA patch effects how the system operates? Ok, they are controlled by PLCs, but if the SCADA sends a signal to the wrong address in the PLC, or prevents the user starting or stopping a pump at the right time, the system could trip. And I certainly wouldn't want to be responsible for tripping out the main pipeline from the Forties field.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
