The Evolution of the Wireless Penetration Test

Years ago a wireless penetration test focused on illustrating the issues with the protocols and implementations in use by the targeted access points. The deliverable would document how an attacker could break into the network due to the use of the ever-so-weak WEP encryption, WPA with a weak pre-shared key (PSK) or insecure distribution of keys. Raise your hand if your 2010 wireless penetration test was made easier by finding the passphrase written on a Post-It note!

Of course, often no encryption was supported or configured at all. There would be screenshot after screenshot of SILICA "breaking into the corporate network in less than 7 minutes" and verbiage that explained how total domination of your corporate wireless network was inevitable. 

Studying the thermodynamics of molten washing machines in the free time that SILICA provided me with.

Times have quickly changed. Access points (from an unauthenticated standpoint, anyway) are much more resilient to outside attacks but wireless networks themselves are made up of more than just an access point - and they are still just as vulnerable.

I have spoken with other wireless penetration testers that assume if you can't break into the network via the access point then the network is considered "secure". This reminds me of the flawed logic of relying solely on automated solutions to determine the security posture of a network or application. These misguided penetration testers will declare "if the tool didn't find a way to break in then a human must not be able to break in". 

If you attempt to crack a typical WPA PSK of your target network today then it may be ready to use by the time your grandchildren's grandchildren need access. Attacker always choose the path of least resistance when it is an option and which do you think provides a larger attack surface? A wireless access point that only accepts 802.1x authentication or the corporate laptop that screams at you that it desperately wants to connect to "attwifi" and check for updates?

Today results are obtained in a wireless penetration test by targeting the wireless clients. In a way this has always been true but more so today then ever before. The wireless clients know how to connect to the target network, they have all the necessary keys stored on them, they often leave the safety of trusted network and connect to hostile environments, they have a lot of applications that want to automatically update, backup, phone home, connect, detect, enumerate and act in a way that makes the user's life easier. And an attacker only needs to compromise one corporate client device to gain access to the target network.

In other words, your mobile devices are mobile not just in space, but in security levels - sometimes that security level is "In StarBucks" and sometimes it's "On the corporate WLAN".

When you focus on the attack surface that the typical corporate laptop provides (or your OD that you BY to the BYOD network) it is actually very challenging to deliver "good news" to your client since there is always a laundry list of security vulnerabilities found, we have sadly learned.

After doing so many of these wireless network assessments you might conclude that Mother Nature has hard coded Human DNA to fail at wireless networking (the ultimate backdoor!) but it's not the fault of the client's network engineers or even the security team. The truth is until operating systems and wireless networking solutions learn to cooperate in harmony these exploitable conditions will remain an issue. 

Below I have listed common issues that I see during wireless penetration tests. These are usually the issues that lead to gaining access to the corporate network.

Home, Office and Public network types in Windows does nothing to save you.

Even if you were to select the most restrictive option (Public) it just sets a few firewall rules and turns off some discovery features. Basically it will keep external requests from triggering any response from the laptop but an attacker doesn't need your laptop to interact with an external request. The next section details why.

Corporate Applications and the protocols that they use have no concept of "network types". 

Your mail client, web browser, back up applications and all other applications installed on your corporate laptops will continue to operate regardless of which network you are connected to. They have no loyalties or rules on how to operate on different networks. "Secure" networks and "Public" networks are all the same to the applications. What does this mean from a security standpoint? It means that no matter which network you connect to (your corporate network, home network or open, public network) all of your applications will immediately attempt to do their job to make your life easier. This is why your corporate laptop becomes a playground to an attacker on a network they control. 

The conveniences you extend to your users are also extended to attackers.

An attacker can impersonate any server or service that applications attempt to communicate with. A great example is the auto-configuration proxy script that your corporate laptop wants to download whenever the web browser is spawned. All an attacker needs to do is answer the WPAD request with a malicious proxy server and now every single web request that is made by that corporate laptop will be tunneled through the attacker's proxy server. Passwords, session cookies and all kinds of sensitive data is harvested in this manner. 

Another example is the auto-reconnecting of networking drives. An attacker can impersonate the file server or answer requests for particular file types with malicious versions. This is a great place to inject a CANVAS callback.

Don't forget about those backup routines! Your corporate laptop wants to communicate with a centralized server to determine if it should back itself up.  An attacker can impersonate this server and initiate a backup that your corporate laptop will lovingly and obediently send to the attacker.

There are just so many attack vectors it almost becomes difficult for the attacker to choose which to exploit first. Most likely there is at least one vulnerability that can be leveraged by the attacker to gain remote code execution on the corporate laptop. After which the attacker can pluck the wireless keys off of the machine and voila - he has successfully broken into the wireless network without having to touch a single wireless access point. And as a bonus he also has corporate credentials plucked from the compromised laptop as well as the local administrator password that can be used to gain access to other corporate resources.

Computer-based authentication is not the answer.

Have you ever tried to export a private key from your corporate laptop? Most network administrators are under the impression that you can't export private keys from the corporate laptop. They probably think this because even they, being the administrators, can't export the certificate after they install it the first time because they selected the please-under-no-circumstances-let-any-user-including-administrators-export-this-private-key box. But the tiny grey-out "export" option is no match for someone who knows what they are doing. You only need to hook one function to trick the Windows API into letting you export non-exportable private keys. This means that under the circumstance where an attacker gains access to one (read: any) corporate laptop and steals the certificate used to establish trust that they can connect any machine they want to the wireless network. So in short - by bypassing that grey-out "export" option you also bypass 802.1x authentication.

Captive portals do not solve any security issues.

Captive portals are more for device management and to keep random people from sucking bandwidth unnecessarily; they provide very little security.  I have yet to see a captive portal whose authentication can't be bypassed with MAC address cloning (clone the MAC address of someone that has successfully authenticated and you're done). It is very common to see that your client is forcing contractors, consultants and maybe even board members to use the guest wireless network which is most likely open to the public but has a captive portal in place. This means all of their traffic is vulnerable to eavesdropping and tampering. Why they consider that consultant and contractor traffic is any less important than an employees is a mystery to me. After all they are hired to work on internal resources or they are trusted with or have access to sensitive data and when they transmit this data it is just as easy to capture as data on a Starbucks wireless network.

In conclusion a wireless penetration test will always result in successful compromise of the wireless network if efforts are made to assess the wireless clients. And you can guarantee that a real-world attacker knows that the corporate laptop is the weakest link to gain access to the corporate network.

I'm just a happy corporate laptop. You can't expect me not to connect my corporate drives on strange networks!

Corporate laptops are really like playful puppies that trust everyone and want to make your life easier and more enjoyable. They go retrieve your newspaper as soon as you wake up (by leaving the safety of home and entering into the hostile world to do so), they lick any surface that may or may not have something edible and/or delicious (because they are hungry, have weird taste buds and are eternally optimistic), they will play fetch with any tennis ball thrown by any person (even the creepy guy that hangs out at the park all the time and who knows where that tennis ball as been?). Even though you have trained your dog well he is still vulnerable and he may never learn who to trust and how to change his behavior to better protect himself.