Kevin's Theorem

Of the security of control systems products.

"Kevin's Theorem" being: all control systems products from a security perspective are crap and when examined will reveal easily exploitable security flaws.

Sad State of Affairs

It has been 3 months since my last post..... guess I am doing a poor job in blogging, but constant security work and a slow changing landscape do little to inspire ;)

Yesterday Italian security researcher Luigi Auriemma released 34 vulnerabilities with working exploits across 4 different ICS platforms.

In an interview with Dale at Digital Bond, Luigi Noted that it took him on average 2 days to reverse engineer the product and develop a working exploit. 2 days for 1 man without SCADA experience...... not that SCADA experience is necessary for finding these types of vulnerabilities and Luigi is one of the IT worlds best.

Now imagine what teams funded with decent dollars armed with the actual products can accomplish. The fruit in our realm is plentiful and very low hanging.

I would propose that any serious researcher looking at any product line in the industry can find an exploitable vulnerability within a week. The state of our industry is this...... SAD.

I said it in my September 30th rant and I will say it again, there is no security in ICS/DCS/SCADA product lines and they are all full of very easily found and exploited vulnerabilities, and this will not change until the asset owners force the vendors to change their ways.

Brilliant

Jason Holcomb of Digital Bond tuned me into this little snippet of brilliant insight from Ralph Langer..... which ties directly into my earlier post:

(Quoting myself) So if you as an asset owner are bewildered by the ease in which Stuxnet propagated, and bemoaning the fact that there is little in most systems that would have stopped it, well you need look no further for culprits then yourselves collectively, as you as a community have simply not demanded it in the products you buy.

Because of the fundamental lack of security in control systems we instead rely on bolt on hardening, and perimeter control. In the face of the metrics coming out about the number of systems infected by Stuxnet, it is obvious that this approach has failed.

Ralph's Brilliant Insight:

As an asset owner, you should presently live under the assumption that you continue to operate because the forces behind Stuxnet allow you to do so.

No truer nor more insightful statement has been made about Stuxnet to date. The biggest take away needs to be and again I am repeating myself...... This could have been a rock instead of a scalpel. The authors went to extreme measures to minimize collateral damage.

I hate to spread FUD, but in the light of the demonstrable impact and possibility of Stuxnet, what would of occurred if this had been merely an instrument of blunt trauma, bricking every flavor of every field device that it could have?

What not to do....

make publicly available documents showing:
network topology
full scada schematics
wireless hotspots
camera coverage
fencing

yada yada yada.

Basically do not do nor make available what you see here:
http://www.tetratech.com/View-document-details/238-Saginaw-Water-Plant-Security-and-SCADA-Improvements-11MB.html

my head asplode.

The root of the problem

In its simplest form the root of the issue with securing control systems is that there is no inherent security in a control system. There are no mechanisms when you purchase and deploy a control system to ensure confidentiality, integrity and authenticity as these were not a driving design criteria.

In a control system the driving principle is availability, reliability and safety. Confidentially is not really needed, but integrity and authenticity measures would go a long way to alleviating many weaknesses of the type exploited by Stuxnet.

The vendors ultimately produce what the asset owners use, and they are only going to revamp their product lines to include security if the market demands it, or by legislative fiat.

Asset owners, when will you start to demand security in your control systems products to the degree that the vendors must respond? The only other mechanism by which this will occur is by federal mandate which flies in the face of the principles of a free market.

So far the market hasn't demanded it. In the 6 years I have been examining thees system there has been no significant change in product lines that indicates that security is a driving design criteria. And this is without addresses the tens of thousands of legacy systems.

So if you as an asset owner are bewildered by the ease in which Stuxnet propagated, and bemoaning the fact that there is little in most systems that would have stopped it, well you need look no further for culprits then yourselves collectively, as you as a community have simply not demanded it in the products you buy.

Because of the fundamental lack of security in control systems we instead rely on bolt on hardening, and perimeter control. In the face of the metrics coming out about the number of systems infected by Stuxnet, it is obvious that this approach has failed.

Stuxnet thoughts and process reactions

There has been a lot of discussion of the Stuxnet malware in the control systems sphere the last couple of weeks. As details emerge it becomes ever more apparent that this malware was the equivalent of a scalpel. By that I mean it targets a specific plant floor, not even a specific product line, but a specific plant floor and then monkeys with code blocks on the PLCs. The end goal is not clear yet but it does not require a huge bit of stretching to say that the target is the Bushehr Nuclear plant in Iran and that it (Stuxnet) most likely has it's origin in either the good ole US of A or Israel.

This package was too surgical to elicit much of a response by our industry. Too few felt the pain.

