Threat Level: green Handler on Duty: Tom Webb

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Microsoft Malicious Software Removal Tool users double check it's running

Published: 2008-08-01
Last Updated: 2008-08-02 02:33:15 UTC
by Robert Danford (Version: 2)
1 comment(s)

A reader (thanks Joe D.) shared with us his recent experience with the Microsoft Windows Malicious Software Removal Tool after the latest update (July).


The tool requires administrative privileges during the initial installation, but can then run as an unprivileged user from then on after accepting the license agreement.

From the release notes:
"You must accept the Microsoft Software License Terms. The license terms are only displayed for the first time that you access Automatic Updates.

Note After you accept the one-time license terms, you can receive future versions of the Malicious Software Removal Tool without being logged on to the computer as an administrator."

It appears that some component of the Agreement may have changed in this latest update which will require an Admin user to launch the tool and accept the new agreement. Some users may not be aware of this and be under the false impression the tool is running on a schedule as expected.

So now would be a good time to double check that the Malicious Software Removal Tool is in fact running on your machine(s) as expected. In fact now is a good time to review any security software in general that is expect/required to be running on your systems to determine it is in fact running. Any number of updates, misconfigurations, network huffage, or even better/worse malicious action could have disabled various programs or prevented them from running.

Many flavors of malware will search for and shutdown or disable most of the common personal firewall, anti-virus/anti-spyware tools. Or even more difficult to audit are those malicious programs which simply modify the firewall settings to allow the ports they need open.

Here is the link to details on the tool:

http://support.microsoft.com/?kbid=890830

This KB has some useful information for determining the tool is running (especially in a large environment):

http://support.microsoft.com/kb/891716/

Excerpt:
"A2. You can examine the value data for the following registry entry to verify the execution of the tool. You can implement such an examination as part of a startup script or a logon script. This process prevents the tool from running multiple times.

Subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RemovalTools\MRT
Entry name: Version

Every time that the tool is run, the tool records a GUID in the registry to indicate that it has been executed. This occurs regardless of the results of the execution."

So for the lastest update (July 2008) the GUID you'll find listed as the "Version" is:

BC308029-4E38-4D89-85C0-8A04FC9AD976

This may also help determine that the tool is being updated.

Robert
ISC Handler on Duty

Keywords: Microsoft
1 comment(s)

Apple's Security Update 2008-005: DNS workaround finally included

Published: 2008-08-01
Last Updated: 2008-08-01 20:06:50 UTC
by Swa Frantzen (Version: 3)
0 comment(s)

Apple released their patch overnight (depending on your timezone of course).

Most importantly it contains the workaround for the DNS bug CVE-2008-1447. Also included is an upgrade to PHP 5.2.6 (which was released in source code at www.php.net on May 1st). Seems we all need to urge Job's gang to release patches significantly faster: it's the price to pay to base parts of your system on open source code.

Apple Mac OS X users get it though software update. As always it's one big patch, given that little choice,  you'll want to PATCH NOW.

UPDATE 1:

A quick packet dump of my fully patched Leopard machine (OS X 10.5.4) shows it is -as a DNS client- still using incrementing ports.

12:31:43.611624 IP [MAC].49514 > [SERVER].53: 41963+ A? www.google.com. (32)
12:31:43.623700 IP
[SERVER].53 > [MAC].49514: 41963 5/7/7 CNAME www.l.google.com.,[|domain]
12:32:04.235692 IP
[MAC].49515 > [SERVER].53: 44651+ A? www.yahoo.com. (31)
12:32:04.259856 IP
[SERVER].53 > [MAC].49515: 44651 2/9/5 CNAME[|domain]
12:32:12.771820 IP
[MAC].49516 > [SERVER].53: 25701+ A? www.ask.com. (29)
12:32:12.902074 IP
[SERVER].53 > [MAC].49516: 25701 4/9/9 CNAME[|domain]

For the record: the traffic was generated with ping to some search engines, but dig e.g. uses exactly the same pattern. /etc/resolv.conf contained nothing but a domain and [SERVER] as the nameserver. The machine did reboot to complete the patch installation. There is no named running on [MAC], just the client libraries are used.

So Apple might have fixed some of the more important parts for servers, but is far from done yet as all the clients linked against a DNS client library still need to get the workaround for the protocol weakness.

UPDATE 2:

Andrew Storms blogged about the same issue with the OS X 10.4 (Tiger) version of the update.

--
Swa Frantzen -- Section 66

Keywords: apple patch
0 comment(s)
Diary Archives