New Siemens SCADA Vulnerabilities Kept Secret

Post Reply
User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

New Siemens SCADA Vulnerabilities Kept Secret

Post by Pigeon » Tue May 24, 2011 9:20 pm

SCADA systems -- computer systems that control industrial processes -- are one of the ways a computer hack can directly affect the real world. Here, the fears multiply. It's not bad guys deleting your files, or getting your personal information and taking out credit cards in your name; it's bad guys spewing chemicals into the atmosphere and dumping raw sewage into waterways. It's Stuxnet: centrifuges spinning out of control and destroying themselves. Never mind how realistic the threat is, it's scarier.

Last week, a researcher was successfully pressured by the Department of Homeland Security not to disclose details "before Siemens could patch the vulnerabilities."

Beresford wouldn't say how many vulnerabilities he found in the Siemens products, but said he gave the company four exploit modules to test. He believes that at least one of the vulnerabilities he found affects multiple SCADA-system vendors, which share "commonality" in their products. Beresford wouldn't reveal more details, but says he hopes to do so at a later date.

We've been living with full disclosure for so long that many people have forgotten what life was like before it was routine.

Before full disclosure was the norm, researchers would discover vulnerabilities in software and send details to the software companies -- who would ignore them, trusting in the security of secrecy. Some would go so far as to threaten the researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers announced that particular vulnerabilities existed, but did not publish details. Software companies would then call the vulnerabilities "theoretical" and deny that they actually existed. Of course, they would still ignore the problems, and occasionally threaten the researcher with legal action. Then, of course, some hacker would create an exploit using the vulnerability -- and the company would release a really quick patch, apologize profusely, and then go on to explain that the whole thing was entirely the fault of the evil, vile hackers.

I wrote that in 2007. Siemens is doing it right now:

Beresford expressed frustration that Siemens appeared to imply the flaws in its SCADA systems gear might be difficult for a typical hacker to exploit because the vulnerabilities unearthed by NSS Labs "were discovered while working under special laboratory conditions with unlimited access to protocols and controllers."

There were no "'special laboratory conditions' with 'unlimited access to the protocols,'" Beresford wrote Monday about how he managed to find flaws in Siemens PLC gear that would allow an attacker to compromise them. "My personal apartment on the wrong side of town where I can hear gunshots at night hardly defines a special laboratory." Beresford said he purchased the Siemens controllers with funding from his company and found the vulnerabilities, which he says hackers with bad intentions could do as well.

That's precisely the point. Me again from 2007:

Unfortunately, secrecy sounds like a good idea. Keeping software vulnerabilities secret, the argument goes, keeps them out of the hands of the hackers.... But that assumes that hackers can't discover vulnerabilities on their own, and that software companies will spend time and money fixing secret vulnerabilities. Both of those assumptions are false. Hackers have proven to be quite adept at discovering secret vulnerabilities, and full disclosure is the only reason vendors routinely patch their systems.

With the pressure off, Siemens is incented to deal with the PR problem and ignore the underlying security problem.

Link

Non tsunami Fukushima anyone...

User avatar
Dr Exile
Posts: 2349
Joined: Tue Apr 05, 2011 5:37 pm
Location: Skellig Michael

Re: New Siemens SCADA Vulnerabilities Kept Secret

Post by Dr Exile » Tue May 24, 2011 10:58 pm

Someday in the distant future we will stop laughing at analog technology.
Credo quia absurdum.

User avatar
Egg
Posts: 8628
Joined: Thu Mar 31, 2011 5:31 pm
Location: In Your Bedroom. Hi! :D

Re: New Siemens SCADA Vulnerabilities Kept Secret

Post by Egg » Tue May 24, 2011 11:53 pm

Dr Exile wrote:Someday in the distant future we will stop laughing at analog technology.
No shit. The more we automate and forget the more someone or some mistake forces us to remember.


User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: New Siemens SCADA Vulnerabilities Kept Secret

Post by Pigeon » Wed May 25, 2011 12:19 am

Most of it is back to analog in the end. It goes to and from digital so a computer can control it. Well at least it used to...

User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: New Siemens SCADA Vulnerabilities Kept Secret

Post by Pigeon » Sat Sep 17, 2011 1:32 am

LAS VEGAS—A security researcher has uncovered a slew of vulnerabilities in Siemens industrial control systems, including a hardcoded password, that would let attackers reprogram the systems with malicious commands to sabotage critical infrastructures and even lock out legitimate administrators.

