daHIFI

Several vulnerabilities in Microsoft’s the Windows Zero Configuration Wireless utility (ZeroConf, also known as Wireless Auto Configuration) have come to my attention in the past few days which could cause serious ramifications for enterprise network security, namely the Microsoft Windows Silent Adhoc Network Advertisement, KARMA Probe Request Response and the WEP-Client-Communication-Dumbdown (WCCD) Vulnerability. Based on testing I believe that administrators should make some GPO changes to protect their users and network.

The first exploit has been named Microsoft Windows Silent Ad-hoc Network Advertisement. The exploit has been documented at http://www.nmrc.org/pub/advise/20060114.txt just in the past few days, although the method has been known for some time. The exploit works as follows:

John Doe brings his company laptop home and connects it to his home network, an unsecured open access Linksys router. The configuration details are stored in the ZeroConf program. John finishes his work at turns off his laptop.

Later, while on a business trip, John powers up his laptop to work on a report that he is doing. His laptop immediately begins to look for the Linksys router, and not finding it begins broadcasting an ad-hoc network using the SSID of his home access point.

Hacker Jane, also in the same airport terminal as John, is running one of many wireless discovery tools on her laptop, and sees John’s machine and its ad-hoc network come online. She initiates a connection to John’s SSID. The two machines then negotiate IP addresses using Microsoft’s Link Local addressing scheme 169.254.x.x. Jane now has a network connection to John’s laptop and can now start typical penetration attacks, SMB, dictionary attacks, etc.

I have also tested the same vulnerability just hours ago using a pair of laptops and an unsecured access point in the lab.

Join Laptop 1 to the access point with SSID ‘1234’
Power off Laptop 1.
Power off the access point.
Bring Laptop 1 online. Network ‘1234’ now shows up in Laptop 1’s network list as ‘Disconnected.’ At this time it is already functioning as an ad-hoc network client.
Bring Laptop 2 online. Network ‘1234’ now shows up in its available network list as an unsecured ad-hoc network.
Connect Laptop 2 to ‘1234’. The moment I pressed this button on Laptop 2 I watched as both it and Laptop 1 went from ‘disconnected’ to ‘acquiring network address’.

This is just one scenario that could be exploited. Given the number of tablets and laptops currently deployed the possibilities are endless. Just yesterday afternoon I was able to make an ad-hoc connection to a user’s laptop within our IS department and browse their hard drive. I believe it would also be possible to have done the same thing from outside of the building using unidirectional antennas. We must also be aware of the possibility that Windows internet connection bridging might also give a hacker direct access to our internal network once connected to vulnerable machines.

