If you haven’t heard by now, the “downadup” worm (renamed various other things by competing vendors) is propagating itself like crazy across the Internet. Various software vendors have added some artificial hype about how fast it is spreading, but I didn’t get sweaty palms until I read that US_CERT is now saying that the patch/Technote Microsoft released to address the issue doesn’t work.
Here’s how it’s going so far – the worm installs itself via the “autorun” feature that is enabled whenever removable device is connected to a computer. This includes, but is not limited to, inserting a CD or DVD, connecting a USB or FireWire device, or mapping a network drive. This connection can result in code execution without any additional user interaction.
So Microsoft issued an out-of-cycle patch that wasn’t really a patch or a fix – just a workaround. The patch/fix/workaround involves disabling the autorun function inside the Windows registry. The instructions in the Technet article 91525 were incorrect, and did not disable autorun.
So if you’ve done this on your network, and think you are safe…..you’re not.
A newer Microsoft Technet article is available here.
At first I was confused, because the article provides instructions for a way to disable autorun as a “workaround” against the worm propagating itself. The information does not address the vulnerability the worm is actually designed to exploit.
After some more digging, the actual vulnerability we should be concerned about is that the worm employs an attack against the “server” service listed as a Bulletin in October 2008. The exact details from the Security Bulletin MS08-067 are as follows:
“This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system remotely. On Microsoft Windows 2000-based, Windows XP-based, and Windows Server 2003-based systems, an attacker could exploit this vulnerability over RPC without authentication and could run arbitrary code. If an exploit attempt fails, this could also lead to a crash in Svchost.exe. If the crash in Svchost.exe occurs, the Server service will be affected. The Server service provides file, print, and named pipe sharing over the network. The vulnerability is caused by the Server service, which does not correctly handle specially crafted RPC requests.”
It seems the only “solution” we are offered from Microsoft for users of anything other than Server 2008 is a manual fix to try and stop propagation.
Where’s the real fix? Not the workaround (which didn’t work). Am I missing something? “Where’s the beef?”