S4xEurope Video: IRONGATE – Technical Deep Dive

June 13, 2016 by Dale Peterson Leave a Comment

We decided to put the IRONGATE video from last week’s S4xEurope out first. There is no new big reveal over the information put out in the FireEye article, but Rob provides a lot of context that makes it easier to understand. He also focuses on unanswered questions and a comparison to Stuxnet.

If this is really a Grad Student Research Project, I would think we would hear who did it in the next couple of weeks. Some of the S4xEurope attendees were going to try to help make contact with the author of PLCSIM.

Here are some highlights of the video:

3:56 Why IRONGATE is interesting from a technical perspective.
6:08 Is the industry numb to this type of release due to naming, hype, process?
8:20 A flow chart showing the major steps of IRONGATE.
14:20 The actual DLL replacement code.
16:20 Record and replay code.
19:25 Comparison and contrast with Stuxnet.

The last ten minutes is Q&A.

Basecamp Redux: Siemens S7-1500 PLC Gets French ANSSI Certification

May 23, 2016 by Dale Peterson Leave a Comment

We will have a series of articles coming soon on the new Siemens S7 PLC security features, and I’m pleased to announce that Oliver Narr of Siemens will join representatives from GE, Rockwell Automation and Schneider Electric on our NextGen PLC Security panel at S4xEurope, June 9-10 in Vienna.

Consider this a bit of appetizer as last week Siemens announced their S7-1500 had been certified to meet the short term security requirements for a PLC as written in a French Protection Profile from l’Agence nationale de la sécurité des systèmes d’information (ANSSI). This is not a Protection Profile in the Common Criteria format, but it is the same principle. An organization writes a Security Target indicating how they meet the requirements of the Protection Profile. A third party, in this case Amossys, tests that the Security Target is accurate and complete.

The brief threat model importantly includes “Attacker on the supervision network: the attacker controls a device plugged on the supervision network of the TOE.” So the threat agent is inside the cyber security perimeter.

The amount of detail in the Protection Profile and Security Target is minimal and leaves a number of questions. For example,

Execution mode alteration: the attacker manages to modify the execution mode of the TOE without being authorized (a stop command for instance).

Integrity and authenticity of commands and PLC mode: The TOE must ensure that the execution mode of the TOE can only be modified by authorized users. This implies, in particular, that they are authenticated.

I believe this means that a user, which the Security Target also states “may be a device or a third-party software”, must have authenticated to the PLC before these commands are accepted. This is not the same rigor as authenticating the source and integrity of the command, and it’s potentially vulnerable to spoofing and man-in-the-middle attacks. Which relates to another security claim:

Secure authentication on administration interface: Session tokens are protected against hijack and replay. They have a short lifespan. The identity and the permissions of the user account are systematically checked before any privileged action.

The rigor of the security controls and the rigor of third party analysis is unclear from the documentation, but it may be well specified somewhere I have yet to see.

Still this is a positive step forward as the documents highlight key security controls for a PLC that are met to some degree. Some of the important security requirements in this Protection Profile include:

Signed firmware and secure boot
Proper handling of malformed input
Secure credential and key storage on the PLC

You may have noticed the “short term” in the previous paragraph. There is another Protection Profile with medium term security requirements. This added features such as log and alarm integrity. Hopefully there will be a long term security requirements Protection Profile with an even more rigorous set of controls, particularly around authentication and recovery.

A number of other Level 1 device vendors participated in the Protection Profile development, e.g. Belden, Phoenix Contact, Schneider Electric, so it is likely other certifications will be coming shortly.

Redpoint Release: Siemens S7 Enumeration

April 15, 2014 by Dale Peterson 2 Comments

Redpoint is our internal project to develop NSE scripts for Nmap to identify and enumerate ICS devices. We are releasing some of the more helpful and less intrusive scripts on GitHub. The first was for BACnet devices, and now we have released a NSE script to identify and enumerate Siemens SIMATIC S7 PLCs.

Full credit for the idea and concept for this script goes to Positive Technologies and SCADA STRANGE LOVE. We ran PLCScan to generate the pcaps, copied what they found useful to enumerate, and used it as QA for our Redpoint script. This script is basically a way to get the PLCScan capabilities in Nmap. Since we use Nmap for enumeration in our assessments and have a number of Redpoint scripts we run in an Nmap category, it was worthwhile for us to port it over. Hopefully the large community that likes Nmap will find it useful.

Let’s go to the screen shots:

We pulled the information from the Module field to identify the model, eg S7 315, S7 317, S7 312. Beyond the value for inventory purposes, it is helpful to identify what are the high powered, most critical PLCs or how large and complex the process you found is.

