Insecure Implementation of Guest Wireless Networks

Most large organizations provide wireless facilities for their guest, which may include vendors, consultants, business associates, employees from other regions etc.

Certain points should be considered while implementing a guest wireless network.

1. Encryption in use
2. Captive Portals or Guest Authentication
3. Network Segregation

Finding the SSID of a Hidden wireless network

To simplify the connectivity for guest devices some organizations configure their networks without encryption i.e. ‘OPEN’. To prevent un-authorized entities from connecting to their networks most of these networks are configured as HIDDEN. As is well known, this configuration does not really provide any security. It is simply a method of obfuscation (Non-Broadcast Wireless SSIDs Why hidden wireless networks are a bad idea).

To identify the SSID of a hidden network you would need:

1. Wireless adapter which supports packet injection (http://www.aircrack-ng.org/doku.php?id=compatible_cards)
2. Aircrack-ng wireless suite (http://www.aircrack-ng.org/)

I will be using an Alfa AWUS036H adapter. This card is well supported by Aircrack-ng.

To verify if your card supports packet injection, simply execute the command:

aireply-ng -9 <INTERFACE_IN_MONITORING_MODE>

You can put your interface in monitoring mode using airmon-ng

airmon-ng start <PHYSICAL_INTERFACE>

Now that we are sure our wireless adapter supports packet injection, we go ahead and disable SSID broadcast on our test wireless network ‘WASHAL’

To identify the SSID of hidden networks, you need wireless clients to be connected to that network.

Running airodump-ng, we can identify the

1. BSSID of the hidden network
2. clients connected to that BSSID
3. channel on which the SSID is being broadcast

First we’ll run the below command to identify all the networks available:

airodump-ng<INTERFACE_IN_MONITORING_MODE>

Now that we have locked on to one network, we’ll fix the channel and BSSID for that Access Point:

airodump-ng<INTERFACE_IN_MONITORING_MODE>-c <CHANNEL> -b <BSSID>

We currently have a client (20:02:AF:CE:EE:5E) connected to the network.

Once we have identified the target BSSID, we need to send a de-authentication packet to the Access Point

aireplay-ng --deauth 1 -a <BSSID><INTERFACE_IN_MONITORING_MODE>

The two switches are explained below:

--deauth1 : sends one de-authentication broadcast packet to the Access Point
-a <BSSID>: defines the MAC Address of the Access Point we are targeting

As can be seen from the above screenshot, when we send the ‘de-authentication’ packet, the hidden SSID is captured by our card,as the client tries to connect back to the network. The same is show is shown in the Wireshark capture below.

Now that we have the SSID of the hidden wireless network, we can simply connect to the network and obtain an IP address (these networks are usually configured with DHCP servers as they are practically used for ‘guests’).

Bypass Captive Portals

To prevent un-authorized entities from gain direct network/internet access, a captive portal is setup.

Depending on the use-case, the organization may decide to ask the user to provide a pre-configured username and password or simply accept the ‘Terms & Conditions’ to access the internet. In the case of latter, user authentication is of not much concern. However, in the case of the former setup, where organizations have setup a login mechanism, they expect the users to be authenticated.

A bad implementation in such cases would be a configuration which only monitors HTTP/HTTPS requests and re-directs users to the captive portal (where the user has to provide login credentials to gain access).

A bypass technique known as Tunneling can be used in such cases if the environment does not restrict protocols like ICMP, DNS etc. before authentication.

You can try to resolve the domain names of a few websites to check if DNS requests are being filtered.

As shown in the above screenshot, we are able to resolve the domain names of different websites (to be certain that the domain resolution is not from cache/hosts, it is better to attempt resolution of non-common domains.)

Now, if we setup an externally hosted DNS server and tunnel HTTP requests into the DNS requests, we should be able to browse the internet as usual – but without authentication. This is known as a DNS tunneling attack. (I’ll try to explain the attack in a future blog post.)

In case you don’t have access to a custom DNS server, you can use tools like ‘Your Freedom’(https://www.your-freedom.net/) which provide servers for tunneling.

Network Segregation

The final bad design decision that needs to be avoided (and is pretty simple to do) is to allow any connectivity from the Guest wireless network to the corporate network. There may be many justified use-cases to provide guest users access to the corporate network. However, once the separation wall between the two environments is broken, the ‘approved exceptions’ keep coming.

To test if you networks are segregated, simply run an Nmap scan(quick or comprehensive) from the guest network against your production network. Any ports found open will be indicative of the holes in the firewall L

nmap -sS -v -F <TARGET_IP_RANGE_OF_PRODUCTION_NETWORK>
nmap -sS -v -Pn -p0-65535 <TARGET_IP_RANGE_OF_PRODUCTION_NETWORK>

Conclusion

It is a good facility that most organizations provide their guests, however, a bad implementation of the guest network can lead to headaches later for the organization.

As a case in point, we had a client who provided guest wireless access to all visitors in their building. The configuration/policy of the guest wireless controller was based on the policies for the corporate wireless controllers. An oversight of the network team had resulted in guest users gaining connectivity to the production servers – similar to the access granted to employees connected on the corporate wireless network.