Stopping Wireless Pineapple Hack

[coxhaus]

Not protecting against a pineapple hack keeps coming up on this forum. Does anyone have an easy setup for protecting from this man in the middle wireless hack which does not require constant attention? I think this would be a good thing for a small business network or home user network.

Running a Radius server has been proposed. So you setup Radius on a switch port to authenticate the real wireless WAP. What stops the pineapple from advertising out in the wireless realm as the same SSID and forwarding to the real WAP?

 

[sfx2000]

Not protecting against a pineapple hack keeps coming up on this forum. Does anyone have an easy setup for protecting from this man in the middle wireless hack which does not require constant attention? I think this would be a good thing for a small business network or home user network.

Running a Radius server has been proposed. So you setup Radius on a switch port to authenticate the real wireless WAP. What stops the pineapple from advertising out in the wireless realm as the same SSID and forwarding to the real WAP?

Pineapple attacks (more appropriately Karma attacks) exploit trust on the wireless client side... I'm not going to go too deep into how to execute, or the deeper specifics of how it works - beyond the scope of SNBForums or haxxor school...

Many WiFI clients, when searching to attach to a network, broadcast the last known/connected SSID in their Probe Request Message - Karma leverages this by saying, basically, "here I am" using the jasager deamon (jasager is "yes man" in German).

How to defeat a pineapple - the only way you can defeat it is by not letting it attach to your network - point (A) below - whether via hardline (which radius can defeat), or over WiFi (WPA2-Enterprise or WPA2 Personal (CCMP-AES) with a strong passphrase), the key thing is don't give it access - these things love open Hospots like Coffee Shops and Hotels, basically anywhere easy access can be had with little authentication.

[Trusted Network] --(A)-- [PineApple] --(B)-- <many SSID's> --(C)-- [Client]

KARMA attacks are really based on Point (C) above - A client, let say, it's last known good network was "CorpWifi", even though it uses WPA2-Enterprise w/Radius auth, sends that SSID in the Probe Request message to any AP (and other known networks as well that it has attached to), and the PineApple at Point B, sees this, and updates the SSID list to be that SSID ("CorpWifi") - the client sees this, and does the initial association - since there is no RSN information, the Auth sequences for WPA2/WPA2 Enterprise, are never started...

Now remember how the wifi connection handshake works...

1) The client searches and sends Probes to a Broadcast Address - the BSSID of ff:ff:ff:ff:ff:ff, and in that Probe Request is also the SSID of the last known network

2) The Pineapple hears this - as this is all in the clear - so it sends a Probe Response, and it uses the SSID contained inside the Probe Request, and more importantly, it does not include any RSN or WEP information, e.g. it's operating as an Open AP, no Auth needed

3) Since the Probe Request/Response handshake is completed, the supplicant is never invoked on the client side, and the device completes the association, sends a DHCP request, and the PineApple offers up a valid DHCP config to the device

4) done, the Client is now associated, has valid address info, and everything is hunky-dory...

That's all fine if Point B (which is under your control perhaps) is wireline or wireless, but what if the trusted network is someone elses network that is under control of the Pineapple owner/operator - let's say it's a 3G modem - well, that's a problem, ain't it? I can set up a pineapple in my house, and attack my neighbor using his SSID, and capture on or more of his clients...

What if the SSID is hidden, does that help - no, it doesn't, because it's still there, and there are ways to get at it, and populate the SSID list of the pineapple - then I can send some deauth packets at the target, and the clients will disassociate and start the handshake all over again, and perhaps some of those clients will land on the rouge AP provided by the pineapple...

MAC filtering? - nope, doesn't help here as the PineApple doesn't require access to the target network, it becomes the target network...

