Hacking SCADA for terrorism and destruction

Hacking SCADA for terrorism and destruction

Summary: SCADA scares me, and I've seen enough things on the Internet to be desensitized to many things, but attacks against SCADA threaten our national security in a very real and topical way by attacking power grids, water treatment plants, nuclear plants, etc.  Hacking networks that SCADA devices reside on and using that access to interact with the SCADA system is nothing really new, it's been covered in the media quite a bit...


SCADA BoomSCADA scares me, and I've seen enough things on the Internet to be desensitized to many things, but attacks against SCADA threaten our national security in a very real and topical way by attacking power grids, water treatment plants, nuclear plants, etc.  Hacking networks that SCADA devices reside on and using that access to interact with the SCADA system is nothing really new, it's been covered in the media quite a bit... including the infamous Idaho National Labs research video which was ridiculously disclosed to CNN by our very own Department of Homeland Security director, who should've been keeping this to himself and creating a serious plan to address these issues, rather than giving terrorists something to salivate over.  If you haven't seen this video, I suggest you have a look as you'll see a generator connected to a SCADA device nearly blow up when sent an Internet based attack.

What we haven't seen a ton of are specific attacks against SCADA devices and protocols.  Why?  SCADA devices can be expensive, or impossible to setup and replicate for those doing vulnerability research (with Idaho National Labs maybe being one of the examples where this isn't an issue) and clients typically would be well advised to NOT assess the protocols on their direct production systems (seems obvious, but you never know).  So what's new about my article today?  Well, our good friends at Core Security Technologies in Boston released an advisory today about a buffer overflow attack in a specific SCADA product.

Read more by clicking the more link below.

In an exclusive interview with the Associated Press, Core Security Technologies and the article author, Jordan Robertson, comment on the advisory:

Citect Pty. Ltd., which makes the program called CitectSCADA, patched the hole last week, five months after Core Security first notified Citect of the problem.

But the vulnerability could have counterparts in other so-called supervisory control and data acquisition, or SCADA, systems. And it's not clear whether all Citect clients have installed the patch.

First off, not to call CitectSCADA out, cause I'd imagine this is not something they deal with all of the time, but five months is a long time to have an issue of this magnitude in such critical pieces of our nation's infrastructure.  Again, I don't fault Citect on that, I'm simply stating the prospect is scary.  Vulnerabilities in the software that manages SCADA devices, the protocols associated with that interaction, and other areas of SCADA technologies have been talked about for quite some time as security concerns.  In fact, not that long ago several people on Full Disclosure's mailing list were discussing direct research being performed on specific SCADA devices which led to some Denial of Service vulnerabilities.

Second, the fact that Citect and other SCADA companies may not have considered things like patch management (by the way, I'm only theorizing here, I don't pretend to know how Citect handles their patch management process, but it would seem likely to be something a lot of SCADA companies have not considered) is very concerning as this simple yet devestating issue could be around for a lot longer.  The Associated Press article goes on to say:

The Citect vulnerability is of a common type. Called a "buffer overflow," it allows a hacker to gain control of a program by sending a computer too much data.

"It's not a very elaborate problem," Ivan Arce, Core Security's chief technology officer, said in an interview. "If we found this thing — and this was not that hard — it would be easy for someone else to do it."

It's a great point made by Ivan, which I think a lot of people miss when thinking about security research.  If the good guys can find it, so can the bad, and it's irresponsible to think they haven't or aren't looking.  The article also describes how this might be attacked as follows:

For an attack involving the vulnerability that Core Security revealed Wednesday to occur, the target network would have to be connected to the Internet. That goes against industry policy but does happen when companies have lax security measures, such as connecting control systems' computers and computers with Internet access to the same routers.

A rogue employee could also access the system internally.