The System Name and Plant Identification Fields could be very helpful if they were entered by integrator or asset owner. We have scanned devices where the System Name was descriptive and others where it was not changed from the default (and therefore not included in output from the NSE). We have yet to see the Plant Identification Field used, but a large organization with multiple plants may find this helpful, as would the person enumerating the S7 PLCs.

Image by Simon and Katrina McPherson

S4x13 Video: Recovering Siemens S7 Level 3 Passwords

May 20, 2013 by Dale Peterson Leave a Comment

Eric Johansson from Management Doctors in Sweden brought over a great Siemens S7 demo rack to demonstrate some attacks on the Siemens S7 PLC family.

At 7:45 Erik shows the Level 3 (highest security that controls read/write access) can be recovered by capturing the packets sent to the PLC. This was actually known and included in Siemens documentation (July 2011) as a potential weakness — with advice to not let the bad guys on your network.

At 14:13 Erik shows a denial of service attack on the Siemens equipment he brought to S4x13. It requires a power cycle and administrator action to put the PLC back into Run mode.

The Q&A at 18:19 is quite interesting.

Arne Vidstrom of FOI was part of the team that did this work.

John The Ripper – S7 Password Cracking

May 10, 2013 by Stephen Hilt Leave a Comment

At S4x13, Scadastrangelove (@scadasl) released a offline brute force password cracking script (http://pastebin.com/0G9Q2k6y). Shortly after the script was released the functionality from that script was added into John The Ripper. Documented in The Rack is how John The Ripper is capable of cracking S7 password hashes using the Scadastrangelove technique of offline password cracking from a packet capture.

John The Ripper has been around for many years, and is one of the most common password cracking utilities out there. With an add-on plugin and a script that is easy to run, the password hashes are extracted out of packet captures, and cracked using John The Ripper.

The use of John The Ripper outside of the normal workstations and servers inside of ICS environments is very limited, as most devices you can’t get the information required to run the software against the password hashes.

With the rise of password complexity requirements inside of ICS environments, auditing the password complexity of PLC and like devices can be difficult and rely a lot of how much you trust the engineer. As an example there is nothing to say that the PLC configuration that you are looking at on the engineer workstation is the one that is truly pushed out to the PLC. With the ability to gather information from a packet capture and then verify the password complexity adds that much assurance to an assessment.

However, this utility can be used for nefarious purposes, take an example where on a support portal for a vendor some one uploads a packet capture to try to get help, now this packet capture is downloaded by an attacker. This utility makes it easier for an attacker to crack the passwords of S7 devices. This gives an upper hand on the ability to write custom malware to alter configurations and the likes. Thats not to be said this couldn’t and wasn’t a capability before, this just took their ability and made it easier for them.

Password cracking is dependent on the hardware in which you are running the password cracking software on. The only testing I was able to perform was on some packet captures that were given to me from Sergey Gordeychik of Positive Technologies, and the passwords were very simple passwords that cracked within a second or two. The more complex the password the more time it takes to crack via brute force techniques, with more and more password breaches happening the word lists are getting bigger which helps the dictionary attacks get that much more powerful. I expect to see more ICS devices fall to this type of attack in the future.

Photo from awaitingdawn

S4x13 Video: WinCC Under X-Rays by Sergey Gordeychik

March 21, 2013 by Dale Peterson Leave a Comment

Sergey Gordeychik of Positive Technologies presents in 45 minutes a large number of vulnerabilities in WinCC at S4x13 — yes the WinCC of Stuxnet fame. There are also some findings on the S7 PLC’s. The work is part of the impressive SCADA Strangelove effort.

He deals with a lot of old exploits, such as an 1825-day exploit in OpenSSL. This and other libraries were compiled in 1997. WebNavigator and ActiveX issues, some discussed and some left as an exercise for the viewer … such as the hint ComRaider still rocks.

My favorite part is at 29:45 where Sergey discusses “Can Project Be Trusted”. The Project is the logic that the PLC is implementing. Of course he shows it cannot be trusted by simply patching The Project. Patching “on the fly” would allow an attacker to change the logic, cause a problem, and then change it back, thereby hiding the attack. You have no integrity.

There is also a lot of new, fresh for S4x13 material here.

The Windows portion of Stuxnet always felt like overkill, belt, suspenders and two more belts. With all these security vulnerabilities and exploitable issues it seems unnecessary to have wasted those Windows 0days.

One last note – this presentation will be interesting for Stuxnet and ICS vuln historians. Sergey shows a number of forum screenshots showing some of the vulns being known and discussed in 2005, 2006, 2008. And a little comment in the Siemens’ code “dreckige hackerei”.

Offensive Cyber Weapons: Construction, Development and Employment Paper

February 18, 2013 by Dale Peterson 1 Comment

The Journal of Strategic Studies published my article Offensive Cyber Weapons: Construction, Development and Employment, and it is now available for free download. Thanks to Thomas Rid for inviting me to write this and organizing the five articles on this topic.

I had two main purposes to writing this article. First, to address the ease or difficulty in creating a cyber weapon to attack a critical infrastructure control system; and second to highlight the importance of deploying the cyber weapons before you need them and maintaining communication with the weapon.

Who Can Create An ICS Cyber Weapon?

Stuxnet has greatly confused this discussion because the delivery mechanism was terribly over-designed (belt, suspenders and another belt, and maybe a rope) and the modification to PLC logic was long, complex and clever.

In the article I give three examples of simple, moderate and complex cyber weapons. The distinction is based on how much skill and effort the attacker places on modifying the process. It is a days work or so to create a cyber weapon to stop the process or brick the PLC. The level of effort and sophistication of the cyber weapon increases from there based on what changes to the process are required.

What seems to be lost in most discussions is that the key participants in developing a cyber weapon aimed at the critical infrastructure are not security experts, researchers or hackers; the key participants are subject matter or process engineers and automation professionals. A moderately skilled security professional with access to the PLC can figure out how to upload whatever he wants to the PLC. Reverese engineering the process and deciding the best way to cause difficult to recover damage or stealthy damage to the process is more difficult.

Deploying And Maintaining Communication With An ICS Cyber Weapon

Now that the potential of a cyber weapon is known thanks to Stuxnet, there are a growing number of people and organizations responsible for offensive cyber capabilities. For the paper I imagined I was tasked with ICS offensive cyber operations for a government.

A government or other organization has a list of likely enemies and is now developing a list of critical infrastructure systems they would like to take out if the situation warrants. This list gets handed to the group(s) responsible for offensive ICS cyber operations. There are two tasks that are not being publicly discussed that are critical to success:

1. Deploy Before Needed – An offensive organization often cannot wait until the weapon is needed to develop and deploy it. Developing and pre-staging weapons is common. If you want to take out an enemies fuel supply, water or electricity when hostilities start, it is necessary to have the offensive weapon in place for that possible conflict. Based on leaks and releases from the Obama administration it is clear that deploying a cyber weapon is an option, and some analysis of international law indicates that deployment on an enemies ICS without causing harm is not an act of war (another future article topic).

Like most weapons produced and deployed, the number of ICS cyber weapons used is likely to be a small percentage of what is deployed and ready to be used. One of my predictions is that there is a major effort to create and deploy ICS cyber weapons, and that some of these will be accidentally discovered.

2. Communications Persistence – If you agree with the strategy prediction that ICS cyber weapons will be deployed in potential future target ICS, then the offensive entity needs a way to activate the ICS cyber weapon. They may also want to update or modify the attack code prior or during the attack. This requires the ability to communicate with the cyber weapon.

Communication could take place through the target’s communication networks and compromised computers, but this is risky. During an attack, external network connections are often removed as the first response. An attacker would prefer to have a communication channel they control, and the Power Pwn is a great commercial example of this.

One of the remaining mysteries of Stuxnet is how it was deployed and how the creators communicated with it. David Sanger’s book provided some clues, but also added confusion. He mentions the Stuxnet PLC attack code was updated many times, and some indication that Siemens’ personnel were the vehicle. Yet Siemens publicly denies any activity with the Iranian nuclear program during that time period. Even if Mr. Sanger is correct, an external communication capability would fit in with the over-designed nature of Stuxnet.

This part of the article was edited down to meet a word count, but it is the most important part for loyal blog readers who likely have known much of the rest of the article.

PROFINET Fuzzer Released

December 17, 2012 by Dale Peterson Leave a Comment

Roland Koch and students at the University of Applied Sciences in Augsburg, Germany have released a PROFINET fuzzer called ProFuzz. While not a top 3 protocol in the US, PROFINET is the most widely used ICS protocol in Europe, particularly in the manufacturing sector. PROFINET is the Ethernet enabled version of PROFIBUS, and Siemens makes PROFINET chips that a large percentage of the devices use. This fuzzer would be particularly useful to test vendors who develop their own PROFINET stack.

ProFuzz runs on the Scapy fuzzing framework. A solid choice in our opinion — we used Scapy in a previous S4 course to teach students how to develop a DNP3 fuzzer. ProFuzz currently will fuzz the following PROFINET frame types:

afr (Alarm Frame Random)
afo (Alarm Frames Ordered)
pnio (Cyclic RealTime)
dcp (DCP Identity Requests)
ptcp (Precision Transparent Clock Protocol – BETA)

Roland and the team are working on a PROFINET preprocessor for Snort with a scheduled release date of February 2013. It will be released as open source code. This is not an easy project as PROFINET is much closer to EtherNet/IP in protocol complexity as compared to the very simple protocols such as Modbus TCP and DNP3.

It’s great to see the students develop some practical, useful tools that will be released and actually used.

Years ago the organization responsible for the protocol, PI, released a security whitepaper whose basic guidance was the classic don’t let the bad guys get to your PROFINET devices. Any European readers have an update on efforts to integrate security measures into PROFINET? Is there a device we should add to Project Basecamp?

Siemens – Time For Code Review / SDL

November 8, 2012 by Dale Peterson 2 Comments

A I spoke recently with Kelly Jackson Higgins of Dark Reading about the number of vulnerabilities being found post-Stuxnet. This obviously is due to the increased attention from researchers and hackers.

The data also shows some vendors and products have a steady stream of disclosed vulnerabilities. There are at least two reasons for this.

A Pack Mentality – much of the SCADA/ICS software is still a bit unknown to the vulnerability hunters. When they learn of another product from the first vulnerability, they download it and look for other vulns. The original vulnerability often shows a simple, 90’s or early 2000’s type of vulnerability that makes vuln hunters salivate. If the developers made that simple mistake there are probably many more.

The software is fatally flawed because it was not designed with good coding practices or any part of a reasonable security development lifecycle.

A good example popped up today with Sergey Gordeychik of Positive Technologies presentation at an event in Seoul. Jeremy Kirk of Computerworld covers it in Siemens Software Targeted By Stuxnet Still Full of Holes. Apparently Sergey and his team have found more than 50 vulnerabilities in the current version of WinCC.

Siemens could patch these 50 vulns and attackers would easily find additional vulns. What Siemens and other vendors need to do is stop and do a security code review of the product. The result may cause a significant effort to remove functions, change the coding practices, and other things that software developers could discuss in great detail.

The ICS community just needs to look at Microsoft and other companies that have faced this problem. Bill Gates famously stopped all work for a few months back in 2002 for a security code review on all development efforts. Even after that Microsoft had a huge legacy code issue, but they realized just fixing identified vulns was a treadmill not a solution.

We should applaud vendors for being more open about accepting and fixing vulnerabilities, as well as disclosing this information to customers. The improvement in Siemens CERT over the last year is clear. Rockwell Automation has done a good job in recent years at researching disclosed vulns and identifying all affected products rather than just what the researcher discovered. The ICS community needs more than improved vuln handling though; better code quality is required.

Picking on Siemens a bit here with questions customers should be asking:

What is your security development lifecycle (SDL)? What products that we are using have been through that SDL? What is the plan to review or migrate legacy code in the products we use into this SDL?
Can you characterize the vulnerabilities that Positive Technologies found? What were the root causes of these vulnerabilities? What is your program and schedule to review the rest of the code for similar errors that may result in latent, undiscovered vulnerabilities.

At least a handful of ICS vendors are 3 to 5 years into their SDL efforts and, while still a work in progress, can demonstrate the SDL is actually being applied and making a difference. They have security design documents, threat models, security code review, rigorous fuzz testing, security in QA and test plans and other elements. They train their developers on secure coding. It’s a shame, but understandable, that these vendors won’t talk publicly about the progress they have made.

The SDL issue is another area where User Groups and procurement can make a big difference. An enlightened vendor will realize that the cost of secure development practices will be recouped in less cost in fixing bugs and vulns — now that the ICS community is beginning to expect them to fixed. A vendor that has not seen the light will only be convinced by customer and prospects demanding it.

Malware Forum Logs from Control Systems, Part Deux

November 7, 2012 by Michael Toecker 6 Comments

Last September, I did a guest blog post titled “Online-Malware-Support-Shows-Infected-ICS-Computers”, where I searched for HiJackThis posts containing automation software. Basically, there are forums available to users that had been infected with viruses. These users can run a set of programs, including HijackThis, DDS, OTS, and others, to pull information from the system. This information is analyzed by the forum community, and recommendations given to those who are infected. Last year, I found data from many control systems being put on these forums because the user could not fix their computer.

With all the activity regarding Shodan and ICS recently, I figured there should be another showing of just how many ICS computer interact with the Internet, and are even potentially infected with Malware. Remember, the main vector now for infecting normal user systems is via web browser exploits, XSS, email phishing and other less direct methods. I went for an Electric Power focus this year, locking on to several very specific programs that interact with Electric Power infrastructure. The programs I selected are relay configuration programs, used in Electric Infrastructure to configure the devices that open and close breakers on Transmission and Distribution lines. These programs aren’t like SCADA HMIs and OPC servers, their only purpose is to provide a user interface that allows management and reconfiguration of a digital protection relay.

[Read more…]

Digital Bond

For Secure & Robust ICS