Bugs In SCADA Software Leave 7,600 Factories Vulnerable 70
mspohr (589790) writes with this news from the BBC: "The discovery of bugs in software used to run oil rigs, refineries and power plants has prompted a global push to patch the widely used control system. The bugs were found by security researchers and, if exploited, could give attackers remote access to control systems for the installations. The U.S. Department of Homeland Security said an attacker with 'low skill' would be able to exploit the bugs. About 7,600 plants around the world are using the vulnerable software. 'We went from zero to total compromise,' said Juan Vazquez, a researcher at security firm Rapid7 who, with colleague Julian Diaz, found several holes in Yokogawa's Centum CS 3000 software which was first released to run on Windows 98 to monitor and control machinery in many large industrial installations. The researchers also explored other SCADA software: 'We ended up finding over 1,000 bugs in 100 days.'" The vulnerabilities reported are in Yokogawa's Centum CS 300 industrial control software.
Re: (Score:2)
Re: (Score:2)
Yes, but does it run SCADA?
It appears that openSCADA would. (http://openscada.org/downloads/)
They all use WIndows 7 anyway (Score:5, Interesting)
It is a good thing they all use Windows 7 with updates turned by default and are all disconnected from the internet. With a good understanding management mixed in who care about this more than their reports from IE 6 this is not a problem.
Re: (Score:3, Insightful)
I believe at this point in time, researchers should only shout out about their vulnerability testing of SCADA software if they DON'T find buckets of basic, serious flaws.
At this point in time, it's like shooting fish in a barrel. Every company with their SCADA system connected to the internet should get daily fines of a percentage of their worldwide revenue.
Re: (Score:3)
Re: (Score:3)
We ended up finding over 1,000 bugs in 100 days.'"
For say $10 per bug, that $100 a day :) . Wow wondoze is profitable for everyone! yay!
Oh! I Say! Shocking ! (Score:2, Funny)
And now this! In some cases the actual software seems to have security holes too. Shocking, shocking, shocking!
Re:Oh! I Say! Shocking ! (Score:4, Interesting)
SCADA systems NEVER EVER get connected to the internet, not ones that are properly installed by competent engineers.
Re:Oh! I Say! Shocking ! (Score:5, Informative)
"not ones that are properly installed by competent engineers."
Depends how management (bean counters, PHBs and MBAs) listens to said engineer. You'd be surprised what stupid (and not even cost-cutting in the long term) decisions companies will make to save a dime tomorrow. The biggest Telco in Canada used (not so long ago) to deploy its wireless routers with only WEP and *NO* admin password on the device, even if WEP was broken about 10 years ago.
It's not like they don't have any competent tech people, but having worked there, yes, that's the kind of stupid decisions management will take.
Re: (Score:2)
I don't believe that Iran's SCADA systems were connected to the Internet but were infected anyway by a compromised Windows machine (Stuxnet) which was used to transfer the program to the SCADA system.
From the Wikipedia STUXNET page: The reason for the discovery at this time is attributed to the virus accidentally spreading beyond its intended target (the Natanz plant) due to a programming error introduced in an update; this led to the worm spreading to an engineer's computer that had been connected to the c
Re: (Score:3)
Re: (Score:2)
>SCADA systems NEVER EVER get connected to the internet
Easy for the clueless to say. But often not connecting a SCADA system (through a firewall) to the internet has more payoff than risk. Worked in a factory with 24 hour operations, having a competent engineer on staff at all times just isn't practical (good engineers don't like to work off shifts, just in case.) So when the meat of the operations go down costing $1000's a hour, allowing the system to be troubleshoot remotely without waiting for a ho
Re: (Score:3)
Re: (Score:1)
Re: (Score:3)
The bugs are in the Centum CS 3000 software that controls the SCADA system, not Windows.
When these systems were first being introduced, there were multiple competing standards on design and everything was proprietary. That model hasn't really changed. Some manufacturers, like ABB, do offer an upgrade path to transition from an older model to a newer model. If you wanted to transition from one manufacturer to another though, you're SOL. So, if you bought into a system that is now defunct, you'll have to
Re: (Score:2)
And as STUXNET shows, it's trivially easy to compromise Windows (all versions) and thereby compromise the SCACA system.
Yay! (Score:1)
Factories are vulnerable. (Score:2, Insightful)
Why did you need factories with direct connections to the internet anyway? Seems like an easy way to have shit go bad to worse.
Re: (Score:2)
And why would you need internet for this?
Re: (Score:2)
Because this is 2014 and we don't use leased lines anymore.
Re: (Score:2)
I beg to differ. For critical applications where down time costs millions, I would use a dedicated line. I'd even consider a dial-in modem interface rather than an Internet connexion. I'd even rethink remote monitoring. Is it really needed? But connecting critical applications to the Internet, especially when you have hardware requirering old OS verions that are full of holes and unsupported, is playing with fire.
Re: (Score:2)
I'm talking about mobile.
And I sincerely doubt there are "7600" (as the article states) "CRITICAL" applications. If you ever connect to the vulnerable ones, chances are they will be a small factory no one cares about.
There is nothing wrong with remote MONITORING, as it happens to be just that: MONITORING. It's not about remotely controlling a process. It's about "the boss" seeing some dumb parameters (production counters). All logic should run in the PLC. Control sould be performed locally, through HMIs. Yo
Re: (Score:2)
Give them a busybox. I doubt they'll know the difference.
Re: (Score:2)
Incompetent programming in a bad language (Score:5, Insightful)
The code:
The company that let that code out the door should be sued for gross negligence, and managers fired. That's not the only example; they failed to do basic checks at least three times. This isn't a subtle bug. This is failing C Programming 101.
(Several times, I've tried to convince the C standards committee to put a "strict mode" [animats.com] in the language and move towards a form of C that's resistant to buffer overflow problems. Maybe I should try again.)
C - now with over thirty years of buffer overflows.
Some can some shouldn't (Score:2)
Re: (Score:2)
Hmm, I prefer Java over C and assembler because although I can write highly stable and secure code in C/asm, the effort to sustain the required level of paranoia and navel-gazing is for most code better directed elsewhere to visible benefits. I write code that actually has respected security crazies and bank auditors telling me to lighten up a bit, yes really!, but I'm still perfectly capable of making a mistake.
However, I'm inclined to think that whoever wilfully lets code out the door without appropriate
Re: (Score:2)
Some operations are never the right answer, such as trusting input not to overrun the buffer.
Re: (Score:2)
Nice idea that is long overdue, but perhaps a better way to get this accepted is to implement this in a real high-profile compiler such as llvm/clang.
I'm afraid, however, that the Real Men Don't Need Bound Checks mentality that is prevalent among C programmers will be a big obstacle.
Re: (Score:2)
I'm afraid, however, that the Real Men Don't Need Bound Checks mentality that is prevalent among C programmers will be a big obstacle.
I've run into that. Usually from second-rate programmers. Programmers who think that way should be put them on maintenance programming for a while. Have them debug program crashes in code written by others.
Re:Incompetent programming in a bad language (Score:5, Informative)
That looks like library code that the compiler generated. Maybe some kind of strcpy variant. As I'm sure you are aware strcpy does not check buffer sizes, but without knowing the context it is used in it is hard to say how bad this problem is.
What you have to keep in mind is that this software was written for Windows 98. Windows 98 doesn't even have filesystem permissions or any real user segregation. There is no firewall by default. Chances are it would be running on some industrial equipment anyway, not connected to an external network. Yes, it uses UDP, but that is actually quite a common technique for processes on the same machine to communicate, or devices within a single piece of industrial equipment. We don't have enough context to know.
I write software for embedded systems. I'm talking microcontrollers, not Windows based. The products I make are complex, but have very few computing resources because they have to run for 10 years on a couple of AA batteries. 16k ram is a luxury. I know that if someone decided to hack one they could do, easily. No through incompetence, through a deliberate decision not to compromise other aspects for extra security. Yeah, we could set up encryption keys on the comms protocol, but then we would need to get the minimum wage morons who deploy these things to understand how to install and use them. We have enough problems already. And no, we can't employ better people, our customers are the ones doing the deployment. They demand features like being able to send a completely unauthenticated text message from a standard phone to a device installed somewhere and have it execute those commands.
So I imagine in this case it is a closed system, never designed to be connected to a network where it could be attacked with malformed UTP packets. The system has been tested and found to be stable because it never generates such packets itself. The real morons are the ones who tried to network it, presumably against Yokogawa's recommendations.
This is commercial reality. Just like your car has a massive vulnerability where the passenger can reach over and yank the wheel and cause an accident the manufacturer probably figured that people ignoring their recommendations wasn't their problem.
Re: (Score:2)
"but then we would need to get the minimum wage morons who deploy these things to understand how to install and use them. We have enough problems already. And no, we can't employ better people, our customers are the ones doing the deployment."
So, the minimum wage morons *are* your customers?
Re: (Score:2)
As STUXNET has proven, you don't have to have a SCADA system connected to the Internet to get infected. STUXNET infected Windows machines which were used to program the SCADA system. Internet->Windows->SCADA. You only need to be connected once to get infected (kind of like STDs).
Re: (Score:2)
That looks like library code that the compiler generated. Maybe some kind of strcpy variant.
Read the analysis of the code. It's not. It is, however, decompiled assembly code; the people doing the analysis don't have access to the source.
What you have to keep in mind is that this software was written for Windows 98.
Irrelevant. This code is vulnerable on any OS that lets it get UDP packets.
We don't have enough context to know.
Read the actual vulnerability report. There's enough context there.
The real morons are the ones who tried to network it, presumably against Yokogawa's recommendations.
You have to assume today that if it has an Internet-accessable interface, an attacker will find a way to get to it from the public Internet. Because, in practice, attackers do.
"Low Skill" (Score:2)
"That's okay, only high-skilled hackers are interested in our operations." - PHB
"IBM PC/AT compatibles" should be warning enough (Score:3)
"IBM PC/AT compatibles" being an old term for a PC
"The Human Machine Interface (HMI) of CENTUM CS 3000 is general-purpose PCs (IBM PC/AT compatibles), running Windows 2000 and Windows XP. Windows 2000 and Windows XP have superb networking functions, and OPC for interfacing with supervisory computers are standard – so supervisory computers can easily access the process, and you can optimize your company at the enterprise level. In addition to OPC for communicating between PCs, we can also provide communication with UNIX machines and the like."
XP has Data Execution Prevention (DEP), WK2 doesn't, every exploit listed was a buffer overflow; which DEP is there to prevent. http://en.wikipedia.org/wiki/D... [wikipedia.org]
"CENTUM CS 3000 is a key part of most of Yokogawa’s Enterprise Technology Solutions, and features:
Open environment for optimizing the whole enterprise,"
An open environment; which the most ardent supporters for non-proprietary software/hardware have to admit is an entry point for ones exploits, when used with a software interface of WK2, and now XP; (Win98 is never mentioned)
HOSTS file prevent me viewing the first link but the above is good reason to of checked out the hardware.
cite: CENTUM CS 3000 Integrated Production Control System System Overview
http://cdn2.us.yokogawa.com/TI... [yokogawa.com]
Re: (Score:1)
Re: (Score:1)
If you were REALLY serious about security you would deploy your sofware on a banana, no one has ever hacked a banana before.
That's how your argument sounds in 2014. It's easy for even the most novice users to maintain and run so its popular, if they started people on *NIX in grade school everybody would run *NIX and it would have 1000 new security exploits every month because it is the bigger target. Obscurity is not security.
Bugs.... (Score:3)
I am surprised when I find that SCADA software works properly. Bugs are expected.
Craptastic SCADA suites like WonderWare are so poorly written and horribly implemented that they barely run. Then you have plant managers that are so stupid they dont understand that you NEVER run anything but the SCADA on the computers, but instead install other software and have them all on the company LAN with internet access...
They deserve the problems they have, because if the SCADA systems were designed right, and managers and business owners were hit in the face with a sack of nickles when they ask for stupid security rick crap, the bugs would not be a problem as there would be a frontline security defense in place.
Dumbasses (Score:2)
Boys and girls, SCADA IS A FRIGGING BUG!!
Let's think about this for just a second or ten. I own a corporation that has produced products for a century or more. In the old days, people did EVERYTHING by hand. Then, along came the assembly line - making things easier and faster. Then came automation. At each stage, my corporation has been pretty secure. Then, along comes this newfangled internet thing. Every Tom, Dick, and Javier in the world can get on this internet thing, and play Hack-a-Day with any
Re: (Score:2)
You, sir, are an idiot.
SCADA is a reporting tool. SCADA is for your manager. If your managers want access, you provide them with access. Because if you're not a fucking incompetent idiot, you can make a secure system that will let management see factory data in real time.
But you're an idiot who just forwards the SCADA web access port to the internet with no password.
The problem with industrial automation "vulnerabilities" is not SCADA, it's not software, it's not anything you're thinking of. The problem wit
Re: (Score:2)
No, you, sir, have chosen not to understand. I am MOCKING every moron in the world who wants all that information to flow out over the intarwebs in real time. The "managers" at my plant choose passwords like "1234abcd". They think it's witty or something.
The fact is, our nation worries itself sick about cyberattacks, when there is no need to worry.
JUST DISCONNECT ALL THAT CRAP FROM THE WEB!!
As for passwords, encryption, or any other security measures, recent events have pretty much demonstrated that the
Re: (Score:2)
I just use VPN. Android and iPhone both can dial in. I even use it for my house CCTV. Give them a strong certificate, then let them have any dumb password they want when they are inside the LAN.
Re: (Score:2)
And, what happens with a MIM? Someone spoofs a cell phone tower, and intercepts your communications. They get the strong certificate, and they are in. Wireless communications (radio) has been known to be inherently insecure by the armed forces since the days of the first radios.
http://www.wired.com/2010/07/i... [wired.com]
Re: (Score:2)
It all comes down to what kind of facility you're working with.
If it's a nuclear power plant, or a missile factory, then there is no need to "dial in". No employee should need to monitor anything remotely.
If it's a small bread factory and you use SCADA to monitor the production line, who cares? No one is going to want to hack you so badly.
Really, this is all a non-issue.
How many years are we going to see SCADA? (Score:2)
Just how many years are we going to see postings/articles on how buggy and security-hole-ridden SCADA is?
Near as I can recall, people have been bitching about this steaming pile of shit for over a decade.
executives will be shocked and outraged (Score:1)