IDGNet Virus & Security Watch Friday 15 August 2003

This issue's topics: Introduction: * Blaster worm, other DCOM RPC exploits; Red Hat up2date update Virus News: * What a blast... * SDBot 'blasted' round 'net Security News: * MS03-026 updated * up2date updated to fix incorrect package signing logic

This issue's topics:

Introduction:

* Blaster worm, other DCOM RPC exploits; Red Hat up2date update

Virus News:

* What a blast...

* SDBot 'blasted' round 'net

Security News:

* MS03-026 updated

* up2date updated to fix incorrect package signing logic

Introduction:

There has really only been one security and virus story this week - the release and aftermath of the Blaster worm. Blaster spreads by exploiting the DCOM RPC bug from the MS03-026 security advisory. The advisory and related patch were released a month ago. Despite being rated as critical for all affected Windows OSes - all NT-based OSes but not Windows 98 or ME - it seems many businesses had still not only not patched but not taken rudimentary remediating security steps such as closing the appropriate ports on their external routers, firewalls and so on. As Microsoft has said that the affected services are not intended for use in hostile network environments such as the Internet, one would have hoped that more vulnerable machines would at least have been firewalled from the Internet in the month since the security bulletin's release. Aside from covering the Blaster worm and its derivatives, we briefly look at a new IRC bot net agent that has added a 'spread via the DCOM RPC vulnerability' feature and reconsider the MS03-026 patch itself, as some new twists in its use have come to light.

Aside from all this Windows 'excitement', Red Hat administrators should look into the update for up2date, some versions of which will incorrectly install unsigned packages rather than reject them.

Virus News:

* What a blast...

Not!

In case you've been living in a cave for the last few days, or have otherwise been completely removed from pretty much all sources of 'news', the IT story of the week must be the Blaster worm and associated developments.

As we have reported in recent issues of the newsletter, many in the security industry have been expecting the release of a worm based more or less closely on the publicly disclosed exploits for the DCOM RPC vulnerability in all NT-based OSes. Earlier this week the wait ended when, in the small hours of Tuesday morning (New Zealand time), the first samples of the Blaster worm were captured spreading in the wild.

Blaster, also variously known, or referred to, as Lovesan, Lovsan, Msblast, Poza and Billy, is a noisy beast. Not only does it spread through vulnerable machines, but the nature of its exploitation of the DCOM RPC vulnerability is that many machines it attacks will spontaneously restart, crash, lock-up, or display other odd symptoms (such as drag'n'drop failing to work, odd error messages when saving certain types of files in common applications, and so on). This instability is due to the worm randomly choosing one of two possible attack vectors when it first starts running. One of these attacks works against unpatched Windows 2000 machines and the other against unpatched XP machines, but each causes problems inside the RPC code of the other type of machine, producing instabilities such as those described above.

Ignoring the things that can go wrong, Blaster works as follows. When run it sets a registry value to run itself at each system startup then checks for a mutex named 'BILLY'. If this is not found such a mutex is created, otherwise the worm exits on the assumption that a copy is already running. If it keeps running it next checks it has an Internet connection and if not, drops into a loop continually rechecking for a connection. When its host machine has an Internet connection it makes a few further checks then gets the current date. If it is later than the 15th of any month, or of it is September or a later month, a thread that runs a SYN-flood denial of service against windowsupdate.com is started. Regardless of whether the SYN flood payload is activated, another thread is started that searches for other exploitable machines on the Internet, sending one of the two aforementioned attack sequences. If any of these attacks succeed, the attacked machine will open a shell back to the attacking machine on port 4444. When this happens Blaster sends commands to those machines to use the standard Windows TFTP client program to obtain a copy of the worm's program file from the attacking machine. On the attacking machine Blaster runs a short-lived thread on port 69 listening for connections and obliges by sending a properly formatted (by TFTP protocol standards) copy of itself. The attacking machine then commands the new victim, via the shell on port 4444 to run the executable it just retrieved and the process starts afresh on the new victim.

Blaster's SYN flood against windowsupdate.com should start this Saturday, 16 August as machines become infected and infected machines are restarted with their clocks set to the first date to trigger the payload since the worm's release. Network managers at some corporate networks are talking of setting up bogus DNS entries for the windowsupdate.com in their internal DNS to direct any infected machines to an internal target, or even back to the infected machines themselves by setting that domain to resolve to the loopback address of 127.0.0.1. Monitoring for machines asking the DNS to resolve windowsupdate.com will tell such administrators which machines are infected (observing the attack traffic itself is not much help as the SYN flood code used spoofs the lower two octets of the outgoing attack packets).

There have already been at least two variants of the Blaster worm beyond the one found early Tuesday. All major antivirus products have been updated to detect all the variants. Patching all workstations and servers that could possibly have exposed port 135 to the Internet or been exposed by mobile or remote machines contracting the worm elsewhere then introducing it 'inside' your network via VPN connections or by physical relocation bypassing your (external) firewalls is still a must. All system administrators should note the issues concerning reliably determining whether the MS03-026 patch has been installed or not discussed in the first item in the 'Security' section of this newsletter.

