Dan Kaminsky's Blog

In December of 2009, Bill Brenner from CSO Magazine asked me what to expect from 2010.  I’d actually never done one of these “predict the future” writeups before, but I took a shot at it.  Bill ended up posting the more CxO of these.  Here’s (roughly) the full set:

1. Economics will cause a few members of the “Old and Hoary Prediction Club” to finally come true.

One of the defining laws of security in general can be thought of as:  “What could possibly go wrong is much more than what actually does.”  Most bad things do not happen because they’re prevented.  They don’t happen because “the bad guys” simply do not choose to do them.  But this is truly the first major economic recession of the Information age, and whatever the numbers say, a *lot* of people are struggling.  That’s motive.  People who struggle get creative, by which I mean “start doing creative and profitable things they heard about”.  Not everything that’s been predicted in previous years will come true, but at the end of 2010, look back to predictions for 2007, 2008, and 2009.  Some of the wrong ones will have happened.  One in particular is number two on this list:

2. Cyber extortion will finally enter the public consciousness.

There’s no good data on — wait, this is security.  There’s not much in the way of good data on *anything*.  But, facing a credible threat to a downtime sensitive, computer driven infrastructure, extortion demands do in fact get paid.  Sometimes the system is large, like a public utility or a manufacturing facility.  Sometimes it’s not exactly on the side of angels, like an online gaming establishment.  And sometimes it’s just some random mom and pop, or even citizen, being told to spend $50 if they ever want to see their documents again.  There’s no good way of knowing how big a problem this has been, but this may be the year that extortion, like credit card fraud and even more like identity theft, becomes part of the national conversation.  Expect stock filings to start having to disclose unexpected expenses, some truly ill-advised marketing campaigns by security vendors, backlash (not at all entirely undeserved) that the threat is being wildly overblown, and continuing aggression towards the channels by which the extortionists get paid.

3. Prosecution for cybercrime will begin in earnest, starting with the sloppy rich.

Our scanners improve!  A new nmap Beta 7 is out (Windows, OSX, Source), with slightly more accurate scan logic research by Renaud Deraison of Nessus.  This tends to find a few extra boxes per network, so it’s definitely worth grabbing.  It doesn’t take too much work to spin up another scan, and heh, it’s an opportunity to play with ndiff, the nmap diffing engine.

McAfee also has a really nice Windows based scanner out the door — check it out.

Of course, you may be thinking:  The world didn’t come to an end.  Clearly, this whole thing was just a Y2K hypefest.  I’m sorry the bad guys aren’t quite the eschatologists some people would like them to be, but somebody’s been investing extraordinary amounts of resources making a worm very difficult to kill.  It’s not like there was a contingent of rogue coders, sitting around figuring out where they could put two-character date fields after January 1st, 2001.  There’s a bad guy out there, and while we shouldn’t panic, we shouldn’t quite ignore the situation either.  Botnets — even much smaller botnets than would have otherwise have been created, thanks to rapid patching and automatic updates by Microsoft — are big business.  As my friend Jason Larsen says, it’s not about ownage, it’s about continued ownage.

What to do?  That’s what makes these scanners nice.  They represent clean, actionable, operationally viable guidance for IT staff that aren’t exactly bursting at the seams with free time.  I continue to be appreciative of all the developers who worked this last weekend to push Tillmann and Felix’s code into their products.  It goes a long way towards moving us closer to less fear, more certainly, and no doubt.

There be news!

First off, the Honeynet Project has released Know Your Enemy:  Containing Conficker.  Tillmann and Felix have done a tremendous job of analyzing Conficker, and their paper makes for a great read.  Plus, you get to find out exactly what Conficker is doing differently on the anonymous network surface.

Secondly, nmap has released 4.85Beta5 (Windows, OSX, Source), with the Conficker detection logic.  Cool, no more hacking up Beta4.

Please, be careful to actually use –script-args=safe=1, like so:

