Pay attention to Cryptowall!
CryptoLocker might be pretty much off the radar. But Cryptowall is alive and kicking, and making the bad guys a ton of money. It mainly spreads by poisoned advertisements and hacked benign websites, and then sneaks its way onto the PCs of unsuspecting users by means of Silverlight, Flash and Java Exploits.
Somewhat unexpectedly, Java is NOT the most prominent for a change. It looks like the Silverlight sploits are currently the most successful.
If you're "had", Cryptowall encrypts all the files that you possible could want to keep (images, documents, etc), and then asks for a 500$ ransom. If you don't pay up quick, the ransom doubles. And after a while of not paying, well, the suckers delete the key. As far as we know, there is not way yet to recover the encrypted data, because the private key is not really present on the infected machine. I hope you have a recent backup.
Last week's batch of infections for example had "food.com" as a prominent source. As far as I can tell, they are cleaned up by now, but we have several samples in the database that show pages like http://www.food[dot]com/recipe/pan-fried-broccoli-226105, http://www.food[dot]com/recipe/barefoot-contessas-panzanella-salad-135723, etc, as the last referer before the exploit triggered.
The domains last week were following the pattern [a-f0-9]{6,8}\.pw and [a-f0-9]{6,8}\.eu, but this is obviously changing all the time. Still, it probably doesn't hurt to check your DNS or proxy logs for the presence of (especially) .pw domains. Yes, I had to look it up as well ... .pw is Palau. A bunch of islands in the South Pacific. It is safe to assume that most of the web sites with this extension are not actually about or in Palau.
More info: Ronnie has an outstanding write-up at http://phishme.com/inside-look-dropbox-phishing-cryptowall-bitcoins/ . Cisco's blog has a lot of IOCs: https://blogs.cisco.com/security/rig-exploit-kit-strikes-oil
Help your pilot fly!
What the Federal Aviation Administration (FAA) calls "novel and unusual" apparently entails some sort of direct network connectivity between the avionics (think: cockpit) and the passenger entertainment system (think: dude with his iPhone connected to the in-seat USB port) in the latest Boeing 737 models.
The good news is, if you get bored on your next flight, and the movies are all *meh*, you might be able to connect to the cockpit and help the pilot do his/her job. Pilots, these days, are all stressed out, and I'm sure they appreciate help from all the XBox and Nintendo pilots sitting in the main cabin! A completely new form of auto-pilot: Flying a plane through majority decision by the geeks in the cabin!
I wonder how many years we are away from a cross-platform virus that moves from Joe Bloe's PC at home, to his phone, to his car, to his tablet, to his airplane. I hope it never happens. But the "internet of things" manufacturers, especially the manufacturers of massive moving things, seem to be very keen to get us there.
Gimme your keys!
It doesn't take a lot of security savvy to realize that private keys used for things like SSH login probably should not be stored in the webroot of a web server. The physical world equivalent would be to place your house key under the doormat, and nobody does that, right?
Still, we are seeing an uptick of scans on web servers looking for such files that really shouldn't be present.
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /dsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_dsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_dsa.old HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /identity HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_rsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_rsa.old HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /key HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /key.priv HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /rsa HTTP/1.1" 404 124 "-" "-"
[...]
The scan looks for about 50 different file names that are commonly associated with SSH keys. In addition, it also probes for the presence of common Unix shell history files:
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.bash_history HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.history HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.sh_history HTTP/1.1" 404 124 "-" "-"
One signature that the scans so far had in common is that the first request is always to "checknfurl123".
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /checknfurl123 HTTP/1.1" 404 124 "-" "-"
This is most likely a test to determine how the scanned server responds to requests for files that do not exist, so that false positives can be eliminated in the subsequent attempts to read the SSH keys. I am currently running a honeypotty to see what the scanners do next if the "HEAD" request comes back with an okay (200). No luck yet, so if you already have that bit of intel, please share via the comments below.
Comments