Trojan Targeting Siemens and APT Thoughts
Pay attention to the P in Advanced Persistent Threat [APT]. Most of the attention paid to the trojan with a payload targeting Siemens control system applications has been on the Advanced nature of this malware. And that attention is warranted because there has not been a public example of malware targeting control systems prior to this.
But now that we have had a few days to chew over that, I’d like to pose the question of how do we know the threat has been removed from any targeted control systems and organizations? There has been much buzz on APT recently, including in the control system community after S4. A lot of the buzz has been to sell products and services, but let’s look at that persistent nature that really is the distinguishing feature of APT.
A company finds that it has been the victim of the attack. They investigate; find the exploit; figure out how to clean it out; and hopefully find a way to prevent it from repeating. However, a few days, weeks, months later a different exploit is found. And this happens again and again. There are a wide variety of exploits, in different systems, that wake up at different times, because the attacker had a strong desire to maintain a presence on your network once they had breached it. Maybe the attacker plants a logic bomb in case they are unable to contact one or more of their connections for a period of time.
This attacker directed their attacks on a specific target because that target had something of great interest or value to the attacker.
Based on the available information, the trojan was passed by USB which can indicate it was a directed attack, and the trojan was gathering project information. Perhaps this information gathering is only the first stage of an attack. If your control system was compromised, how do you determine if you have eradicated the attacker’s presence and capabilities on your system?
Cleaning out and preventing the reappearance of the trojan is necessary but maybe not sufficient. I would be very worried where else the attacker is lurking in the system. We know that many control systems today have little patching, minimal security configuration, shared and default user accounts, … So it is likely that the attacker has compromised multiple systems in multiple ways if they wanted persistence.
PS – The Siemens press release on the trojan conveniently puts all of the blame on Microsoft and does not mention their password issue. This is disappointing, but all too common reaction the first time the control system group gets hit with an issue like this. Better to just be straightforward, take the hit, solve the problem and move ahead. It gives all involved some sense of comfort that a strong security group is on the case.
Author: Dale Peterson
Posted: July 20th, 2010 under APT, Vulnerability Disclosure.
Comments: 11
Comments
Comment from Andrew Ginter
Time: July 20, 2010, 1:25 pm
Dale, I’d like to take issue with your “all the blame on Microsoft” statement. My understanding is that the malware attempts a connection to the local SQLServer database when it takes over a machine, using a default password. Now let’s say the vendor supported changing the password to be unique at every site, and the customer had done that. The vendor’s software still needs access to the site password in order to run. To support unattended reboots, which are a requirement at all sites I’ve ever been to, the vendor’s software has to have that password stored away somewhere, preferably encrypted.
But if malware has “root” on a system, it can do anything that any software on the system can do. If the vendor’s software has a mechanism to find and use the database password, a determined adversary can write their malware to use that same mechanism. A unique password that software has access to is not a high hurdle to jump for a malware author targeting a specific vendor.
Of course, if that SQL connection is exposed over the network, a unique password offers more protection – it prevents connections from machines that do not have software running that must automatically connect and authenticate to the database. But from what I’ve heard thus far, the virus in question is attempting a local connection, not a connection over the network.
As to your question of how to tell the malware is gone, that’s a tough one. Rebuilding the machine from scratch is where most people start. Though, an offline scan of the machine with an SHA-2/MD5 or whitelisting tool, and comparing file checksums to a known good machine or a database of known good checksums, is another possibility.
Comment from Bob Radvanovsky
Time: July 20, 2010, 2:52 pm
I wish people, organizations and governments alike, would get its through their thick heads and *not* call this an “attack”. Unless you *know* the specified target (who is it, which industry is being targetted specifically), this is *not* an “attack”.
This is an “event”. More specifically, this is a “discovered vulnerability”.
You have a guessed level of “intent”, but can *only* guess the intent. You can guess which industries are being targeted, but “everybody” doesn’t count (considering how widespread Siemens products are used worldwide). You can guess who an intended target/victim is, but again, am only guessing.
Until you know *who* is the target (or victim), you cannot state that this is an “attack”.
Does this make any sense?
Worse case scenario is that you refer to this as an “incident”; I prefer Mark Fabro’s definition of it as being an “event”. From a liability perspective, an “event” doesn’t even come close to an “incident”, and so therefore, in the eyes of insurance providers, the threat isn’t as great or as significant as an “incident”, or event greater as an “attack”.
-r
Comment from Dale Peterson
Time: July 20, 2010, 3:26 pm
Bob – Since I don’t know the victim’s name, I can’t say you are wrong, but … It seems highly likely that this was found on someone’s network so someone was “attacked”. How else would it have been found? We don’t know if it was directed or non-directed attack. If it was in fact delivered on a USB stick, then it is more likely, but far from certain, it was directed. It would be highly interesting to determine if the “victims” had the Siemens systems that were targeted by the payload.
Comment from Ron Southworth
Time: July 20, 2010, 6:22 pm
Potato Patato, tomato Tamato
let’s call the whole thing off…..
Comment from Ron Southworth
Time: July 20, 2010, 6:44 pm
Here’s that whole language debate.
If someone discovered a piece of malware and If it turns out it was espionage or what if it turns out it was not?
How do you not know it was not tit for tat. There might not be a single “victim” in this scenarion does it imply there was more than one aggressor.
I’m not implying this is the case by the way but until there is some verifyable confirmation of details it is all heresay and as such dealing with early information our language should be important to imply our neutrality otherwise it implys there is some pre dispisition or desired outcome.
This is one reason why I suggest we should talk about the implications or possibilities that such a situation may mean to us as an industry and wait for people to ffinish playing in the sandpit with what has been uncovered.
One thing that has been overlooked was this disclosure very responsible. Was the vendor contacted before the matter was made public. There is a whole raft of questions or avenues here which ones are apropriate you tell me.
Comment from Ralph Langner
Time: July 21, 2010, 4:43 am
Agree on the P issue, Dale… if the goal really would be to access WinCC archive data, there are several other holes that are still open if the default password issue is resolved.
Let’s hope many asset owners wake up these days and ask themselves:
- are we using the default passwords? (How is the pw changed?)
- is WinCC running with admin rights? (How is it possible to change this?)
- is the internal WinCC OPC server running? (…)
There are some more vulns in a typical WinCC installlation, but naming these in public could be viewed as unresponsible disclosure. The bottom line is, lots of attack vectors for APT. But certainly not only in Siemens products.
Comment from Dale Peterson
Time: July 21, 2010, 5:57 am
Andrew commented, “As to your question of how to tell the malware is gone, that’s a tough one. Rebuilding the machine from scratch is where most people start. Though, an offline scan of the machine with an SHA-2/MD5 or whitelisting tool, and comparing file checksums to a known good machine or a database of known good checksums, is another possibility.”
To be clear, I’m not talking about how to know when the malware that is identified is gone on the system or systems that malware was compromised. That is hard work, but what is being seen in scenarios being classified as APT is the threat agent is leaving a variety of different types of exploits on a variety of systems so finding and cleaning one or two or three of them does not eliminate the presence.
So even if the asset owner cleans out this identified malware everywhere in the network, how do they know what other nasty surprises await. How long have backups included compromised systems?
Comment from Jake Brodsky
Time: July 21, 2010, 8:05 am
From the front lines (where one actually has to DO something), here are my thoughts:
1) There is little doubt in my mind that this malware was no amateur effort. It involved a zero-day exploit, a probable distribution of flash drives, theft of keys, and insider knowledge of the target systems. No one of these things is particularly unusual, but taken together, it seems like someone went to a lot of effort to make this thing happen.
2) We do not have the luxury of reinstalling control systems software whenever we feel like it. Furthermore, we should be concerned about the integrity of not just the control system software but the configuration data and its validity. This is a high stakes risky thing to take a continuous process offline so that we can update. We need three things to make this practical:
First, we need to know that the software has been signed through the entire supply chain, not just by one agent (Microsoft).
Second, we need some way to ensure that the configuration data is valid. Control systems vendors need to create a counterpart to “lint” when programming in C. It needs to look at the configuration database and bark when it sees something unusual.
Third, we need reasonable ways to checkpoint the state of the control system, keep track of the elapsed time since the checkpoint, and then to come back up smoothly.
These three things do not exist in any vendor’s system today. So re-installation of software is dangerous and needs to be carefully planned.
3) I think Siemens’ reaction was tactical. That’s all anyone can expect from them right now. It is easy for people to criticize them for installing a back-door password on their products. Yes, this backdoor was an outrageously stupid strategic decision when designing the product. I’ll wager that most other control systems products also have some really horrible security problems embedded in them. We can bemoan the state of the industry, but that’s a philosophical notion for people to sit around and discuss over drinks.
The key issue is that the backdoor exists in the field right now and we need to deal with it. There is no way anyone can remove that password, and everything associated with it within the next few days without risking all the infrastructure it is attached to. So their response right now is the shortcut icon work-around described in Microsoft’s Security Bulletin.
Yeah, in retrospect, the backdoor was a fetid pile of decisions that Siemens should never have made. But they did. Now we have to do something quick before other attack code emerges.
Beyond tactical decision making, we have many issues to discuss, not the least of which is how to improve the value of signed code, how to move software in to a control system safely, and when malware is discovered, how to notify people in the field.
Pingback from Digital Bond » Learning from the Stuxnet/WinCC Malware
Time: July 21, 2010, 2:08 pm
[...] active for at least a month and spread around the world before it was identified and recognized. To Dale’s point, what else is out there that we don’t know about yet? And if you can’t prevent an [...]
Comment from Eric Knapp
Time: July 23, 2010, 10:00 am
Lots of good points here … I’m not sure where to start.
@Dale: I agree that the presence of hard-coded authentications within any software is something that we should be concerned about, and it’s not likely to ever go away completely. And while there are ways to monitor for and detect the use of default passwords, that’s only possible if the vendors who are using those defaults inform the security vendors about them — which is unlikely.
I’m a fan of whitelisting – but not just app whitelisting on hosts, because there are too many legitimate executables that can be remotely targeted (for example: the MS SQL service is legit in this case). User whitelisting, application content whitelisting (on the wire), and other levels of whitelisting can help lock down behavior on a grander scale. Example: if you know your user accounts, watch for authentications within the network, and if an unknown account attempts to authenticate to a legitimate service, block (or at least flag it).
Of course, that would require a centralized system that understood the context of users, networks, applications, etc … hmmm … (okay, you caught me: that was a blatant plug for nitrosecurity).
@Andrew: application whitelisting is a great start and something that I personally recommend, but unless it’s used ubiquitously — and 100% correctly across all connected devices — there’s still the chance that an unprotected device can be compromised and then use legitimate channels to extract information (or worse, issue commands).
@Ron: I’m a writer by hobby and appreciate the subtleties of language … in this case I’m more concerned that there was an ambiguously-defined-activity that seems to be targeting a PCS: at worst it was an attack; at best it was a proof-of-concept that such an attack could occur.
Re: The blame of Siemens/Microsoft/etc: In my opinion, looking for blame accomplishes nothing. Siemens seems to be handling this very well. Yes, that default password probably shouldn’t be there … but just because software has a vulnerability, it doesn’t mean that the vendor has poor or misguided intentions around security. Most vendors have good intentions about security (with the possible exception of DVL http://bit.ly/8L22M), and many are extremely good implementing it, but vulnerabilities will always exist. My thoughts are that, if we want to really secure our networks, we need to assume that *everything* is vulnerable, and implement as many layers of defense, and as many counter-measures against vulnerabilities as possible.
Pingback from Digital Bond » Stuxnet and Relation To APT Misunderstood
Time: July 27, 2010, 10:21 pm
[...] evidence of an effort to achieve persistence? Every sophisticated directed attack is not APT. Now I blogged earlier questioning if this was only part of a directed attack and other different exploits remain on any [...]
Write a comment