So how does one beat this? Well, something that do help is keeping your client up to date - newer clients don't send out the SSID in the probe request message, it's just sends "Broadcast" and the broadcast SSID, and then picks/chooses the appropriate one - one thing the vendors here can/should do is reject an AP if the known good AP is a member of a robust security network (WPA2 PSK/Enterprise), but this is typically not widely found - there are some 3rd party, if I recall, the enterprise oriented connection managers (Cisco, Intel, etc) have settings that can help here - but generally the client management by Windows/Mac/Android/iOS/Linux don't require auth to be enabled even on known networks...

Radius, in and of itself, isn't going to fix/solve a Pineapple Karma attack - it can keep a pineapple off the wireline controlled by the Radius server, but... see above, a pineapple doesn't need to be there, all depends on what the pineapple operator wants to do..

UTM's can help in areas controlled by the network operator to keep rogues off the LAN, and they can also detect and mitigate to some degree a pineapple in the area - I've seen one case where the UTM did detect the rogue AP, and started knocking clients off it by sending deauth frames at the pineapple...

So how can I be safe?

a) Don't use open wifi in public areas, or use it very sparingly
b) if one must, then VPN is an absolute neccesscity, even if only PPTP - VPN operates at a higher layer than a Pineapple does, so even if your client is 'pwned', the VPN will keep the upper layer traffic safe.
c) SSL verification - a bit of work, but keeping your browser current, and having only trusted SSL certs in your keychain can help - but SSLstrip can defeat this
d) Use a browser that supports HSTS, meaning that it'll first use HTTPS before falling back to HTTP - most modern browsers do this - Chrome, Safari, Firefox

 

[Nullity]

There is a post above that is waiting for moderator approval (probably keyword triggered)

You've got my vote for a spamfilter override.
The last thing we want is to discourage posts from established members.

 

[System Error Message]

One method not mentioned is using RADIUS with NAT detection. By blocking devices behind a NAT you stop pineapple hak from working because the devices behind wont be able to access internet. Essentially when you detect NAT blocking the device performing NAT solves it.

With windows 10 around wifi passwords to travel about so wpa2 enterprise is the only option.

 

[sfx2000]

One method not mentioned is using RADIUS with NAT detection. By blocking devices behind a NAT you stop pineapple hak from working because the devices behind wont be able to access internet. Essentially when you detect NAT blocking the device performing NAT solves it.

With windows 10 around wifi passwords to travel about so wpa2 enterprise is the only option.

That doesn't solve the use case where one is using a Karma attack against a roaming client - e.g. Bob the business man at the hotel where he is the target - even if his "CorpWiFi" is set with WPA2-Enterprise, the pineapple is faking CorpWifi with either a 3G or pre-authenticated connection already in place on WiFi...

Since his client software trusts CorpWifi, it connects to it, rather than "HotelWifi", and then things can go more wrong from there...

 

[System Error Message]

That doesn't solve the use case where one is using a Karma attack against a roaming client - e.g. Bob the business man at the hotel where he is the target - even if his "CorpWiFi" is set with WPA2-Enterprise, the pineapple is faking CorpWifi with either a 3G or pre-authenticated connection already in place on WiFi...

Since his client software trusts CorpWifi, it connects to it, rather than "HotelWifi", and then things can go more wrong from there...

but at least it prevents them from connecting to your network. Im not sure if RADIUS has certs just like HTTPS for hotspot.

 

[Nullity]

This is a client threat, right? Most home networks are safe?

Clients with stored WPA2 networks are safe as well? If so, I thought WPA2 had been the standard for years. Are public hotspots still using WEP, WPA, or possibly open networks?

 

[sfx2000]

It's mostly a client focused threat, but can be a real threat in the SMB space, esp. if Radius isn't deployed on the network, or where some may not have a dedicated/knowledgable security focused IT team - having a rogue AP like a Pineapple can be a serious compromise to an organization's data and security systems.

In the SOHO arena, perhaps less of a threat, as we tend to know our networks, and what is attached to those networks. However, nothing would stop someone from being across the street/next door/on the curb from trying to conduct a Karma attack against your network...

