New Beagle on the war path

Published: 2005-12-15
Last Updated: 2005-12-15 23:15:38 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
A new Beagle/Bagle variant is making the rounds. It comes in an almost empty email, as a ZIP attachment containing the worm as an EXE. The attachment name, email subject and sole text content of the email all seem to be male or female names. Keep your eyes peeled, especially if your users are reading their mail over webmail, as it seems to take another couple of hours until the AV vendors have their patterns lined up.

Update 23:10 UTC:  It took most of the AV vendors their sweet time to get the patterns out for this one. Now things slowly start to look a bit more cheerful, though we know of at least one vendor where the Beagle/Bagle attachment still sails right through the filter, even though the vendor website claims that protection is in the current pattern. If you are not yet anyway already blocking all .exe (and .exe within .zip) on your email gateway, days like today should maybe make you reconsider.

Keywords:
0 comment(s)

If MS05-054 doesn't apply correctly...

Published: 2005-12-15
Last Updated: 2005-12-15 17:19:37 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
Shinil Hong of SUNY Buffalo has sent us his analysis of problems encountered with the installation of MS05-054. Here's what Shinil found out:  The cumulative Internet Explorer patch fails to install when ProgramFilesDir value in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion registry key points to a manually changed drive letter that is different from the default %SystemDrive%\Program Files path (e.g. C:\Program Files). The U.S. distribution versions of Microsoft Windows Server 2003 and XP ship with MS Internet Explorer 6.0 installed by default in %SystemDrive%\Program Files\Internet Explorer\ directory. If the ProgramFilesDir registry value points to D:\Program Files, for example, while the actual program directory of MS Internet Explorer is C:\Program Files\Internet Explorer, the patch installer will attempt to update the empty D:\Program Files\Internet Explorer directory and fail eventually.  For a solution, change the registry key back to the default while applying the update. 
[Note: This problem description and resolution has not yet been verified by SANS ISC]

Keywords:
0 comment(s)

MS05-051 (MSDTC) Malware / Port 1025

Published: 2005-12-15
Last Updated: 2005-12-15 16:04:03 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
A blog entry over at F-Secure mentions a new piece of malware dubbed "Dasher.A" that is trying to exploit the MS05-051 aka MSDTC vulnerability. The spreading mechanism seems to be very unreliable, but likely explains the surge in Port 1025 traffic we've seen recently . The captured packets look a lot like what the MS05-051 POC exploit posted at FrSIRT.com would cause.  [Thanks to Juha-Matti and David for reporting this.]

Update 15:27 UTC: Georg Wicherski from the German Honeynet Project has successfully captured the full exploit, including payload, on one of these tcp/1025 attacks. The payload will be called Dasher.B by F-Secure - and unlike the .A variant, this one does work, and drop a keylogger. Georg is planning to update mwcollect with MS05-051 detection and capture code over the next days.


Keywords:
0 comment(s)

LAND attacks against network devices

Published: 2005-12-15
Last Updated: 2005-12-15 13:56:26 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
A "LAND" attack involves IP packets where the source and destination address are set to address the same device. Older variants, as reported http://isc.sans.org/diary.php?date=2005-03-07 earlier, rely on the source address to be spoofed to the same value as the destination IP.  A recent post to Bugtraq came up with a new twist: LAND attacks against routers and perimeter devices, addressed to the outside interface and with the source spoofed to the inside interface. Rumour has it that these attacks are easily conducted and surprisingly "successful".  The defense, though, is just as simple: Packets with spoofed source addresses have no business entering your perimeter networks. If you have not yet applied ingress filtering on the outermost devices of your internet connection that you have control over, now is a good time to do so. RFC 2827 and RFC 3704 are good sources of information on ingress filtering and Reverse Path Forwarding. And while you're at it updating your filters, dont forget to apply outbound spoofing filters as well - see this paper in the SANS Reading Room for details.


Keywords:
0 comment(s)

Comments


Diary Archives