worm blog

Chinese Honeynet Project Writup of Dasher.B

The Chinese Honetnet Project has a nice writeup of the early December MSDTC worm Dasher, specifically the B variant. While it's light on text, it has a few screenshots and some info that goes beyond the writeups from most AV vendors.

Dasher.B is a worm that exploits the MSDTC vulnerability (as described in MSB MS05-051) on TCP port 1025 and some other vulnerability includes mssql vulnerability. Worse, it has a keylogger using a rootkit to hide itself.

Source: Worm-Dasher.B Report: Chinese Honeynet Project

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.

Dasher.C Now In The Wild

There's a new variant of Dasher.C on the loose, this one has the following changes over Dasher.B:

• It doesn't just scan for the MSDTC vulnerability, it scans for TCP ports 42 (WINS), 445 (LSASS), and 1433 (MS SQL). As always, scans have a source port of 6000, a constant IPID of 256, and an initial TTL of 120. The 3 additional attacks, which are proven attacks recycled by a lot of recent malware, is designed to find and recruit more victims.
• This one doesn't appear to have as severe target network restrictions for the scanning and attacks, meaning it will encounter more victims.
• It connects to a different FTP server to fetch the files.

This version also doesn't appear to mess with the registry based on some analysis I had a chance to do today on the files I obtained (thanks to some European research partners).

You can block TCP port 21211 outbound to stop this FTP fetch of the malware from the central malware distribution site, and block the scanning activity by blocking TCP SYN packets from TCP source port 6000 to TCP ports 42, 445, 1025, and 1433.

An additional note: As some people have noted, there are some problems with certain posts for veiwing the archives and the comments. Please note that Typepad had a catastrophic failure yesterday (Friday) and lost some parts of the database. I am rebuilding the database when I encounter these errors, which should remedy the problem. Thanks for your understanding.

New Worm: Dasher

There's a new worm on the loose. It goes by the name "Dasher", and it's attacking the MSDTC vulnerability reported by Microsoft on October 11, 2005. Furthermore, it uses Swan's MSDTC heap overflow to achive it's attack.

The worm has two known variants at this point, Dasher.A and Dasher.B. In many ways, they are very similar worms. They both have separate programs that act as the TCP SYN scanner (scanning a /16 network for TCP port 1025 reponses, all packets with the IPID of 256, an initial TTL of 120, and a source port of 6000), and a program that is the actual MSDTC exploit (it looks like Swan's exploit, compiled and named "SqlExp.exe"), driven by another process (Sqltob.exe in the A variant, svchost.exe in the B variant). When the worm attacks a host, the exploit is directed to download the worm package from a central location.

The A variant is not propagating much in the wild at this time, the central location has been shut down. The B variant, however, is in the wild and has been caught and analyzed by several groups.

If you need to protect against this, block inbound TCP port 1025, which is the service the attack comes in over. IDS signatures for the MSDTC exploit from Swan should pick it up.

Analysis

Having analyzed the worm earlier today, it looks to me like the worm was quickly put together by someone of limited coding skill, especially in managing recycled exploit code. If the author had been smart they would have sent the worm from the attacker to the new victim, not from a central site (which is prone to being shut down). Furthermore, they would have done this all as one process, not as a process that gathers the result of the scanner into a .bat script and then launches the exploit binary against those targets.

The B variant shows some increased sophistication, but recycles components from other malware.

Look for this worm to be worked on by malware authors in the coming days and possibly perfected. The exploit's reliability is not more than about 50%, meaning the worm isn't able to propagate all that well.

Links

Dasher.A  from F-Secure
Dasher.B from F-Secure
W32/Dasher-B from Sophos
Swan's original MSDTC exploit
MS05-051 from October 11, 2005, describing the vulnerability and the patch
Microsoft Distributed Transaction Coordinator Memory Modification Vulnerability from eEye, who discovered the vulnerability