(BTW - don't need a pineapple to do a karma attack, can do pretty much the same with a linux machine and the right SW tools - Kali Linux comes to mind - Pineapple's by Hak5 just make it easy as an all-in-one solution that is extremely portable)

WPA2-Enterprise can be vulnerable depending on the EAP in use - Just because there is a radius server on the backend, one must also look at how things are authenticated when devices are attempting to attach (either wireless or wireline).

Some upside on the SME/SMB space, if one is running decent security is that many of the vendors also include agent SW that replace or enhance the built in wireless clients - and these agents can enforce policy on a profile/system level basis - e.g. force the client to only use the auth/encryption scheme set by the network - so check with the vendor.

WIPS and UTM can help mitigate some of the threat, but also good physical security of the premises is a must..

 

[System Error Message]

client security can be difficult to maintain because it requires some knowledge from the client but the important bit is securing the network so that if someone attached a pineapple hak to the network it would not be able to function and also from other sorts of exploits. Certs are usually the best way to maintain security between client and server so if it is possible to use certs with RADIUS that would be better.

The problem is that all consumer gear are vulnerable to various exploits and hacks and businesses are using them as well in their infrastructure.

Regarding physical security it is possible to bind a mac address to a port on a managed switch and the use of active VLANs and layer 3 can make it much much harder for an attacker to infiltrate the network physically since it would have to get the configuration. Every client can be assigned a VLAN and a routed IP meaning that in order to attach to the network the attacker would need the mac address, vlan value configured into NIC and perhaps the required user login for the authentication server for the VLAN and mac but this sort of segmentation will prevent many of the attacks that listen on the network. The question is would you be willing to perform all this configuration in your house?

 

[sfx2000]

Certificates are not a requirement for WPA2-Enterprise, or Radius for that matter - but typically they are used in many enterprises - what is needed for Radius to work in the AAA role is user accounts, and certs are but one way to validate a user...

And, again, the challenge with the Karma style attacks is that the network is the guardian, not the client, so if the AP doesn't offer auth/encryption as part of the Wifi association handshake all bets are off, unless the client machine has policies in place to prohibit such activities..

One thing to note - in a Karma style attack, there is no WPA2 or other encryption typically offered, as that presumes that the operator of the Karma attack device would have to have knowledge and/or, in the case of WPA/WPA2 Enterprise, access to a radius server with the appropriate credentials for that particular user account - nothing is impossible, esp. if the Rogue AP is inside the network perhaps - and that is a different kind of attack... but then, if the Rogue AP is inside the network, Radius can stop it from attaching to the ethernet LAN, if properly set up.

What I meant with Physical Security is access control by an untrusted person to the facilities, or a trusted person who is a bad-actor.

 

[sfx2000]

I'm just going to recap...

1) WPA/WPA2 Personal - no way to really get around this, as the WiFi client software (outside of enterprise packages/agents) trusts that the AP is who it says it is, and will connect

2) WPA/WPA2-Enterprise - can be defeated in some cases, depending on the client SW (agent SW can help), but if the Rogue AP is on the enterprise LAN, even with RADIUS, the pineapple can just change the MAC address to a trusted one, and provide credentials - many RADIUS/AAA servers will allow more than one login per account

3) HTTPS/SSL - since a Pineapple, outside of the Karma scenario, is a Man in the Middle problem, it has tools in place to defeat SSL - remember that a Pineapple has multiple internet connections, and can/will act as a proxy there - SSL is no defense against a determined pineapple

4) VPN - can help, as like I mentioned earlier, it builds tunnel above the WiFi connection, it won't keep your client from attaching to a pineapple, but at least your traffic is somewhat safe..

5) Client Management/Policies - not consistent across platforms, and most clients as a default trust the network to provide the security, hence the risk here - again, agent SW from enterprise vendors can help a bit...

