Sign in to follow this  
Followers 0
CX_Luigi

Industrial networks attacked by a custom-made virus

17 posts in this topic

As far as i recall this is one of the first instances of attacks to a process control or industrial control network. That Siemens is specifically targeted in this instance is also important, giving their great diffusion: Link to article on Computerworld

Share this post


Link to post
Share on other sites
Old subject. Some Siemens SCADA applications WERE compromised and they completed a very thorough and professional job at resolving the issues. LET'S MOVE ON

Share this post


Link to post
Share on other sites
In my humble opinion, this is a big topic and is important to those of us in the industry. This is not a "Siemens fixed a security hole" story. Take a look at the detail that Ralph Langner has put into his analysis: http://www.langner.com/en/index.htm Stuxnet wasn't espionage or commercial sabotage. Stuxnet is a weapon.

Share this post


Link to post
Share on other sites
Ken, so when and where do u think AB Rockwell products will be compromised? Which product and platforms? Siemens has done a pretty darn good job at resolving this issue. Hope that Rockwell is ahead of the game! Edited by BITS N BYTES

Share this post


Link to post
Share on other sites
Please don't read my posts as being critical of Siemens; I think they've done a top-notch job responding to this issue for the systems that were collateral damage. Siemens was part of the target because they're the #1 company in industrial automation and because they happen to build the controllers that run the systems that are the Stuxnet worms actual target. I hope that when an exploit appears that targets Logix that we detect it and handle it as aggressively as they did. A former RA guy is the chairman of the ISA99 committee on control system security. We work with some of the same labs that are investigating Stuxnet in the USA. And it scares the living daylights out of us. From an international espionage and cyber-warfare perspective, this story is huge and deserves a great deal of attention. From an industrial control systems security perspective, it's also worth continuing to look at. I have found gaping security holes at some of my customers, but I've never gotten enough visibility for these problems to get them to do anything but install simple antivirus software on some of their workstations. Most of us work on systems that don't get our countries threatened by the UN. But think about how many controllers are out there sitting in "remote run" mode, wide open to the injection of code by a sophisticated attacker. All that protects them is obscurity. That's not enough.
1 person likes this

Share this post


Link to post
Share on other sites
I think there's a fundamental difference here. Windows and also Siemens controllers accept machine code and run it blindly. AB PLC's operate on tokenized or similar code. It would be akin to trying to infect a Java based system...sure you can inject Java bytecode and probably even get it executed (not sure I fully trust the Java security model). But since you can't inject raw code (maybe you can but Rockwell doesn't publish any details about the machine code interfaces in ControlLogix for instance), you can't do arbitrary actions. It is certainly possible to at least crash them and I've done it accidentally a few times by sending code to a lower revision PLC written for a later revision (sending PLC-5 a MSG command with an invalid format). But actual machine code injection seems highly unlikely. Windows and Siemens routinely accept DLL's and execute them outside of a sandboxed or otherwise controlled environment leaving them highly vulnerable. It is however fairly easy to design DoS (denial of service) attacks by simply crashing various systems in lots of ways or to screw with IO card configurations via the existing published interfaces. It doesn't take too long to find ways to crash AB systems. And since it is a known machine code format, it wouldn't surprise me to see hacks that work against FactoryTalk View SE or ME. Then again, that platform is so unstable that I'm not sure that the end users would be able to tell the difference. Keep in mind the details on the Stuxnet attack: 1. Four previously unknown Windows exploits were used. 2. Siemen's own communication/database structure was used to spread the malware around. 3. User-defined blocks with what appears to be spyware (based on the reports...nobody is publishing details) with application-specific names were injected into any PLC's that were located by the Stuxnet system. 4. Windows security was bypassed with 2 different sets of credentials which revealed that two different private keys used in the Microsoft certification system were stolen. Items 1 & 4 reveal that the Stuxnet authors were both very knowledgeable of Windows security and highly skilled. Item #4 may suggest access to considerable financial or other connections. Item #3 reveals that the code was developed for a specific target (the Iranian nuclear program). It also reveals again, very advanced skill & knowledge of Siemens software platform. Taken together, it seems to point towards an espionage effort either by a government or corporate entity. Given the same highly concerted and well connected effort, I have no doubts that similar attacks could be made on AB software and hardware.

Share this post


Link to post
Share on other sites
Langner has made a valid point on his web page, the cat is out of the bag as far as industrial control systems are concerned. Now that Stuxnet has demonstated that a virus/worm/trojan can attack industrial control systems the amateur hackers have a new target that they didn't even know existed before Stuxnet. They have some new toys in their toybox and they will want to play...

Share this post


Link to post
Share on other sites
I think this topic demands some additional discussion also. This isn't a Siemens matter, it is an area of growing concern no matter what platform you are using. To "move on" would be to put blinders on and act as if nothing had happened. An incident in Australia in 2001 where a disgruntled employee for Queensland's sewage treatment plant was able to dump 264,000 gallons of raw sewage first made me realize that security by obscurity was no longer a viable solution. I couldn't find the article from 2001 but here is an article that mentions it among others http://ciip.wordpress.com/tag/scada-incidents/ What makes the Siemens incident interesting...or concerning...is that it was capable of spreading. There is now more to fear than then disgruntled employee who happens to know the master password and the WEP keys to the wireless system.

Share this post


