Threat Level: green Handler on Duty: Bojan Zdrnja

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-05-15 InfoSec Handlers Diary Blog


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

Path-conversion weakness in major AV products reported

Published: 2006-05-15
Last Updated: 2006-05-15 23:39:57 UTC
by George Bakos (Version: 1)
0 comment(s)
Juha-Matti Laurio was kind enough to put together this excellent summary of a potentially sticky vulnerability:

Reportedly "there is a design flaw in the way that NTDLL performs path conversion between DOS style path names and NT syle path names. Although many attack vectors are possible, in this paper [see later] some proof of concept cases are covered". "This issue occurs because the operating system uses multiple differing algorithms to resolve file paths. Attackers may exploit this issue to bypass security software such as antivirus and antispyware products. Other attacks may also be possible.", continues Symantec.

List about the affected products is located at
http://www.securityfocus.com/bid/17934/info

Some examples about products listed:
Norton AV, Kaspersky AV, AVG AV, Norman AV, Ad-Aware, Spybot Search&Destroy and all Windows versions from NT4.0SP1 to Windows Server 2003 SP1.

A sample .bat file demonstrating this issue was also published at
http://www.securityfocus.com/data/vulnerabilities/exploits/17934 . bat
Note: I deliberately broke this link so that this story will make it through subscribers' mail filters. Remove those spaces around the dot if you wish to retrieve this. - gb

It appears that this issue is based to the following Bugtraq posting:
http://www.securityfocus.com/archive/1/433583
More details at this 48Bits.com PDF document:
http://www.48bits.com/advisories/rtldospath.pdf

- Juha-Matti

We at the ISC have verified this behavior and strongly advise that all Windows users exercise "safe surfing" habits such as verifying attachments before opening, not executing programs unless obtained from a trusted source, etc. Also, you can hasten the update process by staying on top of your A/V vendors support group. A partial list of vulnerable products is contained in the advisory.
Keywords:
0 comment(s)

RealVNC Exploits, Bleeding Snort Signature

Published: 2006-05-16
Last Updated: 2006-05-16 21:53:42 UTC
by Kyle Haugsness (Version: 2)
0 comment(s)
Update: Matt Jonkman posted some signatures to bleeding snort that identifies the exploit attempt.  Matt reports good success with these so far.  I'll do some testing with them tomorrow.  http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/EXPLOIT/EXPLOIT_RealVNC?view=markup

Given the details of the RealVNC vulnerability that were disclosed this morning (May 15) on Full Disclosure, exploits are now being released.  This note is to alert our readers that the exploit is trivial and very effective.  (In fact, you can modify a VNC client to exploit the vulnerability with very little code changes -- around 1 line.)

Administrators should be scanning their networks for open VNC servers (typically on TCP port 5900).  You want to upgrade any VNC servers that give you protocol above 3.3.  You can use the service detection in nmap to get the protocol number. 

We can't confirm that VNC servers from other projects like TightVNC or UltraVNC are vulnerable - I don't think they are vulnerable.  At this time, it only appears that RealVNC servers are vulnerable.  Unfortunately, there doesn't seem to determine which software the remote end is running.  You only get to see the protocol number.

Unless you like to have unauthorized folks moving your mouse around the screen, you are strongly urged to upgrade to the latest RealVNC release.  Also, you should consider binding the VNC daemon to 127.0.0.1 and tunnelling the VNC traffic through an SSH tunnel, which will provide you with stronger authentication mechanisms.  Google "vnc over ssh" for more detailed instructions on how to accomplish this on your platform of choice.

Keywords:
0 comment(s)
Diary Archives