Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security IT

Italian Hacker Publishes 0day SCADA Hacks 106

Posted by timothy from the how-to-turn-on-the-hot-water dept.
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."
This discussion has been archived. No new comments can be posted.

Italian Hacker Publishes 0day SCADA Hacks More

Italian Hacker Publishes 0day SCADA Hacks

Comments Filter:

  • You cant blame him (Score:1, Offtopic)

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

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Like the US economy?

    • The italian justice system?

    • Re: (Score:1)

      by gtall ( 79522 )

      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 (Score:5, Insightful)

        by said213 ( 72685 ) on Thursday September 15, 2011 @09:39AM (#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.

      • Yeah, the Italian economy is circling the loo.

        Pecunia non olet! [wikipedia.org]

    • Re: (Score:1)

      by Anonymous Coward

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

      • 99)... ... ... ...

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

  • Isolated networks are A Good Thing (Score:4, Insightful)

    by davidwr ( 791652 ) on Thursday September 15, 2011 @09:25AM (#37409338) Homepage Journal

    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 (Score:4, Informative)

      by UdoKeir ( 239957 ) on Thursday September 15, 2011 @09:27AM (#37409362)
      To be honest, an insider attack can just as easily be carried out with a large hammer.

      • Re: (Score:2)

        by buanzo ( 542591 )
        But it's too noisy DURING the attack :P

      • Re: (Score:3)

        by geekoid ( 135745 )

        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.

      • 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 proba

    • Re:Isolated networks are A Good Thing (Score:4, Informative)

      by LoRdTAW ( 99712 ) on Thursday September 15, 2011 @10:42AM (#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: (Score:2)

        by AB3A ( 192265 )

        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

        • Re: (Score:2)

          by LoRdTAW ( 99712 )

          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 syste

          • Re: (Score:1)

            by ttong ( 2459466 )
            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

          • Re: (Score:2)

            by tzanger ( 1575 )

            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 extrem

          • Re: (Score:2)

            by sjames ( 1099 )

            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.

      • 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: (Score:1)

      by Anonymous Coward

      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 them

  • Why not isolate the networks? (Score:3)

    by kyouteki ( 835576 ) <kyouteki@@@gmail...com> on Thursday September 15, 2011 @09:26AM (#37409342) Homepage
    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: (Score:2)

      by headhot ( 137860 )

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

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

        • Data diodes. (Score:1)

          by Anonymous Coward

          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: (Score:2)

      by geekoid ( 135745 )

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

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

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

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

      • 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: (Score:2)

          by Lumpy ( 12016 )

          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

          • 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: (Score:2)

              by Lumpy ( 12016 )

              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.

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

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

    • 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 do

      • 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,

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

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

    • 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 infra

    • *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 installation

  • Its not that hard! (Score:5, Insightful)

    by inasity_rules ( 1110095 ) on Thursday September 15, 2011 @09:28AM (#37409382) Journal

    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! (Score:4, Interesting)

      by hjf ( 703092 ) on Thursday September 15, 2011 @09:56AM (#37409720) Homepage

      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.

      • 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 s

      • 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 licen

      • Re: (Score:2)

        by Trogre ( 513942 )

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

      • 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: (Score:1)

      by Anonymous Coward

      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.... (Score:3)

    by Lumpy ( 12016 ) on Thursday September 15, 2011 @09:53AM (#37409670) Homepage

    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.

    • Kick managers in the nuts

      He he. OK, I will *sighs*

    • 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 "ne

      • * 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!

    • 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 compromi

  • Common Thread (Score:1, Interesting)

    by Anonymous Coward

    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 (Score:3)

    by WaffleMonster ( 969671 ) on Thursday September 15, 2011 @10:04AM (#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.

  • 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: (Score:1)

      by edbob ( 960004 )
      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 unlik
  • 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.

  • 2011 and we still have the same idiot programming (Score:3)

    by Old Wolf ( 56093 ) on Thursday September 15, 2011 @04:29PM (#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: (Score:2)

      by orzetto ( 545509 )

      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 no

  • 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 c

    • Re: (Score:2)

      by Tom ( 822 )

      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.

  • 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"),

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close