nmap -PN -d -p 445 –script=smb-check-vulns –script-args=safe=1 1.2.3.4

Third, I’ve rebuilt the py2exe versions of Tillmann and Felix’s scs code, now with Core’s impacket library safely embedded.  See here.  Source code, of course, is at their site (see scs.zip).

Finally, commercial scanning products continue to make steady progress protecting their customers, with nCircle and Qualys coming online.

We may not know what the Conficker authors have in store for us on April 1st, but I doubt many network administrators want to find out.  Maybe they don’t have to:  I’ve been working with the Honeynet Project’s Tillmann Werner and Felix Leder, who have been digging into Conficker’s profile on the network.  What we’ve found is pretty cool:  Conficker actually changes what Windows looks like on the network, and this change can be detected remotely, anonymously, and very, very quickly.  You can literally ask a server if it’s infected with Conficker, and it will tell you.  Tillmann and Felix have their own proof of concept scanner, and with the help of Securosis‘ Rich Mogull and the multivendor Conficker Working Group, enterprise-class scanners should already be out from Tenable (Nessus), McAfee/Foundstone, nmap, ncircle, and Qualys.

We figured this out on Friday, and got code put together for Monday.  It’s been one heck of a weekend.

The technical details are not complicated — Conficker, in all its variants, makes NetpwPathCanonicalize() work quite a bit differently than either the unpatched or the patched MS08-067 version — but I’ll let Tillmann and Felix describe this in full in their “Know Your Enemy” paper, due out any day now with all sorts of interesting observations about this annoying piece of code.  (We didn’t think it made sense to hold up the scanner while finishing up a few final edits on the paper.)

Couple useful things for IT admins out there.  I’ve packaged up Werner and Feder’s PoC scanner via py2exe here.  You can now simply run:

C:\Python26\scs\scs>scanner.exe 1.2.3.4

———————————- Simple Conficker Scanner ———————————- scans selected network ranges for conficker infections ———————————- Felix Leder, Tillmann Werner 2009 {leder, werner}@cs.uni-bonn.de ———————————-

[WARNING] 1.2.3.4 seems to be infected by Conficker!

C:\Python26\scs\scs>scs.exe 1.2.3.4 1.2.3.4

———————————- Simple Conficker Scanner ———————————- scans selected network ranges for conficker infections ———————————- Felix Leder, Tillmann Werner 2009 {leder, werner}@cs.uni-bonn.de ———————————-

[WARNING] 1.2.3.4 seems to be infected by Conficker! Done

Note that scs.exe will also take an IP list, so if you can generate that in a fast sweeper, scs.exe will go much faster.

Of course, what would be really helpful is getting nmap going — and the code is in fact in SVN!  I believe the nmap guys are working on packages right now, but in the meantime, here’s what their dev says to do if you’re on Unix:

If you prefer to install it: svn co –username=guest –password=” svn://svn.insecure.org/nmap cd nmap./configure && make sudo make install nmap -PN -d -p445 –script=smb-check-vulns –script-args=safe=1 <host>

If you don’t want to install it: svn co –username=guest –password=” svn://svn.insecure.org/nmap cd nmap./configure && make export NMAPDIR=../nmap -PN -d -p445 –script=smb-check-vulns –script-args=safe=1 <host>

Building nmap is a little tricky on Windows apparently, but happily enough, this isn’t necessary.  Follow these steps to get high speed scanning on Windows:

1) Install the latest development build, of nmap, 4.85Beta4, from here. 2) Retrieve this package, extracted from SVN, and merge it into your c:\Program Files\nmap directory. 3) Enjoy:

C:\Documents and Settings\dan>nmap -PN -d -p 445 –script=smb-check-vulns –script-args=safe=1 1.2.3.4

Winpcap present, dynamic linked to: WinPcap version 4.0.2 (packet.dll version 4. 0.0.1040), based on libpcap version 0.9.5