Link to post
Share on other sites
Given the latest developments that have came out about the Stuxnet virus, I thought I would give this thread a bump. Without getting too far into the politics involved with it, one of the leading conspiracy theories behind the Stuxnet virus is that is was written by some nation to specifically target Iran's nuclear program. Whether it was written for this or some completely other target, it seems it was written for a particular purpose. But it seems there were plenty of civilian casualties that could have been any of our systems with over 100,000 infections. It is now apparent to me that every system I have probably installed is vulnerable to a similar attack, including those I have in extremely secure facilities. What precautions should we be adopting to prevent such attacks. Ken even mentioned things as simple as not leaving a controller in "Remote Run". Until now I've always been annoyed by finding controllers that were not in "Remote Run", but now I'm even questioning that. Here are some links I found about Stuxnet but I don't know what is concrete evidence and what is not http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf http://news.cnet.com/8301-27080_3-20018530-245.html http://antivirus.about.com/b/2010/10/02/debunking-the-bunk-of-stuxnet.htm

Share this post


Link to post
Share on other sites
Here's a good resource for people interested in control systems security. http://www.us-cert.g...tems/index.html And here is a bit of info relating to stuxnet. It's listed as ICSA-10-238-01, 01A, and 01B. *EDIT* Just noticed that ICSA-10-201-01, 01A. 01B, and 01C are specific to the siemens attack also. http://www.us-cert.g...rt/archive.html *EDIT* Please be mindful of the distribution restriction at the bottom of those documents. They are not classified, but they don't want you editing these or posting them on public websites. If anyone has any specific security questions about control systems, feel free to hit me up. I'm not very well versed in the "OMG they're out to get us, what do we do?" type questions though. Every individual security implementation has specific requirements, I'm not very good at large generalized questions about motivations, theories, regulation, etc... I've been away from MRPLC for a few years now, glad to be back!! Edited by Camel

Share this post


Link to post
Share on other sites
Good to see you back! I'm not trying to present a panic scenario. The main things about this virus that concern me is it's supposed ability to spread to other targets and alter PLC code without human intervention. Up until now your biggest threat required human action such as a disgruntled employee.

Share this post


Link to post
Share on other sites
Your controls systems are only going to be a secure as the effort you put forth to secure them. A few things I always try to preach are: 1. Always firewall your controls systems from your business network or any public network. Use DEFAULT DENY rulesets in the firewall. I set up a redundant firewall set once using OpenBSD (PFSYNC, CARP, PF) and a pair of old dell poweredge 2650's for around 100 bucks.... 2. Disable USB thumb drives on every machine. 3. Don't use autologin or shared logins. Don't make password policies so complex that people have to write their passwords down.... 4. Avoid wireless. If you can't avoid wireless, use frequency hopping spread spectrum radios (FHSS). 5. Use a virus scanner. 6. At least put a little bit of thought into physical security. If someone with malicious intent can just waltz into your control room with a gun, security doesn't matter anymore. 7. If it's critical that your control systems is running, and it's running on a windows based OS take a look at placing the machine in special security limited functionality (Windows SSLF mode). http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems/microsoft_windows.shtml 8. Update your software. If a vendor is slow at this, maybe it's time to look at other alternatives. It's easy to protect your systems from whatever has already been discovered. The trick is trying to mitigate the damge from something that was dreamed up this morning.

Share this post


Link to post
Share on other sites
While points 1 through 7 were valid, I wanted to discuss 8 a little more. This is the main reason I've always been reluctant and at times flat out refused to put PCs in my equipment. Who is suppose to update the systems? While I hope the end user would take all steps possible to take care of their equipment mechanically, electrically, etc, how often does it happen? On most the way we put it in today is the way it will be until their is a problem or it is decommissioned. Do we need to run back to old jobs every time AB, Siemens, or whoever makes a firmware change? That would be too costly. But if something like this was to happen to one of my systems it would be my reputation that would take the hit. I guess I'm looking for what steps should be taken on the front end to do our best to prevent this from happening given today's circumstances? Do we allow machines to run in remote run anymore? Where do we draw the line between easy distribution of data to our clients and keeping our systems safe?

Share this post


Link to post
Share on other sites
First thing you should do is analyze the impact that any patch will have on your systems. Second, if your company has a windows based domain, they probably have a server running windows server update services (WSUS). You could push patches to your control machines with this. The setup that I have ran across in the field was based on altiris. They would get a wonderware patch, create an installer, and push it out to the controls machines that were running altiris agents. On the plc side of things, you would have to check and see if the software your updating supports the firmware in the plc. If it doesn't, someone will be making a trip of some sort. You could update the firmware in a spare processor and download the PLC app to it, then ship it to where it needs to go with instructions on how to change it out. I've seen a company make that work. They even made a video on how to change it out for the plant people. Most methods that IT departments use to manage thousands of pc's are applicable to industrial control systems. You just have to get creative and learn a few more acronyms. Edited by Camel

Share this post


Link to post
Share on other sites
In light of the recent Duqu worm (http://www.isssource.com/tag/duqu/ ) I thought I would comment on this thread. In addition to the 8 security enhancers mentioned by Camel, a 9th point would be to implement sifts monitoring into your control system. Sifts monitoring will help detect any changes to the programs on Windows or Linux based devices. Unlike a virus or antivirus, it isn’t signature based therefore you don’t need to do daily updates to get new signature files. You can monitor multiple devices from a single security appliance. To find out more about how this could help prevent a Stuxnet variant account check out: http://www.phoenixcontact.com/local_content_pdf/pdf_eng/Post-StuxnetIndustrialSecurity.pdf

Share this post


Link to post
Share on other sites
Our friends at No Such Agency, pulled down the link you have posted in 7... Kinda disappointed, I wanted to read up on SSLF.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0