6) It comes down to trust - if you don't trust the connection, or if things are "hinky", then don't use it - the challenge here is knowing when...

UTM/WIPS, Radius policies on the LAN, this can help to some degree, but in the face of a determined and experienced attacker, a pineapple is a very strong tool to use... and it's likely not the only tool in their collection..

Quick Tip - pineapples tend to be slow on the network connectivity side, the pre-rolled solutions are based on older chipsets, and many are 2.4GHz only... but they evolve, as everything does, so situational awareness, as a user, as a SNB member, a small business/home network user/operator, being aware of traffic anomalies in lieu of tools like WIPS/UTM, is your best defense...

 

[sfx2000]

See one of these on your network - or in a coffee shop... iphone5 is used for size visualization..

 

[System Error Message]

I think the main problem is with getting the client secured and whether or not you're willing to do all these configs to your network to secure it. If only computer security was a standard just as driving a car then client security would be less of a problem.

 

[sfx2000]

You've got my vote for a spamfilter override.
The last thing we want is to discourage posts from established members.

I think we're dancing on the edge of something...

I'm a white hat in this game - not a red-team or a black hat - I study these things to understand and defend against them...

 

[sfx2000]

I think the main problem is with getting the client secured and whether or not you're willing to do all these configs to your network to secure it. If only computer security was a standard just as driving a car then client security would be less of a problem.

Average Joe - perhaps not, unless it's someone just doing mayhem...

My concern is more the traveler/telecommuter - if you're a person that is interesting, then need to be more aware... in my earlier use case, Bob the Business Guy...

Bob is visiting a business partner/client/customer/provider - he stays at the hotel the partner recommends - so the competition, to get an edge up, launches an attack like this on an already untrusted network...

This is the bigger risk - hotels, and coffeeshops - being someone 'interesting' perhaps is why this attack is so tough to defeat - it's not just technology... it's how we use it.

 

[System Error Message]

for free wifi blocking NAT would help and i know a number of hotels use hotspot.

VPN for the client would help though. You could add an extra layer to you secured layer 1, 2,3 network by adding layer 4 (VPN) just to connect to internet. so to connect to internet you'd have to connect to VPN to the gateway for internet.

 

[sfx2000]

for free wifi blocking NAT would help and i know a number of hotels use hotspot

NAT doesn't block this kind of attack - it's below that layer in the stack... and a pineapple can do the NAT, and one wouldn't know then, eh?

 

[System Error Message]

NAT doesn't block this kind of attack - it's below that layer in the stack... and a pineapple can do the NAT, and one wouldn't know then, eh?

NAT detection and blocking doesnt block every attack but it helps. There are also cisco tutorials on preventing rogue DHCP servers which would be important in a hotel network because for a hack like the pineapple hak to work traffic must go through it.

 

[sfx2000]

NAT detection and blocking doesnt block every attack but it helps. There are also cisco tutorials on preventing rogue DHCP servers which would be important in a hotel network because for a hack like the pineapple hak to work traffic must go through it.

Part of the challenge looking for a rogue DHCP server with a pineapple attached to the LAN - to the LAN, it's a DHCP client only, and to the evil wifi side, it's offer DHCP and routing - LAN sees just a client MAC and traffic, has no idea that it's actually a router.

And that assumes that the evil AP is actually on the LAN, what if it's on the WAN side? NAT detection isn't going to help there, nor will radius for that matter..

A WIPS can see the "evil" AP, and in the enterprise LAN environment, this is likely the best defense against a pineapple/karma attack.

Thinking outside of the box a bit - all 11n and above AP's have to do OBSS scanning anyways, so taking those reports from the radio, and matching it against a list of known "good" AP's on the WLAN, one could send deauth/deassciate frames at the target evil AP, essentially knocking it offline - at least this would protect the clients in the local WLAN environment.

Challenge then is when outside the local WLAN environment, and that is the main problem with pineapple/karma, and that can only be solved on the client side.