« New MySpace XSS worm circulating | Main | DIMVA 2006 - Call for Papers »

Dasher Analysis and Thoughts

Some thoughts on the new Dasher worm that's spreading.

First, I've had a chance to look at all thre variants of the worm and reverse engineer the actual code. A big thank you to some research partners for the binaries. Having looked at the operations the worm is doing, it's obvious that it's been put together in a very haphazard fashion. The main driver of the worm actually writes a batch file that gets executed, the actual exploit code and the actual scanner are not married as code. As such, it has to be coordinated by a process (Sqltob.exe) to launch the scanner process and manage the exploit process (or processes). No one even stripped out Swan's happy little printf() statements in the code! This is a very amatuer effort on the basis of the reverse engineering.

Secondly, the worm is using a central distribution point to send out the worm binaries. The tradeoffs here are mostly obvious. As a benefit, the worm master can update the binaries here and inject new exploits or new capabilities, or just bugfixes, quite handily. It may not affect the existing worm infected systems (unless they actually poll or are connected to a worm master controlled site), but that can be sufficient. If you think about it as a seeded base from which to launch a new, improved worm, that's quite an obvious benefit. The risk inherent in this is also obvious, namely that it's easy to either shut down or begin blocking access to this central distribution site. You can block a domain name or even a 2LD, an IP address, or a port and achieve most of the blocking you need to. Pretty easy to shut this one down, as happened with Dasher.A. Dasher.B and C recycle the same master fetch site. Why someone hasn't yet repackaged the worm to send the payload from the attacker to the victim is beyond me, assuming they were capable of it.

Thirdly, the worm is clearly being worked on. It's been shown that you can get an effective worm installed (some stats I've seen suggest a couple thousand hosts worldwide are infected by this worm) using the MSDTC exploit, but it's already been augmented with three older vulnerabilities: UPNP/LSASS, MS SQL, and the WINS exploit. So, this is going to see some more work before it goes away, and we'll probably see the MSDTC exploit code rolled into the various flavors of RBot, SDBot, and such in the next few days (if you're not seeing it already).

Keep in mind it's not usually the best and brightest of the attackers who write worms, which means it's usually pretty easy to analyze these things and shut them down. While there's been great effort put forth to make stealthy, polymorphic, and difficult to analyze malware, it rarely gets used in the wild on a global scale. For the forseeable future, we're going to see worms like Dasher get launched, and we're going to have to shut them down the same way we always do.

If you haven't patched your MSDTC holes yet, go do so. If you can't, make sure you block port 1025 to those systems.

December 18, 2005 in dasher, editorial | Permalink
Tell others: digg submit | del.icio.us this | Reddit

Comments

is this vulnerability capable of being exploited only once? how does the worm chooses the payload to attack different systems (win2k, winXP)?

Posted by: vinicius | Dec 18, 2005 6:23:10 PM

i'm not sure if it can be exploited only once or multiple times. i had a look at swan's exploit (the basis of SqlExp.exe), and the value it uses for both choices (0 and 1) is the same. then i had a look at the worm's master process, SqlTob.exe, and i see it construct two attack commands, one using the 0 choice and one using the 1 choice. i didn't see it try and determine which one to use, it looks like it fires off both of them (unless i'm reading this horribly wrong).

so, to answer your question, it looks like it just fires and hopes for the best.

Posted by: jose | Dec 27, 2005 2:08:02 PM

The comments to this entry are closed.