Showing posts with label malware. Show all posts
Showing posts with label malware. Show all posts

SSL Blacklist

The guys over at abuse.ch who publish the ZeuS and SpyEye tracking lists among others have added another list, this time tracking the SSL certificates in use by various pieces of malware for C&C traffic.  There are two types of lists, a list of fingerprints of observed certificates and a list of IP addresses associated with the traffic. The fingerprint list also comes as a ruleset for the Open Source (IDS/IPS) Suricata, unfortunately Snort doesn't support SSL/TLS fingerprinting so Snort users are out of luck (the IP lists would certainly be of some use). It also comes as a CSV.

This got me to thinking about other ways to do this without having a Suricata instance or doing this with historical data (maybe you run full packet capture at the gateway and don't discard ssl?). Granted for the historical use case you could just fire up Suricata and run the pcaps through it, but where's the fun in that? *nix has a utility called ssldump which looks at network data, live or pcap, and parses out the session information including the certificate. Once we have the certificate it can be fingerprinted with OpenSSL and compared to our list of known bad fingerprints.

This is still a work in progress and currently doesn't work with live traffic (something goes awry with the awk script I think) and I can't clain to have written all the code, more glued some bits and pieces together but it seems like it could be quite effective with a bit more fiddling. I'd be interested to see how it goes on a reasonable size data set. I still need to write something to grab the Source and Destination IP from the ssldump too.

 ssldump -AN -r ssl.pcap | awk 'BEGIN {c=0;} { if ($0 ~ /^[ ]+Certificate$/) {c=1;} 
if ($0 !~ /^ +/ ) {c=0;} if (c==1) print $0;} ' | tr "\\n" " " | sed 's/ *//g' | 
perl sslbacklist.pl   

The contents of the Perl script is as follows

 use strict;  
 use warnings;  
 use Text::CSV;  
 use Data::Dumper;  
   
 my %bad_thumbprints;  
 my $csv = Text::CSV->new( { sep_char => ',' } );  
   
 my $file = 'sslblacklist.csv';  
   
 open( my $data, '<', $file ) or die "Could not open '$file' $!\n";  
 while ( my $line = <$data> ) {  
   chomp $line;  
   if ( $csv->parse($line) ) {  
     my @fields = $csv->fields();  
     if ( $fields[1] ) {  
       $bad_thumbprints{ $fields[1] } = $fields[2];  
     }  
   }  
   else {  
     warn "Line could not be parsed: $line\n";  
   }  
 }  
   
 my @certificates = split( /certificate\[\d+\]=/, <> );  
   
 foreach my $certificate (@certificates) {  
   unless ( $certificate eq 'Certificate' ) {  
     my $thumbprint = `echo $certificate | xxd -r -p | openssl x509 -inform der -fingerprint`;  
     $thumbprint = lc substr $thumbprint, 17, 59;  
     $thumbprint =~ s/://g;  
     if ( exists( $bad_thumbprints{$thumbprint} ) ) {  
      print  
 "ALERT: Bad Thumbprint ($thumbprint) detected indicating $bad_thumbprints{$thumbprint} malware \n";  
      } 
   }  
 }  
   

   
   

References:
Awk script came from http://serverfault.com/questions/313610/extracting-ssl-certificates-from-the-network-or-pcap-files
OpenSSL and xxd commands from http://stackoverflow.com/questions/22211140/conversion-x-509-certificate-represented-as-a-hex-string-into-pem-encoded-x-509

edit: Updated Perl script to do the awk part and other cleanup, also extracts IP addresses

 ssldump -ANn -r ssl.pcap | perl sslbacklist.pl  

 use strict;  
 use warnings;  
 use Text::CSV;  
 use Data::Dumper;  
 my %bad_thumbprints;  
 my $csv = Text::CSV->new( { sep_char => ',' } );  
 my $file = 'sslblacklist.csv';  
 open( my $data, '<', $file ) or die "Could not open '$file' $!\n";  
 while ( my $line = <$data> ) {  
   chomp $line;  
   if ( $csv->parse($line) ) {  
     my @fields = $csv->fields();  
     if ( $fields[1] ) {  
       $bad_thumbprints{ $fields[1] } = $fields[2];  
     }  
   }  
   else {  
     warn "Line could not be parsed: $line\n";  
   }  
 }  
 my $c = 0;  
 my $certificatestring;  
 my $source_ip;  
 my $dest_ip;  
 while (<>) {  
   chomp;  # strip record separator  
   if ( $_ =~  
 m/New TCP connection #\d+: (\d+\.\d+\.\d+\.\d+)\(\d+\) <-> (\d+\.\d+\.\d+\.\d+)\(\d+\)/  
    )  
   {  
     $source_ip = $1;  
     $dest_ip  = $2;  
   }  
   if ( $_ =~ /^[ ]+Certificate$/ ) {  
     $c = 1;  
   }  
   if ( $_ !~ /^ +/ ) {  
     $c = 0;  
   }  
   if ( $c == 1 ) {  
     $certificatestring = $certificatestring . $_;  
   }  
 }  
 $certificatestring =~ s/\n//g;  
 $certificatestring =~ s/ //g;  
 my @certificates = split( /certificate\[\d+\]=/, $certificatestring );  
 foreach my $certificate (@certificates) {  
   unless ( $certificate eq 'Certificate' ) {  
     my $thumbprint =  
 `echo $certificate | xxd -r -p | openssl x509 -inform der -fingerprint`;  
     $thumbprint = lc substr $thumbprint, 17, 59;  
     $thumbprint =~ s/://g;  
     if ( exists( $bad_thumbprints{$thumbprint} ) ) {  
       print  
 "ALERT: Bad Thumbprint ($thumbprint) detected indicating $bad_thumbprints{$thumbprint} malware. Source IP: $source_ip Dest IP: $dest_ip \n";  
     }  
   }  
 }  