The vulnerabilities exist in several models of Siemens programmable logic controllers, or PLCs—the same devices that were targeted by the Stuxnet superworm and that are used in nuclear facilities and other critical infrastructures, as well as in commercial manufacturing plants that make everything from pharmaceuticals to automobiles.

Stuxnet was discovered on systems in Iran last year and is believed to have been aimed at destroying uranium-enrichment centrifuges at the Natanz nuclear facility in that country. It targeted Siemens Simatic Step7 software, which is used to monitor and program Siemens PLCs. It then intercepted legitimate commands going from the Step7 system to PLCs and replaced them with malicious commands aimed at sabotaging processes controlled by the PLC; in this case the spinning of centrifuges.

The newly discovered vulnerabilities go a step further than Stuxnet, however, in that they allow an attacker to communicate directly with a Siemens PLC without needing to compromise, or even use, the Step7 software.

One of the most serious security holes is a six-letter hardcoded username and password—“Basisk”; “Basisk”—that Siemens engineers had left embedded in some versions of firmware on its S7-300 PLC model. The credentials are effectively a backdoor into the PLC that yield a command shell, allowing an attacker to dump the device’s memory—in order to map the entire control system and devices connected to it—and reprogram the unit at will.

“I was able to log in via Telnet and http, which allowed me to dump memory, delete files and execute commands,” says Dillon Beresford, the security researcher with NSS Labs who discovered the password, and at least a dozen more subtle security holes.

Beresford, a security researcher with NSS Labs, had planned to discuss a few of the vulnerabilities at TakeDownCon in Texas in May, but pulled the talk at the last minute after Siemens and the Department of Homeland Security expressed concern about disclosing the security holes before Siemens could patch them.

Since then, he discovered additional vulnerabilities in several models of Siemens PLCs that would variously allow attackers to bypass authentication protection in the PLCs and reprogram them, or issue a “stop” command to halt them. They all require the attacker to have access to the network on which the PLCs run. That might be accomplished by infecting a legitimate computer on the network, such as with a phishing attack targeted at an employee, or through an infected USB stick—the method Stuxnet used.

Beresford will be presenting his findings on Wednesday at the Black Hat security conference in Las Vegas, but spoke with Threat Level in advance of his talk.

He’s been working with DHS’s Industrial Control Systems Cyber Emergency Response Team, or ICS-CERT, to validate and disclose the vulnerabilities and plans to withhold some information, as well as actual exploit code, until Siemens has a chance to patch the vulnerabilities that can be fixed. Not all of the vulnerabilities affect every model. Some of the vulnerabilities are inherent in the architecture of the systems and would require more than a patch.

One of the main vulnerabilities, he says, is that the systems have no defense against a so-called “replay attack”. An attacker could intercept commands going from any Step7 control system to any PLC—including a system in his own lab that he controls—and later play them back to any other PLC.

The attacker, for example, can capture a CPU “stop” command going from his own Step7 engineering workstation to his PLC, then replay the command back to another PLC to shut it down. He could also sabotage whatever the PLC is controlling by replaying malicious commands that would, for example, cause the speed of motors or rotors to increase on a centrifuge or cause valves to open or close on a pipeline.

“If I could only replay the same traffic into my own PLC, that would constitute a vulnerability,” Beresford said. “The fact that I can record traffic going to and from my own PLC, and play them back to any PLC, that’s what makes it a big issue.”

Generally, this kind of captured traffic should have a session ID that expires. But the Siemens PLC session never expires, Beresford said, so an attacker can use the captured traffic repeatedly, unless the PLC he’s attacking crashes and an administrator physically re-cycles it and then issues a “run” command to restart it.

Last May, Beresford revealed that he could conduct the replay attack against Siemens S7-1200 PLC model. Siemens said at the time that it believed the flaw did not affect other models of its PLCs, and last month the company announced that it had fixed the flaw in the S7-1200. But Beresford found that the flaw also exists in the S7-200, S7-300 and S7-400 models of Siemens PLCs.

It’s possible for an attacker to communicate directly with the PLC, without needing to use Siemens Step7 system, because Siemens’ PLCs don’t restrict or otherwise limit which computers communicate with them. There are no rules in the PLC limiting traffic or commands to specific IP addresses or to specific computers with Step7 installed on them, Beresford said. The PLCs also do not keep logs to identify the computers that send them commands, so trying to identify the source of a malicious command a PLC received would be difficult.