Ok, so hang on here, I tend to disagree with this a bit.  So, when the term Internet is used in this context, I'm going to assume that the author of the article means the externally accessible Internet, where as the internal only accessible piece of the Internet is going to be called a company's Intranet.  This is pretty standard terminology, but we need to point it out to be on the same page.  Really, the statement that the target network would have to be connected to the Internet is actually untrue.  The article mentions rogue employees, and that covers another threat, but these are what I see as the actual threats:

  1. Rogue employees that can access the SCADA network from their corporate Intranet
  2. Third-party contractors given guest access to any network in a corporation, as trust relationships between domains can be leveraged to gain access to other networks
  3. Third-party or employees given VPN access to the corporate Intranet, as depending upon the implementation of VPN access, this could be vulnerable to attack... especially consider web application VPN portals that might be vulnerable to cross-site scripting allowing me to steal a valid VPN user's session giving me the capability to load the VPN connection/software
  4. The Internet (hopefully a SCADA devices is not corrected direct to the Internet)
  5. Any firewall bypassing attacks that might be useful leading to vulnerability linkage getting us to this internal SCADA network.  This one is really important.  There's a lot of web application based attacks

    1. See Protocol Handler Abuse, research published by myself, Billy Rios, and Rob Carter
    2. See anti-DNS pinning attacks including research by myself, Billy Rios, Rob Carter, Dan Kaminsky, Kanatoko, Martin Johns, etc.
    3. These types of attacks may allow an attacker to deploy serious attacks to a high traffic web application, using cross-site scripting as the deployment vector.  Once a user has been compromised by the cross-site scripting attack, the attacker can use anti-DNS pinning to use the victim's browser to interact with internally accessible resources to the network the victim is on, or use protocol handling attacks to try to compromise the underlying operating system of the victim's machine, thus giving the attacker a foothold into the internal network.
    4. For even more in application/browser flaws that turn into extremely serious issues, see my talk at Black Hat Vegas '08 this year with Rob Carter, John Heasman, and Billy Rios... teaser here.

These web application attacks that allow crossing over the boundary put in place by the firewall are extremely concerning when you consider vulnerability linkage which may ultimately lead to the compromise of a SCADA device.  Consider the impact of a successful compromise of a SCADA device, which the original AP article so accurately described:

Security experts say the finding highlights the possibility that hackers could cut the power to entire cities, poison a water supply by disrupting water treatment equipment, or cause a nuclear power plant to malfunction by attacking the utility's controls.

Eeek... the article also mentions that Citect suggests that companies using SCADA devices segregate the devices from the Internet... well, that's certainly a great recommendation, but they go on to mention proper firewall configuration, etc.  Again, this is a great step, but I think it is very important to underscore that simple firewall rules to the outside world of the Internet only eliminate a piece of the attack space.  As I mentioned, internal employees, third-parties given access, and compromise of users of the companies network may again put the SCADA device at risk.

So then, we need to ask ourselves... is the threat real?  Hopefully you saw the video I linked to above, but if that wasn't enough to get your concern level up, the CIA reported that a power outage in several cities outside of the United States was actually caused by hackers who had demanded money or threatened to turn out the lights.  Another example that strikes much closer to home is something I think a lot of us will remember, when the lights went out on a large portion of the eastern seaboard.  National Journal Magazine conducted interviews with government officials who believed the power outages to have actually been caused by Chinese hackers:

One prominent expert told National Journalhe believes that China’s People’s Liberation Army played a role in the power outages. Tim Bennett, the former president of the Cyber Security Industry Alliance, a leading trade group, said that U.S. intelligence officials have told him that the PLA in 2003 gained access to a network that controlled electric power systems serving the northeastern United States. The intelligence officials said that forensic analysis had confirmed the source, Bennett said. “They said that, with confidence, it had been traced back to the PLA.” These officials believe that the intrusion may have precipitated the largest blackout in North American history, which occurred in August of that year. A 9,300-square-mile area, touching Michigan, Ohio, New York, and parts of Canada, lost power; an estimated 50 million people were affected.

So in conclusion, the threat is real.  If you are a vendor of SCADA devices, get your products assessed.  If you are a company using SCADA devices, get an Internet/Intranet/Extranet assessment done to try to determine how well you've segregated these devices from the rest of the network and make appropriate corrections based upon those results.