Starting Nmap 4.85BETA4 ( http://nmap.org ) at 2009-03-30 08:42 Pacific Daylight Time ————— Timing report ————— hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 ——————————————— mass_rdns: Using DNS server 4.2.2.1 Initiating Parallel DNS resolution of 1 host. at 08:42 mass_rdns: 0.38s 0/1 [#: 1, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1] Completed Parallel DNS resolution of 1 host. at 08:42, 0.36s elapsed DNS resolution of 1 IPs took 0.38s. Mode: Async [#: 1, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0] Initiating SYN Stealth Scan at 08:42 Scanning 21Cust103.tnt1.kingston.on.da.uu.net (1.2.3.4) [1 port] Packet capture filter (device eth0): dst host 192.168.1.103 and (icmp or ((tcp o r udp) and (src host 1.2.3.4))) Discovered open port 445/tcp on 1.2.3.4 Completed SYN Stealth Scan at 08:42, 0.75s elapsed (1 total ports) Overall sending rates: 1.33 packets / s, 58.67 bytes / s. NSE: Initiating script scanning. NSE: Script scanning foo (1.2.3.4). NSE: Initialized 1 rules NSE: Matching rules. NSE: Running scripts. NSE: Runlevel: 2.000000 Initiating NSE at 08:42 Running 1 script threads: NSE (1.438s): Starting smb-check-vulns against 1.2.3.4. NSE: SMB: Extended login as \guest failed, but was given guest access (username may be wrong, or system may only allow guest) NSE (6.001s): Finished smb-check-vulns against 1.2.3.4. Completed NSE at 08:42, 4.58s elapsed NSE: Script scanning completed. Host foo (1.2.3.4) appears to be up … goo d. Scanned at 2009-03-30 08:42:46 Pacific Daylight Time for 6s Interesting ports on foo (1.2.3.4): PORT    STATE SERVICE      REASON 445/tcp open  microsoft-ds syn-ack

Host script results: |  smb-check-vulns: |  MS08-067: NOT RUN |  Connficker: Likely INFECTED |_ regsvc DoS: NOT RUN (add –script-args=unsafe=1 to run) Final times for host: srtt: 360000 rttvar: 360000  to: 1800000

Read from C:\Program Files\Nmap: nmap-services. Nmap done: 1 IP address (1 host up) scanned in 6.00 seconds Raw packets sent: 1 (44B) | Rcvd: 1 (44B)

I’m sure there’s some way to use the NMAP GUI too — if someone wants to post a doc for that, I’ll link to it.

So the general theme of my talks for the last year has been about the extraordinary damage that infrastructure attacks are capable of. I do believe it’s possible to bolster endpoint security — to achieve end-to-end trust — but it will take more than what we’re doing right now. It will take, somewhat to my surprise, DNSSEC.

It will also take treating infrastructure itself with more care, and more security due diligence, than we do today. Forget patching infrastructure. When my DNS bug hit, a remarkable number of sites suddenly found themselves simply identifying the DNS servers they were dependent on. We can do better. We need better operational awareness of our infrastructure. And we need infrastructure, over time, to become a lot safer and easier to update. That means automatic update isn’t just for desktops anymore, that firmware patches need to have a much higher likelihood of not bricking the hardware, and possibly, that we need fewer builds with more testing for the new production environment, that is increasingly under attack.

The reality is the bad guys are out there, and they’re learning.  Just as attackers moved from servers to clients, some are moving from compromising a single client to compromising every client behind vulnerable infrastructure.  Psyb0t, a worm that has been bouncing around since January, was recently found by DroneBL and reported on by Ryan Naraine.  It targets home routers, and early estimates are that it has hit over 100K of them.  Home routers are a wonderful, enabling technology for users, and even for security, they carried us through 2001-2004’s years of widespread server side vulnerabilities.  So we shouldn’t be too down on them.  But they do have vulnerabilities, and they are getting exposed.

This, of course, is something quite a few people have been talking about.  CSRF — Cross Site Request Forgery — attacks have affected everyone from Linksys to Motorola to Siemens to Cisco.  More problematically, the DNS Rebinding attacks discussed by myself, David Byrne, Dan Boneh/Adam Barth/Collin Jackson, and others in 2007 still affect home routers. And I’m not talking about Java and Flash sockets, like at this year’s CanSecWest talk.  I’m talking about simply running rebinding against the browser itself, to make a remote website and a local router appear to be the same name, thus able to script against one another.

This should sound familiar, because this is what I discussed at RSA last year.

Yep, that still works, in all browsers. It has to. Moral of the video, please don’t have a default password on your home router — and, maybe, home routers can someday only allow default passwords to work 10 minutes after power cycling.

Slides from Cansec, replete with TCP NAT2NAT goodness.

(In my defense, this trick is way less hideous than my 2001 IP TTL game!)

Staring Into The Abyss

I’m just going to come out and say it:  I miss packet craft.  Sure, we can always pull out Scapy, and slap amusing packets together, but everything interesting is always at the other layers.

Or is it?

For CanSecWest this year, I thought it’d be interesting to take a look at the realm of Deep  Packet Inspectors. It turns out we were doing a lot of this around 2000 through 2002, and then…well, sort of stopped.  So, in this year’s CanSecWest paper, “Staring Into The Abyss:  Revisiting Browser v. Middleware Attacks In The Era Of Deep Packet Inspection” (DOC, PDF), I’m taking another crack at the realm — and I’m seeing really interesting capabilities to fingerprint, bypass, and otherwise manipulate systems that watch from the middle of networks, using protocol emulation abilities that have been part of browsers and their plugin ecosystem from the very beginning.

Ah, but here’s where I need some help.  I’ve worked pretty closely with Robert Auger from Paypal, who just published his own paper, “Socket Capable Browser Plugins Result In Transparent Proxy Abuse”.  We independently discovered the HTTP component of this attack pattern, and as I describe in my paper, we’ve kind of forgotten just how much can be done against Active FTP Application Layer Gateways.

So, if I may ask, take a look, check out my paper, and if you have some thoughts, corrections, or interesting techniques, let me know so I can integrate them into my CanSecWest presentation.  Here’s the full summary, to whet your appetite:

DPI — Deep Packet Inspection — technology is driving large amounts of intelligence into the infrastructure, parsing more and more context from data flows going past. Though this work may be necessary to support important business and even security requirements, we know from the history of security that to parse data is to potentially be vulnerable to that data – especially when the parser is designed to extract context as quickly as possible. Indeed, companies such as BreakingPoint and Codenomicon have made their names building test tools to expose potential faults with DPI engines. But could anyone actually trigger these vulnerabilities? In this paper, we restart an old line of research from several years ago: The use of in-browser technologies to “tweak” Deep Packet Inspection systems.

So Crystal and the rest of Workhabit just threw another Unconference:  Cloudcamp Seattle.  I’m actually pretty impressed with the crowd — there’s representation from Amazon EC2, Windows Azure, and RightScale (who, non-ironically, have actually implemented Cloud on Cloud).   Crystal asked if I’d be willing to do a Cloud Security talk.  The Man couldn’t fly out, but here’s my thoughts on the cloud.  Quick summary:  There are ugly engineering (and procedural) issues we can’t actually ignore, mainly around escaping the management layer and the problem of intrusion disclosure, but:

a) This is such a superior way to deploy software, that I expect to see the necessary modifications to hardware and authentication technologies so as to obviate the threats in this deck, and b) Private clouds are such an obvious value add that they’ll carry us through until the modifications are implemented.

I’ll throw video on as well if people want.  Enjoy!

When Irresistable Forces Attack

I’ll write more detailed commentary later, but here are the slides I recently presented at Black Hat.

2008 And The New (Old) Nature Of Critical Infrastructure