Researcher Claims Siemens Lied About Security Bugs 46
chicksdaddy writes "A month after an unknown gray hat hacker calling himself 'pr0f' used a three character password to hack his way onto Siemens software used to manage water treatment equipment in South Houston, Texas, a security researcher working for Google is accusing the company of trying to cover up the existence of other, more serious vulnerabilities in its products. Billy Rios has disclosed a range of vulnerabilities in Siemens SIMATIC software on his blog. The holes could allow a remote attacker to gain access to the Simatic user interface without a user name and password. Rios claims that he has disclosed the hole to Siemens and that the company has acknowledged the problem, only to deny its existence when a reporter asked for more information about the vulnerability."
Lose the remote... (Score:4, Insightful)
The main problem these things have is that there's nothing more than password authentication protecting them from any random user getting in, and sometimes leak or get guessed.
For this kind of access there should be a technician dispatched to the site... no remote login should be allowed. Water control is a lot like Enron's electricity control in that a wipeout of any size can cause a complete mess of a local economy.
Re: (Score:1, Flamebait)
Re: (Score:1)
Re:Lose the remote... (Score:5, Insightful)
I don't know about your community, but mine complains incessantly about taxes. If we had to have full-time SCADA engineers guaranteeing on site support 24x7, we'd have to pay more for water, sewer, gas, electricity, street lights, traffic control signals, and all those other industrial controllers that are hidden under little green boxes on the side of the roads.
And I live in a large, wealthy city that could afford such amenities. I'm picturing the poor bastards in Bumfuck, Idaho*, population 174, located three hours from the nearest grass-strip airport. Who exactly is going to monitor their town water pump and filtration plant? Are you and every other taxpayer going to agree to pony up an extra $500/year to have a SCADA engineer sitting in the town bar all day and night, just waiting for your pump to croak? Or are you going to contract with REMOTE-SCADA-R-US.com to remotely monitor and maintain your plant, and possibly fix issues in minutes instead of days?
I'm not saying that they should just plug it into the internet and walk off. But disconnected isn't even an option for a lot of installations.
*My apologies to any fatherless indigents living in or near Bumfuck, Idaho. I'm sure you're all very nice people.
Re: (Score:2)
The problem is not that they allow remote access. That is obviously useful. The problem is that they rig the thing up on the internet, sans firewall, where anyone can hammer away at it.
I don't see any reason why a company cannot run all of these systems through a a VPN where only the only people allowed on the VPN is the engineers who need to be. I suspect they they don't do this simply because they are lazy or incompetent.
Re: (Score:2)
A VPN is usually only protected by a password or maybe a stored secret which is just a more complex password. There needs to be better authentication such as calling headquarters, being recognized by voice, location, and password and then having them agree your move makes sense before it's put into play.
Re: (Score:2)
if you don't even need a password, there's no password authentication on the actions taken on the server even..
Re: (Score:2)
You misunderstand Siemens. It used to be a great electrical company, but nowadays it is an investment bank. What sets it apart from other investments banks is that they deal in technology (and foreign exchange), and they have a very good understanding of technology. The production/engineering/service segments are really just used for better investment leverage. That does not necessarily mean that the engineering sucks, actually some of it is brilliant. But either way it is not as relevant as it may see
Re: (Score:3)
No, I don't think they "have a very good understanding of technology"
Many moons ago, when I setup my first NATed local network here, I bought a Siemans router. I set it up with a 12 character PW for admin purposes, the maximum it would allow. It was rooted and bricked 3 days later. If it was that easily attacked, I sure as hell didn't want it and took it back to Circuit City. They agreed, and weren't surprised that it came back.
So I next brought home a Linksys BESFR41, which in a pinch I can still use.
Huh. (Score:4, Insightful)
I seem to remember seeing SCADA vulnerabilities being added to vulnerability testing tools and IDS systems recently -- anyone know if this is related (ie: the tools now check for these non-existent flaws) or if the additions were to cover previously-reported bugs?
If the former, Siemens had best fix this damn fast. Infrastructure companies are in a corner - they don't have the cash for a major migration and alternative vendors are hardly thick on the ground. Some will be unable to afford decent security and others will be too politicized to secure their networks. Much of the infrastructure is too big and/or too expensive to duplicate, so the market is useless. The only place this can be fixed is at Siemens itself. The others that technically could won't and the rest can't.
The problem with the current paranoia over security is that you can't fix a fault you won't admit exists, companies won't deploy a fix if you tell them it's not needed, and so what you're ultimately left with is not security, merely obscurity.
Re: (Score:1)
ISS started adding SCADA checks to it's Proventia line and it's scanner right around the Stuxnet publications. But, it's hard to test or verify the information. So, they basically have to fake it. Which sucks, because often how they claim something works is not how it really works. And, the only way to verify a problem with a related-check is when a customer files a report. Which again, they'll probably only bother in the event of a false-positive (they won't even look further if it's a false-negative)
Re: (Score:3)
The solution given the reality of Siemens is to simply disconnect these SCADA systems from the internet. Why anyone would hook up industrial controls to the wider network. And yes I mean every single workstation that has access to the SCADA machinery should be disconnected from the broader internet. If that means people need two computers on their desk that's the solution. If that means you have to dispatch someone to the office to fix things, that's better than some hacker causing a massive failure by mis-
Re: (Score:1)
That works - right up until somebody hooks up a cross-over cable between two networks, or management says "It takes too long that way, just get it working, we'll fix it up when we get the budget."
You're absolutely correct that these systems shouldn't be on the Internet - shouldn't be reachable from the 'net, shouldn't even let workers plug in USB keys (or hard drives, or CDs, or ...). But unless and until there is criminal liability put in place for this sort of thing, it's just going to keep happening. Bas
Re: (Score:2)
Precisely, and trying to shape human nature through regulation is where you run into the politicized nature of these environments. Yes, these systems should never be connected to the Internet (even by indirect means such as sneaker net) and yes fixing the problem must take human nature into account, but it must do so cleverly because applying the fix also involves human nature. That's a tough one.
Re: (Score:2)
The easier fix would be to provide a nice machine with almost fully open access to the web and/or internet, and a good enough machine to keep control of the SCADA system, that way you have your system operators happy, alert all the time and without any need to break security procedures.
Um, no, that's a BAD idea (Score:5, Insightful)
The problem is not necessarily with Siemens. Industrial controls in general are not inherently meant to be accessible over large networks. They're designed to run reliably as they are, not with patches and updates. This applies to anything from Siemens/Fanux/Rexroth/Allen-Bradley/Mitsubishi to Cognex cameras to ABB/Fanuc/Kuka robots, or any little bastardized system in between.
Why not? Well, there is a ton of weird, unique software that runs on industrial controllers. They run some really embedded HMI (Human Machine Interface) software on top of, say, XP Embedded, or even NT4 or Win2k or some Linux flavor, or WinCE. If you start throwing out patches to those systems, there is a very very good probability that at some point, the system that you are updating will fail due to the update. Heck, Siemens updates regularly break its own software, much less Windows patches. If you try, and screw things up, you're forced to revert to some old dated backup or Ghost image stored in a filing cabinet on a CD-R or server if you're lucky. If you're not lucky, you call the vendor in to fix your broken system. Hopefully they are competent enough to have a backup from their last visit 6 years ago, and work from there, losing all your work in the meantime. So, you have machine downtime of hours, days, or even weeks if you're not lucky. How much does downtime cost? It depends on how many systems you took down, and the product. Conservatively, anywhere from $5,000 to $1,000,000 per hour.
What to do? You obviously can't push out patches. But, there is a lot of good that comes from monitoring machines, their productivity, uptime, faults, etc, remotely. By taking these systems off of an internal network, you also lose productivity in efficiency losses. So, you're forced to be the High Priest of IT and lock down a network like no other. No outside USB sticks, manufacturing firewalled off from the rest of the plant, and all kinds of restrictions that make users angry. It sucks, but it's possible. Unfortunately, small time manufacturers with their one part time learn-on-the-fly IT guy probably won't do it right. Perhaps this is where the DHS can come in to help, in the name of national security?
Re: (Score:2)
The problem is not necessarily with Siemens.
The problem lies squarely with Siemens. They made the choice to build systems with expected design lifetimes of more than 20 years on top of platforms that have a known support lifetime of less than that.
Their needs for OS services are not great. They could have developed their own operating system. They could have bought a small embedded operating system that they would then support in-house. They could have licensed an open source OS such as FreeBSD. They don't need a GUI. They don't need audio sup
Re: (Score:2)
> The problem lies squarely with Siemens.
> They don't need a GUI.
Actually both is wrong. They need a GUI, and the problem is with the customers. The customers chose Siemens over some other SCADA solution exactly because it runs on Windows. Siemens made this decision very early on (I think in the NT4.0 days), and from a business perspective it is more successful then they could have imagined.
Technically it was wrong, I agree there, but would you rather go bust with the right technology or prosper wi
Re:Um, no, that's a BAD idea (Score:4, Informative)
You are ignoring the essential role of HMI in SCADA systems. A SCADA can acquire data and coordinate components without a UI, but operators cannot monitor a plant or take corrective action without an HMI.
The HMI is graphical and allows the operator to override normal operation in order to respond to abnormal situations. It needs all the input and output devices a normal workstation requires.
You are also ignoring the issue of data storage by SCADA systems, and the generation of reports on that data which are used by various business departments in real-time. A Manufacturing Execution System may provide real-time reports for sales staff so that they can give customers accurate estimates of completion/delivery dates. Orders are added to a queue and will be automatically executed by the SCADA. Stores will receive low-stock notices for just-in-time ordering. Line stops exceeding 2 hours will result in automatic escalation to the COO.
This level of automation brings huge business benefits. The business is more responsive to customer needs, and there are fewer manual steps involved in completing an order (leading to fewer mistakes, less waste, fewer unsatisfied customers). The downside is that the business network is directly connected to the MES and the SCADA in a manner that allows at least some commands to be issued (as opposed to having read-only access to a database). An air-wall is not possible.
So now you have PCs on the business network able to interact with a MES which is necessarily able to access the network with the SCADA and HMI. And there's a 100% chance that the business PCs have e-mail access, which means that somewhere there is a physical cable to the outside world.
Yeah, because they have extensive expertise in OS development and oodles of cash to throw at the problem, and as we well know the available commercial and free embedded OSes never have bugs.
The problem is that the environment is not conducive to upgrades/patches and is hard to isolate logically. The economic reality is that for any given SCADA environment the risk* inherent in regular upgrades is larger than the risk of a malicious attack (for now).
* = (likelihood of event) x (cost of event), where cost includes recovery plus the direct and opportunity costs of downtime.
Re: (Score:2)
I saw HMIs back in the early 1980s that were built on dumb terminals, with colored line drawings on a 25x80 screen, and the menu represented by a series of function keys listed across the bottom of the screen. There's even an ancient serial terminal in the North Star Building's elevator lobby in Minneapolis that still displays a curses-drawn picture of the elevator system operating. These screens are certainly adequate to graphically represent the systems they are controlling in a very understandable mann
Re: (Score:2)
embedded operating system wouldn't have helped.. when network was never meant to be attached to public internet in the first place.
Re: (Score:2)
embedded operating system wouldn't have helped.. when network was never meant to be attached to public internet in the first place.
A custom embedded OS, one they could maintain themselves, would have helped tremendously in preserving the longevity of the investment. If the controllers back then had 8MB of RAM, they simply would not have added crap to their OS patches making them require machines larger than 8MB. They had full control of the hardware (they were building it, after all.) An embedded OS could have been maintained for many decades while remaining within the 8MB constraint of their oldest systems. Windows, on the other h
Re: (Score:2)
The problem is not necessarily with Siemens
Hackers certainly aren't to blame. Generally ranting here, but what I've seen make headlines is the 'hacker' (definintion in contention) equivalent of waking up one day and finding water all over your bathroom and realizing someone's been in there splashing water everywhere. Besides the overreaction to all it is, which is just annoying and expensive (time) is the overengineering to prevent it from happining again. Serious people seriously doing serious work seriously... we are the easiest marks. These kin
pr0f exploit a hoax? (Score:1)
I may misremember things, but wasn't the whole water-treatment plant 'hack' a legitimate worker logging in from his holiday in Russia, and some wannabe hacker claimed responsibility with fake screenshots?
Re: (Score:3, Informative)
That was a different water-treatment event; in fact, it's the one that prompted pr0f to pull his attack, because nobody was taking the security holes seriously: http://nakedsecurity.sophos.com/2011/11/22/interview-with-scada-hacker-pr0f-about-the-state-of-infrastructure-security/ [sophos.com]
Verticle markets (Score:2)
Re: (Score:1)
If I see another VB6 app out there I am going to, well, it's not pretty.
You is go horizontle?
Re: (Score:1)
The huge problem is that the CEOs and other management of industries do not understand, nor do they want to understand security. They want the SCADA systems to be online so HQ can check up on them without sending anyone out and without needing to contact any of the operators. They want to be able to audit certain parameters and such however don't want the added expense of running a physically airgapped network, they see the Internet as "convenient" and "cheap", the only things that matter to them.
This probl
Re: (Score:1)
Is it still lying if you don't know you're lying? (Score:3)
Re: (Score:2)
The OP claimed that Siemens lied about the security of their SIMATIC controllers, but don't you have to know you're lying in order to lie? Having dealt with Siemens over these things in the past (at one point we debated flying someone to Munich to club them repeatedly over the head until they realised there was a serious, showstopper flaw in their control system), it's quite probable that they genuinely believe that they're secure. We ended up using Allen-Bradley gear in the end, which also sucked, but not as much as the Siemens stuff.
That could be used as an explanation to escape just about any lie.. :)
I guess the point is, that if a security researcher sends you detailed information on vulnerabilities in your system, then either don't answer, or give a decent reply. If after 6 months the Siemens guy was not lying it means they are not very competent. It's not like this was a complicated issue...