Topics: Networking, Browser, Enterprise Software, Mobility, Security, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • SCADA vulnerability

    As an Engineer who has spent the past 20 years working on SCADA systems for water and wastewater plants, I have some comments on this article. (And yes we are a user of CitectSCADA) First, where I work, we NEVER connect our plant control systems (SCADA systems) to ANY other network. Not Internet, Intranet, wireless, or anything. They are set up as standalone systems. The risk is just too great, and the benefits are marginal. As mentioned in the article, there is an army of hackers out there always looking for a vulnerable system - the best way to protect the system is not to present it to them. I know of other industries (power generation) that have similar bans on connection to outside networks. We also never allow any contractor to access our SCADA network, for any reason.
    This 'stand alone' approach does take dicipline and support - there are always people in the company that want to integrate the 'process' SCADA side with the 'business' side, either through the company's Intranet or the Internet. It takes strong convictions by the IT staff, plant operation staff and Engineers in charge of the plant to resist these efforts. It's sometimes not easy, but we sleep very well at nights knowing that some hacker on the other side of the planet cannot get into our system.
    • You're a cut above the rest

      The company that I work for, Ernst & Young, does a lot of attack and penetration assessments. While a lot of people have segregated their network out physically, through VLANS etc., we inevitably find some way to jump over to the SCADA network. This may be through Active Directory domain trusts, it my be from attacking a VLAN trunking protocol (802.1Q), etc.

      Keep in mind that just because a network is logically separated does not mean it is physically separated and there is attacks that can bridge those logical gaps.

      I think the only real solution is to "air gap" the network. Similar to how the gov't handles the NIPR/CIPR networks. Having a completely physically separated network creates challenges.

      If you guys have a physically air gapped network for your SCADA system, then kudos to you for doing the right thing, but I would say that this is not normally the case. We've done numerous assessments for energy companies and we've been able to reach their SCADA network in nearly 100% of those engagements.

      • SCADA systems have so many connections that it is almost impossible to

        guarantee that nobody can connect to it. Somebody could drop a small wireless device into a cabinet where you have some switches, and you think you have "air gaps", but they are still on your network.

        To top it off, these guys are using Windows for SCADA.
    • Still, Citect SCADA runs on Windows and has no place in safety critical

      SCADA. It would be ok for small isolated non safety critical systems.

      Also, you might be surprised how easy it would be for somebody to get a connection to your network. It IS good to separate your network, but do NOT depend on that keeping intruders out.

      You CAN connect the SCADA systems to business systems via tricks like one-way serial cable, or carrying the data by hand on a USB flash disk if once a day is enough. But, if you want everybody to see the data in real time, use a one-way serial cable (CUT the RX line) between two boxes.
      • Ah yes. You had to make it a Windows issue.

        Actually most SCADA devices run on Windows.

        Actually I believe more guys like him are out there and physically separate the network. Even a local LAN completely disconnected from the internet is uncrackable. No road in. And he did say that he separated the system from the internet. Now all you have to do is a background check on the employees and contractors where most threats come from. Within.
        • I'd want *Nix too

          For something like this, I would want a system that I could strip down to the barest of bare minimums required... you can't do that with Windows.

          • Doesn't matter if it ran off of a Abacus.

            What is important is that the firewall (hardware) is formidable. Of course if it is completely disconnected from the internet, that is the best. Obviously a Barney Fife could turn it off (janitor) or hardware failure or disgruntled employee or ... Time to rethink how security is implemented.

            By the way, I am sure you know how to turn off unneeded services in Windows like I do. I am sure they do too. What would be nice is to read the security manual from these SCADA companies and if implemented.
          • And go back to the time when a dot matrix printer costs $2500. No thanks.

            The manufacturing industry has long switched to the Windows platform for this reason. Proprietary Unix systems costs a lot of money. Ease of use and connection between the control network and the business network is one of the driving force in Windows adoption. Control engineers are more concerned with how the control systems deliver the highest quality product. They just don't have time tinkering with the OS to make it work with a dot matrix printer available off-the-shelf that's way "cheaper" compared to the vendor's Unix-only offering.

            By the way, access to plant floor data is limited to a set of read-only data for business consumption. Control parameters cannot be accessed via the company intranet.
          • Hmm

            Well, the numerous assessments performed by my company of several industrial clients shows that SCADA is not segregated properly and that an attacker may be able to get to SCADA control devices.

            In the end, I understand WHY Windows is being used of *Nix in this case, in fact, it proves my point as to why *Nix should be used. Windows is great for any number of things, but I want as stripped down a system as possible for running SCADA.

        • Modern SCADA systems have a lot of network connections and can be

          nation-wide. Even limited to a single building, you could install a small wireless device in a wiring cabinet, and then you could take your own sweat time figuring out how to break in. Windows just makes your job a lot easier. I would go with BSD and strip it to the bare minimum, and mix and match components.
          • Riiiiight!

            Just because someone can do it doesn't mean they have the opportunity. If I was securing the network to be local only, why on earth would I put a wireless device in or let someone else do it. Since I take security seriously, it would be wired only infrastructure and I would check the property on a regular basis for unauthorized equipment. You must think workers can do anything they want in most places. They can't. Someone is always watching.

            By the way, you would not make a good criminal anyway. Since you know the name and password ahead of time of the router and some systems, you should be in like Flynn. No need to figure it out. As for BSD, forget it. The SCADA equipment runs on Windows only. By the way, you couldn't crack my Windows installs anyway. Turn off all unnecessary services and you are halted. ]:)

            If you were connected to the internet, use a FreeBSD firewall called m0n0wall. That is about it for nix. The applications decide the OS for the SCADA part of it. You guys are nix nutz when all you have to do is use your head.
          • ...

            That depends, while your premise is sound on keeping an eye out for new hardware, take into account some places such as where I work, we have over 4 square miles of territory with about 2000 buildings and a limited amount of man power.

            It is possible for someone to install a wireless connection long enough to do what they need to... then again maybe not. But unless you are running a small foot print, then it's more difficult to secure the physical sites. We are constantly dealing with vandalism and all sorts of other crap from the students, so anything is possible.

            Now we have SCADA here and have had no problems with people hacking into it. Then again it's also set up to monitor only so not too much damage could really be done. And it's behind some pretty tough security set-ups. I don't have all the details but I could easily get them from the administrator, since his office is about 300 feet from me.

            Anyhow, I agree with your premise but toss the caveat of size versus man-power. ]:)
            Linux User 147560
          • ***

            The places we are talking about have security guards. To have the contractors searched on entry and leaving is very effective and using security to patrol the property with the right equipment should keep this at bay.

            The ability to put in a wireless trojan would be easier at a university than at a nuke plant. At your place, security is important but at a nuke plant it is mission critical.

            Sure if it is monitor only, then hacking into it wouldn't do them much good. They would move on. But I believe most critical applications are not controlled over the internet.

            The extra man hours do cost and that is why security paramount facilities are very expensive. Other places a breach just annoys or steals identities.
          • detectors

            Wireless network detection devices are sold over the counter. Setting a few up to monitor and sound an alarm, should one be detected, would be about as difficult as making a pot of coffee in the morning.
            Dr. John
  • It's getting easier.

    Because most SCADA providers have moved away from protocols like MODBUS and DH/DH+ to Ethernet-IP networks, where not just the workstations have IP addresses, but each individual PLC also has its own IP address.

    This is an absolute disaster waiting to happen.
    Hallowed are the Ori
    • Agreed

      But not to mention that I think certain implementations of modbus (see Full Disclosure mailing list where research was causing crashes of the modbus service), etc. have their own issues as well. As long as you can figure out how to talk to it, I tend to think it is game over.

      Systems like this are the kind of system where you're worried about even portscanning it since something terrible might happen.

    • Limiting the functionality of the communications channels IS a good way to

      limit vulnerabilities, but it would also cost us trillions of dollars if we could not use any off the shelf technology for SCADA systems. IP networks will continue to grow in the SCADA world and we need to look for ways to make them safer. Don't lose sight of the fact that better monitoring enabled by by IP networks can also make systems safer and reduce the probability of catastrophic events not related to terrorism. Nothing is ever quite so clear cut.
  • When did we ...?

    When was it that we as people get to the point of saying it is the polices fault that crimes are committed and the criminal is the injurred party. When did we forget, because a thing can be done, does not mean a thing should be done. What was the turning point that allowed the sociopath to run unfettered in our society.
    These are the underlying questions your article leads me to ask, the techy problems you so astutely point out are symptoms of a far greater threat to our social fabric, You rightly show some trepidation as to were this will end up and we better get to the root of the problem and the sooner the better for all our sakes.
    • Agreed

      And I'm still blown away by why DHS decided to release such a eye opening video to CNN. Why not just bend over for the jihadists as well? If this is where we are weakest, or have serious concerns, DHS should've addressed this first and then if they felt fit they could release the video and say, "But now we've fixed all that so feel safe!"

      Basically, DHS dropped an 0-day exploit on our entire nation.

    • Blaming criminals does NOT keep your systems any safer. It does not really

      matter why there are criminals or terrorists, we still need to deal with the fact that they exist.

      That said, we have done a lot of VERY stupid things as a country, that have made a whole lot of people in the world very angry with us and created a lot of terrorists. It is time we figure out how to reduce the number of people that are angry with us. We can not track down and kill all of them as Bush and Cheny would have you believe.