Hacking Guest Wifi Networks

(Cross-posting from my organization’s blog – http://niiconsulting.com/checkmate/2014/03/insecure-implementation-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>

Setting your interface in ‘Monitor’ mode

Test to verify that Wireless Adapter supports packet injection

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

Wireless Router Settings

Wireless Router Settings

 

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>

Identify an OPEN wireless network

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>

Airodump view of wireless network

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

Injecting De-authentication Packet

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.

Wireshark capture of packet injection

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).

Login page of Captive Portal – restricting users from accessing internet

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.

DNS queries are resolved

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.

Your Freedom – DNS Tunneling utility

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s