Siemens did not respond to a request for specific comment about the vulnerabilities but said the company had sent several representatives to the BlackHat conference and is working with Beresford to understand and patch the vulnerabilities.

“ICS-CERT and Siemens have issued technical alerts/updates on this topic, and will continue to do so on an as-needed basis,” said Frank Garrabrant from Siemens SIMATIC Security Industry Automation Division, in a written statement.

Previously, Siemens has asserted that the attacks Beresford describes could be thwarted by air-gapping PLCs and their control computers from the Internet. But according to Vik Phatak, CTO of NSS Labs, not all companies have a complete understanding of what constitutes an air-gapped system.

“We’ve talked to a number of different companies that have told us that their version of an air-gapped network [means] there’s no inbound connection, but they definitely have outbound connections to the Internet for their employees,” Phatak said.

Even air-gapping a system would not work if someone plugged removable media containing malware into the system.

The only thing on the PLCs that would prevent an attacker on the network from communicating directly with the devices is an authenticated packet that passes from the Step7 machine to the PLC. But Beresford found a way to bypass this authentication protection.

Step7 machines authenticate themselves to a PLC using a hash generated from a password. The hash is stored inside a project file that gets sent from the Step7 machine to a PLC. If the hash matches a hash stored on the PLC, a switch on the PLC is flipped that allows a programmer to then read and write to the PLC. Beresford found that he could bypass this by capturing the authentication packet and replaying it to a PLC.

“If you capture it, you have the authenticated packet, there’s nothing the PLC can do to stop you,” Beresford said.

Beresford could also do a replay attack to disable the authentication protection on a PLC. He’d simply issue a command to his own PLC to disable the password protection, then capture that command as it passed to his PLC and replay it to the PLC he wanted to attack.

“I can even change their password, so if I wanted to lock them out of their own PLC I could do that as well,” he said.

To find a PLC on a network, an intruder could introduce malware designed to scan the network for any devices operating on port 102—the port the PLCs use to communicate—and map all of the PLCs on a network in order to attack them all, or target specific ones.

As for the hard-coded password, “Basisk,” that he found in the S7-300 firmware, Beresford says it was obfuscated by a basic shift sequence that involved swapping characters and shifting them to the right. It took him two and a half hours to decode the password. Beresford could only confirm that the hardcoded password existed in a specific version of the firmware on his S7-300 PLC—firmware version 2.3.4.

The credential would give a user command shell access on the PLC, allowing someone to reprogram the PLC or otherwise completely control it. The password also gives access to a memory dumping tool that would allow an attacker to dump memory from the PLC in real time in order to gather intelligence on the PLC to devise a targeted attack.

He found he could dump SDRAM, uncached and cached, NOR flash, as well as other parts of RAM and scratchpad data. He could also obtain the serial numbers and tag names of devices connected to the PLC. All of these would allow an attacker to discover new vulnerabilities in the system and to determine what’s connected to the PLC and what normal operating conditions exist for those devices in order to design a worm like Stuxnet to attack them. An attacker could also write a worm that copied itself to a PLC—so that anyone who communicated with the PLC would be infected—or use the PLC to launch attacks against other machines on the same network.

Siemens has acknowledged that the password existed and said that developers had put it in the system for testing purposes, but then forgot to remove it.

ICS-CERT has issued an alert about the password (.pdf). According to the alert, Siemens discovered the password in 2009 and removed it from subsequent systems. But anyone using pre-2009 versions of the S7-300 firmware would likely still have the password installed.

“Anything before October 2009, for the PLCs, in terms of the S7-300, would be affected by the hardcoded password,” Beresford said.

Finally, Beresford also found an Easter egg in two versions of the S7-300 PLC firmware—versions 2.3.2 and 2.3.4. It’s an html file that depicts a handful of dancing chimpanzees and a German proverb that is the equivalent of the English phrase, “All work and no play makes Jack a dull boy.”

Siemens was not aware the Easter egg was in the firmware. “They weren’t exactly happy,” Beresford said. “Considering where these devices are deployed, they didn’t think it was very funny.”

While the Easter egg may have simply been a developer’s idea of fun, Beresford says he’s still examining it to see if it’s possible to send commands through the html page back to the PLC.

Siemens is beginning to move out patches for some of the vulnerabilities this week, but others will take longe

Link


Post Reply