My biggest take away has been the reaction of the industry, which appears minimal. As this package is a scalpel it does: no, to minimal damage on the non-target systems that it infects. And so, the asset owners are not screaming bloody murder.

Now if the payload had been a hammer instead of a scalpel would the asset owners be as quiet? What I mean by this, is that as it has little adverse impact no one is screaming for heads. But, instead of doing little damage had this package turned a couple of 10,000 PLCs into expensive paperweights across multiple brands(which is demonstrably possible) how would the industry have responded?

I think that the asset owners would be screaming for blood and that the vendors would be forced into change, by pure market force if not legislative fiat. As it is, nothing is going to change. This malware has shown that a smart worm could quite possibly kill thousands of PLCs and yet little is being said in these regards. So business as usual will continue and systems with no inherent security will continue to be the norm, even in forthcoming product lines.

Something has got to change.

My second take away is that the system is broken. This is a direct reference to my previous "Moot" blog post from a couple of months ago, deriding the mootness of most security research in this field.

Siemens is by the INL's own website's admission a research partner with INL. And yet if the exploit paths employed by stuxnet were detected by the INL's assessment(s) of the Siemens products, then either: Siemens failed to act on the finding; or the vector was not found. Either way shows that spending a chunk of tax dollars to produce assessments to which the vendor has sole dissemination discretion seems to serve no one but the vendor. The vendor can choose to squash, ignore or act upon the findings and the lab, for all its work, bound by NDAs and CRADAs, has to remain mum. This in no way serves the interests of the asset owners or the tax payers at large who contribute a significant portion of the funding for these assessments. But this appears to be the mode in which these assessments are handled. Perform the work on the taxpayer's nickel and trust in the good will of the asset owner to do something about the findings.

Continuing on mootness, ICS-CERT failed. They neither have led in the analysis of the malware package, nor have provided any real mitigation. Instead Symantec, Kaspersky, and Ralph Langer's team have produced the most usable results. Again this may be due to ICS-CERT being some what bound in what they can disclose..... but if this is the case then why do they exist? What value is the tax payer getting from their efforts?

Why do we fund ICS-CERT, and research at the national labs if the results can not be shared, and if they provide no real leadership?

Siemens has also failed. Failed to say much of anything or provide their users with any real guidance on check for the presence of or mitigating the exploit paths. This failure is so bad that changing the default DB passwords, said passwords were one of the exploit vectors, will break the system.

So my take aways from this incident are:

*There are some damn crafty control systems hackers out there with access to real resources.

*The labs and ICS-CERT are providing little true leadership.

*The vendors are continuing like it is 1995. (Ok I will cut them a little slack on this as they have only been invited to the table in many ways since ICSJWG fall 09).

*The impact of the malware could have been potentially huge. In most ways this is good, in terms of driving a real reaction and security it is too bad.

Couple of little scripts

used to check for:
Well from a hacker's side, credential re-use, you know see if that password hash you just cracked will work on other systems;)

From a defender's side... check for ssh services and service account existence.

First the login/authentication tester (expect script):


#!/usr/bin/expect -f
#!/usr/bin/expect -d

set host [lrange $argv 0 0]
set uname "username" #placeholder username
set pass "password" #placeholder password
set timeout 120
set win "TESTLOGINFAIL $uname@$host\n"
spawn -noecho ssh -l $uname $host
log_user 0
match_max 100000

expect {
"(yes/no)?" {
send -- "yes\r"
exp_continue
}
"assword:" {
send -- "$pass\r"
expect {
"$ " {
puts "TESTLOGINTRUE $uname@$host\n"
send -- "exit\r"
close
exit
}
"Permission denied" {
puts $win
exit
}
timeout {
puts $win
exit
}
eof {
puts $win
exit
}
}
}
-re . {
exp_continue
}
timeout {
puts $win
exit
}
eof {
puts $win
exit
}


}


Next a wrapper to pass the test a range of IPs and to parallel-ize it for speedy performance (in perl with a nod to factor the perl wizard).



#!/usr/bin/perl
#
#
use Net::IP;
use Parallel::ForkManager;

#input can be of the form 192.168.10.1-192.168.10.22
#or 192.168.10.0/24

my $argIn = $ARGV[0];

my $pm = new Parallel::ForkManager(25);
my $ip = new Net::IP ($argIn) || die;
# Loop
do {
$pm->start and next;
my $bVal = 0;
my $nIP = $ip->ip();
$bVal = `./fail.exp $nIP`;
#$bVal = `./fail.exp $nIP`;
if($bVal =~ /TESTLOGINTRUE/){
print "$bVal : TRUE\n";
}else{
print "$nIP : FALSE\n";
}
$pm->finish;
} while (++$ip);
$pm->wait_all_children;

Enjoy!