The second attack focuses on a probe request, a type of packet that Windows sends as it scans the ether for wireless networks it has connected to in the past. A hacker tool known as KARMA (http://www.theta44.org/karma/) can intercept these requests and automatically configure itself to reply as an access point for all clients. A presentation (http://www.theta44.org/software/iaw6.ppt) is available on the same page that details how this can be exploited to fool a laptop into connecting to an unsecured spoof network even when it is configured to connect to a WPA enabled secure network.

To guard against these exploits there are several steps adminstrators can take, the first being to configure ZeroConf not to connect to ad-hoc networks. There is a Wireless Network (IEEE 802.11) Policies Group Policy Extension available here: http://www.microsoft.com/technet/community/columns/cableguy/cg0703.mspx that we can use to set this and many other settings including disabling the ZeroConf service altogether. Windows does not natively support the type of encryption that we use within our HQ and the rest of our enterprise should not be using wireless at all. Disabling ZeroConf completely would enable us to maintain the security of our network by rendering a majority of rouge access points (unauthorized AP’s brought in by FEI employees) unusable.

The first argument against disabling ZeroConf that I hear is that it will interfere with persons that wish to use their access points at home. My response to this argument is that the vendor supplied software that we have, namely the Intel software for our HP clients and the Cisco 802.11 client software would allow users to use their home AP’s while providing us with the layer of security that we need. Initial reports state that the Intel software is not susceptible to this type of attack, although it has not been fully tested.

The final vulnerability that I am aware of has been dubbed the WEP-Client-Communication-Dumbdown (WCCD) Vulnerability (http://www.securitystartshere.net/page-vulns-wccd.htm). To put it briefly it describes how a certain wireless XP card drivers can be tricked into dumping a WEP enabled network connection and joining an attacker’s unsecured one. I have not tested this to see if we are vulnerable or not, but simply bring it to your attention as another example of the issues that we are facing.

Enterprises are susceptible to these attacks if they have decided to disable the MS firewall thru GPO. Once an attacker has gained wireless access they can attack a machine using any standard hacker / script kiddie attack tools known to man, as well as utilize any unpatched MS vulnerabilities that exist on the system. Once in they might utilize a persistent agent on the box to gain a foothold on an inside network when a user connects back to our hard wired or VPN network.

Internal network security is only as strong as the network attached to it. Some changes must be made to see that these wireless security issues do not go unresolved.

Filed by Michael at 4:06 pm under Uncategorized
No Comments

From Joshua Kinberg’s site comes a couple of scripts for the ever awesome Greasemonkey Firefox extention which allows you to save the videos off of Google and YouTube.

[Update: I also stumbled across this page about saving Flash videos as AVI’s or MPG’s.

Filed by Michael at 11:06 am under Uncategorized
No Comments

Note: This testing was performed prior to the MS WMF patch being released on 1.5.05

Purpose: Evaluate susceptibility to the recent un-patched WMF vulnerability currently being used by attackers in the wild and test the various prevention methods.

Testing environment: Both the attacker and all of the victims were run within a Virtual Machine environment on my machine which contains a 64 bit CPU with support for Data Execution Protection (DEP)

Attacker: Ubuntu Linux 5.1 running Metasploit Framework 2.5
Victim 1: XPSP2, fresh installation, no AV
Victim 2: Latest patches installed , Norton 10
Victim 3: XPSP1, fresh installation

Procedure:

First I loaded the Metasploit framework and setup IE_XP_PVF_METAFILE.PM exploit script to be served from the attacker’s IP. I opened IE on Victim 1 and pointed it at the attacker. The IE info bar popped up informing me that it had blocked the file download. At this point I clicked the ‘download file’ button to see what would happen if a user decided to do the same. The system would not let me open the .BMP file, only save it to disk. I saved it to desktop and tried to open it. The File and Fax viewer program opened. While it was generating the image, a DEP warning popped up to tell me that the file had been closed. I also received an error that the F&F viewer had terminated unexpectedly.

Next I pointed the victim 2 at the attacker. I received the same sequence of events with the info bar blocking the download and DEP squashing the execution of the file. However Norton did not step in to recognize the file until after I did a copy & paste and tried to open the file with notepad. Only then did it recognize the file as bloodhound.exploit.56 (http://www.symantec.com/avcenter/venc/data/bloodhound.exploit.56.html)

Continuing on to Victim 3 I again repeated my test. This time I was able to gain shell access to the victim with a CMD window interface on the attacker.
I then loaded a copy of Norton AV 10.0.1 from the IS download page on the Pipeline. After making sure that it had the most recent definition files loaded I was able to successfully exploit the system again and again, and even tested a VNC injection which gave me remote desktop capabilities from the victim to the attacker.

Around this time Norton began to intercept some of my attacks. During the next few steps that follow Norton would begin to intercept my attacks, but I was able to reboot the Metasploit framework on the attacker or restart the victim and was able to access the system again.

I next tested adding a %windir%\system32\shimgvw.dll software restriction to a Local Policy, much like FEI has done within Group Policy. I restarted the machine and attempted my attack again. The software restriction had no effect on my ability to infiltrate the system.

Next I ran ‘regsvr32 -u %windir%\system32\shimgvw.dll’ on victim 3. At this point I was unable to successfully attack the system. While trying to open malicious URL I was greeted by a message that the temp file could not be found. Shortly after this I received an infection notice from Norton. I was no longer able to gain remote access to the system, even after re enabling the DLL and deleting the software restriction.

At this point I disabled Norton’s auto protect feature and tested both the software restriction and unregistered the DLL to verify that they were unable to successfully prevent my attacks.

At this point Norton re-enabled itself. I tried to download the malicious payload and was able to compromise the victim again.

Next I downloaded the unofficial patch from Ilfak Guilfanov’s Hexblog, restarted the system and disabled Norton before trying to compromise the system. After downloading the file I was greeted with an ‘invalid menu handle’ pointing to the download. I re-enabled Norton and tried again; Norton was able to block the file. I restarted the Metasploit framework and tried again on the victim, at which point Norton let the file thru. The patch blocked the infection.

I uninstalled the patch and restarted the machine. I was still greeted by the ‘invalid menu handle’ error.

I reverted victim 3 within VM to a point before I had begun my attacks or installed Norton.

I changed the file handling of BMP files to be opened by PAINT. I received an error that the file was not a valid BMP file.

I changed the file handling of BMP to opened with IE. I received the same error.

I restored BMP handling to File and Fax Viewer and verified that I was able to exploit the system again.

At this point I felt I had enough information.

Conclusion:

The recommended course of action from Microsoft, un-registering SHIMGVW.DLL, does not work.

Norton is the only enterprise wide protection that we have from the WMF threat currently. Norton does not appear to block randomly crafted WMF metafiles. If Norton did detect any of my tests I was able to defeat it by crafting a new file. Norton’s best chance of blocking the WMF files was after the system had been infected already and I had tried a subsequent test.

While Norton will protect us from known threats I do not believe that it will stop someone from crafting a file to target us specifically. The best advantage that Norton gives us is that it should detect any tools that an attacker may try to upload to a system such as Trojans, backdoors or rootkits.

I discovered that once a malicious file has been opened to grant access to the system closing the File and Fax viewer did not protect the system. The remote shell could only be closed by the attacker.

Machines running windows XPSP2 that have 64 bit CPUs are protected both by the DEP and IE6’s info bar. Non 64 CPUs may be able to become infected if a user manually downloads and saves the file to their system before executing.

The only current protection that non-XPSP2 FEI machines have is Norton. They are extremely vulnerable.

I did not test Windows 2000 but I believe it to be as bad off as non-XPSP2 machines.

The only sure fire preventable methods of protecting from the exploit was changing file handling of the vulnerable file types to PAINT or IE, and installing the Ilfak Guilfanov Hexblog patch, although I believe that the un-install for this patch does not work properly.

Filed by Michael at 11:21 am under Uncategorized
No Comments

I spent most of yesterday using the Metasploit framework to test system vulnerabilites within a VM environment and found that none of the suggested fixes except for the unofficial patch prevented me from taking control of a system.

Norton seemed to have mixed success stopping the attack, as it would usually allow an attack on the system the first try and then pick up the subsequent rounds of attacks against the system. I’ll post my full report on the vulnerability testing soon.

Thankfully Microsoft released a patch ahead of schedule which we’ve started to test within our IS department; we’re weighing deploying the patch over the weekend or waiting till Tuesday to submit them with our normal round of patches.

As a sidenote, I submitted news of the event to one of my favorite sites, Digg.com, and as of now the post has 656 Diggs and appeared on the front page. My first post to Digg beat out at least 6 other similar posts, even with a mispelling in the description!

Filed by Michael at 9:43 am under Uncategorized
No Comments

I have performed some testing on the WMF vulnerability at work and have found that while Windows XP systems with SP1 are vulnerable, SP2 is less susceptible, while the latest version of Norton does appear to be able to block the intrusion.

I have Virtual Machine installed at work, so I installed a copy of Ubuntu Linux with the Metasploit framework(the attacker) on one and a fresh SP2 installation and our current work image with all updates (the victims) on 2 others.

After loading the IE_XP_PVF_METAFILE.PM exploit script I opened IE on the XP2 box and pointed it at the attacker. The IE info bar popped up informing me that it had blocked the file download.

At this point I clicked the ‘download file’ button to see what would happen if a user decided to do the same. The system would not let me open the .BMP file, only save it to disk. I saved it to desktop and tried to open it at which point the File and Fax viewer program opened. While it was generating the image, a DEP warning popped up to tell me that the file had been closed. I also received an error that a program had terminated unexpectedly. My work machine has a 64 bit CPU which is neccessary for DEP to work.

Next I pointed work image box to the attacker. I received the same sequence of events with the info bar blocking the download and DEP squashing the execution of the file. However Norton did not step in to recognize the file until after I did a copy & paste and tried to open the file with notepad. Only then did it recognize the file as bloodhound.exploit.56

My next step is to install Norton on the SP1 box and gauge the different protection methods available. First I will try preventing the shimgvw.dll file using group policy, then disabling it using the REGSVR32 command, and then with the unofficial patch.

A Microsoft employee has reportedly leaked a copy of Microsoft’s patch thru a dissussion board within the past few hours before it was yanked. Word is that MS will release this patch before it’s usual patch day next Tuesday.

I will have more information available tomorrow after I can do some more testing.

Filed by Michael at 8:20 pm under Uncategorized
1 Comment