edit 2: now works when sniffing and needs a refactor...

 sudo ssldump -ANn -i eth0 | perl sslbacklist.pl  

 use strict;  
 use warnings;  
 use Text::CSV;  
 my %bad_thumbprints;  
 my $csv = Text::CSV->new( { sep_char => ',' } );  
 my $file = 'sslblacklist.csv';  
 open( my $data, '<', $file ) or die "Could not open '$file' $!\n";  
 while ( my $line = <$data> ) {  
   chomp $line;  
   if ( $csv->parse($line) ) {  
     my @fields = $csv->fields();  
     if ( $fields[1] ) {  
       $bad_thumbprints{ $fields[1] } = $fields[2];  
     }  
   }  
   else {  
     warn "Line could not be parsed: $line\n";  
   }  
 }  
 my $c = 0;  
 my $certificatestring;  
 my $source_ip;  
 my $dest_ip;  
 my $connection_no;  
 while (<>) {  
   chomp;  # strip record separator  
   if ( $_ =~  
 m/New TCP connection #(\d+): (\d+\.\d+\.\d+\.\d+)\(\d+\) <-> (\d+\.\d+\.\d+\.\d+)\(\d+\)/  
    )  
   {  
     $connection_no = $1;  
     $source_ip   = $2;  
     $dest_ip    = $3;  
   }  
   if ( $_ =~ /^\s+Certificate\s*$/ ) {  
     $c = 1;  
   }  
   if ( $_ !~ /^ +/ ) {  
     $c = 0;  
   }  
   if ( $c == 1 ) {  
     $certificatestring = $certificatestring . $_;  
   }  
   if ( $c == 0 && $certificatestring ) {  
     $certificatestring =~ s/\n//g;  
     $certificatestring =~ s/ //g;  
     my @certificates = split( /certificate\[\d+\]=/, $certificatestring );  
     foreach my $certificate (@certificates) {  
       unless ( $certificate eq 'Certificate' ) {  
         my $thumbprint =  
 `echo $certificate | xxd -r -p | openssl x509 -inform der -fingerprint`;  
         $thumbprint = lc substr $thumbprint, 17, 59;  
         $thumbprint =~ s/://g;  
         if ( exists( $bad_thumbprints{$thumbprint} ) ) {  
           print  
 "ALERT: Bad Thumbprint ($thumbprint) detected indicating $bad_thumbprints{$thumbprint} malware. Source IP: $source_ip Dest IP: $dest_ip \n";  
         }  
       }  
     }  
     $certificatestring = "";  
   }  
 }  

There's now a github for this here

Ironic?

Irony: Emails about Governments snooping on private data used to distribute malware that allows criminals snoop on your private data...

Blue Coat Mid-year Security Report

Blue Coat security have released their mid-year security report [pdf].
From the report:

The majority of web threats are now delivered from trusted and popular web sites that have been hacked for use by cybercrime. For this reason, reputation defenses become less effective...

... Search engine poisoning (SEP) ranks as the number one web threat delivery method at this point in the year. To be more specific, image searches have passed text searches and are now the top vector for malware delivery....


...From a user agent perspective, some Mac users are searching for pirated goods and images and falling into known malware delivery vectors. While exploit kits today focus on Windows users, many Mac users have their noses pressed against the glass of cybercrime. When cybercrime’s focus switches to the Mac, these users will be lined up like lambs....
It's short, but worth a read.

Military Digital Complex

State of Security have a nice post about the 'Post-Zeus/Stuxnet World'. In a year that saw what many believe was the first real government created 'cyber-weapon' or 'weaponized malware' that did more than just knock a site offline, but destroyed physical infrastructure.
Combine this with events such as an arms manufacturer buying an Australian security company that (among other things) performs penetration tests and the future certainly looks..interesting.

More over Military Industrial Complex and hello Military Digital Complex?

This is nothing that was unexpected, the logical progression of military might is from the physical to the digital realm. For a smaller, less technologically developed nation, striking with weaponized malware at your larger more advanced and more techonolgy-dependant foe (especially if no one can prove it came from you!) has to be attractive.

Any security professional knows defence is hard. An attacker only has to find that one weak point, while the defender has to protect and monitor the whole perimeter. Unlike the castles of old, digital perimeters look more like the Great Wall in scale and are constantly changing.


