Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Italian Hacker Publishes 0day SCADA Hacks

timothy posted more than 3 years ago | from the how-to-turn-on-the-hot-water dept.

Security 106

mask.of.sanity writes "An Italian security researcher, Luigi Auriemma, has disclosed a laundry list of unpatched vulnerabilities and detailed proof-of-concept exploits that allow hackers to completely compromise major industrial control systems. The attacks work against six SCADA systems, including one manufactured by U.S. giant Rockwell Automation. The researcher published step-by-step exploits that allowed attackers to execute full remote compromises and denial of service attacks. Auriemma appeared unrepentant for the disclosures in a post on his website."

Sorry! There are no comments related to the filter you selected.

first (-1)

Anonymous Coward | more than 3 years ago | (#37409300)

here

You cant blame him (0, Offtopic)

Chrisq (894406) | more than 3 years ago | (#37409312)

You cant blame him. If I were Italian I would be trying to find things that are crappier than the Italian economy too.

Re:You cant blame him (2, Insightful)

Anonymous Coward | more than 3 years ago | (#37409348)

Like the US economy?

Re:You cant blame him (0)

Anonymous Coward | more than 3 years ago | (#37409398)

Don't underestimate Italian economy...

Re:You cant blame him (0)

Anonymous Coward | more than 3 years ago | (#37410436)

Don't underestimate Italian economy...

I think you mean overestimate.

Re:You cant blame him (0)

Anonymous Coward | more than 3 years ago | (#37411322)

Did you mean overestimate?

Re:You cant blame him (1)

Alimony Pakhdan (1855364) | more than 3 years ago | (#37415836)

Slasheconomists upvote trollery again.

Re:You cant blame him (1)

ravenshrike (808508) | more than 3 years ago | (#37409408)

The italian justice system?

Re:You cant blame him (1)

Anonymous Coward | more than 3 years ago | (#37409452)

Italian government?

Re:You cant blame him (2)

Exitar (809068) | more than 3 years ago | (#37409740)

Silvio, is it you?

Re:You cant blame him (0)

Anonymous Coward | more than 3 years ago | (#37409424)

economy is not that bad, public debt is :-/

Re:You cant blame him (0)

gtall (79522) | more than 3 years ago | (#37409446)

Yeah, the Italian economy is circling the loo.

However, if someone were to be injured or killed because of this fellows actions, I think his reasoning is going to ring a bit hollow.

Re:You cant blame him (5, Insightful)

said213 (72685) | more than 3 years ago | (#37409520)

That it's 'in the open' just means that there is an urgency to correct these problems... problem being; that urgency existed prior to public disclosure.

Better to have this information publicly disclosed and subject to scrutiny than the previous system... which involved, apparently, obfuscating or ignoring vulnerabilities or gross incompetence of those responsible for detecting such vulnerabilities.

Re:You cant blame him (1)

Anonymous Coward | more than 3 years ago | (#37409484)

Italian economy isn't crappy, at least not much more than US economy in these days.

However, we've got a things or two which are actually very crappy:
1) Prime Minister
2) Government
3) Legal System
4) Infrastructures
5) Taxes ...
99)... ... ... ...

Re:You cant blame him (2)

doogledog (1758670) | more than 3 years ago | (#37409598)

99)... ... ... ...

I take it a bitch isn't one of those problems though?

Re:You cant blame him (0)

Anonymous Coward | more than 3 years ago | (#37410486)

I remember Clinton some years ago...

Re:You cant blame him (1)

Anonymous Coward | more than 3 years ago | (#37411082)

Yeah, the stupid idiot who almost had the US completely out of debt. What a fag.*

*That's fag in the pejorative sense, not the cigarette sense.

Re:You cant blame him (1)

ravenshrike (808508) | more than 3 years ago | (#37417046)

Hillary Clinton took a position in the Italian government?

Better (0)

Anonymous Coward | more than 3 years ago | (#37410048)

he (who doesn't appear sinister) does this rather than some asshat secret group to turn a 9/11 style drill into a compromise of security.
Bravo!!!

Isolated networks are A Good Thing (4, Insightful)

davidwr (791652) | more than 3 years ago | (#37409338)

Isolated networks are your friend.

It won't stop insider attacks or naive-person-inserts-poisoned-USB-attacks but it's a good first step.

As for naive employees: Train your people well.

Re:Isolated networks are A Good Thing (3, Informative)

UdoKeir (239957) | more than 3 years ago | (#37409362)

To be honest, an insider attack can just as easily be carried out with a large hammer.

Re:Isolated networks are A Good Thing (2)

buanzo (542591) | more than 3 years ago | (#37409432)

But it's too noisy DURING the attack :P

Re:Isolated networks are A Good Thing (1)

Exitar (809068) | more than 3 years ago | (#37409866)

Just use earplugs.

Re:Isolated networks are A Good Thing (1)

swordgeek (112599) | more than 3 years ago | (#37410062)

Nah. In most data centres, dismembering a server with a roofing hammer would barely be heard. In some data centres, it would probably be routine procedure.

Re:Isolated networks are A Good Thing (2)

geekoid (135745) | more than 3 years ago | (#37409468)

No really. I mean, you can smash their equipment, but that's hardly a big deal.

Controlling valves, system, dropping rods, shutting off dam, and so on are the big risks.

Re:Isolated networks are A Good Thing (2)

Bob the Super Hamste (1152367) | more than 3 years ago | (#37409838)

An insider would probably be able to mess with the system and control remote equipment, why smash some computers when you could melt a multi-million dollar generator, or break a large dam, blow up some high voltage transformers, etc... About the only way to deal with an insider is to make sure you hire good people and keep them happy. They do frequent background checks and some are quite detailed, get a background check to work on the system for the Israelis, have frequent trainings and other stuff. I probably get 2-3 background checks a year so that if I am needed I can work on various customer projects. I also do several security trainings each quarter, one for each company so I can continue to work on their systems. The insider is a huge thread and the systems I work on there has been a major push to limit access as much a possible. My company is starting to introduce some very fine grained user access to limit what one can do and see.

Re:Isolated networks are A Good Thing (3, Informative)

LoRdTAW (99712) | more than 3 years ago | (#37410232)

The Stuxnet worm proved that even isolated networks are vulnerable. Besides there is tons of valuable data and metrics on those networks that needs to make its way to plant managers who may or may not be onsite. That data also makes it way into reports that show plant efficiency and keep track of problems that pop up. Its difficult to isolate that data from the rest of the world.

We need to face facts that many automation protocols are severely dated and insecure. Has anyone ever heard of Modbus? Its an industrial communications protocol that was developed by Modicon in the late 70's and is STILL used today. Its 100% insecure and can be used to write to registers and "coils" on many PLC's/PAC's. Originally it ran over rs232/422/485 networks but today it has a modern TCP version called ModbusTCP. And that has no authentication built in. As long as you can talk to that PLC you can write to any of its registers. Other protocols are also wide open such as the massively popular Profibus/ProfiNET, and etherNet/IP (IP stands for industrial protocol).

There are dozens of automation controller manufactures out there. Many using these insecure protocols with no replacements in sight. Plus add to that that many end devices that communicate with these controllers are pretty simple in design, pressure gauges, temperature sensors, valve islands motion controllers, etc. are simple in design and implementing a security layer between them is not easy. Modbus is simply a send command to read a register or coil and a simple response. The only other setup is usually setting an 8 bit device address that is accomplished via a set of rotary or dip switches.

Until someone that is big in the industry (Schneider/Modicon, Allen Bradley, Siemens or Rockwell) comes out with a secure protocol that is simple, reliable and open to anyone to implement, there wont be any change. The only security is to isolate networks and pray no one infects computers inside the control network.

Re:Isolated networks are A Good Thing (1)

AB3A (192265) | more than 3 years ago | (#37411230)

There are dozens of automation controller manufactures out there. Many using these insecure protocols with no replacements in sight.

I would like to point out that there ARE some efforts to secure the non-deterministic SCADA side of things. Secure authentication is available for the DNP (IEEE-1815) protocol. At the present they must be pre-shared symmetric keys and there is no way to change those keys over the protocol; though that feature has been written and is undergoing review. The secure authentication specification is described in IEC 62351. Other protocols such as IEC 60870, and UCA2 (61850) are working on similar authentication features.

As for PLC/PAC protocols, they were designed for real time millisecond by millisecond timing. Authenticating would at least double the number of network transactions required to pass traffic and validate it. Some slower applications may be able to handle such speed penalties, but many can not. Remember that these protocols were designed to use the IP transport layer because the test equipment, network hardware, and software is widely available, cheap, and well understood. Unfortunately too many small minded idiots put it on the internet for the bragging rights of showing how one can program the plant floor controller from a tiki bar on the other side of the earth.

Regardless of what the marketeer crowd may have said in the past, it makes no sense to expose a deterministic real time network to any node that doesn't play nice. You don't have to do anything special to bring down such networks. If the traffic level gets too extreme, the controllers will fault. This is by design. They are supposed to make calculations every so many milliseconds and flush the results back to the field within a very short, limited time window. If they can't do that, they must stop working and the I/O should assume a safe state.

So yes, it's not hard to make a mess of one of these networks. That's why those networks must be carefully defended and kept to a very limited scope. Building authentication in to such networks is not nearly as effective at keeping hackers at bay as conventional wisdom would have you believe.

Re:Isolated networks are A Good Thing (1)

LoRdTAW (99712) | more than 3 years ago | (#37411960)

I should have pointed out the real-time nature of these protocols as well. And its a good point that security will increase response time. That is unacceptable.

But again, getting plant floor data from the control systems to reporting/database software is something that everyone wants to access from anywhere in the world. As long as internet facing computers are hooked to control/SCADA systems gathering such data for reporting means there is a bridge to the control network.

I am working on an automation system that controls three vacuum chambers. The boss wants to see pump down reports from his home in Connecticut when the shop in in Long Island, NY. Something has to bridge the gap. You cant easily get away with complete isolation.

Re:Isolated networks are A Good Thing (1)

ttong (2459466) | more than 3 years ago | (#37413094)

You aggregate the required statistics on a box inside the SCADA network and use a one way ethernet cable [dgonzalez.net] to send the data in a defined format at regular intervals to a server which generates the reports. You then let this server rsync the files to your fileserver or whatever and there you go. It's physically impossible to hack your way across a unidirectional link. Of course, no one should come anywhere near the SCADA systems with a storage medium such as a USB flash drive. IIRC this is what allowed Stuxnet to cross the air gap.

Re:Isolated networks are A Good Thing (0)

Anonymous Coward | more than 3 years ago | (#37413268)

People like your manager are the ones that put these systems into peril by hooking them up to an internet connection. Industrial networks were originally physically isolated because of their medium, RS232/485, ProfiBus/Devicenet, etc. The switch to Ethernet based systems was to reduce overhead of installation of distributed communications because cat5 is cheaper to procure than company specified cabling, often more physically robust, and allowed different network topologies. They were, and still are, intended to be isolated networks completely removed from anything else because of the timings, device addresses, and network tweaks required to get a sophisticated process running. The scary part is people are starting to use 802.11 b/g/n in their networks because it further reduces cabling costs.

If your boss really wants his data why don't you get him to buy a GSM modem. Write a script to power that sucker up, SSH into a secure server, send your data to this predetermined location, then turn it off. Physically wire a relay to the power supply if you have to.

Re:Isolated networks are A Good Thing (1)

tzanger (1575) | more than 3 years ago | (#37415436)

I spent 15 years in industrial power, working with the exact communications and control networks you complain about. I know what you're talking about and sympathize to a large extent.

Your boss' request, however, does not compromize security. There is nothing insecure about providing read-only access to the network. A secure device sitting on the industrial network could export/expose the system status through a variety of means, none of which would accept requests to alter the system state. At a very extreme case, a unidirectional optical link could stream system state from the critical side of the device to the noncritical one, and the insecure side could then pick out what it wants to report on. There's enough bandwidth available in gigabit ethernet and the filtering problem is largely solved already (and has been for well over a decade with CAN), which is where DeviceNet and Ethernet/IP get their roots from.

It'd be an uphill battle, but I'd like to design a PLC module that works exactly this way. I miss the industrial work. :-)

Re:Isolated networks are A Good Thing (1)

sjames (1099) | more than 3 years ago | (#37416268)

Control net facing machine receives updates, forwards them over rs232 to an internet facing machine. Cut the Tx on the public net machine so it cannot in any way signal back to the secured machine even if it is compromised.

Re:Isolated networks are A Good Thing (1)

StikyPad (445176) | more than 3 years ago | (#37412914)

The Stuxnet worm proved that even isolated networks are vulnerable.

To be fair, it only demonstrated that a single piece of software could exploit multiple attack vectors. As to what networks were infected and how isolated they were, that's mostly speculation.

Re:Isolated networks are A Good Thing (1)

Anonymous Coward | more than 3 years ago | (#37410276)

I think the government are asshats, but one logical reason for remote control of SCADA (i.e. if the government deliberately had the exploits - conceivable) would be in the hypothetical scenario that China or some other 'adversary' were to take control of a nuclear plant and use it to power deployed weapons and craft, or try to make it a nuclear disaster site to weaken morale or wreck infrastructure and capability etc. OR, maybe the government just didn't know, OR maybe they planned to use said exploits themselves in a 9/11 style red flag attack on their own people.

Why not isolate the networks? (2)

kyouteki (835576) | more than 3 years ago | (#37409342)

I used to work at a foundry that had a Rockwell SCADA system. It operated on a completely physically separate network from the normal, internet-facing corporate network. If somebody needed access to both the SCADA system and their email, they had two computers on their desk. For something not as critical as say, a utility, I think this was a bit of overkill (at least they could have used VLANs), but why is this not a semi-common practice? Why do these controls need to be on a network with a route to the internet?

Re:Why not isolate the networks? (1)

headhot (137860) | more than 3 years ago | (#37409536)

Crack the router with the VLANS and you have both networks. If its something someones life depends on, physically isolate the networks.

Re:Why not isolate the networks? (1)

inasity_rules (1110095) | more than 3 years ago | (#37409696)

And now you're running 15 plants country wide and head office wants all the data on your shiny new SCADA system centrally available (for no other reason than they like to pretend they know what they're doing), so you're forced to run a VLAN. The problems here are mostly social, not technical.

Re:Why not isolate the networks? (0)

Anonymous Coward | more than 3 years ago | (#37410112)

If you *need* something to just come out, do precisely that. Take one cable, snip out the return pair to make it single directional, then spew the data you require via UDP. Jobs a good un.

Data diodes. (1)

Anonymous Coward | more than 3 years ago | (#37410492)

They want the data? Display it on a screen and point a webcam at it. Data diode.

Complexity can be added as needed (eg an intermediate system that stores all the data and can run queries on it -- but still can't send anything back to the SCADA system), but there needs to be the equivalent of an air gap across which information only flows one way.

Re:Why not isolate the networks? (1)

geekoid (135745) | more than 3 years ago | (#37409550)

Separate systems have been how all the SCADA system I have seen are set up.

Re:Why not isolate the networks? (2)

rubycodez (864176) | more than 3 years ago | (#37409692)

not me, since early 90s there was *always* some guy with card in his pc hooked to SCADA net also NIC to corporate LAN. Maybe you should look at each and every box that touches your imagined "secure" systems to make sure.

Re:Why not isolate the networks? (1)

Hijacked Public (999535) | more than 3 years ago | (#37409750)

I've been in hundreds of plants all over the world, in a wide variety of industries, and I would estimate maybe 25% have had an air gap. Maybe half had a bridge PC or a router.

This includes a lot of old facilities, that were controlled with pre-ethernet PLCs. In most of those place the PLC network had some separate segments (running Modbus or Devicenet of something), but there was usually an ethernet PLC somewhere plugged into the same network as everything else.

Re:Why not isolate the networks? (2)

mabhatter654 (561290) | more than 3 years ago | (#37409554)

Of course that was because of SOX. The design of most SCADA networks is so bad just about any normal computer security beraks them.. Especially when multiple vendors are involved. SOX auditors made everybody kick SCADA off the business network... Which has the side effect in most shops of keeping it off the Internet as well.. Or limited to point-to-point networking (dial up)

Re:Why not isolate the networks? (1)

rubycodez (864176) | more than 3 years ago | (#37409726)

how is dial-up with password any more secure than being on vpn or vlan? caller id is trivial to spoof, and once the bad guys social engineer your password or know a maintenance password from vendor,......

Re:Why not isolate the networks? (0)

Anonymous Coward | more than 3 years ago | (#37409876)

You enter your username and password and the system calls *you* back - to a predefined phone number. To spoof you'd have to be at that end user's location to intercept the phone call.

Re:Why not isolate the networks? (1)

rubycodez (864176) | more than 3 years ago | (#37410024)

sorry, but the callback model has been cracked. You spoof the callback modem into thinking the line was hung up and then intercept.

Re:Why not isolate the networks? (1)

rubycodez (864176) | more than 3 years ago | (#37410090)

there is another crack that puts call forwarding on the authorized line if one knows that number. those two cracks I mentioned have been well known for over a decade

Re:Why not isolate the networks? (1)

Lumpy (12016) | more than 3 years ago | (#37409884)

using real modems.
  Site 1 calls in and logs on.
  main site drops the connection and uses the credentials to call back to site 1 on the Stored phone number.
Hell I had a us robotics modem from 1989 that did this it's called ringback security and is highly effective. it kept a lot of fellow hacker friends out of my stuff. I even dared them to crack it.

Today a dial up system is stupid. Private T1 line connection from point to point is the cheap answer ($79.00 a month today not crossing state lines) as no hacker can hack a private point to Point T1 connection unless he breaks into a CO or tie point and knows what he is looking for.

Re:Why not isolate the networks? (1)

rubycodez (864176) | more than 3 years ago | (#37410058)

nope, broken for U.S. robotics and the other common "security" modems - you spoof the modem into thinking a hangup has occurred, stay on the line and party on from there. There is another hack where you put call forwarding onto the authorized person's line. Look in any modern WAN security text, callback modems are now thumbs down.

Re:Why not isolate the networks? (1)

Lumpy (12016) | more than 3 years ago | (#37410266)

My USR modem would hang up for 30 seconds (It's a setting) and this would clear the line even if the other side did not hang up.

I did live in a broken exchange though that did not clear the line if both sides did not hang up. but that was years ago. Telephone spec calls to clear the line if the ON hook is pressed for 5 seconds or more.

Incorrectly configured modems that hang up and instantly dial back can be spoofed this way.

Re:Why not isolate the networks? (1)

MikeBabcock (65886) | more than 3 years ago | (#37410484)

You're assuming the person doesn't know how to fool the switching equipment into staying connected.

There's a lot of old phreaking tricks that aren't so common now, but with computerized switching equipment, anything's possible.

Re:Why not isolate the networks? (1)

niteshifter (1252200) | more than 3 years ago | (#37412022)

Alas, those old phreaking tricks won't work anymore in places that have moved away from the legacy in-band signaling and control hardware. Which is pretty much all of the civilized world since the early '90's for the PSTN. One could I suppose get lucky with a local PBX - but the attack still requires obtaining access to the PBX controller / software, not just access to modem's phone line.

Re:Why not isolate the networks? (0)

Anonymous Coward | more than 3 years ago | (#37409576)

Why do these controls need to be on a network with a route to the internet?

Because some lazy/stupid guy in a management position wants to see things from home and (don't know)/(too stupid to use) a vpn.

Re:Why not isolate the networks? (0)

Anonymous Coward | more than 3 years ago | (#37409640)

Because some lazy/stupid guy in a management position wants to see things from home and (don't know)/(too stupid to use) a vpn.

Yea, because if he knew how to use a VPN, he'd be able to connect remotely to a server that has no connection to the internet....

Re:Why not isolate the networks? (1)

Bob the Super Hamste (1152367) | more than 3 years ago | (#37409748)

Mostly it is a cost thing, there are the system admins and the system owners/users. The admins would much prefer to have the systems isolated and air gaped the problem is that the management and users don't care since that costs more money since now they are buying multiple machines for each user, also it is less convenient for each user since they are going between 2 machines. Another benefit of having them have a path to the internet is that it allows remote support. Congrats on your former company for doing the right thing. Also I wouldn't call a utility less critical as a SCADA system at a power company controls a whole host of things probably the least dangerous of which would be high voltage breakers, add into that generation controls, dam controls, phase controls and other thing I don't know about and someone with malicious intent could cause sever damage that would take at least a few months to repair. I actually work in the security area at my company which makes SCADA systems and managements poor idea of having a path to the internet sure makes a lot of work for me.

Re:Why not isolate the networks? (1)

Hijacked Public (999535) | more than 3 years ago | (#37409812)

More often than not I have found the justification for connecting the control and office networks to be the "DA" part of SCADA. Management wants control side data in reports and it is much more cost effective and timely to automate that than to have someone physically enter it on another network.

Most of the SCADA outfits sell software to do exactly that, the "data historian" type applications. Invensys sells modules to deliver data directly from control networks to both their office side products (Avantis, etc) and to SAP.

Re:Why not isolate the networks? (1)

Bob the Super Hamste (1152367) | more than 3 years ago | (#37409940)

Again it is convenience and money those were my points. Unfortunately I haven't seen a system setup where the bridge between the SCADA network and the corporate network is through the historian that has been fully secured and firewalled on either side to limit any access.

Re:Why not isolate the networks? (1)

Pinky's Brain (1158667) | more than 3 years ago | (#37412426)

As someone said above, making an unidirectional UDP connection is quite trivial.

Re:Why not isolate the networks? (1)

Leaf Node (692630) | more than 3 years ago | (#37410192)

It is common practice. It is done in various ways though. Sometimes they're physically separate networks, sometimes via routers and VLANs. Only the smallest plants have a single network where you can reach the internet from the PLC network. Usually this is fixed as soon as the company is big enough to build a decent network infrastructure. At the big manufacturing companies I've done work for: 3M, Johnson & Johnson, Anheiser Busch, Ely Lilly, Pepsico, Bayer-- all these companies have huge network infrastructure and policies that keep PLCs physically isolated. There is no way that the exploits here could be useful against them. Even smaller companies such as Bacardi or BASF have these same policies in place. You'd have to target someone really small and vulnerable. A company big enough to be using a SCADA system, but not big enough yet to incorporate a decent network infrastructure to protect itself. I've seen those companies too, but none of their names you would recognize because they are too small. Yes they are vulnerable. Pick any small town with a population under ~30,000 and you'd probable find an automated water plant or two you could infect. Big deal.

Re:Why not isolate the networks? (1)

thegarbz (1787294) | more than 3 years ago | (#37415332)

*Most* larger plants run by *Most* larger companies are actually quite capable of such a thing. What you are suggesting isn't uncommon at all. Pretty much every plant I have worked at bar one had either isolated networks (a horrendous pain in the arse), or a VLAN arrangement with routers and firewalls, the most common end point being a one way trip out of the control system onto some other network in a DMZ style arrangement (a very workable solution).

The problem ultimately is cost. The critical installations that aren't protected like this will be small plants with simple PLCs / SCADA systems, and small low budget utility providers. I once visited a simple Bitumen Blowing / Loading plant run by the current number 2 oil company. The I/O was small, the control interface consisted of about 5 screens, and any geek could have wired that up into a simple PLC in a week. But no, they had a 3 tiered network structure with a DCS controlling the plant. They had more computers / routers in this tiny little plant than they had people running it.

It's all about budget.

UGG how to identify true and false? (-1)

Anonymous Coward | more than 3 years ago | (#37409358)

        1 from the price. cheap ugg [uggsalecheap.net] expensive because the raw material is produced in Australia as a whole lambskin, fur one, sole also has a special structure, even if the ex-factory price by the UGG production plant does not end at three hundred, which is called upon to mm must remember that those "make you the price" to buy back the is absolutely fake.
        2 from the color terms. Genuine uggs boots outlet [uggsalecheap.net] , color is very positive, UGG colors prevail on the official website And the plush interior and the outside color of the color is the same.
3 From the point of shoes. Touch the cheap ugg boots online [uggsalecheap.net] is quite soft and delicate, fine shoes, also more delicate. Very neatly inside the plush, length of uniform density, very soft feel comfortable, very comfortable light wearing.

Its not that hard! (4, Insightful)

inasity_rules (1110095) | more than 3 years ago | (#37409382)

Most SCADA's are still bound to COM. Easiest way to get DCOM working; disable *ALL* security. When you're commissioning a site, and the hardware is being finicky, the last thing you want to do is spend 9 hours debugging some obscure DCOM glitch specific to server 2003 service pack 1 (the only system some of this stuff runs on), so it isn't hard to see why most people have zero security.

Bring on the days of OPC UA, which makes security possible without having a hernia!

Re:Its not that hard! (0)

Anonymous Coward | more than 3 years ago | (#37409674)

But OPC UA makes all the legacy code obsolete. Are you suggesting that they have to start from scratch? No matter that the new protocol is supported for any OS, like linux, qnx, wince, windows, etc, without the stupid COM/DCOM dependency.
So, again, is the dinosaur able to evolve to a human beings?

Re:Its not that hard! (1)

gnalre (323830) | more than 3 years ago | (#37409732)

You can run OPC-UA over DCOM so you don'y have to throw away your legacy code. You can then evolve your system later

But I too will be so glad when I don't have to run a system over DCOM

Re:Its not that hard! (0)

Anonymous Coward | more than 3 years ago | (#37409844)

I agree, but again your old OPC code will be useless, simply because the newer standard does not require COM/DCOM, which means Windows API, which means all the thread management, locks, libraries, etc.... And if you want your new code to support the both standards, you have to either give up all this neat windows libraries (which is the main point of this new protocol), or give up linux,qnx,RTOS support (which makes this exercise useless).

Re:Its not that hard! (1)

inasity_rules (1110095) | more than 3 years ago | (#37409938)

Practically speaking, I honestly don't see much of the industry moving off windows. Sure it is technically better, but try persuading management.

UA, however will give you added security on windows, which is at least a start.

Re:Its not that hard! (0)

Anonymous Coward | more than 3 years ago | (#37410110)

Yep, it is almost impossible for some big company to move/evolve to the newer and better protocol. But in a smaller company, once you show them the benefits of using cheaper hardware (because of linux) with better security, and better source code structure (yes, it is important for some managers), then the decision would be obvious. Also there is carrot effect, the first ones to implement the OPC UA, will be more competitive, translated happier share-holders, and management, and one could hope, even developers....

Re:Its not that hard! (1)

inasity_rules (1110095) | more than 3 years ago | (#37410258)

I can vouch for the happier developers part... But lets be practical here, name a UA toolkit for Linux? Oh, and because most of industry is still on legacy OPC, it must support publishing via DCOM. You can't alienate 90% of your clients because you are an early adopter. I would be very seriously interested in seeing such a toolkit.

Re:Its not that hard! (0)

Anonymous Coward | more than 3 years ago | (#37410422)

http://www.unified-automation.com/opc-ua-development

You will need a registration, it is free of course, and the evaluation version is free too (but only for internal development).
And theoretically, this toolkit could work under WinCE too, if you insist......
And there is one more thing, they are providing some "bridge" application, able to link your new OPC UA application with the older COM/DCOM based protocol.

Re:Its not that hard! (1)

inasity_rules (1110095) | more than 3 years ago | (#37417672)

I will have a a look, but my company is not a member of the OPC foundation, so the source code option is out for us. Hopefully in the future we can move to this, but the clients right now demand a windows solution.

Re:Its not that hard! (1)

inasity_rules (1110095) | more than 3 years ago | (#37409752)

The company I work for is doing exactly that. Our new OPC server will support both. It is hoped that the monstrosity that is DCOM will eventually go the way of the dinosaur. We chose an OPC toolkit specifically because they had UA support (and possibly in the future WPF).

Re:Its not that hard! (3, Interesting)

hjf (703092) | more than 3 years ago | (#37409720)

2003 SP1? HA! I've seen stuff running on Win98, because the electric engineers in charge are out of their league when it comes to computers, and win98 "just works"

I took some PLC introduction course in 2006 or 2007 and the guy was bitching about linux, because linux doesn't have support. And he liked linux because it's stable, but manufacturers only support Windows, and the only way to be SURE that your software is going to work AND last for many years, is to use a not-so-new computer. I'm glad that guy only does small things like cooling control and wood drying facilities.

But at least he got one thing right: All the control LOGIC has to be in the PLCs. The SCADA is for a nice GUI and logging ONLY. You should add enough buttons, switches and lights to make the system fully usable even if all the SCADA computers are down. And that doesn't mean "manual override", which is something else you should have too.

I doubt there are applications where a SCADA system should be making decisions.

Re:Its not that hard! (2)

inasity_rules (1110095) | more than 3 years ago | (#37410130)

Actually, support at rockwell, will specify your windows version and service pack. Otherwise the software does not run. It isn't always a matter of incompetence on the engineer's side, but sometimes the vendor shoves stuff down your throat. And its all well and good to only work with vendors with decent support and security, but practically if you are a SI, your clients often specify what hardware and software you use. And the most secure systems sometimes lack functionality. We tend to select the latest software the vendor will support as much as we can, but that still leaves us running a lot of Server 2003 PCs.

Though most of the software I've seen in the field is minimum Windows 2000, Toshiba's PLC software looks like it was written for windows 3.10.

Re:Its not that hard! (1)

thegarbz (1787294) | more than 3 years ago | (#37415498)

2003 SP1? HA! I've seen stuff running on Win98, because the electric engineers in charge are out of their league when it comes to computers, and win98 "just works"

You have a horrendously over simplified view of the industry or happen to have seen some few isolated cases. No the reason so much stuff runs on Windows 98 is not because it just works and the engineer doesn't know how to use a computer. Quite the opposite. In many cases trying to keep old computers running is harder than switching to the new ones, but the cost is non-trivial.

We have emergency shutdown systems who's major interface run on Windows 98. Not because a new computer is too hard or a windows license is too expensive. No it's because the system itself is certified to use only that version of software and that software only runs on Windows 98. The entire thing is obsolete and due to be replaced. Cost estimates have been around $150k and needs to wait for the next full plant shutdown in 2016. This is unfortunately situation normal in the industry.

Other classics include SCADA systems which could simply be upgraded to a new version of software which is 100% backwards compatible. I've also seen a tiny little system like this. When we investigated upgrading the software the vendor's cost for the upgrade actually pushed us over the edge. It took us a few years but we replaced the entire system with something else. Then there's hardware dongles that only work on older computers, proprietary cards that have ISA interfaces and no Windows XP drivers, or my personal favorite, the vendor was bought out by someone else who EOLed their system 10 years earlier than expected.

Most often you do not have the choice as to what OS you run. The bigger the system, the more restrictions you have. I mean shit we have one NT4 system on site for which the vendor won't even give us the Admin password and you so much as hit the wrong key on the keyboard you're in breach of a license.

Re:Its not that hard! (1)

Trogre (513942) | more than 3 years ago | (#37415994)

Luxury. Some process-control systems are still running Windows 3.x

Re:Its not that hard! (1)

chmodman (565242) | more than 3 years ago | (#37416684)

Actually there are PLC's that have built in web-servers these days so you don't have to rely on a windows machine for visualizations anymore either. While the development is done in Windows (although it can run on WINE), the PLC is an embedded ARM device running Linux. Here is a video video [youtu.be] showing how to program one if your interested.

Re:Its not that hard! (1)

Anonymous Coward | more than 3 years ago | (#37409738)

exactly. i have to agree by 100%. i work winthin the branch. its just like you said. but most likely you DONT HAVE TO hack into something...factory default passwords in controllers and embedded systems are (at least in building IT) more common then (even weak) custom logins. if you make it to reach a controllers (web) interface, chance is good you just access it by default password.

DUH.... (2)

Lumpy (12016) | more than 3 years ago | (#37409670)

If your SCADA system is on an unprotected and ISOLATED network then you deserve the hack.
Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators. there is NO reason to allow any access except from the keyboard and mouse. anyone WORKING on the systems, IE the programmers and engineers should be using sanitized laptops that are ONLY USED for that purpose.

I was doing this in 1996 when I was doing SCADA systems using the craptastic WonderWare and AB systems.

Re:DUH.... (1)

snookiex (1814614) | more than 3 years ago | (#37409846)

Kick managers in the nuts

He he. OK, I will *sighs*

It's not 1996 any more (1)

WebCowboy (196209) | more than 3 years ago | (#37414718)

Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators.

Turds run downhill--that middle-manager probably has directives from his boss...or perhaps the government or regulatory body...to obtain data from the SCADA system and so in turn has requested access so he can provide that data.

I don't get much call for remote access to the HMI (operator interface) itself in my projects--but it is my primary purpose in these jobs to provide remote access to these systems for access to alarming/annunciating as well as process historian data. On-call operations personnel "need" to have SMS notification on critical alarms/events. Regulatory bodies need reports for everything from custody transfer to environmental contamination data. It is IMPOSSIBLE to keep a SCADA system truly isolated from all public networks anymore. To be legally compliant much less competitive requires data from SCADA systems to be available off-site. Even with 100% physical separation you'd be shuffling USB drives around which would be just as vulnerable, or using other physical media (DVD-R's etc) but that is not an acceptable solution due to volumes of data and the requirements for timely data (up to near real time in some cases)

Ideally, it would be GREAT if we could play in our own little sandbox but technology moves on and outsude forces beyond our control demand we leverage that technology to boost production, increase efficiency, make the workplace safer and reduce environmental damage-those demands cannot be meant without connectivity in any way at all. So instead of fighting it we MUST address security PROPERLY--not just including perimiter security. That includes not just patching SCADA software but implementing proper system architectures as well as enforcing policies and procedures. Some stuff I rarely see done but should always be done these days include:

* enforce complete ban on shared logins--no more of this "user operator password Operator1" crap.
* In windows platform systems make it a policy to elimiate "workgroups" and implement proper domains with group-policy enforced security
* disable all removable media access for all but a very few
* NEVER put real-time (PLC's/PAC's/controllers) and supervisory (HMI, historian data logging, etc) on the same network!
* make security audits and software patches or upgrades part of the maintenance/turnaround schedule with all other equipment--and insist to vendors (with threat of rip and replace) that support for current OSes and sane security policies are a requirement for your business.

Using Windows in ana automation system might be flawed, security might not be built into real-time netowrks, and SCADA software may be full of bugs, but the most immediate threat is how far behind the times automation systems are in implementing security measures compared to business/general IT.

Re:It's not 1996 any more (1)

thegarbz (1787294) | more than 3 years ago | (#37415536)

* NEVER put real-time (PLC's/PAC's/controllers) and supervisory (HMI, historian data logging, etc) on the same network!

This here is really one of the keys. Network segregation is your friend. The network design is as important as the logic in these systems. The "airgap and be done with it" crowd do not seem to understand this!

Re:DUH.... (1)

thegarbz (1787294) | more than 3 years ago | (#37415520)

If your SCADA system is on an unprotected and ISOLATED network then you deserve the hack.
Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators. there is NO reason to allow any access except from the keyboard and mouse. anyone WORKING on the systems, IE the programmers and engineers should be using sanitized laptops that are ONLY USED for that purpose.

I was doing this in 1996 when I was doing SCADA systems using the craptastic WonderWare and AB systems.

We have a WonderWare based system on our plant. I can understand why you're so bitter and twisted :-)

But on the topic of managers, they aren't the problem. In engineering everything is possible and you can only question the implementation. It's really trivial to design a system that allows complete remote view / remote access without compromising the core integrity of your control system. It really comes down to competence, and like mindedness. If management tells you to do it on the cheap and your compromise security to do it like that then you're part of the problem. If you provide them a cost estimate of doing it right chances are they will outright reject the idea because they don't understand the engineering of it enough to know how to skimp on security.

Common Thread (1, Interesting)

Anonymous Coward | more than 3 years ago | (#37409708)

Windows is the COmmon thread to all the threats. STUX was a windows exploit. When can folks get it through their head that Windows belongs on the bosses desk running excell and project and NOT on the factory floor running production.

Luigi Auriemma is my hereo (2)

WaffleMonster (969671) | more than 3 years ago | (#37409804)

It would not surprise me if he ends up finding more vulnerabilities than the rest of the world combined and he does it exclusivly for fun/challenge.

"Responsible" disclosure does tend to mitigate problems in the real world much like a virus scanner installed on a random desktop.

However neither approach provides the proper incentives to the market to address the root cause of the design/process deficiency which allowed the defect to occur. Responsible disclosure actually artifically lowers the cost the industry has to pay for a security failure only while it is found by someone who is deemed to be "responsible". This makes all software less safe in the long run.

Programming suite != PLC (1)

squish18 (758259) | more than 3 years ago | (#37409924)

By the look of the Rockwell exploit, [altervista.org] it only impacts the PC-based programming suite, rslogix. The worst of it would seem to be that you could aggravate a programmer trying to setup a system and NOT remotely take over and reconfigure a PLC system.

Then again, if your PLC network routes publicly, you deserve to be aggravated.

Re:Programming suite != PLC (1)

edbob (960004) | more than 3 years ago | (#37410702)

I agree, although I have been unable to determine what the two .dat files are for. I think that Rockwell is on the right track as far as securing the data tables in the PLC is concerned. They just need to come up with a way for one to define which devices can change tag values (and exclude all others). Since v18, it has been possible to deny access to a tag by defining its "external access". It's really all a matter of scale. A piece of simple equipment that sits off in the corner of the plant is unlikely to ever be connected to the internet and therefore doesn't need the level of security that one would use on a PLC that is controlling an entire plant process. The equipment that my company manufactures uses PLCs and operator interfaces from Rockwell. I recommend to customers that they NOT connect these to the internet or phone line unless there is a problem where we need to make a remote change to the logic and once we are completed I tell them to unplug. SCADA software is a steaming pile that is going to take a massive rethink to fix. IDEs are buggy and inconsistent. (Is it a "screen", "display", or "graphic"? -- I don't care what you want to call it, just call it the same thing throughout the IDE!) I have seen these packages eat up 70% of CPU usage even when they are supposedly idle. I wouldn't be surprised to find out that they are just checking to make sure that the license is valid every millisecond.

Rockwell (0)

Anonymous Coward | more than 3 years ago | (#37410036)

The Rockwell exploit is for the programming software, RSLogix5000, which is the equivalent to an IDE. Very unlikely open and running on a computer that is mission critical. This is only for changes and initial commissioning of the system, not a SCADA system.

I sure hope my retro encabulator is safe (1)

jp102235 (923963) | more than 3 years ago | (#37410284)

Rockwell better make sure my retro encabulator [youtube.com] is secure from those hackers!
If someone got access to the modial interaction of magneto reluctance and capacitive duractance, we could all be in a world of hurt.

Re:I sure hope my retro encabulator is safe (0)

Anonymous Coward | more than 3 years ago | (#37416456)

I've always thought that the basic mechanism of the reciprocating dingle arm was vulnerable to exploit.

This guy is an outlier (0)

Anonymous Coward | more than 3 years ago | (#37411796)

I knew this guy years ago for his published exploits for different Quake3-based servers. I was amazed at the level of detail and wide spectrum of exploits/tools for those games. It was really helpful and allowed server admins to patch the vulnerabilities.

Now it seems his real job is in the industry. Good to know, the industry will be safer with him around, as everything else.

Luigi (0)

Anonymous Coward | more than 3 years ago | (#37411914)

Mr. Auriemma has been discovering security vulnerabilities and publishing them on the major security website like Secunia etc...
he has been doing a great job and we have been patching promptly after his discoveries.

This is just one of them, just b/c it's gov stuff, he doesn't need bashing!

Blocked by company Internet policy (0)

Anonymous Coward | more than 3 years ago | (#37414402)

I work in an industrial environment, doing PLC/SCADA automation systems. The company appears to have blocked access to this website, so here's hoping we don't use any of those systems ;-)

2011 and we still have the same idiot programming (2)

Old Wolf (56093) | more than 3 years ago | (#37414474)

I checked over a few of his bug reports, and was bemused to see the same old rubbish

"mplayer" - calloc() called with a 32-bit integer multiply
"id Tech 4 engine" - memcpy(_,_, size - 6) , where 'size' is the size of a received packet and can be 5 bytes
"Unreal server" - crash the server by sending an unexpected packet (the code does an assert() instead of just dropping the packet or whatever)
"winamp" - craft a video with large dimensions, winamp does signed 16bit multiply of video height*width

I guess the mplayer one can be explained by free software people not having proper programming training, but iD etc. , you would think that they would hire programmers who think about the possible contents of the variables each time they write an arithmetic operation, especially when it's known that the value of the variable is read from a file or socket and could be anything.

It really is not difficult to check that size >= 6 (and then that size - 6 buffer_size) before writing "size - 6" in a memcpy.

I never understood assert() either, just seems like a recipe for disaster in production; it's not difficult to test conditions and invoke actual error handling and recovery

Re:2011 and we still have the same idiot programmi (1)

orzetto (545509) | more than 3 years ago | (#37415200)

I never understood assert() either, just seems like a recipe for disaster in production; it's not difficult to test conditions and invoke actual error handling and recovery

assert() is very useful if used properly. It is supposed to be a debug support tool, crashing the program the moment something happens that cannot possibly be right, e.g. a function being called with an array with the wrong number of elements. This way, when the program crashes, you have immediately an idea of what went wrong, and must not dig as long into the code. This is different from exceptions or other error handling because the latter can legitimately happen in operation, while assertions indicate conditions that cannot happen if the program is not buggy.

If you are correct about the Unreal server, it seems clear they used an assert() where an exception was due, since the program is not broken only because it is fed bad data.

Re:2011 and we still have the same idiot programmi (0)

Anonymous Coward | more than 3 years ago | (#37417634)

I guess the mplayer one can be explained by free software people not having proper programming training, but iD etc. , you would think that they would hire programmers who think about the possible contents of the variables each time they write an arithmetic operation, especially when it's known that the value of the variable is read from a file or socket and could be anything.

Clearly, you have never seen the craptastic bug ridden code that Carmack creates.

Take Doom1&2 sources: At first, he is elegant and modular and clean. Then, in the effort of getting shit done he will becomes sloppy and hackish.
When faced with a deadline and a performance issue he invents REJECT table -- an O( n^ ) complexity system which does not scale well at all X sectors creates X*X REJECT entries, this feature, bolted on basically in Beta...

It stands to reason that if even the lead programmer makes mistakes, his subordinates will do so as well.

We're all human, even if you choose to worship some.

unrepentant (1)

Tom (822) | more than 3 years ago | (#37414556)

Of course he is.

We've had the "responsible disclosure" discussion, and although some of you may disagree, I'm not the only one who thinks it was a bust. Looke a lot like lazy companies wanted ahead notice, without living up to their share of the "responsible" part, namely actually fixing the bugs in a timely manner.

And then there was legal and other actions against people who told the manufacturers ahead of time that they were going to disclose a vulnerability at this conference or that publication.

If you can think of a better way to make sure people don't tell you in advance about what they found wrong with your crap, I'd like to hear it. :-)

Sorry, but while I would give most Free Software and small/hobby projects the benefit of the doubt and be kind to them, anything manufactured by a large company needs immediate full disclosure. Pain is the only way these MBAssholes learn. If you try to be "responsible" with them, they'll consider it an opportunity to fuck you over and still do nothing about the quality of their stuff.

Re:unrepentant (1)

Tom (822) | more than 3 years ago | (#37414608)

Oh yes, I forgot:

If you think that exploits don't exist until someone discloses the vulnerability, you live in lalaland. More often than not, when a 0day is published, a whole lot of bad guys already knew and actively exploited it for quite a while. In fact, if you read carefully, you'll notice that suspicious activity is sometimes what caused the investigation that lead to the discovery of the vulnerability.

Re:unrepentant (0)

Anonymous Coward | more than 3 years ago | (#37417660)

> And then there was legal and other actions against people

Legal is "better" than "other" if repercussion means 9x19 mm to the back of the head... If any of those SCADA vulns he disclosed includes one the jews was just about to unleash on Iran's atomic programme, that italian guy is in big trouble. Mossad kills people left and right with impunity provided by Uncle Sam.

simple solution to SCADA "hacks" (1)

Gravis Zero (934156) | more than 3 years ago | (#37415896)

What viruses like STUXNET do is reprogram the hardware (CPLDs) to do what they want. In a recent article about BIOS viruses (and antivirus) people were saying how dumb it is to give an OS the ability to reprogram the BIOS without any physical safeguard. In mission critical systems absolutely no hardware should be reprogrammable without a physical safeguard like a switch. Of course to make sure the idiots dont leave it switched to programmable (we all know they would be because a switch is "such a pain"), it would only boot to an internal keyboard menu system that would prompt you on how/if you want to reprogram the system when switched to program mode. To be clear, I'm talking about switch that would actually change the circuit and not just be an indicator for the firmware.

Why is it so hard for people to realize that these systems need to be well protected?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?