Dillon Beresford of NSS Labs finally went on stage to discuss the multiple vulnerabilities he has found in the Siemens S7 PLC’s. In Part 1 of the report, I’ll go into the details of the attacks as I understand them. Note that Siemens customers are still not receiving any detailed information from Siemens on what the vulns are and or the potential impact. The information from ICS-CERT is similarly sparse. This despite knowing the information and knowing Dillon would present it at Black Hat.
Hard Coded Credentials / Back Door on S7 300
I’m sure many loyal readers have already learned there are hard coded, not default, actual hard coded credentials in certain versions of the S7 300 (user: Basisk, password: Basisk). The credentials allow login to a telnet and http server that were unnecessarily left on the PLC.
Once logged in an attacker can get a memory dump of the PLC including all of the program logic. The type of information that would be required if an attacker were going to modify the process in a sophisticated way a la Stuxnet.
This is a great example of why reducing the attack surface as much as possible is important. If Siemens had removed these unnecessary servers, the vulnerability would not exist.
Solution: Upgrade to an available software package that removes this unnecessary software.
Mitigation: ACL’s in the switching/routing infrastructure to prevent access to the Telnet and HTTP server ports.
Command Shell, Including Linux Bash, on S7 300
The hard coded password allows an attacker to access a command shell on the S7, but this is not the Linux Bash. (Note: the S7 is running a 32-bit Linux OS). I couldn’t get a firm understanding of what command shell an attacker accesses with the hard coded password. It appears to be some type of debugging capability for Siemens engineers.
Here is a bit of news that was not at Black Hat – Dillon was able to escape from the debugging command shell and get Linux Bash. He has no immediate plans to demonstrate this, but it should be further impetus to upgrade to software that removes the unnecessary servers.
Solution: Upgrade to an available software package that removes this unnecessary software.
Mitigation: ACL’s in the switching/routing infrastructure to prevent access to the Telnet and HTTP server ports.
Metasploit Modules
Dillon has written eight Metasploit modules. I was writing them down furiously as the slide flashed and got at least a partial name of all of them that is descriptive enough to understand:
- 1200_cpu_cmd
- 300_cpu_cmd
- mem_dump
- 1200_cpumem_write
- disable_mem_protect
- cmp_protect_disable
- 1200_cpu_dos
- 300_cpu_dos
In addition to the specific attacks or functions these modules perform, Dillon very correctly pointed out that they would be useful templates for attackers/pen testers to build from as they have the basics for communicating with the S7.
He is not going to release the Metasploit modules to the general public immediately to give owner/operators time to address the vulnerabilities. He has not set a date yet when they will be released. My recommendation is he take a Tipping Point ZDI approach and set a firm date. He likely will share these with selected individuals, and we hope to get our hands on them.
Replay Attack
We covered this in Making Sense of Siemens Vulnerability Conflation/Confusion. The replay attack is actually a misnomer because the weakness in the limited password security in the S7 protocol allows an attacker to affect or modify the process in any manner he chooses.
Compensating Controls: Use all access control features you have in the switching/routing infrastructure to limit access to the PLC to authorized IP addresses. If your S7 PLC has a physical keyswitch, available in older models, set it to prevent changes. This will have an operational impact as well. Keep an eye out for IDS/IPS signatures that are likely to be developed around these vulnerabilities.
Denial of Service (DoS) and Denial of Control (DoC) Attacks
The replay attack and other ways of affecting the program logic are easy ways to create a DoS / DoC condition. Dillon also identified some other legitimate commands that cause a DoS. For example:
- Issuing repeated Start and Stop commands brought the PLC’s down and required a reboot to bring the PLC back. The two cpu_cmd Metasploit modules do this.
- A read request to an invalid address shuts causes a segmentation fault and requires a reboot.
- The password for the weak password protection feature could be changed. This would prevent the operator from making changes. Also, the password protection feature by flipping the appropriate bit.
If Dillon found these in a short time, this is likely only a partial list of the implementation flaws in the S7 that could cause a DoS.
Mitigation: These specific attacks are ideal situations for IDS/IPS signatures.
Dancing Monkeys HTML Easter Egg
The developers left an Easter Egg in the code in the form of four dancing monkeys on an html page. Seemed appropriate. I was surprised at the attention this got beyond the humor. Many felt this was damning evidence that Siemens had no control over their engineers. My view is Siemens has a complete lack of an SDL based on the other vulnerabilities Dillon and others have identified. Control of the engineers is not even close to the biggest problem.
Finally, Dillon gave his level of effort for this work. US$10K and two to three months of work on nights and weekends. Nice job by NSS Labs providing the seed money and supporting Dillon in his work.
Long Post Warning: If you want a quick read, skip down to the bullets on our suggested ICS guru message.
After covering the technical details of Beresford’s presentation at Black Hat in Part I, let’s look at the politics of the situation and the ICS vendors, owner/operators and ICS security guru’s response.
The best way to look at both Stuxnet and the Beresford vulns is they are the first instances where the insecure by design and poor security posture of PLC’s became widely known outside of the niche ICS security community. In Stuxnet it was the dramatic impact of the attack on the Iranian nuclear program, and the Beresford vulnerabilities showed that neither ICS expertise nor vast resources were required. Both have whetted the appetite of hackers of every hat color to break PLC’s and other ICS components.
The attendees at Dillon’s presentation were taking a lot of photo’s and paying great attention, even during some of the slower parts waiting for things to happen in the demo. I can’t claim to be in sync with the Black Hat audience, but it appeared to me that the reaction was much more “isn’t that cool, I’d like to try to do some of that” rather than “this is a problem we need to fix”. We will have to wait and see what type of research/hacking and results come from this.
ICS Security Guru’s Need To Stop Rationalizing Vulns
Why is it whenever a PLC vulnerability is brought up, the ICS Security Experts asked to comment start off explaining how this is a longstanding known problem in all PLC’s due to the lack of access control? They are not wrong, but the primary message should be this vuln results in a huge security risk, and the vendor needs to provide a secure PLC asap.
Earlier I blogged on Eric Byres and Joel Langill giving Siemens cover at the Siemens user group meeting. Now I have to call out Jonathan Pollet and Tom Parker from the Black Hat press conference. These are all top notch ICS security professionals, and competitors, who would do a great job helping any owner/operator secure their SCADA or DCS. However, they are falling into the rationalization trap that I was in for years.
At the post-Beresford press conference, Jonathan and Tom followed Dillon’s explanation of the Siemens vulns with the usual explanation that this is a well known problem in ICS, protocols lack security, affects all vendors, will be around for a long time due to product life cycle, … none of this is wrong, but it should not be the message we are giving the press. I was watching the press, and it definitely took the enthusiasm out of the room that this was an important story. It was old news.
We should be embarrassed, I know I am, that we have made almost zero progress on PLC security over the last ten years — the lost decade. The fact that is a long-standing, wide-spread, well-known in the community problem is nothing to highlight when we have the world’s attention that might help or force the PLC vendors to finally make progress.
A reporter’s follow up question asked about the real impact of this. Again the ICS security experts tried to calm things down with talks about systems being heterogeneous and difficulty of widespread attacks. Again, not wrong but why focus on downplaying the problem. Why not focus on owner/operators with a S7 PLC need to be very concerned because Dillon’s attacks or slightly modified Stuxnet could take out their plant or SCADA system with huge loss of money, possible loss of life, environmental damage, and other negative affects?
ICS Security Guru’s and others who talk to the press, consider changing the message to:
- This is very serious set of vulnerabilities that puts anyone who has a process that relies on S7 PLC’s at risk. If an attacker can gain access to the PLC, they can affect the process with potentially huge financial loss, destruction of systems, environmental impact and even loss of life.
- Siemens needs to provide clear and honest information to their customers on the vulnerabilities and impact. Not a small job since Dillon has found 15 already, not to mention remaining Stuxnet issues. They need to stop denying problems. Stop misleading and lying to their customers. Stuxnet vulns in the PLC are not fixed. The vulns Dillon identified have not all been patched. Dillon’s work could be leveraged by bad guys to compromise SCADA and DCS that use Siemens’ PLC’s, again with grave results.
- Siemens needs to provide customers with information on how they will fix each vuln, integrate missing security features, and firm dates/versions when these will be available. In parallel, they should be providing customers with compensating controls. Who better than Siemens to provide IDS/IPS signatures for these vulns to their customers?
- Siemens security development lifecycle is hugely flawed. A number of the Beresford vulns are not missing security features, they are the result of very poor software engineering practices. Siemens should tell customers what modifications are being made to the SDL to prevent this in future code.
Full stop. No temporizing the message.
I know many colleagues in this small ICS security niche would say this is unfair to Siemens. Is it really our job to defend Siemens to their customers and the press? Be just as tough on each vendor when this comes up, rather than easing up on Siemens with weasel words. If it makes any of you feel better, Siemens will not be out there by themselves for long. We have our Project PLC Basecamp results scheduled for S4 this year, and I’m sure many others are inspired by Black Hat to look hard at PLC’s.
Stuxnet Politics
Dillon repeatedly stated that his motivation to start this work was to prove that Stuxnet or a Stuxnet-like attack would not have required a nation state level of effort. On this point he is only partially right.
He has proven that a highly skilled security professional with no ICS experience and limited resources can learn to attack PLC’s and affect the SCADA and DCS process.
Where Stuxnet differed from Dillon’s efforts was the sophistication of the engineering in attacking a couple of specific nuclear-related processes. First it was necessary to get the project file / process logic. Was this done with HUMINT? Directed hacking on one of the integrators?
This was followed up by a detailed effort to understand the complex logic in the process. Then the Stuxnet team determined how to modify the process in a way that caused failures that would be difficult to detect the root cause. The ladder logic that was written for the attack on the S7 400’s was substantial.
So the Stuxnet effort included someone like Dillon, perhaps some HUMINT, a process automation expert with Siemens system experience, and one or more nuclear experts.
Likely Impact of Beresford Vulnerabilities
Frankly, I hoped for more. Unless we see a change of approach from the ICS security community, Siemens and other vendors are going to weather this storm without any serious change.
The people who need to force the change at Siemens or any other PLC vendor are the customers. PLC customers are busy running their plant, pipeline, transmission EMS, … Security is another problem to deal with. Almost all are very receptive to the vendor message that the vendor is taking security seriously and all is ok. Everything is fixed. This means security is one less thing for the PLC customer to worry about.
ICS owner/operators first source of information is the vendor. The vendor/asset owner bond is very tight. There next source of information is the automation press who refuses to cover the story. The next source of information is the mainstream press. I would like to say that this blog, ICS security conferences, and other ICS security resources are a source of information for owner/operators, but we only reach those who care about security. Getting them to care is the first step.
Stuxnet could be a template. The automation press covered it little and in a very benign way until the mainstream press picked it up. Even then, most of the best reporting on Stuxnet has been done in the mainstream press. After it got in the mainstream press, owner/operators began taking is seriously.
Where we failed is allowing the message that Stuxnet is fixed to take place. I’m actually a bit baffled at how this has happened. Maybe it is a credit to the Siemens marketing department and a black mark on the ICS security community.
Image by Paul J Everett