The bad guys are smart, and they learn. The complexity and effectiveness of the likes of Stuxnet will have been noticed and will be part of the next generation of crimeware. As Government or Military contractors develop increasingly weaponized malware, the techniques and methods they use will filter into the ranks of the black hats and criminals - just as advances in military technology have always flowed into civilian life. Radar? TCP/IP? The Internet?

2011 is shaping up to be an interesting year...

A different view of Stuxnet

Over at Forbes.com Jeffrey Carr has an interesting article on the now-infamous stuxnet worm that takes a contrary view to the more common USA/Israel angle on the likely culprits.

The original whitepaper is here [pdf]

The enemy of my enemy is my.....enemy?

Oh McAfee what have you done? Last week McAfee released an update for their antivirus software that crippled Windows XP SP3 machines. This is not the first time McAfee have had this problem, having crippled machines last year with a bad update as well.

Of course, the 'bad guys' have immediately jumped on the bandwagon as well, flooding google with links scareware sites promising to fix the problem.

What to do? Well I'm not here to bash McAfee (they have enough angry customers right now to do that), and all the big vendors make mistakes, but this does expose a serious problem in the quality control of another big AV vendor.

Last year I sat through a presentation by McAfee where they talked about the massive rise in malware and viruses, a comment that was echoed by Symantec in a presentation around the same time. The Sophos 2010 Security Threat Report [pdf] states that "Sophos’s global network of labs received around 50,000 new malware samples every day during 2009".

Combine that with the constant need to beat the competitors to market with the latest protection and it's no wonder a mistake like McAfee's recent one was made. It seems almost inevitable it will happen again.

But what can be done to protect your servers and desktops? Do AV updates need to be treated like patches and be run through a testing regime before deployment? Is this even feasible in an era of daily (or multiple times daily) signature updates?

I'm no developer and not in the AV business, but it would seem to me having a 'whitelist' of known good items (such as critical windows components) might be a way to stop something like this occurring again...

More Aurora

I was pointed to some more information on Aurora by a Uni classmate. HBGary have a slightly more in-depth threat review of Aurora here [pdf] and are offering a 'Aurora inoculation shot' with details here. The inoculation does not address the social engineering aspect of the attack, it is more of a scanner to tell if you're already infected and help clean the infected machine (which to me seems like more of an after-the-fact action than the name 'inoculation' implies).

One thing in the HBGary report is the CRC algorithm used is claimed to "indicate the malware package is of Chinese origin". This was originally announced by Joe Stewart and widely reported, but there has since been some dispute as to whether the CRC is a 'smoking gun' indicating China.

We may never know...

On a somewhat related topic (malware in general), I often use virustotal to scan 'suspect' files, but a colleage recently pointed me to a coupleof other sites that provide a similar service: virusscan.jotti.org and threatexpert.com. All three are worth investigating if you haven't seen them before.

"Aurora" attacks

iSec has published a brief report [pdf] into the widely-reported "Aurora" attacks on Google (and others) that allegedly orginated from the Chinese Government. The report provides an interesting insight into a recent sophisticated attack that I suspect few organizations would have been able to repel, and is well worth reading.

An important point from the end of the report is that the:
"...most interesting aspect of this incident is that a number of small to medium sized companies now join the ranks of major defense contractors, utilities and major software vendors as potential victims of extremely advanced attackers. This is concerning for many reasons, not the least of which is that even most Fortune-500 companies will not be able to assemble security teams with the diversity of skills necessary to respond to this type of incident."

Unusual Vectors

Threatpost is reporting the use of the more unusual malware vectors with a pentester sending bogus CDs and letters supposedly from the National Credit Union Administration containing training materials. The CDs, of course, contain malware and the real lesson is not to judge a CD by its cover letter.

There's nothing new about this type of attack vector; its similar to an old case of pentesters who left usb sticks outside their target and watched the employees 'find' the drives and then, as expected, plug them in their computers as soon as they got into the office.

While a well trained staff should have had second thoughts about the latter, the former is much more troubling. How would even a trained security officer know the difference between a 'real' training CD from an official body (or partner company) and a fake?

Many organizations are constantly receiving CDs in the mail, legitimate CDs from partners, regulatory and government bodies or software trials/updates from vendors. Should someone with malicious intent be targeting an institution (or institutions), then slipping this type of trojan-laden CD into the mail probably wouldn't be all that hard. Especially if it was disguised as something the organization was expecting or receives on a regular basis.

The downside of this type of spear-phishing attack is it becomes more difficult to maintain the level of anonymity that the internet can provide once you are passing out physical discs, so although it might have a higher strike rate for the attacker, the risks of being caught are also greatly increased.

I can recall once dealing with a company in the past who had simply removed all the CD drives from their PCs to stop employees bringing in malware. This is something similar to the old 'supergluing the usb ports' trick. While an effective measure, it is somewhat extreme and will more than likely cause more problems than it will solve.

Nonetheless this type of attack is a troubling thought for those tasked with protecting a company's information assets. The only good part is it is unusual and unlikely to happen to you, but might be worthwhile mentioning in your next security awareness course.

powered by Blogger | WordPress by Newwpthemes | Converted by BloggerTheme