Posted
by
samzenpuson Monday November 26, 2012 @06:10PM
from the target-rich-environment dept.

Trailrunner7 writes "It is open season on SCADA software right now. Last week, researchers at ReVuln, an Italian security firm, released a video showing off a number of zero-day vulnerabilities in SCADA applications from manufacturers such as Siemens, GE and Schneider Electric. And now a researcher at Exodus Intelligence says he has discovered more than 20 flaws in SCADA packages from some of the same vendors and other manufacturers, all after just a few hours' work."

Sweat anyway, if you've got SCADA connected directly to internet. Especially if it's older software. For a very long time these control systems were written assuming a closed network, or that customers were never going to use the devices in unsupported manners. Customers wanting cheap software and devices is half the problem. Customers wanting convenience is the other half (ie, they don't want to deal with hassles that must always come if security is beefed up).

Not necessarily. A good number of SCADA RTUs (I'm thinking of the Logica units) have built in parameterised overrides -- you can set a safe range of settings for an RTU (e.g. "close this valve if sensor A gets above 150, no matter what") that can't be overridden, or re-flashed, via the network. This can severely limit any attempts at outside fiddling by muckabouts. At the same time, you can read them across a network for operational situation displays. You just have to engineer the limits into the deplo

SCADA is old and almost never replaced. It is the nature of the beast to not touch stuff that moves or monitors big and critical things. This is not a software engineer's idea, but an industrial/mechanic engineer's idea of how to work an indistrial facility. There is a gap in understanding between people that do the (really)hardware stuff in an industrial place, and the software people that make SCADA stuff.

But its all good IMHO because what is going to happen is that SCADA will get better, and believe me,

Where's the lazy editing? It's not like this is the first SCADA story on/.. Are we going to start defining every non-everyday term in a summary?

"Researchers have identified a hole (an overlooked security concern) in the TCP (Transmission Control Protocol a system of information transmission that aids in reliable data transfer) layer (a metaphorical layer in a sandwich of other layers each of which pertain to certain elements of the network stack (the combination of hardware (physical parts of a computer) and software (the computer code that resides on a computer's storage that makes up a computer program) that allow a computer to/talk/ to another computer over a network)) of Windows (a computer operating system (a complex computer program that coordinates and translates software requests into hardware actions))."

"Researchers have identified a hole (an overlooked security concern) in the TCP (Transmission Control Protocol a system of information transmission that aids in reliable data transfer) layer (a metaphorical layer in a sandwich of other layers each of which pertain to certain elements of the network stack (the combination of hardware (physical parts of a computer) and software (the computer code that resides on a computer's storage that makes up a computer program) that allow a computer to/talk/ to another computer over a network)) of Windows (a computer operating system (a complex computer program that coordinates and translates software requests into hardware actions))."

There's a fairly major difference between "everyday" terms for the general population and those for/. readers. What you've done is somewhat facetiously define a number of terms that one might consider "everyday" for the vast majority of the visitors to this particular news aggregator. SCADA isn't something that most of us deal with, and I think readers could be forgiven for wanting an definition in the summary, especially if they've missed the recent bout of SCADA-related articles.

Why not? I don't see the harm in <span title="Transmission Control Protocol">TCP</span> Ok, spans are semantically void so there's probably a better tag, but it's the attribute which matters. HTML titles are quite appropriate for unobtrusive expansion of TLAs. Your example is intentionally absurd, but it would be fine if applied only to acronyms and "initialisms".

When the light turns on, the roaches scurry. SCADA has been ignored by infosec up till now. Many of these systems are old, or are new systems not designed any different then they were in the 80's or 90's. It's not hard to find low hanging fruit when you're the first person picking it. Give 'the system' a few years and it won't be any different then Linux and Windows bug hunting now.... once you convince everyone to upgrade, that is.

I've been hearing anti-scada fud for about two decades and it never gets any better.

I suppose as agitprop the early 1980s movie "wargames" is pretty good anti-scada. Or claims that Kevin Mitnick can whistle into a telephone thus launching nuclear missiles. There was a cheesy hollywood horror/action movie in the late 80s or 90s that could basically be subtitled "misterhouse grows into a skyscraper and has a tantrum killing everyone inside". I distinctly remember a 6-million dollar man or 6-million dollar woman (a late 1970s psuedo-scifi tv show) which had a nuclear power plant scada attack, with a friendly computer that donated a 7400 series TTL logic chip to repair the magic prosthesis that was LOL funny at the time. There is also at least one anti-scada james bond movie, probably 80s era but I can't remember the details. Oh and there was a cheesy 80s "hacking" TV kids show perhaps the "whiz kids" or something that also had a anti-scada plotline.

There's about 50 zillion star trek episodes and movies which basically show a scada attack on a warship. Most notably when Kirk drops Kahn's shields remotely and pretty much blows his ship up in ST2. But there's about 49 other examples.

This would be a fun/. article... everybody troll the depths of your memory to build a timeline of anti-scada FUD.

IF you plan to see Skyfall read no further.
The current Bond is pretty much nothing but a SCADA horror story.

Yup the new Q should have been fired on the spot if he was still a network engineer grunt at MI6 for making a rookie mistake!!! Why is he putting a non-secured machine from a hostile party into a secure network in the first place???

Getting a USB stick from Russia or who knows where else physically plugged into a SCADA system somewhere in the USA is quite a bit more difficult than some hacker sitting in a basement in some distant land breaking in over the Internet.

Yep, since the bran counters have gotten so obsessed with saving money by reducing head count we have to have lights out facilities and remote managenent. Hook everything up to the internet, security be damned and who gives a shit about employmentor security we saved $700,000 this year.

These days you have to design your system in such a manner as to have expected that your 'private' network has become connected to your public network. What used to be a techs laptop, is now a techs laptop with a 3G/4G card. You can have a network connection open to the world where you never expected it. Things also get connected by accident, someone plugs the internet switch in to the private network, then later some hacker notices it. Holes in the firewall, or other compromised computers relaying a tcp tu

I suspect most SCADA systems are less buggy than most Windows applications. Most of them really to have a lot of stability and reliability. A buggy SCADA device is bad news and customers get very angry over it (much angrier than merely having a Windows application crash), as it means lost money, lost safety, etc. Companies who build SCADA systems absolutely paying attention to this. Where is falls down though is the relatively new prevalence of SCADA systems connected to external networks.

Some of those systems are based on a technology called OPC. That's OLE for Process Control. Over the network it runs on DCOM. Of course unencrypted and usually without authentication because it's already hard enough to get it running somehow.Of course those are Windows-only solutions. And of course, those systems are often so complex and badly made that updates are next to impossible.

There is currently no knowledge about security in those companies. They simply don't understand it. I've been in companies wh

Those systems are supposed to be secured physically, not via software. They should have physical access restrictions, and never be connected to anything other than a dedicated network with no other devices on it.

That is standard practice for all sorts of critical equipment. I used to write software for fire alarm systems, and the control panel was protected by a locked glass-fronted cabinet. If someone opened it they could turn on sprinklers, open vents, break stuff and generally make sure that if a fire st

Well yes of course. Those should never be connected to anything else, but...

a) That software is often so bad/insecure it doesn't work reliably.b) Many software vendors in that area require you to have license keys... which come in the form of files.... which opens the USB attack vector.

Physical security sounds like a good idea on paper, but then again it's of no use when you press the "brake" button and the system simply will not respond within a second. As on the new ICE-3 designed by Siemens.

This is why SCADA needs to be built out separately from your data network.

While that is indisputably a good idea, it does not cover all the bases. Disgruntled employees, industrial espionage, and state-sponsored sabotage (in the case of critical or defense industries) won't let a silly air gap stop them.

False dilemma. One excellent security practice not being the sole practice necessary doesn't mean its not an excellent security practice.

I've never worked at a place without airgapped or at least tightly firewalled "IT" and "production"/"engineering" networks. I'm sure there exist places where the receptionist can install a toolbar or weatherbug on her windows PC and literally blow up the plant, but I've never personally seen or worked at one.

As long as you realize that air-gapping is a weak form of security in itself, air-gapping is ok. One break in the gap and it folds. Too many wireless devices out there these days to ever be sure that your system is really isolated. If your plant network isn't monitored for aberrant traffic patterns and firewalled from internal threats, you'll never know if your air-gap is working.

As long as you realize that air-gapping is a weak form of security in itself, air-gapping is ok. One break in the gap and it folds. Too many wireless devices out there these days to ever be sure that your system is really isolated. If your plant network isn't monitored for aberrant traffic patterns and firewalled from internal threats, you'll never know if your air-gap is working.

Hence it is a standard practice to have ZERO wireless devices within the air-gapped secure network to start. You are correct the traffic monitoring and strict firewall (on an air-gapped network) are still necessary. They should be standard practice in a critical network today, even in SCADA/Control application. There are very little reason not to do so today.

How do system updates or license updates work then?Keep in mind those systems often are Windows systems running huge amounts of software on them like SQL-servers or.net frameworks. And the software often has 1990s style licensing systems running which might need regular license keys to stay up to date. This was apparently the most common infection vector for Stuxnet.

Todays SCADA systems are less and less designed to allow for that. Another obvious point would be that those systems need to boot from read-on

The industry uses what they use because that's what they use. Their standards are built on their expectactions which are built on their experience. Long ago, computers were machines you didn't turn off. They were reliable and steady. People wrote software which adhered to that mindset. But then the PC industry came and every hobbyist became a programmer. That's when all hell broke loose. But that was fine because these were small system and you just reboot and keep on with whatever you were doing. You were just one person. What did it matter? But the next thing you know "enterprise applications" are being built on a platform intended for single users... bringing with it a whole crapload of lax and shoddy standards.

Now you know how we got where we are today.

How do we get out? Linux is built under the same old school priciples of reliability and stability so it tends to be able to run a lot longer than WinTel. But even that's showing signs of relaxing. And Apple? It had a reputation for not having problems... that was until people started to use it.

So how do we get out? Obvious answer is to go back to what worked. But that's EXPENSIVE. No more "off the shelf solutions" with implied (though EULA denied) guarantees. No more OSes built from single-user, patched and hacked systems. AS/400 for mature systems and service standards come to mind. IT got cheaper with PCs and WinTel. But they also became 10,000 times more risky. People who spend money are constantly lied to by various parties and don't listen to their own IT people about what they should do.

See the paper above. In the first two pages it describes what SCADA is and what its architecture generally consists of. The most important statement is that while SCADA used to be based on other OSes, it is now primarily based on Windows though there is a Linux based SCADA vendor out there.

My rant points out that In addition to evolving from a single user OS, Windows brings along with it unprofessional coding

... The most important statement is that while SCADA used to be based on other OSes, it is now primarily based on Windows though there is a Linux based SCADA vendor out there...

The RTUs (Remote Terminal Units) that form the sensor/control layer of a SCADA network are individual programmable units, which generally have their own minimalist platform and programming language for their specific embedded systems. A control network of these may be infectable, but the individual end-terminal units - the ones that do the actual control - are a wee bit esoteric for your average (or not so average) script kiddie. It would be like connecting your PC across the network to a strange device,

The compromises which have occurred on SCADA systems have compromised the Windows portions. Once the Windows portions are infected, the network is compromised. If these SCADA programable units are set to accept command and control from these Windows machines, the game is over. And I believe that has been the case in every documented SCADA system compromise.

Unfortunately in this risk-vs-reward scenario there's a get-out-of-jail free card which we've ALL seen played fast-n-loose recently.

If your industry is "to big to fail" the government will step in and throw money at the problem.

So it's actually a financially viable proposition to invest in crappy workmanship, shoddy systems, and brain dead fundamentally unstable computing systems until A CRISIS LOOMS then wait for The Government so save your sorry ass.

It's EXACTLY what the banking/finance industry recently did in the US.

They KNEW perfectly well that what they did, while technically not illegal, was A REALLY REALLY BAD IDEA which *might* (possibly) not blow up in their faces, while making them insanely rich.

If business are perfectly happy with suchlike RAMPANT STUPIDITY (er I mean UNCONTROLLED GREED) even before the Government had made their "too big to fail" bailout, how much more likely is such behaviour these days?

Remember folks: if your screwup is BIG enough, there are NO CONSEQUENCES... ANY risk, no matter HOW insane, is worth it - as long as the scale of the potential disaster is large enough.

That is why there was a petition in Germany to force nuclear power plants to have an insurance. Because they simply have not as it would be far too expensive and any disasters are the problem of the inhabitants anyway. If nuclear power plants had an insurance, the energy would not be so deceptively cheap with respect to clean energy.

Everyone knows about the holes, including the manufacturers. They're designed to operate on controlled, private networks. Every time someone gets hacked, they should go after the implementors, not the vendors as they should factor security onto their site designs. I'm not excusing the manufacturers, just people need to know this is engineering and not infosec - people buy black boxes which do stuff and that's all that matters to them.

Everyone knows about the holes, including the manufacturers. They're designed to operate on controlled, private networks. Every time someone gets hacked, they should go after the implementors, not the vendors as they should factor security onto their site designs. I'm not excusing the manufacturers, just people need to know this is engineering and not infosec - people buy black boxes which do stuff and that's all that matters to them.

The problem is even airgapped networks can be broken into. See stuxnet and flame - they exploited several machanisms to install themselves onto airgapped networks. It also went to show that even airgaps can be broken into if you don't need much in the way of return information - you just need to get onto the network, and not send data back out. Heck, the USAF had their UAV computers infected with a virus.

The weakest part of an airgapped network is the maintenance thereof - add some new PLCs to the network? Well, they have to be configured to work with everything else, so someone has to plug something into it to configure it. And that something is unknown - it could be a technician's laptop, it could be a thumb drive, etc.

The thing is, an airgapped network has to be maintained, and it's really hard to do so without at some point having to plug something in-between the gap. (For Stuxnet, it was a software update or other thing, for the USAF, it was... map updates). And at some point, data has to be transported across

Heck, even the thumbdrive isn't invulnerable - it could for example be infected during manufacturing.

In the end, all networks are interconnected. Some less so than others, but eventually they will have to be in some shap or form.

There are huge maintenance advantages to having your SCADA system connected to the internet: as an example it allows your experts to debug problems from home, rather than wasting time to drive in. This leads to the (quite reasonable) desire to connect the systems but implement various types of security to prevent unauthorized access. Of course even if that is done correctly, the "authorized" person may themselves be the unintentional source of the hack - just because someone knows how to tune the paramete

And just as many security disadvantages. Yes you get the immediate savings of lights out management but no bean counter ever takes into the long-term and hard to quantify costs of all the additional security necessary to protect your convenience.

Back in the day when the IT folks wanted to gather data from my Modicon PLC's I put a seperate PLC on Modbus Plus Network and used Ladder commands to transfer what they wanted to it. Then I put a Gateway in between with custom built ROM that disabled the Modbus commands that could change or write to that PLC and left them with only Read Register (4xxxx).

And Stuxnet managed to get past this air gap. However that was a piece of malware designed with an enormous amount of resources too.

The problems here are large. SCADA systems involve many different devices all from different manufacturers all jury rigged to work together. Putting a lot of security best practices in place is difficult. And to be fair, security actually scares a lot of people here. They are worried that they'll be unable to control the network like they used to, worry that once they flip

Now can someone tell me what I saw? All I can see is video of some commands being typed into a command window in a older version of Windows, and lots of graphics (and funky music) saying exploit this and exploit that. How do I know that what they are claiming is what is shown on that video?

Note that I am not doubting that SCADA systems are not secure, the've been my bread and butter for a long long time. I just want cold hard facts., not a presentation that looks like it is a sales pitch aimed at scaring SCADA manufacturers.

OK, unfortunately the video is not really informative.Remote execution means that the attacker was able to tell the other system to run commands. One common method (stack overflow) works like this:(In C) you have a local variable, for example to hold a string. Imagine it's 10 characters long, and you want to write 20 characters into it. It's obvious that you overwrite something. Since local variables are on the stack, you overwrite parts of it. The stack also stores the return address of the function call.

SCADA was supposed to be an industrial control system, where nobody thought "hey... let's suddenly connect this incredibly important system that could literally kill people if it were compromised..... to the internet".

So it shouldn't be surprising the thing is full of vulnerabilities. It wasn't designed to be a secure system from smart and incredibly skilled people trying to attack it. It was designed to be secure through physical security and lack of access in the first place. The problem is that ever

If the Big Bosses want to know the status of their machines and run reports on that status 24/7, fine.

Just have the equipment log to a write-only device that is in turn read by equipment the Big Bosses can access.

There's still the very serious risk of highly sensitive data leaking out and being used against the company or its SCADA devices in a USB- or social-engineering-based attack, but at least the equipment that can kill people will not be directly write-able from the Internet.

That might have been an OK excuse 5 years ago, but it's been rather a long time (in Internet time) since SCADA started getting hooked into the Internet. We've had a bunch of discussions about this exact issue for quite awhile. The industry has a set of best practices (air gap, data diodes, etc). The manufacturers of SCADA gear have had plenty of time to revamp their designs.

If you believe TFA, they haven't done a particularly good job of the latter.

Factories don't work on internet time. Once a large expensive piece of industrial equipment is installed it's there for a loooong time. I used to work on upgrading some software for four machines that were 15 years old at the time. Two new machines were ordered (with a price tag of around 4M) and they wanted the control software to be compatible with the old machines. That was about a decade ago. The plan was not to upgrade until old control computers start failing. As far as I know they are still working.

So, if I'm a random security researcher, how do I get my hands on these SCADA systems to test them? They certainly aren't open source, and I'm guessing they aren't cheap. I doubt you can just type a credit card number into GE's web site and download one. How do they get one to look at?

So, if I'm a random security researcher, how do I get my hands on these SCADA systems to test them? They certainly aren't open source, and I'm guessing they aren't cheap. I doubt you can just type a credit card number into GE's web site and download one. How do they get one to look at?

I believe you have just nailed their security through obscurity philosophy. Only organizations with a small pile of cash, the right connections, or existing industry experience are able to play with these toys. This isn't something script kiddies can do.... yet. Sure you can break into a Duke Energy's VPN, and maybe they are stupid enough to still have control software on their internal non-control network. But you probably wouldn't know how to get started with controlling anything unless you had prior

$6000 for a dongle is pretty bad but arguably there is some special sauce or secret things inside the dongle. Any salesperson could concoct a convincing argument justifying it somehow. Until recently, our steam turbine controllers had a $400 backup battery for the memory. It was a 3.6v lithium AA-sized battery with a fancy connector soldered to both terminals and shrink wrapped. It became such a sore point that some more customer-oriented salespeople just pointed the customers to the correct digikey par

16 years ago I worked on/developed industrial control systems and the fact this industry hasn't moved anywhere on the security front is not surprising. At the time development was still 1970s-80s style, save the punch cards. Most of the software developers had never learned structured programming and would still argue against it a solid decade after their mainstream ilk gave up the fight. Their code style was pure 70s at best and pure chaos at worst when written by the EEs. The newest code was all written i