Saturday, May 23, 2009

Intel Centrino wireless drivers fail to properly process malformed frames

In early August of 2006 a researcher at SecureWorks said he had revealed a vulnerability in Apple's MacBook wireless software driver that would allow him to take control of the machine. While the researcher did find a vulnerability, he was using a third-party wireless driver. David Maynor and Johnny Cache demonstrated the vulnerability at the Black Hat conference on 1st August using a MacBook and an external USB plugged in wireless card .
I was looking for a way to penetrate in a protected wireless network and this method sounded good. Unfortunately there wasn't any details about the vulnerability and any publicly-available exploit. Moreover, the researchers demonstrate the vulnerability in Mac OS X and I was not sure that the bug could be exploitable in Microsoft Windows operative system.

So I decided to try to trigger the vulnerability in Microsoft Windows and to write my own exploit. A security bulletin was made public by Intel on 12th January 2007, it was INTEL-SA-00001 and looks like the following:

"Security vulnerabilities exist in the Microsoft* Windows* drivers for the Intel 2200BG and 2915ABG PRO/Wireless Network Connection Hardware because of the way that they currently handle certain frames. An attacker could potentially exploit these vulnerabilities which could potentially lead to remote code execution and system control. Security vulnerabilities have been identified in the Microsoft* Windows* drivers for the Intel 2200BG and 2915ABG PRO/Wireless Network Connection Hardware (w22n50.sys, w22n51.sys, w29n50.sys, w29n51.sys), which could potentially be exploited by attackers within range of the Wi-Fi station to execute arbitrary code on the target system with kernel-level privileges. These flaws are due to a memory corruption while parsing certain frames.".

Analyzing the driver w22n51.sys provided with the Intel 2200BG integrated wireless adapter, after a few days of work I found a way to execute a little portion of code "beep shellcode" through a stack overflow that allowed me a remote code execution in Microsoft Windows kernel mode. The stack overflow was triggered when a 802.11 Probe response frame was received with a multi vendorspecific tag and "x00" was set as essid and essid length element. After that I decided to publish a PoC exploit on milw0rm website. Unfortunately, the space I found to place the shellcode in memory was very small and the code I have been able to inject was limited to a code that reproduces a system bell.

Finally, after a few weeks of works I found a way to execute a more useful shellcode that allowed me to download and execute an executable file into the attacked machine.

After a few months of private keeping I finally disclosed the fully working exploit and published it on 17th April 2008 on milw0rm website as a metasploit framework plug in.

Related links

No comments:

Post a Comment