Most wireless devices host a common set of services for management. Typically, a web server component can be found on every wireless device for web-based management of the device. These web interfaces will sometimes suffer from common web application security flaws. Testing the web component for OWASP Top 10 can reveal if there are any security flaws in the application stack on the AP. Cross-Site Request Forgery, Cross-Site Scripting, Command Injection, and Denial of Service are the most common vulnerabilities among wireless devices. Services like HTTP for web management, SNMP for network management, and SSH or Telnet for remote access are commonly found on the devices. Setting these services with weak passwords or leaving the default credentials on can be easily attacked by an attacker using a brute force attack. If not properly configured, these services can be misused by an attacker to gain access to the device.
In this section, we will discuss how we can leverage these services and attack the device to gain access to them.
Telnet is a remote access service that enables management and configuration changes via command-line. Telnet is commonly being replaced by SSH as the preferred command line option for remote management; however, many legacy systems may still have Telnet enabled by default. Telnet is a clear text protocol: the username and password, or any other commands sent to the device, can be easily sniffed by anyone in between the Telnet client and server. Managing devices via Telnet is more of a risk if used on wireless networks with open encryption. Any individual who can put their wireless card into monitor mode will be able to collect the wireless traffic and extract Telnet's authentication or command and control traffic. Attacks on clear text communications will be covered in depth in Chapter 7, Advanced Wireless Sniffing.
Secure Shell (SSH) is a tool used to log in to another computer over a network, in order to execute commands on the remote machine. SSH encrypts the underlying connection, thus it can be used over unsecure communication channels. SSH is an alternative for Telnet and other protocols like rlogin and Remote Shell (rsh). In SSH, authentication can be performed using two different methods:
- By using a simple username and password
- By using private and public keys
In this section, we will show how to perform a brute force attack on an SSH service.
Brute forcing SSH is a common way that attackers attempt to gain access to devices and gain administrative access. This process is simplified by tools found on the Kali distribution. For this attack, we will use Hydra, which is a common tool for brute force. Follow these steps:
- Download a common password list or create your own based on your knowledge of the organization you are testing. If you need a generic one that contains commonly used passwords, one can be downloaded from GitHub at the following location: https://github.com/jeanphorn/wordlist.
- Open a command line and launch
hydra-wizard, as shown in the following screenshot:#hydra-wizard
- Use the following parameters to execute this attack:
Service to attack: sshTarget: IP or hostname of targetUsername: Administrative username of router or APPassword: File name of your dictionary or password listSame as Login, Null, or Reverse Login: snrPort Number: 22 or just enter for defaultThe following screenshot shows the output of hydra-wizard:
- Hydra will execute with the parameters you specified and will attempt to brute force the SSH username and password combination. This will either result in the administrative credentials being found or will tell you that none of the combinations were successful.
The following screenshot shows the successful brute force of the admin password for the device:
Simple Network Management Protocol (SNMP) is specified in RFC 1157. SNMP is a widely used application layer protocol for network management. Virtually all devices support SNMP like computers, servers, routers, switches, access points, VPN devices, and Firewalls. SNMP architecture contains Managers and Agents.
- Manager: Manager is a software application responsible for interacting with Agents and getting their management information via SNMP.
- Agent: Agent is a software module in a managed device responsible for maintaining local management information and delivering that information to Manger via SNMP.
- MIB: Local management information is stored in the form of objects. Each object represents one aspect of a managed agent and has a unique object identifier, "OID". These objects are collected into a hierarchy tree structure called Management Information Base (MIB). An MIB tree consists of every object maintained locally at the managed device.
The data exchange in SNMP is very simple. Either Manager can initiate a request to Agent to get the information, or Agent can send data to Manager voluntarily by using Trap messages. The entire data exchange is done in the form of SNMP messages. Manager sends GetRequest, GetNextRequest messages to Agent to get the information, and Agent responds with a GetResponse message with the information requested. In SNMPv2, two additional PDUs (Protocol Data Unit) are added: GetBulkRequest and InformRequest. In addition to the traditional polling method, Agent can also send Trap messages voluntarily to the SNMP Manager. These Trap messages are used to inform Manager about critical events that occur in managed devices.
SNMP uses UDP as its transport protocol, which is a connectionless protocol. SNMP is a clear text protocol in two of the most common versions, SNMPv1 and SNMPv2; encryption of PDUs was introduced in SNMPv3. An attacker sniffing on the network between Manager and Agent can read the SNMP messages in plain text, which sometimes contains sensitive data. Typically, Manager sends a GET request to Agent to retrieve the MIB objects. Agent responds back with GET response PDUs.
Now questions arise: can anyone send a GET request to Agent and retrieve information from the management agent? Can the attacker abuse the SNMP service by forging a GET request to Agent? To reduce the likelihood of this, the concept of a community string
was introduced in SNMPv1, where every SNMP message from Manager to Agent should contain a community name. This community name acts like a password; the message is assumed to be authentic if the sender knows this community string. Communities at Agent are again divided into two categories, Public and Private. Typically, the public community group has read-only access to the MIB and the private group has read-write access to MIB. In SNMPv1 or SNMPv2, if the attacker has the community string used for authenticating the requests, they can access the entire MIB. The problem with community names is that they are transmitted in the clear with every GET or SET request and they are visible to anyone sniffing on the network, as SNMPv1 and SNMPv2 does not encrypt the data payload. An attacker sniffing on the network between Manager and Agent can read the community name and use it to get information from managed devices.
Both SNMPv1 and SNMPv2 are vulnerable to this eavesdropping. In this section, we will discuss practical ways to mount SNMP attacks on our target network.
It is common for administrators to either configure SNMP with default community names, to choose names that are simple to guess, or to only leverage SNMPv1 or v2 that are unencrypted. By gathering MIB information on the devices, an attacker can have a wealth of knowledge on the target that otherwise is not possible to gather. Most of the vendors of access points still support SNMPv1 and SNMPv2 for backward compatibility. If the device on the target network uses SNMPv1 or v2 then it is certainly a candidate for further investigation.
We will discuss some examples of SNMP information disclosure vulnerability publicly listed on the National Vulnerability Database. You can also search the National Vulnerability Database using the link https://web.nvd.nist.gov/view/vuln/search.
SNMP is often overlooked by administrators of the network: either they leave it without changing the community strings or configure it with weak passwords. The Arris Touchstone DG950A cable modem with software 7.10.131 has an SNMP community of public, which allows remote attackers to obtain sensitive password, key, and SSID information via an SNMP request. By default, this device was found exposing critical information via an SNMP public community string. According to Shodan, a search engine for Internet-connected devices, more than 50,000 of these devices are exposing SNMP to the Internet. The following OIDs contain the sensitive information that should not be exposed via a public community string. To extract all the MIB objects, use snmpcheck in Kali Linux:
PASSWORD -- 1.3.6.1.4.1.4491.2.4.1.1.6.1.2.0 SSID -- 1.3.6.1.4.1.4115.1.20.1.1.3.22.1.2.12 WPA PSK -- 1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.12
The SNMP daemon in ArubaOS 3.3.2.6 in Aruba Mobility Controller does not restrict SNMP access, which allows remote attackers to read all SNMP community strings via SNMP-COMMUNITY-MIB::snmpCommunityName (1.3.6.1.6.3.18.1.1.1.2) or SNMP-VIEW-BASED-ACM-MIB::vacmGroupName (1.3.6.1.6.3.16.1.2.1.3) with knowledge of one community string, and read SNMPv3 usernames via SNMP-USER-BASED-SM-MIB or SNMP-VIEW-BASED-ACM-MIB. It is possible to learn all configured SNMP community strings as long as at least one of them is known to the attacker.
The vulnerability has been identified in ArubaOS version 3.3.2.6. However, previous versions are also likely to be affected.