Posted
by
timothy
on Friday April 04, 2014 @11:30PM
from the about-that-skeleton-key dept.

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.

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.

I mean... I had always understood that SCADA vulnerabilities were caused by amateurish system design (connecting SCADA systems to the Internet using cheapo consumer-grade routers, without precautions like stealth, VPN's, whitelist callbacks, etc.) and shoddy system management (factory default passwords, obvious passwords, dictionary passwords, no passwords).

And now this! In some cases the actual software seems to have security holes too. Shocking, shocking, shocking!

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.

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

If only. Come be a utility in Texas, where ERCOT (the state-wide electric utility authority) seriously considered making their push notification system be Internet-only. As in, you HAD to connect your SCADA system to the Internet (even if through an intermediary server in a DMZ) to be able to receive the (required, if you wanted to be licensed and in business) control signals from ERCOT. Thankfully, for once, the backlash was so bad ERCOT actually listened to it and backed off that plan. That's exceedin

>SCADA systems NEVER EVER get connected to the internetEasy 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

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

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.

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

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.)

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

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.

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.

"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."

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).

"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.

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.

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.

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

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

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

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.

My prediction is the executives of any compromised oil rigs, refineries and power plants will assure us they will not stop until they bring to light any shortcoming that caused any resultant catastrophe. They will go on to say that no one could have foreseen this happening and they are laser focused on keeping our infrastructure safe.