Forgot your password?
typodupeerror
Security IT

Researcher Publishes Industrial Complex Hack 190

Posted by samzenpus
from the who-runs-the-power-plant dept.
snydeq writes "Security researcher Kevin Finisterre has published code that could be used to take control of computers used to manage industrial machinery, potentially giving hackers a back door into utility companies, water plants, and even oil and gas refineries. The code exploits a flaw in supervisory control and data acquisition software from Citect. The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection. Finisterre, however, sees the issue as indicative of a 'culture clash' between IT and process control engineers, who are reluctant to bring computers off-line for patching due to the potential havoc wreaked by downtime. 'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"
This discussion has been archived. No new comments can be posted.

Researcher Publishes Industrial Complex Hack

Comments Filter:
  • Well (Score:4, Insightful)

    by Anonymous Coward on Wednesday September 10, 2008 @07:43PM (#24954721)

    If you hook up a device to the internet without any firewall protection, you deserve what you get.

    • Re:Well (Score:5, Insightful)

      by lysergic.acid (845423) on Wednesday September 10, 2008 @07:51PM (#24954819) Homepage

      what do you get? internet herpes?

      a firewall will protect your computer from many exploit attacks, but that's not a reason to rely solely on a firewall for protection.

      running a system with a bunch of unpatched security vulnerabilities and simply relying on a firewall to protect you is just as foolish as connecting to the internet without a firewall. after all, what happens if the firewall fails, is bypassed, or has a security vulnerability of its own?

      • I'm sitting at work, where our firewall restricts internet access. Yet here I am, posting on Slashdot.

        Firewalls are amazingly easy to bypass.

        • Re:Well (Score:5, Funny)

          by Solra Bizna (716281) on Wednesday September 10, 2008 @08:26PM (#24955217) Homepage Journal

          Firewalls are amazingly easy to bypass.

          From the inside, certainly.

          -:sigma.SB

          • They are much easier to circumvent from the inside, but I've yet to see a firewall that can't be breached.

            • Re: (Score:2, Interesting)

              by rivetgeek (977479)
              Then you've never seen a properly configured firewall. When I set up a cisco box, it doesn't even give a banner and drops all icmp/udp/malformed tcp. If the ACLS are properly defined, you wont be bypassing anything. Also, If I wanted to block someone from the inside its just as easy, and dont say ssh tunnel because that can be blocked too.
            • by Anpheus (908711)

              You don't see many firewalls do you? If I have a machine inside the firewall and it's not communicating with the outside world, as far as you, and a properly configured firewall is concerned, it doesn't exist. There's no established route from the firewall to the computer because the firewall doesn't need to talk to it.

              Pretty sure this is an easy configuration.

    • Re:Well (Score:5, Insightful)

      by PC and Sony Fanboy (1248258) on Wednesday September 10, 2008 @07:54PM (#24954853) Journal

      If you hook up a device to the internet without any firewall protection, you deserve what you get.

      We should be glad that people release these 'bugs' openly - I'm sure that this information would have made Mr. Finisterre a lot of money, if he approached the right (wrong?) person. Imagine what would happen with no firewall AND no public notification?

    • Re: (Score:3, Informative)

      by zobier (585066)

      These kind of issues seem to [slashdot.org] come up [slashdot.org] here a [slashdot.org] fair bit [slashdot.org].

      http://google.com/search?q=site%3Aslashdot.org+SCADA [google.com]

    • by adavies42 (746183)
      ITYM if you hook up a safety-critical device to the internet without proving it's secure, you deserve what you get. firewalls are flimsy shields for incompetent programmers to hide behind, and only acceptable in the common case because most desktops don't have the power of life and death over large populations.
  • Why ... (Score:5, Insightful)

    by sconeu (64226) on Wednesday September 10, 2008 @07:44PM (#24954731) Homepage Journal

    The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection.

    Why would you have critical systems like that directly connected to the 'Net anyways?

    • I don't care WHAT the reasons for connecting them to the Internet are.

      The fact that it allows anyone in the world, anywhere, anytime, a chance to attack your systems is the only reason needed to refuse that.

    • Re:Why ... (Score:5, Informative)

      by phatvw (996438) on Wednesday September 10, 2008 @07:49PM (#24954801)

      Why would you have critical systems like that directly connected to the 'Net anyways?

      To reduce costs. Its cheaper for an engineer to remote-in to check on something than have them physically drag their butt to work. Fewer people are able to monitor more 24/7 systems this way.

      And its almost always cheaper to use an Internet connection than a dedicated leased line for this sort of thing.

      • Re:Why ... (Score:4, Insightful)

        by geekoid (135745) <dadinportland @ y a hoo.com> on Wednesday September 10, 2008 @08:02PM (#24954953) Homepage Journal

        It will only take one incident to loose any cost savings by an order of magnitude.

        Seriously, you can't get into any of your machines for an hour, how much does that cost? the machines start doing the wrong thing?

        • Re:Why ... (Score:5, Interesting)

          by baggins2001 (697667) on Wednesday September 10, 2008 @10:21PM (#24956311)
          What if the machine is a nuclear reactor?
          If an engineer can get eyes on without disrupting operation (talking over the phone), then he might be able to avert a problem.
          What if the machine is part of a chemical plant?
          Same as above.

          As an engineer in both instances, you would probably move more than an hour away.

          Since there are usually junior engineers on at night it can be very helpful to have a senior engineer with eyes on. It wasn't until I had 10 years of experience before I realized that I didn't have the knowledge or experience to handle an emergency during my first 5 years.

          And the powers that be wouldn't think of paying for someone that had more experience to be there.

          So some of the accidents that occur at night which are blamed on people being tired are due to them not having enough experience.

          I agree that more money and security are needed.
          But very few managers get paid extra for spending more money.
          The worst I've seen is where a controller was connected to a phone line. That controller had about 20 chemical reactors tied to it. Another controller also had a phone line and it had 4 reactors tied to it. But before this sounds really dramatic, if someone had hacked in they probably could have done some damage to the reactors, but it would not have caused a danger to humans.

          The worst I saw (safety/security) was where someone had installed pipelines carrying caustic chemicals without using a double-walled pipe (Yeah, Electrical Engineers are the same as Chemical Engineers). Yep , sure enough they had a leak. Luckily no one was injured. Some equipment was trashed, but they had insurance.
          The funniest was when the insurance guys came and wanted it to be turned on to confirm that it wasn't working. The engineer told him that he highly recommended that the equipment not be turned on. He actually showed them the fuzzy crap that was growing on the controller boards. He and another guy went and gathered five fire extinguishers, put those at their feet and told them to pull out the big red button and to press this button to start it up, if they really had to. Then told them they would be waiting outside. The insurance guy turned popped out the emergency stop button. The robotics went nuts and white flashes could be seen from the vents of the controller panel. Never got to the power on button. Experiment lasted about 3 sec. Insurance agent nearly drove the Emergency off button into the panel.

          There were 3 more systems and they decided that they could just look at the fuzzy stuff on the control cards. Didn't need to turn them on after all.

          So considering all the trouble we had with keeping safety standards in check, I'd say good luck with handling getting money for proper security costs.

          And they finally did double-wall their chemical lines and eventually it became a legal requirement. So from then on there wasn't a problem with getting chemical lines double-walled and properly labeled, not with just the yellow caution tags, but with flags. Flags weren't a legal requirement, but they are cheap.
        • by kestasjk (933987)

          It will only take one incident to loose any cost savings by an order of magnitude.

          Seriously, you can't get into any of your machines for an hour, how much does that cost? the machines start doing the wrong thing?

          The people who put these systems in place know what they are doing, and aren't throwing money out of the window needlessly.. These aren't machines in the server room down the hall, these are machines in unmanned installations, which may need constant monitoring.

        • Re: (Score:3, Interesting)

          by TheLink (130905)
          Sure, but the CEO makes money by cutting costs and doing things just like other companies.

          And when stuff goes poof, the CEO gets a golden parachute, and writes a nice goodbye letter to the company staff.

          Of course people then say, "See that's why a good CEO is worth $$$$$$$$", yes that's true, the funny thing is companies keep paying bad CEOs a lot too rather than have stuff like a "probation period" or having the $$$$ linked to what happens to the company 3 years later.
      • Re: (Score:2, Funny)

        by CrazyJim1 (809850)
        And it is cheaper still to have a drinking bird do your remote work.
      • Re: (Score:2, Informative)

        by POTSandPANS (781918)
        The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection.

        Seriously? If you can't afford to buy some sort of basic protection for internet connected equipment, you need to re-think your business model. If you can't afford the downtime to install a simple firewall, then you really won't be able to afford the downtime it will cause when somebody breaks in.

        • Re: (Score:2, Insightful)

          by the_B0fh (208483)

          The nuclear station that went down due to slammer wasn't because they did not have firewalls.

          Typically, it's the authorized users who're the biggest problems.

      • Re:Why ... (Score:4, Funny)

        by LaminatorX (410794) <sabotage.praecantator@com> on Wednesday September 10, 2008 @09:37PM (#24955905) Homepage

        If only there were some sort of virtual private network available that could give them a reasonably secure low-cost option for remote access.

      • Re: (Score:3, Informative)

        by Rostin (691447)

        Maybe, but I doubt it. The people who continuously monitor control systems are not engineers, they are operators. Engineers are usually "exempt" employees, so their overtime is free. I might also say that if your control engineers are stretched too thin by call-outs, the solution is not more engineers, it's different engineers. I used to work as THE process control engineer at a small chemical plant. Having to go into work at 3 am to fix a problem is very strong incentive to find the real cause of that

    • by kesuki (321456)

      imagine you're a multinational oil company with 300 billion dollars worth of oil and gas reserves, and want to know the exact amount of oil and gas coming out of each well every day or even hour by hour...

      and you're doing this without the internet because you like rolling out your own private wide area network? much easier to make a WAN that sits on top of the internet.

      remote administration is a lot cheaper than flying admins to every site too. so the question really is, why wouldn't these systems be hooke

      • Re:Why ... (Score:5, Insightful)

        by dave562 (969951) on Wednesday September 10, 2008 @07:58PM (#24954903) Journal
        You download the data to a historian server and reference that. There is no reason to ever remotely connect to the actual hardware that is controlling the valves and actually running the plant. I'm not sure what kind of sites you'd need to fly an admin out to, but odds are that there are already people there. I don't know too many power plants, electrical generation facilities, or oil/gas operations that are 100% automated and don't have any people around.
        • I don't know too many power plants, electrical generation facilities, or oil/gas operations that are 100% automated and don't have any people around.

          yes, but are there qualified people available to do the adjustments on site? What about those un-manned off shore oil rigs? I bet the engineers were pushing HARD for remote access there..

          • by dave562 (969951)
            I'm not all that qualified to comment on the dynamics of off-shore oil rigs. If they are truly 100% unmanned then they are probably already remotely controlled. But remotely controlled is not the same as connected directly to the internet. They're probably running an IP VPN across a satellite link or something similar.
          • Re: (Score:3, Interesting)

            that's why we have these things called vpns.
        • I worked at a 100% remote plant for a short time. We were onsite during the day, but at night if the turbines needed to start they ran them from another state. At that time, the liklihood of turbines running at night wasn't very large, but it did happen once a week or so.
    • Re:Why ... (Score:5, Insightful)

      by PC and Sony Fanboy (1248258) on Wednesday September 10, 2008 @07:52PM (#24954827) Journal
      Keeping critical systems offline sounds smart, until you realize that

      a) What is critical to you may not be critical to me
      b) Keeping them offline might make sense for security, but it makes servicing them more difficult, and so more people need to be hired, and so it is more expensive (which is bad, apparently)
      c) Sometimes, critical systems need to be online, and widespread. For example, if banking wasn't networked, then ATMs wouldn't work. If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty. Also, work-from-home wouldn't 'work', and corporate VPNs would be pointless.

      Critical systems *should* be connected to the 'net, so we can have access to them. But, they should also be better protected, and backed up offline.
      • Imagine if I could go online and check my power consumption against that of my neighbours? Or see the average power usage in a neighbourhood before buying a house in the area? Or being able to do that for any utility? ... These should be connected online!

        Not to mention the cost savings that come with remote management... I'm happy with anything that keeps the cost of living down.
      • by kesuki (321456)

        not all firewalls are made of the same stuff. especially consumer grade firewalls, and any unmanaged firewalls. if ports inbound can be opened by spoofing a 'return' packet (full open firewall) then hackers can get inside it.

        but yeah, there are reasons to put systems on the internet, and there are reasons to not skimp on it, and get admins who have a clue about security and what hackers can really do.

        as for banking networks, they kind of evolved before the internet evolved, so it's possible that banks ATM

        • for instance, if you have a routine scan of your brain waves, chances are it's going over modem to a place in Tennessee to be evaluated, and not over the internet.

          Well, it will be sent over the phone/modem for now. Until some bean-counter realizes that it is cheaper to use the 'net...

      • By the numbers. (Score:4, Insightful)

        by khasim (1285) <brandioch.conner@gmail.com> on Wednesday September 10, 2008 @08:14PM (#24955105)

        a) What is critical to you may not be critical to me

        And who are you? Seriously. Why is your opinion of what is "critical" worth anything in this discussion?

        b) Keeping them offline might make sense for security, but it makes servicing them more difficult, and so more people need to be hired, and so it is more expensive (which is bad, apparently)

        And the cost of hiring those people vs the cost of cleaning up after an attack? Skipping security is ALWAYS cheaper. As long as you never consider the cost of an attack.

        c) Sometimes, critical systems need to be online, and widespread. For example, if banking wasn't networked, then ATMs wouldn't work. If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty. Also, work-from-home wouldn't 'work', and corporate VPNs would be pointless.

        #1. ATM's. No. They were not originally connected to the Internet.

        #2. Driving license. So what? That would catch up to you after the traffic tickets were entered into their system.

        #3. Corporate VPN's. We're talking critical systems here.

        Critical systems *should* be connected to the 'net, so we can have access to them. But, they should also be better protected, and backed up offline.

        Wrong. There is access to them without having them connected to the Internet. Just as it was back in 1990.

        All of your reasons come down to "cheaper".

        "Cheaper" should not have more weight than "secure".

        • I never said cheaper should have more weight than secure. But, if you havn't noticed, people prefer to save money. Corporations prefer to make money. Stockholders perfer to have increases in their investments. So, even though I agree with you - all signs point to 'cheaper' winning out over 'better'.

          As for my opinion of critical? Well, if I owned a large, multi million dollar company, then I would consider anything that had a major impact in my ability to make money AS CRITICAL.

          To be even more callous
        • by db32 (862117)

          Just to play devils advocate a bit. "Cheaper should not have more weight than secure" is not true. Think about space travel. "Secure" would involve thicker shells to protect better from debris and more lead to protect against radiation and so on and so forth. The "Cheaper" in this case allows it to happen at all because all of that extra layering would make the whole thing pretty cost prohibitive.

          I can think of tons of reasons these things should be networked. I am having a hard time with why they shou

        • "Cheaper" should not have more weight than "secure".

          It is a trade off. Everything costs money - failures cost money, security costs money, redundant engineering costs money. Since we do not have an infinite supply of money the goal is to get a handle on all of the risks involved and pick the combination that reduces total cost.

          The hard part is to properly evaluate those risks (and then re-evaluate them as circumstances change).

        • "Cheaper" should not have more weight than "secure".

          This betrays almost unthinkable naivete. Cheaper always has weight. It's a question of overall system cost, and people tend to ignore non-obvious risk. Welcome to the human condition.

          Ever go to any of those sites that tell you where your dollar bill has been? They have a place where you can put your bill's serial number, and see if anybody else has done the same. It's kinda fun!

          But did you notice that there is NO SECURITY WHATSOEVER behind authenticating y

        • #2. Driving license. So what? That would catch up to you after the traffic tickets were entered into their system.

          Have you ever heard of identity theft?

          All of your reasons come down to "cheaper". "Cheaper" should not have more weight than "secure".

          I'm sorry we can't all live in your world, but in my world, immediate cost savings outweigh spending a never ending wad of cash on security.
          Most companies have to be hit with a pile driver to enact costly security or safety measures. So either the
      • If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty.

        You can anyway - they need PC in order to pull you over and run your license. Anyway, all of your examples miss the mark; your ATM doesn't need to be sitting on the internet (probably doesn't). It needs a network connection, but that's covered with VPN type tech or a private network. The cost angle needs to be weighed against the risk of doing things on the cheap - no need for direct access, at least not naked access.

    • Re: (Score:2, Insightful)

      by Cornwallis (1188489)
      Why would you have critical systems like that directly connected to the 'Net anyways?

      Because a project manager, working under pressure from his/her boss says "Get it done" and the poor shmoe tasked with installing it doesn't probably know what a firewall is. He is simply following the instruction manual. So many bosses turn a blind eye to this stuff you end up with serious vulnerabilities. I've seen them.

    • by zappepcs (820751)

      Here is the thing, do you remember all those stories about the NSA working with OS vendors to secure them? Some thought that was good, others (like me) thought it a bit dubious. Well, all that work was for nothing, as evidenced here in this story. No matter what they did, no federal governmental department did anything to secure our IT infrastructure. Now, I'm not going to mention 9/11 conspiracies, but you can just imagine how all this plays out. can't you?

      They have those systems connected to the Internet

    • Re: (Score:3, Insightful)

      by HikingStick (878216)
      Because the people who implemented these solutions were not IT people. They're skilled in their fields, but usually have only a marginal understanding on contemporary issues in networking and network security. To them, having the machines net-facing is just a convenience so that they can connect and address issues without dispatching someone to the location.
    • by arth1 (260657)

      The biggest problem with "[...] and risk arises only for systems connected directly to the Internet without firewall protection" is the assumption that all the bad guys are on the other side of the firewall. In reality, a very large portion of penetrated systems are penetrated from the inside.

      If you don't see inside penetration as a problem, why not run all your machines inside the firewall without passwords?

  • by Enderandrew (866215) <enderandrew@noSPam.gmail.com> on Wednesday September 10, 2008 @07:46PM (#24954779) Homepage Journal

    ...a standard cell phone will let you pretty much instantly hack and control anything in the country except for the utilities. For those, you need to go to 2 different locations that control all the utilities in the country.

    That movie had the "Mac guy" so I totally trust it.

  • " 'Their industry is not very familiar with hacking and hackers in general."

    The policy of most utility plants is to never connect any type of machinery control to the internet. If you have left yourself open like this, you are not following industry practices.
  • by dave562 (969951) on Wednesday September 10, 2008 @07:52PM (#24954823) Journal
    I've done a little bit of work with control systems (Honeywell) that are used to run a power plant. The author of the article is a bit disconnected from reality. You can't exactly just take one of those systems offline to patch it. Shutting the powerplant down is a complex operation that takes time. Starting it back up takes time. Things need to get up to temperature. Pressures need to build up. Fuel needs to be loaded. It's not just as simple as, "Email is going to be down for 15 minutes while we reboot the Exchange server."

    At the place I did the work for, the control systems were completely isolated from the internet. They sit on their own network and only talk to each other. They are all running Windows Server 2003 on HP Proliant ML370s with redundant everything (RAID drives, power supplies, UPSes, etc). The closest those things get to communicating with the outside world is when they download their data to a historian server on the other side of a DMZ link. It is a one way connection to the historian server. The historian is then referenced when people offsite need to know what is going on at the plant. The only way to connect to the historian is with VNC from one specific IP/MAC.

    Enough of the security tangent. The point I was originally trying to make is that most industrial machinery doesn't need to be patched. It runs one or two software applications that do a specific thing. There is absolutely no reason to touch the box once it is up and running. Security in an industrial environment needs to be handled at the physical/network layer, not at the box. Why does the hardware running your valves need internet access? Why does a box running a CNC machine need internet access?

    • It is a one way connection to the historian server.

      Truly one-way? Not even ONE packet is sent from the historian to ACK receipt?

      • Obviously not.

        Like I commented on his thread, I do the same thing with my security camera recording point. All of it's over wifi with 1 sending, the other receiving.

        It's completely 1 way. Radio-direction-finding proves I'm not emanating signal on that rf card.

    • by Vancorps (746090) on Wednesday September 10, 2008 @07:59PM (#24954917)

      You make a fair point but what happens if one of those machines does fail? Believe me, I've had triple redundant power supplies fail on me before it will happen.

      The IT world believe in redundancy and so too I would have thought does the industrial world where uptime has to be 100%. Rebooting your Exchange server should not result in any downtime if email is considered mission critical.

      So if there are redundant control systems in place why can't individual machines be brought offline and patched as necessary?

      The only argument I can see that holds water here is that an update could theoretically break the tool but if it is properly redundant then it won't come back online when you're done and the problem stops there until the node can be replaced or updated.

      • by dave562 (969951)
        The servers themselves are physically mirrored. It takes two computers to run the plant and there are four of them.
      • Re: (Score:3, Insightful)

        by baggins2001 (697667)
        (Before we start with a flame war, I just want to say this isn't directed at any previous author.) In the industrial world, why would you patch a system that is working fine.

        If the system is not connecting directly to the internet, why open yourself up to problems.

        The original author said that they are using Windows Server 2003. I have seen many places where windows 3.1 and windows 95 are still in use.

        Haven't had a patch in well, I don't know how long.

        My point is, I wouldn't want to put a patch on
    • by geekoid (135745)

      So if someone gets a bot onto that computer to access it remotly, then they can compromise the entire system.
      In the system I worked at, if you want to know what is going on, you called. If you need history you called and we burned you a disk. If you brought a computer device(PDA, Smart Phone, laptop) into the control room, you were reprimanded. do it again and you got the opportunity to work for someone else.

      "Why does a box running a CNC machine need internet access?"
      Porn~

      • by dave562 (969951)
        If the remote access computer gets compromised then they can remote into the historian. The historian is not the control system. For the longest time the owner of the company called all the time. He's such a control freak that he wanted to see things in real time. He wouldn't take no for an answer so we secured it as much as possible while mitigating the potential for disaster. Sure it would suck to have the historian go down but it is physically mirrored so it's not the end of the world.
    • I have a server at home set up like that.

      my camera hooked up feeds data to a wifi channel 1 on an unspecified ssid. Data is sent essentially to the aether.

      I have another hidden box with wifi receiving only recording all udp packets with certain parameters. My recording server. There's no way to probe it, no way to attack it, no way to know it even exists.

      • by the_B0fh (208483)

        Unless you wrote your own wireless driver, I highly doubt so.

    • Re: (Score:3, Interesting)

      Why does a box running a CNC machine need internet access?

      After I was caught playing solitaire on a CNC lathe (working one summer in a factory), the engineers thought it would be a good idea to network all the windows controlled CNC machines so they could do remote monitoring and updates. They were mechanical engineers, not IT guys ... and They didn't bother with any security, and so I could browse their 'mshome' workgroup with read/write access. I always wondered what sorts of havok I could have caused ...

    • A CNC machine may need network access and the net work may hooked to the internet.

    • by WillRobinson (159226) on Wednesday September 10, 2008 @09:07PM (#24955637) Journal

      I have done quite a bit of work in the scada area in the past. What we had was the machine network physical separated from everything.

      A serial link was used to query the scada system and recorded all the interesting points.

      There was no way to write to the scada system via the serial link. That system then dumped the data to sql databases, where it was then queried by the internal web server and provided lookups and pretty pictures for those that dont really need to know, but want to.

      The webserver was then on the office network, but could also be accessed by dialup, the office network was not internet facing.

        Think that is a bit more secure due to the fact that we actually took 10 minutes to think of a method that would be

    • These machines need to be patched because, ultimately, they will get connected to a network (whether local or Internet). Then, when the unpatched, unprotected systems are exposed they can catch bugs.

      They end up with Internet access for ease of troubleshooting and remote support.

      Likely an even greater risk to the security of most such machines is that they are likely using the same passwords today that were being used when the machines were first deployed. Even if they were switched from the default valu
    • Some vendors of CAD/CAM software require each machine running their software to be able to communicate with a "license server" on your network before the software will run. If you buy a sitewide license for say, GibbsCAM, you need to designate a single box on your network as the "license server", and each workstation or machine running the package will "phone home" to the license server periodically to make sure that you have a valid license.

    • by Lumpy (12016)

      are you high?

      you CAN take the SCADA system offline without affecting the plant. They continue operation just fine with the SCADA pc's offline.

      I suggest you learn about modern (1990-now) SCADA it's very different now and relies on the AB systems more than the PC running the crappy software.

  • "who are reluctant to bring computers off-line for patching due to the potential"

    no shit? of course they are, an and industrial machine should ahve to come down for patching.
    This is why Windows should not be used in 24/7 industrial work.

    Computers need to live up to the needs of the industrial machines they serve, not the other way around.

    • by dave562 (969951)
      They don't need to come down for patching. That is the point. Show me an unpatched Linux box that can live on the internet without getting owned. I think the important point is that if you have a critical control system, no matter what it is running, don't put it on the internet. At some point companies need to do a risk analysis and figure out if the "cost savings" of being able to remotely manage something outweigh the potential liabilities of having it compromised. There is a reason that banks use a
      • Show me an unpatched Linux box that can live on the internet without getting owned.

        http://www.linuxdevices.com/articles/AT8574944925.html

        Unfortunately, it seems to have died before I could get my hands on one. :(

        -:sigma.SB

    • This is why Windows should not be used in 24/7 industrial work.

      I worked in a factory that used completely unpatched XP (sp1) for everything. Time clocks, CNC control, Quality control records and monitoring... Whenever I had a bad day in production with out of spec parts, I'd just unplug the ethernet cable a little bit, so they wouldn't receive any of my readings (but I could see them). About half an hour later, someone from QA would come by, examine my gauges, and tell me to make SURE I was measuring things properly. At that point, I'd stop measuring, because any par

  • that blew up a Russian gas facility with the force equal to a small nuke.

  • by Ransak (548582) on Wednesday September 10, 2008 @08:23PM (#24955197) Homepage Journal
    I've done SCADA security audits and managed a variety of environments with SCADA devices (PLCs, HMIs, etc).

    It's a mixed bag. Some (older GE Fanuc PLCs for example) have zero security features, and only have a telnet daemon wide open to the world. The obvious answer is to bitch at the vendor and mitigate it with ACLs or some such, but really you'd have to know something about what you're hacking at to force it to do anything more than lock up, which might be bad, but generally is more of an inconvenience to a worker on the floor since all mission critical environments should have people standing by in such a case with the ability to manually override.

    To my knowledge there's only been one real targeted SCADA hack that caused damage, [computerworld.com] and he had inside information. Don't get me wrong, I'm all for increasing security in SCADA environments, but the biggest hurdle isn't technical; it's political. Most SCADA environments that I've seen have been set up by electricians that programmed the SCADA devices but know pretty much nothing about IT (FYI, there's a lot of Linksys gear out there). They're usually paid overtime to work on the SCADA network and they see IT personnel as a threat to their livelihood. Someone I know was threatened with a screwdriver for just trying to replace a router.

    • Someone I know was threatened with a screwdriver for just trying to replace a router.

      What's the big deal? Drink the screwdriver and then replace the router.

    • Worked on a bunch of large scale systems myself. The best were where they used a serial link that was read only from the large scale plc systems and feed to a sql system, which then fed a linux web server, with another net connection to the office network.

      The plant network was not connected in any way to the office networks directly.

      The only outside connection was logging in to a dialup to view stuff remotely.

  • Citect is not the only SCADA software company out there. They have a large market share, yes, but there are many other companies that author software for this market. This 'buffer overflow' affects only Citect software and none of the other company's offerings are affected. Yes there are some fools out there who will connect their systems directly to the `tubes, but there probably aren't as many as you would think. There are probably some vulnerabilities in other vendor software as well. But you know what,
  • Firesale - call McClane.

  • I am a process engineer, and this can be a significant problem. I've seen large-scale equipment shut down because of computer viruses, much less full control exploits - the resulting cost to rush in an IT worker (not usually onsite) with a new box, the lost production time and resulting hash-over of the whole plant's network was astronomical, because a floor worker had figured out how to get into IE from the terminal, which was supposed to be disabled.

    The implications of this may not be that far-reaching
  • This is a lot like the network printers hack story that they have been used as hack points and the flaw was WITH THE SOFTWARE and not the OS.

    Any even if you use Linux you still need to do the updates and update the software.

  • > The vendor has released a patch and risk arises only for systems connected directly to
    > the Internet without firewall protection.

    Such systems should not be connected to the Internet. Full stop.

  • by ScrewMaster (602015) on Wednesday September 10, 2008 @09:11PM (#24955677)
    'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"

    He's attempting to lay blame for these infrastructural issues at the feet of the engineering staff. What he doesn't understand is that engineering systems have very different operational requirements from running a server farm or a few thousand desktops. Engineers avoid IT like the plague, because IT people will come down on engineering systems like a ton of bricks, enforcing arbitrary company-wide standards regardless of the damage they do. For example, if you have a timing-sensitive real time process running on a PC, it may not be wise to put the Symantec Antivirus pig on that particular box. Yet I've seen that happen, usually without the person in charge of that equipment even being notified. Afterwards, everybody wonders what happened with something goes seriously wrong with a production process. IT's attitude in such cases is usually "we followed company policies. Not our fault." The hell it wasn't.

    The reality is that IT misguided or ignorant departments are frequently a far bigger danger to process control and real-time data acquisition systems than any number of Chinese crackers. That's because they rarely make the slightest effort to accommodate the needs of the technical staff, and have often gone to extreme lengths to have upper management approve utterly Draconian policies that MUST be applied to ALL computers.

    Engineers are often justifiably leery of having IT involvement in any of their projects. The consequence of that, of course, is that now you have people with no specific security training implementing remote communications. Of course, a lot of these problems could be ameliorated with some simple requirements such as "all off-site communications MUST be secured with a VPN" or something similar.

    Ultimately, what it comes down to is communications being handled by conscientious, well-trained individuals that are open-minded and willing to accommodate the special needs of engineering systems. I can't tell you how rarely I've seen that happen.
    • Amd im an EE student that was going into computer and network engineering.

      There's a way to introduce engineering methods in IT. I just treat each network as its own system and hook those systems together like black boxes. As long as we diagram the traces (read network connections), we can follow trouble patterns and diagnose problems quickly. We can then map virtual networks above as we would have a 2 layer circuit board. Since we know what goes where, we can easily see why a level 2 network connection woul

      • super lock down does not work that well and after it blows up a big job it will get canned so fast your head will spin.

        Also going to the minimum will need a lot of testing to see if a app does not blow when it try's to use what was disabled and even then YOU STILL NEED TO DO THE UPDATES.

        As some can use a hole in the system to be able to run code at the system level by passing the lock down.

        • Re: (Score:3, Interesting)

          Then I assume that you are not familiar with RBAC systems like SELinux built in the kernel. In a "dangerous" environment where 1 minute of downtime is equal to 100k$'s, lockdown is the only way to go. Running as root or equivalent should never be allowed, period.

          We can lock even root down to console-only access and have the user-servers loaded up from netboot and nsf mounted drives from the user-server. Roles based upon who the user is will grant access to what they need to do, and nothing more. All actions

      • Re: (Score:3, Informative)

        by Tarwn (458323)

        And I am an IT person with a CS degree that worked as a historian and i/o integrator, industrial software developer, and most recently have been working on a project to integrate equipment w/ layer 4 scheduling data.

        Most of the places I have done work for I have seen at least a small number of HMIs that were running on Windows (InTouch, ProcessBook, RsView, etc). I agree that kiosks can be built running off of a read-only image, etc but that takes a great deal of effort, especially for a system that likely

  • I work around a number of similar systems, and one trend I see as somewhat alarming is that they're increasingly showing up as Windows boxes with an ethernet port attached. I'm talking about things like industrial x-ray machines, industrial refrigerant control systems, PLC control systems for complex industrial machinery, all sorts of things that can go boom or otherwise cause death and dismemberment if they go sideways. It's not that Windows sucks per se, but rather that many of these systems are sent ou
    • SCADA SCHMADA (Score:3, Insightful)

      by codepunk (167897)

      Actually in my opinion the SCADA PCs although vulnerable in many cases are not the best
      way to attack these systems. It is much easier to just start firing junk into the registers
      of the PLCS controlled or monitored by the SCADA systems. In many cases the controllers are just
      hanging balls to the wind on the network. Anyone that has messed with them at the protocol level
      knows that most of the protocols in use have little or no security functionality.

  • Someone needs to add the "scada" tag to this story.
  • Plain fear mongering (Score:2, Interesting)

    by tsfrankie (1359717)
    Plain Fear mongering at work, nothing more. I have worked in Power Plants for 30 years now, from analog to digital, and he is so full of fear mongering and "what ifs" worse than a Long Island housewife. First, there being no money or "secrets" in hacking a power plant, why bother? If this was such a problem, then why don't we see it happening? Also, there is a huge cost on manpower, material, resources and lost revenue to take a powerplant down on someones fantasy security exploit, and those resources are m
  • by Weasel Boy (13855) on Wednesday September 10, 2008 @09:55PM (#24956079) Journal

    I developed an HMI using Citect, and for my needs it was significantly better than the alternatives. Actually, it was pretty excellent. But you wouldn't use it to control dangerous machines: it runs on Windows. :-) Supervisory Control and Data Acquisition is high-level: the user-friendly end of process control. We used Citect to control the machines that control the machines.

    You could poke a button on Citect that said, "open this valve," but all Citect did was message an industrial PLC that performed all the safety calculations and bounds checks and actuated the relay, then sent the result back for Citect to display. Actually, a better example would be to poke a button to start the next phase of a run. You wouldn't use SCADA to open or close an individual valve much more than you'd invoke a single C function from a CLI.

    I would argue that in fact the traditional rules of IT do not all apply to these SCADA systems. They are quite often single-purpose PCs that have little or no connection outside the plant floor. If they worked on commissioning day, they'll probably still work today. They don't need a lot of management. Not that machines don't get taken down for maintenance, but you don't want a surprise incompatibility in your software update keeping the system down longer than anticipated. Wreaks havoc on the supply chain. Actually, Citect can clone control stations (legitimately, not just 0wn3d), so you could do a phased deployment of patches without losing any capability; I was speaking more generally.

    It is true, though, that process engineers I've known don't think much about network security. They're concerned about guarding against a china syndrome, so the important stuff is off the net and often talks to SCADA via RS-232. A hacker might steal data or stop the run, but probably couldn't make things go boom.

  • I've seen the flip side of that scenario. We (engineering) designed, built and maintained a shop floor control system. It served our company for over a decade with no instances of malicious hacking. Although we were behind a firewall, we were subject to security reviews by the IT department as well as some black hat testing from within the firewall. Never been hacked. The system featured a modular, object oriented s/w architecture that could be updated on the fly from our integrated revision control system!

  • How difficult would it be to write a simple domain scanning ocx,executable etc that fires
    off a bunch of tcp modbus register writes...may take all of 10 minutes or so. Yes it could
    do some serious damage if not cause bodily harm or death(think machine operators).Many of these
    plc's on most networks are just directly connected without a ounce of security on them. Ever work
    in a manufacturing facility? Most of this stuff is ladder programmed etc by engineers who
    have no clue what tcp or modbus protocol even is, mu

  • by Animats (122034) on Wednesday September 10, 2008 @11:46PM (#24957141) Homepage

    From the article: "The system is composed by software installed on standard computer equipment running on commercial-of-the-shelf Microsoft Windows operating systems."

    And that's the problem. It's not running on QNX, or VxWorks, or LynxOS, or MonteVista, or even Windows XP Embedded. With those systems, the system is usually built to have just the components needed to do the job, not with every gimmick Microsoft puts in their desktop OS.

    And, of course, it's yet another buffer overflow, part of the defective-by-design semantics C and C++ use for arrays. (And yes, I know what I'm talking about.)

  • I did my Master's thesis on SCADA, and it's entirely true--most of the industry is stuck somewhere in the early 80's, when unsecured modems, network lines, and radio (!) links seemed perfectly safe.

In a consumer society there are inevitably two kinds of slaves: the prisoners of addiction and the prisoners of envy.

Working...