The severity of the Blaster incident is such that the CERT Coordination Center has issued an advisory about the worm. A link to that advisory is included, along with our usual antivirus vendor descriptions, below (note that due to the exceptional load Microsoft servers are currently bearing due to interest in this worm, access to Microsoft pages may occasionally be difficult).

CERT Advisory CA-2003-20 W32/Blaster worm - cert.org

Computer Associates Virus Information Center - 36265

Computer Associates Virus Information Center - 36309

Computer Associates Virus Information Center - 36310

F-Secure Security Information Center - msblast

F-Secure Security Information Center - lovsanb

F-Secure Security Information Center - lovsanc

Kaspersky Lab Virus Encyclopedia

Network Associates Virus Information Library -100547

Network Associates Virus Information Library -100551

Network Associates Virus Information Library - 100552

Sophos Virus Info -w32blastera

Sophos Virus Info - w32blasterb

Symantec Security Response - w32.blaster

Symantec Security Response - w32.blaster.b

Symantec Security Response - w32.blaster.c

Trend Micro Virus Information Center - msblast.a

Trend Micro Virus Information Center - msblast.b

Trend Micro Virus Information Center - msblast.c

* SDBot 'blasted' round 'net

Whether inspired by the Blaster worm (see above) or not, a new SDBot variant has also surfaced in the last couple of days. Adding self-spreading functionality is increasingly popular among the makers and users of bot net agents such as SDBot and Spybot. In this case a self-spreading function based on the same DCOM RPC exploit as was used for the Blaster worm's spread mechanism has been added to an SDBot. Other self-spreading functionality that has been added to some of the bot net agents include spreading via Windows Networking shares (usually taking advantage of the unfortunately common, very weak administrator passwords on Windows 2000 and XP machines) and self-mailing features.

Regular readers of this column will probably not be surprised to hear that again, a host of names have been applied to this malware by the antivirus companies, including RPCSDBot.A, Randex.E, SDBot.RPC.A and Spybot.worm.lz.

Computer Associates Virus Information Center - 36298

F-Secure Security Information Center sdbot_rpc_a

Network Associates Virus Information Library - 100549

Sophos Virus Info

Symantec Security Response - w32.randex.e

Trend Micro Virus Information Center - rpcsdbot.a

Security News:

* MS03-026 updated

Microsoft has updated MS03-026 to note that the patch will actually install on Windows 2000 SP2 and to add further workaround details. The patch itself has not been altered, so there is no need to obtain another copy of the patch. When the patch development of the patch started, SP2 was one of the supported platforms under Microsoft's Support Lifecycle policy, but as SP4 was released before the patch was completed and released, the original security bulletin did not include details of support for SP2. Microsoft now acknowledges that the patch will install on Windows 2000 SP2 and that 'limited' testing of that platform was performed. Obtaining and installing either of the later, supported, service packs for Windows 2000 and installing the patch on that is still Microsoft's preferred recommendation.

Another important note about this patch has arisen during the Blaster worm investigations. It appears that many systems may have had the MS03-026 patch installer either fail to complete installation of the patch, or to have suffered a patching order error, such that the MS03-026 patch may seem (from some vantage points) to be installed, when in fact it is not. For example, it seems clear that installing the MS03-026 patch on Windows 2000 SP3 and then installing SP4 without restarting the machine after the patch installation finishes will result in the registry entries indicating that the MS03-026 patch installer has run being present, but the versions of the RPC DLLs from SP4 (which contain the MS03-026 vulnerabilities) being installed on the machine.

This is particularly problematic for users who generally depend on Windows Update (WU) and some third-party patch managers, which simply look at the registry values set by the patch installers, rather than check the actual file versions of the installed files. The Microsoft Baseline Security Analyser (MBSA), Shavlik's 'hfnetchk' and some other third-party patch managers make these file version checks and are thus not affected by situations such as those above. However, in the same situation, WU will simply fail to present the MS03-026 patch as WU thinks the patch is already installed. If you depend on WU technology, either through the WU website or through Software Update Services, or on third-party patch management products, to keep your Windows patches up to date, it would be prudent to check the MS03-026 security bulletin (linked below) and check the individual file versions as outlined in the 'Verifying patch installation' section. The KnowledgeBase article 823980 with the relevant file manifests is also linked below for your convenience.

Microsoft Security Bulletin MS03-026

Microsoft Knowledge Base Article 823980 - microsoft.com

* up2date updated to fix incorrect package signing logic

Red Hat has released an update for its up2date package manager and installer. The versions of up2date shipped in Red Hat 8.0 and 9.0 have been found to have faulty logic when presented with unsigned packages, installing any unsigned packages if they are provided from Red hat Network servers. The default behaviour is supposed to be that up2date will only install properly signed packages. More details and links to the updated up2date packages are in the Red Hat security advisory linked below.

up2date improperly checks GPG signature of packages redhat.com

Join the newsletter!

Error: Please check your email address.

More about CA TechnologiesCERT AustraliaF-SecureKasperskyKasperskyMBSAMicrosoftRed HatShavlikSophosSymantecTrend Micro Australia

Show Comments

Market Place

[]