{"id":629961,"date":"2023-04-16T09:49:25","date_gmt":"2023-04-16T14:49:25","guid":{"rendered":"https:\/\/news.sellorbuyhomefast.com\/index.php\/2023\/04\/16\/macstealer-allows-for-wifi-client-isolation-bypasses-cve-2022-47522\/"},"modified":"2023-04-16T09:49:25","modified_gmt":"2023-04-16T14:49:25","slug":"macstealer-allows-for-wifi-client-isolation-bypasses-cve-2022-47522","status":"publish","type":"post","link":"https:\/\/newsycanuse.com\/index.php\/2023\/04\/16\/macstealer-allows-for-wifi-client-isolation-bypasses-cve-2022-47522\/","title":{"rendered":"MacStealer allows for WiFi client isolation bypasses (CVE-2022-47522)"},"content":{"rendered":"<div data-target=\"readme-toc.content\">\n<article itemprop=\"text\">\n<h2 tabindex=\"-1\" dir=\"auto\">\n<p>MacStealer: Wi-Fi Client Isolation Bypass<\/p>\n<\/h2>\n<h2 tabindex=\"-1\" dir=\"auto\">1. Introduction<\/h2>\n<p dir=\"auto\">This repo contains MacStealer. It can test Wi-Fi networks for <strong>client isolation bypasses<\/strong><br \/>\n<strong>(CVE-2022-47522). Our attack can intercept (steal) traffic toward other clients at the MAC layer<\/strong>,<br \/>\neven if clients are prevented from communicating with each other. This vulnerability affects Wi-Fi<br \/>\nnetworks with malicious insiders, where our attack can bypass client isolation, which is sometimes<br \/>\nalso known as AP isolation. The attack can also be used to bypass Dynamic ARP inspection (DAI),<br \/>\nand can likely also be used to bypass other methods that prevent clients from attacking each other.<br \/>\nThe attack is also known as the <em>security context override attack<\/em>, see Section 5 of our<br \/>\n<a href=\"https:\/\/papers.mathyvanhoef.com\/usenix2023-wifi.pdf\" rel=\"nofollow\">USENIX Security &#8217;23 paper<\/a> (<a href=\"https:\/\/github.com\/domienschepers\/wifi-framing\">repo<\/a>).<\/p>\n<p dir=\"auto\">Concrete examples of possible affected networks are:<\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\">Enterprise networks where users may distrust each other, and where techniques such as client isolation<br \/>\nor ARP inspection are used to prevent users from attacking each other. For instance, company<br \/>\nnetworks with accounts for both guests and staff, networks such as eduroam and govroam, etc.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Public hotspots protected by <a href=\"https:\/\/www.wi-fi.org\/discover-wi-fi\/passpoint\" rel=\"nofollow\">Passpoint<\/a> (formerly Hotspot 2.0).<br \/>\nThese are hotspots that you can automatically and securely connect to. For instance,<br \/>\nit can seamlessly authenticate you using your phone&#8217;s SIM card.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Home WPA2 or WPA3 networks that have client isolation enabled. This includes networks with<br \/>\na separate SSID for guests or for insecure (IoT) devices. It also includes networks where<br \/>\nmultiple passwords are used to further isolate devices, which is also known as<br \/>\n<a href=\"https:\/\/www.arubanetworks.com\/techdocs\/central\/2.5.1\/content\/access-points\/cfg\/security\/wpa2_mpsk.htm\" rel=\"nofollow\">Multi-PSK<\/a>,<br \/>\n<a href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/wireless\/controller\/technotes\/8-5\/b_Identity_PSK_Feature_Deployment_Guide.html\" rel=\"nofollow\">Identity PSK<\/a>,<br \/>\n<a href=\"https:\/\/0x72326432.com\/posts\/perstapsk_en\/\" rel=\"nofollow\">per-station PSK<\/a>,<br \/>\nor <a href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/wireless\/controller\/9800\/17-6\/config-guide\/b_wl_17_6_cg\/m_epsk.html\" rel=\"nofollow\">EasyPSK<\/a>.<br \/>\nSee the <a href=\"http:\/\/github.com\/#id-threat-model\">threat model discussion<\/a> for extra info.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Public hotspots based on <a href=\"https:\/\/www.wi-fi.org\/beacon\/thomas-derham-nehru-bhandaru\/wi-fi-certified-wpa3-december-2020-update-brings-new-0\" rel=\"nofollow\">WPA3 SAE-PK<\/a>.<br \/>\nThese are hotspots protected by a shared public password, but where an adversary cannot<br \/>\nabuse this publicly-known password.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\">We remark that <strong>our attack cannot bypass VLANs<\/strong>. In other words, based on current experiments,<br \/>\nour attack cannot be used to exploit a device in another VLAN.<\/p>\n<p dir=\"auto\">The <a href=\"https:\/\/github.com\/domienschepers\/wifi-framing\">repository of other results in our USENIX Security &#8217;23<\/a> is also available.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">2. Vulnerability details<\/h2>\n<p dir=\"auto\">The core idea behind the attack is that the manner in which clients are authenticated is unrelated to<br \/>\nhow packets are routed to the correct Wi-Fi client. Namely, authentication is done based on passwords,<br \/>\nusernames, 802.1X identities, and\/or certificates, but once the client has connected the routing of<br \/>\npackets is done based on MAC addresses. A malicious insider can abuse this to intercept data towards<br \/>\na Wi-Fi client by <strong>disconnecting a victim and then connecting under the MAC address of the victim<\/strong><br \/>\n<strong>(using the credentials of the adversary)<\/strong>. Any packets that were still underway to the victim,<br \/>\nsuch website data that the victim was still loading, will now be received by the adversary instead.<\/p>\n<p dir=\"auto\">More precisely, attack consists of three steps:<\/p>\n<p><a target=\"_blank\" rel=\"noopener noreferrer\" href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/attack.png\"><img decoding=\"async\" src=\"http:\/\/github.com\/vanhoefm\/macstealer\/raw\/main\/attack.png\"><\/a>\n<\/p>\n<ol dir=\"auto\">\n<li>\n<p dir=\"auto\"><strong>Letting the victim request data<\/strong>: The adversary first waits until the victim (client)<br \/>\nestablishes a Wi-Fi connection with the vulnerable Access Point (AP). We assume the victim<br \/>\nwill then send a request to a server on the Internet. For instance, the victim may send a<br \/>\nHTTP request to the (plaintext) website <code>example.com<\/code>. The goal of the adversary is to<br \/>\nintercept the response that will be sent by the website.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><strong>Connecting under the victim&#8217;s MAC address<\/strong>: After the victim requested data, for instance<br \/>\nby sending a HTTP Request packet, the adversary will forcibly disconnect the victim from the<br \/>\nnetwork <em>before<\/em> the response arrives at the<br \/>\nvulnerable AP. In our example, this means the victim is disconnected before the response from<br \/>\n<code>example.com<\/code> arrives at the AP. Once the victim is disconnected, the adversary spoofs<br \/>\nthe MAC address of the victim and the adversary will connect to the network using their own<br \/>\ncredentials. This means the adversary is a malicious insider that can connect using their own<br \/>\ncredentials to the network, for instance, using their own username and password in an<br \/>\nEnterprise Wi-Fi network.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><strong>Intercepting the response<\/strong>: Once the adversary connected under the MAC address of the victim,<br \/>\nthe AP will associate the adversary&#8217;s newly generated encryption keys with the victim&#8217;s MAC address.<br \/>\nAs a result, when the response from the server arrives at the Wi-Fi network, or any incoming traffic<br \/>\ntowards the victim in general, the router will forward these incoming packets to the victim&#8217;s<br \/>\nMAC address. In our example, this means the response from <code>example.com<\/code> is forwarded by the router<br \/>\nto the victim&#8217;s MAC address. However, the adversary is now using this MAC address. This means the<br \/>\nAP will encrypt the response using the keys of the adversary. In other words, the adversary will<br \/>\nnow recieve any pending traffic that is still underway the victim.<\/p>\n<\/li>\n<\/ol>\n<p dir=\"auto\">We remark that intercepted traffic may be protected by higher-layer encryption, such as TLS and HTTPS.<br \/>\nNevertheless, even if higher-layer encryption is being used, our attack still reveals<br \/>\nthe IP address that a victim is communicating with. This in turn reveals the websites that a victim<br \/>\nis visiting, which can be sensitive information on its own.<\/p>\n<p dir=\"auto\">By default, the attack does not intercept traffic <em>sent by the victim<\/em>, but can only intercept<br \/>\ntraffic <em>sent towards the victim<\/em>. However, an adversary can attempt subsequent attacks to also<br \/>\nintercept traffic sent by the victim. In particular, by intercepting a DNS reply to the victim,<br \/>\nthe adversary can spoof a DNS reply and intercept all IP traffic both sent towards and sent by<br \/>\nvictim.<\/p>\n<p dir=\"auto\">Performing the above attack only makes sense when client isolation is enabled in the target network.<br \/>\nOtherwise, if client isolation is disabled, a malicious insider can just directly attack other<br \/>\nclients using techniques such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/ARP_spoofing\" rel=\"nofollow\">ARP spoofing<\/a> (see the<br \/>\n<a href=\"http:\/\/github.com\/#id-test-isolation\">client isolation tests<\/a>).<\/p>\n<p dir=\"auto\">The attack is identical against Enterprise WPA1, WPA2 and WPA3 networks. This is because the attack<br \/>\ndoes not exploit any cryptographic properties of Wi-Fi, but instead abuses how a network determines<br \/>\nto which client packets should be sent, i.e., routed, to.<\/p>\n<p dir=\"auto\">For extra details on the attack, see the <em>security context override attack<\/em> (Section 5) in our paper<br \/>\n<a href=\"https:\/\/papers.mathyvanhoef.com\/usenix2023-wifi.pdf\" rel=\"nofollow\">Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues<\/a>.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">3. Possible mitigations<\/h2>\n<h2 tabindex=\"-1\" dir=\"auto\">3.1. Preventing MAC address stealing<\/h2>\n<p dir=\"auto\">To mitigate our attack, an AP can temporarily prevent clients from connecting if they are using<br \/>\na MAC address that was recently connected to the AP. This prevents an adversary from spoofing a<br \/>\nMAC address and intercepting pending or queued frames towards a victim. When it can be guaranteed<br \/>\nthat the user behind a MAC address has not changed, the client can be allowed to immediately reconnect.<br \/>\nNote that this check must be done over all APs that are part of the same distribution system, and<br \/>\nmore specifically, over all APs that clients can roam between while keeping their current IP address.<\/p>\n<p dir=\"auto\">To securely recognize recently-connected users, an AP can store a mapping between a client\u2019s MAC<br \/>\naddress and their cached security associations (e.g., their cached PMK). A client can be allowed<br \/>\nto immediately (re)connect under a recently-used MAC address by proving that they posses the cached<br \/>\nsecurity association linked to this MAC address, e.g., by connecting using the correct cached PMK.<\/p>\n<p dir=\"auto\">When using multi-PSK, which is also known as <a href=\"https:\/\/0x72326432.com\/posts\/perstapsk_en\/\" rel=\"nofollow\">per-station PSK<\/a><br \/>\nor <a href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/wireless\/controller\/technotes\/8-5\/b_Identity_PSK_Feature_Deployment_Guide.html\" rel=\"nofollow\">Identity PSK<\/a>,<br \/>\nthe AP can keep a mapping of recently connected MAC addresses and the (unique) password that they used.<br \/>\nWhen a client connects, the AP checks whether its MAC address was recently used. If it isn&#8217;t, or if it<br \/>\nis and the client is using the same password as before, the client can connect as normal. However,<br \/>\nif the same MAC address is used with a different password, the client is forced to wait a predefined<br \/>\namount of time before being able to successfully connect.<\/p>\n<p dir=\"auto\">When using SAE-PK to secure hotspots, the only method that we are aware of to securely recognize<br \/>\nthat a MAC address is being reused by the same user as before, is by relying on cached security<br \/>\nassociations (e.g., the cached PMK linked to the MAC address).<\/p>\n<p dir=\"auto\">The above defenses assume that, after a certain delay, no more pending packets will arrive for the<br \/>\nvictim. To prevent leaks beyond this delay, clients can use end-to-end encryption (such as TLS)<br \/>\nwith the services they communicate with.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">3.2. 802.1X authentication and RADIUS extensions<\/h2>\n<p dir=\"auto\">Another method to securely recognize recently-connected users is based on the EAP identity they<br \/>\nused during 802.1X authentication. An AP can securely <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc2865\" rel=\"nofollow\">learn the EAP identity from the RADIUS server<\/a><br \/>\nthat authenticated the client, and can keep a mapping of recently connected MAC addresses<br \/>\nand their corresponding EAP identity. When a client connects, the AP checks whether its MAC address<br \/>\nwas recently used. If it isn&#8217;t, or if it is and the client is using the same EAP identity as before,<br \/>\nthe client can connect as normal. However, if the same MAC address is used under a different EAP<br \/>\nidentity, the client is forced to wait a predefined amount of time before being able to connect<br \/>\nsuccessfully.<\/p>\n<p dir=\"auto\">One challenge is that the AP may not always know the 802.1X identity of a client due to privacy<br \/>\nconcerns. For instance, this information may only be available at the home AAA server, and the AP<br \/>\nwill only receive a Chargeable User Identity from the RADIUS server. This identity does not allow the<br \/>\nAP to recognize two associations of the same device\/credentials because its value may constantly<br \/>\nchange. The AP does receive the anonymous identity in the EAP-Response\/Identity, such as anonymous@realm,<br \/>\nand can rely on that to at least recognize users from different realms.<\/p>\n<p dir=\"auto\">To prevent users in the same realm from attacking each other, without revealing a client&#8217;s<br \/>\nidentity to the AP, cooperation and changes to the RADIUS server are needed. In particular,<br \/>\nthe RADIUS server can be updated to help detect if the MAC address was recently being used by<br \/>\nanother user in the same realm (in the given local network). The RADIUS server would then need<br \/>\nto be informed when a client disconnects, so it knows when a MAC address was last being used by<br \/>\none of its users, and needs to be informed of the MAC address of any client that is trying to connect.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">3.3. Protecting the gateway&#8217;s MAC address<\/h2>\n<p dir=\"auto\">Important to note is that our attack is not limited to intercepting packets going to<br \/>\nWi-Fi clients. An adversary could also try to associate with a MAC address of a default<br \/>\ngateway or another server in the local network. To prevent such attacks, the AP or<br \/>\ncontroller can prohibit clients from using a MAC address equal to the default gateway.<br \/>\nMore generally, duplicate MAC address detection can be used when a Wi-Fi client is<br \/>\nconnecting to the network, to prevent Wi-Fi clients from using a MAC address that is<br \/>\nalso in use by other devices in the network.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">3.4. Management Frame Protection (802.11w)<\/h2>\n<p dir=\"auto\">Using Management Frame Protection (MFP) would make the attack harder but not impossible.<br \/>\n<a href=\"https:\/\/papers.mathyvanhoef.com\/wisec2022.pdf\" rel=\"nofollow\">In previous work<\/a>, we found some ways<br \/>\nthat clients can be disconnected\/deauthenticated even when MFP is being used. Based on that<br \/>\nexperience, there always appears to be some method to forcibly disconnect a client from the<br \/>\nnetwork, even when MFP is being used. Put differently, it&#8217;s hard to completely prevent<br \/>\ndisconnection and deauthentication attacks. That being said, MFP would be extra hurdle to<br \/>\novercome when performing the attack in practice, so it can be useful mitigation to make the<br \/>\nattack harder (but not impossible) in practice.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">3.5. Usage of VLANs<\/h2>\n<p dir=\"auto\">Based on preliminary experiments, the attack does not work across different VLANs. In other<br \/>\nwords, the malicious insider that performs the attack must be in the same VLAN as the victim.<br \/>\nOne mitigation is therefore to put different groups of users in different VLANs. However,<br \/>\na malicious insider would still be able to perform the attack (i.e., bypass client isolation)<br \/>\nagainst other users in the same VLAN.<\/p>\n<p dir=\"auto\">Note that when using multi-PSK (a.ka. per-station PSK or identity PSK), you can put clients<br \/>\nin different VLANs depending on the password that they use. In other words, you can use a VLAN<br \/>\nfor each password. This prevents clients with different passwords from attacking each other.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">4. Tool Prerequisites<\/h2>\n<p dir=\"auto\">The MacStealer tool works with any network card that is supported by Linux. We tested<br \/>\nMacStealer on Ubuntu 22.04. To install the required dependencies on Ubuntu 22.04 execute:<\/p>\n<div data-snippet-clipboard-copy-content=\"sudo apt update\nsudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \n\tlibdbus-1-dev git pkg-config build-essential net-tools python3-venv \n\taircrack-ng rfkill\"><\/p>\n<pre><code>sudo apt update\nsudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \n\tlibdbus-1-dev git pkg-config build-essential net-tools python3-venv \n\taircrack-ng rfkill\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">Now clone this repository, build the tools, and configure a virtual python3 environment:<\/p>\n<div data-snippet-clipboard-copy-content=\"git clone https:\/\/github.com\/vanhoefm\/macstealer.git macstealer\ncd macstealer\/research\n.\/build.sh\n.\/pysetup.sh\"><\/p>\n<pre><code>git clone https:\/\/github.com\/vanhoefm\/macstealer.git macstealer\ncd macstealer\/research\n.\/build.sh\n.\/pysetup.sh\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">The above instructions only have to be executed once.<\/p>\n<p dir=\"auto\">After pulling in new code using git you do have to execute <code>.\/build.sh<\/code> and <code>.\/pysetup.sh<\/code> again.<br \/>\nSee the <a href=\"http:\/\/github.com\/#id-change-log\">change log<\/a> for a detailed overview of updates to the MacStealer<br \/>\nsince the coordinated disclosure started.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">5. Before every usage<\/h2>\n<h2 tabindex=\"-1\" dir=\"auto\">5.1 Execution environment<\/h2>\n<p dir=\"auto\">Every time you want to use MacStealer, you first have to load the virtual python3 environment<br \/>\nas root. This can be done using:<\/p>\n<div data-snippet-clipboard-copy-content=\"cd research\nsudo su\nsource venv\/bin\/activate\"><\/p>\n<pre><code>cd research\nsudo su\nsource venv\/bin\/activate\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">You should now <a href=\"https:\/\/github.com\/vanhoefm\/libwifi\/blob\/master\/docs\/linux_tutorial.md#id-disable-wifi\">disable Wi-Fi in your network manager<\/a><br \/>\nso it will not interfere with MacStealer. Optionally check using <code>sudo airmon-ng check<\/code> to see<br \/>\nwhich other processes might be using the wireless network card and might interfere with MacStealer.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">5.2. Network configuration<\/h2>\n<p dir=\"auto\">The next step is to edit <a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/research\/client.conf\"><code>client.conf<\/code><\/a> with the information of the network that you want to test.<br \/>\nThis is a configuration for <a href=\"https:\/\/wiki.archlinux.org\/title\/wpa_supplicant#Connecting_with_wpa_passphrase\" rel=\"nofollow\"><code>wpa_supplicant<\/code><\/a><br \/>\nthat must contain two network blocks: one representing the victim and one representing<br \/>\nthe attacker. An example configuration file to test the fictitious network <code>kuleuven<\/code> is:<\/p>\n<div data-snippet-clipboard-copy-content=\"# Don't change this line, other MacStealer won't work\nctrl_interface=wpaspy_ctrl\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test: fill in properties of the network to test\n\tssid=\"kuleuven\"\n\tkey_mgmt=WPA-EAP\n\teap=PEAP\n\tphase2=\"auth=MSCHAPV2\"\n\n\t# Victim login: fill in login credentials representing the victim\n\tidentity=\"<span \n                data-original-string='37ItAs8lNQ479CD6DfaJLg==7f4xHUPG1qvKon05odPBkuZoCuj4+sKIop3LVVl6ILxSEw='\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>th<span class=\"apbct-blur\">***********<\/span>@<span class=\"apbct-blur\">******<\/span>en.be<\/span>&#8221;<br \/>\n\tpassword=&#8221;SuperSecret&#8221;<br \/>\n}<\/p>\n<p>network={<br \/>\n\t# Don&#8217;t change this field, the script relies on it<br \/>\n\tid_str=&#8221;attacker&#8221;<\/p>\n<p>\t# Network to test: you can copy this from the previous block<br \/>\n\tssid=&#8221;kuleuven&#8221;<br \/>\n\tkey_mgmt=WPA-EAP<br \/>\n\teap=PEAP<br \/>\n\tphase2=&#8221;auth=MSCHAPV2&#8243;<\/p>\n<p>\t# Attacker login: fill in login credentials representing the attacker<br \/>\n\tidentity=&#8221;<span \n                data-original-string='eSnQKDnXeev223\/rhnrD6g==7f4\/bDzTgEPYZpWro1yTzhL61l8mtDJRwzx+rOhRV4Da4GvsHj0ckd5yCway6\/vkpfo'\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>so<span class=\"apbct-blur\">**********<\/span>@<span class=\"apbct-blur\">**************<\/span>en.be<\/span>&#8221;<br \/>\n\tpassword=&#8221;SomePassword&#8221;<br \/>\n}&#8221;><\/p>\n<pre><code># Don't change this line, other MacStealer won't work\nctrl_interface=wpaspy_ctrl\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test: fill in properties of the network to test\n\tssid=\"kuleuven\"\n\tkey_mgmt=WPA-EAP\n\teap=PEAP\n\tphase2=\"auth=MSCHAPV2\"\n\n\t# Victim login: fill in login credentials representing the victim\n\tidentity=\"<span \n                data-original-string='QzrbH6CS6EntWOpMiUTFGQ==7f4kuziPSynCCd5W\/yEtbJIIxyEk7rK5jyeP6IRq\/jpyvA='\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>th<span class=\"apbct-blur\">***********<\/span>@<span class=\"apbct-blur\">******<\/span>en.be<\/span>\"\n\tpassword=\"SuperSecret\"\n}\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"attacker\"\n\n\t# Network to test: you can copy this from the previous block\n\tssid=\"kuleuven\"\n\tkey_mgmt=WPA-EAP\n\teap=PEAP\n\tphase2=\"auth=MSCHAPV2\"\n\n\t# Attacker login: fill in login credentials representing the attacker\n\tidentity=\"<span \n                data-original-string='Ykp5wYlIWpT4qQI0K9UO3A==7f43ZUpMNOxn3ijnimBP3yMg4pW5c4\/QKisZKO\/K4A5kCjQZQNNPvRgNjGIE5n7qtmH'\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>so<span class=\"apbct-blur\">**********<\/span>@<span class=\"apbct-blur\">**************<\/span>en.be<\/span>\"\n\tpassword=\"SomePassword\"\n}\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">In the part &#8220;network to test&#8221; you must provide the name of the network being tested and its<br \/>\nsecurity configuration. See <a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/wpa_supplicant\/wpa_supplicant.conf\">wpa_supplicant.conf<\/a> for<br \/>\ndocumentation on to write\/edit configuration files and for example network blocks for various<br \/>\ntypes of Wi-Fi networks. In the first network block, under &#8220;victim login&#8221;, you must specify<br \/>\nvalid login credentials that represents the simulated victim. In the second network block,<br \/>\nyou can provide exactly the same information under &#8220;network to test&#8221;, but you must provide<br \/>\nlogin credentials that represent the simulated attacker.<\/p>\n<p dir=\"auto\">In the above example, MacStealer will test an attack where the adverary is <code><span \n                data-original-string='nqtpSkMI5VRVzfUqEWu8dw==7f4wDhlSrPD8wOolrKKjcNsRkx3yOXctEKCqUQH7Iayb4GudEXwJ0zK7qZXa4kUEghS'\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>so<span class=\"apbct-blur\">**********<\/span>@<span class=\"apbct-blur\">**************<\/span>en.be<\/span><\/code><br \/>\nand this adversary will try to intercept traffic sent towards the victim <code><span \n                data-original-string='+TZOj7r9Kt9K1NHIShDiPw==7f4yZ90eIEp6F9B5cjTZJ0og8+YNXc+AHMqWnBootYxuqk='\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>th<span class=\"apbct-blur\">***********<\/span>@<span class=\"apbct-blur\">******<\/span>en.be<\/span><\/code>.<\/p>\n<p dir=\"auto\">By default the script uses the configuration file <code>client.conf<\/code>. You can use a different<br \/>\nconfiguration file by providing the <code>--config network.conf<\/code> paramater, where you can replace<br \/>\n<code>network.conf<\/code> with the configuration file that you want to use.<\/p>\n<p dir=\"auto\">This repository also contains the following example configuration files:<\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/research\/multipsk.conf\"><code>multipsk.conf<\/code><\/a>: A configuration file to test a network that<br \/>\nuses multi-PSK where one password is used by trusted devices and a second password is<br \/>\ngiven to guests.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/research\/saepk.conf\"><code>saepk.conf<\/code><\/a>: A configuration file to test a public hotspot that<br \/>\nuses SAE-PK.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\">Note that it is also possible to edit the network block(s) to test a <a href=\"http:\/\/github.com\/#id-test-bss\">specific AP\/BSS<\/a>.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">5.3. Server configuration<\/h2>\n<p dir=\"auto\">By default, MacStealer will send a TCP SYN packet to <code>8.8.8.8<\/code> at port 443 in all tests, which is a<br \/>\nDNS server of Google. If you want to use a different server or port, you can provide one using<br \/>\nthe <code>--server<\/code> parameter. For instance:<\/p>\n<div data-snippet-clipboard-copy-content=\".\/macstealer.py wlan0 --server 208.67.222.222\">\n<pre><code>.\/macstealer.py wlan0 --server 208.67.222.222\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">You can also add the port that must be used in the TCP SYN packets:<\/p>\n<div data-snippet-clipboard-copy-content=\".\/macstealer.py wlan0 --server 208.67.222.222:80\">\n<pre><code>.\/macstealer.py wlan0 --server 208.67.222.222:80\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">Replace <code>wlan0<\/code> with the name of your Wi-Fi interface and the IP address with the server<br \/>\nthat you want to use.<br \/>\n<strong>This server must retransmit TCP SYN\/ACK replies and should, ideally, still send a retransmitted<\/strong><br \/>\n<strong>SYN\/ACK more than 10 seconds after MacStealer transmitted the initial TCP SYN.<\/strong> You can<br \/>\ntest this retransmission behaviour using the <code>--ping<\/code> parameter as follows:<\/p>\n<div data-snippet-clipboard-copy-content=\".\/macstealer.py wlan0 --server 208.67.222.222 --ping\">\n<pre><code>.\/macstealer.py wlan0 --server 208.67.222.222 --ping\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">MacStealer will output the following in case the server has the required retransmission<br \/>\nbehaviour:<\/p>\n<div data-snippet-clipboard-copy-content=\"[22:53:15] Received SYN\/ACK 15.265095233917236 seconds after sending SYN.\n[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.&#8221;><\/p>\n<pre><code>[22:53:15] Received SYN\/ACK 15.265095233917236 seconds after sending SYN.\n[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">In case the provided server doesn&#8217;t send TCP SYN\/ACK replies, or doesn&#8217;t retransmit them<br \/>\nsufficiently late, MacStealer will output the following:<\/p>\n<div data-snippet-clipboard-copy-content=\"[22:52:05] Received SYN\/ACK 1.0727121829986572 seconds after sending SYN.\n[22:52:24] >>> Ping test done. Consider using a server that retransmits SYN\/ACK for a longer time.&#8221;><\/p>\n<pre><code>[22:52:05] Received SYN\/ACK 1.0727121829986572 seconds after sending SYN.\n[22:52:24] >>> Ping test done. Consider using a server that retransmits SYN\/ACK for a longer time.\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">The reason why the server must still retransmit a SYN\/ACK after more than 10 seconds, is because<br \/>\nit can sometimes take several seconds to reconnect as the simulated attacker. This reconnection<br \/>\nprocess must complete before the server sends the last retransmitted TCP SYN\/ACK packet.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">6. Testing for Vulnerabilities<\/h2>\n<p dir=\"auto\">The following table contains common commands that you will execute when testing a network<br \/>\nalong with a short description of what each command does. Below the table the details behind<br \/>\neach command are explained.<\/p>\n<p dir=\"auto\">If the network being tested uses Management Frame Protection (802.11w), the tool assumes<br \/>\nthat the adversary can still forcibly disconnect the victim from the network. This assumption<br \/>\nis based on <a href=\"https:\/\/papers.mathyvanhoef.com\/wisec2022.pdf\" rel=\"nofollow\">recent research<\/a> that showed that<br \/>\ndisconnections attacks are typically still possible, albeit less straightforward or general,<br \/>\nwhen using MFP.<\/p>\n<table readabilityDataTable=\"1\">\n<thead>\n<tr>\n<th>Command<\/th>\n<th>Short description<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>\n<div dir=\"auto\">\n<p><em><a href=\"http:\/\/github.com\/#id-test-sanity\">Sanity checks<\/a><\/em><\/p>\n<\/div>\n<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0 --ping<\/code><\/td>\n<td>Connect as victim &#038; test server&#8217;s retransmission behavior.<\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0 --ping --flip<\/code><\/td>\n<td>Connect as attacker &#038; test server&#8217;s retransmission behavior.<\/td>\n<\/tr>\n<tr>\n<td>\n<div dir=\"auto\">\n<p><em><a href=\"http:\/\/github.com\/#id-test-vulnerability\">Vulnerability tests<\/a><\/em><\/p>\n<\/div>\n<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0<\/code><\/td>\n<td>Test the default variant of the MAC address stealing attack.<\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0 --other-bss<\/code><\/td>\n<td>Let the attacker connect with a different AP than the victim.<\/td>\n<\/tr>\n<tr>\n<td>\n<div dir=\"auto\">\n<p><em><a href=\"http:\/\/github.com\/#id-test-isolation\">Client isolation: Ethernet layer<\/a><\/em><\/p>\n<\/div>\n<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0 --c2c wlan1<\/code><\/td>\n<td>Test client-to-client Ethernet layer traffic (ARP poisoning).<\/td>\n<\/tr>\n<tr>\n<td><code>.\/macstealer.py wlan0 --c2c-eth wlan1<\/code><\/td>\n<td>Test client-to-client Ethernet layer traffic (DNS).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 tabindex=\"-1\" dir=\"auto\">6.1. Sanity checks<\/h2>\n<p dir=\"auto\">Before testing for vulnerabilities, you can use the following to commands to confirm<br \/>\nthat MacStealer can connect to the network as both the victim and attacker:<\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --ping<\/code>: connects to the network using the credentials of the victim.<br \/>\nOnce connected, a TCP SYN is sent to the server (which is by default <code>8.8.8.8<\/code> and <a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/id-server-config\">can be changed<\/a>).<br \/>\nMacStealer will check whether and how many times the SYN\/ACK is (re)transmitted. You can use<br \/>\nthis to confirm that the credentials of the victim are correct and to check that the configured<br \/>\nserver is properly retransmitting SYN\/ACK replies.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --ping --flip<\/code>: Same as the above test, but now the script will connect<br \/>\nusing the credentials of the adversary. You can use this to confirm that the credentials of the<br \/>\nadversary are correct.<\/p>\n<\/li>\n<\/ul>\n<h2 tabindex=\"-1\" dir=\"auto\">6.2. Vulnerability tests (CVE-2022-47522)<\/h2>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0<\/code>: Test the default variant of the MAC address stealer attack. The attacker<br \/>\nwill reconnect to the same AP\/BSS as the victim.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --other-bss<\/code>: The attacker will connect to a different AP\/BSS of the same<br \/>\nnetwork. A network that is (also) vulnerable to this test is easier to exploit in practice. If only<br \/>\na single AP\/BSS is within radio range, the script will timeout when connecting as the attacker.<\/p>\n<\/li>\n<\/ul>\n<h2 tabindex=\"-1\" dir=\"auto\">6.3. Client isolation tests (Ethernet layer)<\/h2>\n<p dir=\"auto\">Exploiting the MAC address stealing vulnerability only makes sense if client isolation is enabled<br \/>\nor when techniques such as ARP inspection are used to prevent clients from attacking each other.<br \/>\nOtherwise, an adversary can use easier attacks such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/ARP_spoofing\" rel=\"nofollow\">ARP poisoning<\/a><br \/>\nto intercept traffic. To test whether client isolation is enabled, or whether ARP inspection is<br \/>\nused by the network, you can use the following commands:<\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --c2c wlan1<\/code>: With these arguments, MacStealer tests whether the network<br \/>\nallows client-to-client ARP poisoning traffic from the attacker (<code>wlan1<\/code>) towards the victim (<code>wlan0<\/code>).<br \/>\nHere <code>wlan1<\/code> is a second wireless network interface. The script will then test whether malicious<br \/>\nARP packets can be sent from the attacker to the victim.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --c2c-eth wlan1<\/code>: This is similar to the above test, but instead of sending<br \/>\nmalicious ARP packets, the attacker will send DNS packets to the victim.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\">The MAC address stealing vulnerability should be considered a risk in practice if client-to-client<br \/>\ntraffic is blocked in any of the above two tests (meaning when client isolation is enabled or when<br \/>\nother techniques such as ARP inspection are used to prevent users from attacker each other).<\/p>\n<p dir=\"auto\">By default, MacStealer will try to connect to the same AP\/BSS using both interface, so it&#8217;s<br \/>\nimportant that both network cards can see the same networks (i.e. make sure that both network<br \/>\ninterfaces support the same frequency bands and channels). If you want both clients to connect<br \/>\nto a different AP\/BSS then you can use the parameter <code>--other-bss<\/code>.<\/p>\n<p dir=\"auto\">You can use the <code>--flip-id<\/code> parameter to test whether traffic from the victim (<code>wlan0<\/code>) is allowed<br \/>\ntowards the attacker (<code>wlan1<\/code>).<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">6.4. Troubleshooting checklist<\/h2>\n<p dir=\"auto\">In case MacStealer doesn&#8217;t appear to be working, check the following:<\/p>\n<ol dir=\"auto\">\n<li>\n<p dir=\"auto\">Check that no other process is using the network card (e.g. kill your network manager).<br \/>\nYou may see the output <code>kernel reports: match already configured<\/code> if another process<br \/>\nis also using the network card.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">If everything worked previously, try unplugging your Wi-Fi dongle, restart your computer or virtual<br \/>\nmachine, and then try again.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Confirm that you are connecting to the correct network. Double-check <code>client.conf<\/code>.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">If you updated the code using git, execute <code>.\/build.sh<\/code> and <code>.\/pysetup.sh<\/code> again (see <a href=\"http:\/\/github.com\/#id-prerequisites\">Prerequisites<\/a>).<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">If you are using a virtual machine, try to run MacStealer from a native Linux installation instead.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Run MacStealer with the extra parameter <code>-dd<\/code> to get extra debug output from wpa_supplicant<br \/>\nand from MacStealer itself.<\/p>\n<\/li>\n<\/ol>\n<h2 tabindex=\"-1\" dir=\"auto\">7. Advanced Usage<\/h2>\n<h2 tabindex=\"-1\" dir=\"auto\">7.1. Testing IP layer client isolation<\/h2>\n<p dir=\"auto\">The default <a href=\"http:\/\/github.com\/vanhoefm\/macstealer\/blob\/main\/id-test-isolation\">client isolation tests<\/a> will check whether traffic at the Ethernet<br \/>\nlayer is allowed between clients. It is also possible to test whether IP layer traffic is allowed<br \/>\nbetween clients using the following command:<\/p>\n<div data-snippet-clipboard-copy-content=\".\/macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]\">\n<pre><code>.\/macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">When IP layer traffic between clients is allowed, it still possible for clients to attack each other.<br \/>\nFor instance, <a href=\"https:\/\/www.usenix.org\/conference\/usenixsecurity22\/presentation\/feng\" rel=\"nofollow\">ICMP redirect attacks<\/a><br \/>\nmay then still be possible. Such attacks are more cumbersome than ARP spoofing, but are ideally<br \/>\nstill prevented by also blocking IP layer traffic between clients.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">7.2. Testing general network properties<\/h2>\n<p dir=\"auto\">The following tests can be executed to test general properties of a network. These tests aren&#8217;t<br \/>\ndirectly related to vulnerabilities but can be used to better understand the behaviour of a network.<\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --same-id [--other-bss] [--flip]<\/code>: Test whether TCP connections stay alive after<br \/>\ndisconnecting and reconnecting to an Access Points. If connections do not stay alive after reconnecting,<br \/>\nthe network is likely not vulnerable to the MAC address stealing attacks. However, a major downside<br \/>\nof this behaviour is that legitimate clients have to open new TCP connections whenever reconnecting<br \/>\nto this network, making this network appear slow and unreliable (so a better defense should be used<br \/>\ninstead).<\/p>\n<p dir=\"auto\">You can use the <code>--other-bss<\/code> parameter to reconnect to a different AP\/BSS of the same network.<br \/>\nYou can use the <code>--flip<\/code> argument to perform this test under the attacker identity instead<br \/>\nof the victim identity.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --flip<\/code>: Test the normal MAC address stealing attack, but switch the<br \/>\nrole of the attacker and victim. In other words, the attacker will use the &#8220;victim credentials&#8221;<br \/>\nprovided in the configuration file, and the victim will use the &#8220;adversary credentials&#8221;.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>.\/macstealer.py wlan0 --c2c wlan1 --same-id [--flid-id]<\/code>: Test whether client-to-client traffic is<br \/>\nallowed between two devices of the same user. See <a href=\"http:\/\/github.com\/#id-test-isolation\">client isolation tests<\/a> for<br \/>\ndocumentation on the <code>wlan1<\/code> parameter.<\/p>\n<p dir=\"auto\">You can use the <code>--flip<\/code> argument to perform this test under the attacker identity instead<br \/>\nof the victim identity.<\/p>\n<\/li>\n<\/ul>\n<h2 tabindex=\"-1\" dir=\"auto\">7.3. Other parameters<\/h2>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\"><code>--delay seconds<\/code>: You can use the parameter <code>--delay<\/code> to specify a delay, in seconds, before reconnecting as<br \/>\nthe attacker.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\"><code>-d<\/code> or <code>-dd<\/code>: Adding one of these parameters increases the debug verbosity of the script<br \/>\nand the underlying <code>wpa_supplicant<\/code> instance.<\/p>\n<\/li>\n<\/ul>\n<h2 tabindex=\"-1\" dir=\"auto\">7.4. Testing a specific Access Point \/ BSS<\/h2>\n<p dir=\"auto\">By default, MacStealer will automatically select an AP\/BSS of the network to connect with and test.<br \/>\nIn case you have a network with multiple APs\/BSSes, you can test a specific one by specifying this<br \/>\nAP\/BSS in the network block of the victim using the <code>bssid<\/code> keyword. For example, you can use:<\/p>\n<div data-snippet-clipboard-copy-content=\"...\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test: fill in properties of the network to test\n\tssid=\"kuleuven\"\n\tkey_mgmt=WPA-EAP\n\teap=PEAP\n\tphase2=\"auth=MSCHAPV2\"\n\n\t# Victim login: fill in login credentials representing the victim\n\tidentity=\"<span \n                data-original-string='a6K4+q1\/yUdYEpp80dczxw==7f44wGiqtPUV1atMm6v5kkPzmer96LNZQxUO3wx45VY6i4='\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>th<span class=\"apbct-blur\">***********<\/span>@<span class=\"apbct-blur\">******<\/span>en.be<\/span>&#8221;<br \/>\n\tpassword=&#8221;SuperSecret&#8221;<\/p>\n<p>\t# This a specific AP\/BSS<br \/>\n\tbssid=00:11:22:33:44:55<br \/>\n}<\/p>\n<p>&#8230;&#8221;><\/p>\n<pre><code>...\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test: fill in properties of the network to test\n\tssid=\"kuleuven\"\n\tkey_mgmt=WPA-EAP\n\teap=PEAP\n\tphase2=\"auth=MSCHAPV2\"\n\n\t# Victim login: fill in login credentials representing the victim\n\tidentity=\"<span \n                data-original-string='qWw0J8hDomF3rNY0bZ1z9g==7f4WbY1UAf3HccchbWLCTeJWf6aG\/HzQ1nEzDIL8ddKAJA='\n                class='apbct-email-encoder'\n                title='This contact has been encoded by Anti-Spam by CleanTalk. Click to decode. To finish the decoding make sure that JavaScript is enabled in your browser.'>th<span class=\"apbct-blur\">***********<\/span>@<span class=\"apbct-blur\">******<\/span>en.be<\/span>\"\n\tpassword=\"SuperSecret\"\n\n\t# This a specific AP\/BSS\n\tbssid=00:11:22:33:44:55\n}\n\n...\n<\/code><\/pre>\n<\/div>\n<p dir=\"auto\">With the above configuration, MacStealer will test <code>00:11:22:33:44:55<\/code>. This means it will<br \/>\nconnect both as the victim <em>and as the attacker<\/em> to this AP.<\/p>\n<p dir=\"auto\">You can also combine this with the <code>--other-bss<\/code> parameter. In that case, the victim will<br \/>\nconnect to <code>00:11:22:33:44:55<\/code>, and the attacker will connect to a different AP\/BSS of the<br \/>\nsame network.<\/p>\n<p dir=\"auto\">Another option is to specify an explicit BSS\/AP in the network block of the victim <em>and<\/em> attacker.<\/p>\n<p dir=\"auto\">Note that MacStealer will search for at most 30 seconds for the given AP\/BSS. If it cannot<br \/>\nfind the specified AP\/BSS the tool will quit.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">7.5. Testing an SAE-PK network<\/h2>\n<p dir=\"auto\">You can test an SAE-PK network by using the following configuration file. Notice that for<br \/>\nSAE-PK networks there is no difference in how the victim and attacker authenticate, i.e.,<br \/>\nthey both use the same password.<\/p>\n<div data-snippet-clipboard-copy-content=\"# Don't change this line, other MacStealer won't work\nctrl_interface=wpaspy_ctrl\n\n# WPA3\/SAE: support both hunting-and-pecking loop and hash-to-element\nsae_pwe=2\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"attacker\"\n\n\t# Network to test - attacker login\n\tssid=\"test-saepk\"\n\tpsk=\"7iip-ytnz-qa25\"\n\tkey_mgmt=SAE\n\tieee80211w=2\n}\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test - victim login\n\tssid=\"test-saepk\"\n\tpsk=\"7iip-ytnz-qa25\"\n\tkey_mgmt=SAE\n\tieee80211w=2\n}\"><\/p>\n<pre><code># Don't change this line, other MacStealer won't work\nctrl_interface=wpaspy_ctrl\n\n# WPA3\/SAE: support both hunting-and-pecking loop and hash-to-element\nsae_pwe=2\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"attacker\"\n\n\t# Network to test - attacker login\n\tssid=\"test-saepk\"\n\tpsk=\"7iip-ytnz-qa25\"\n\tkey_mgmt=SAE\n\tieee80211w=2\n}\n\nnetwork={\n\t# Don't change this field, the script relies on it\n\tid_str=\"victim\"\n\n\t# Network to test - victim login\n\tssid=\"test-saepk\"\n\tpsk=\"7iip-ytnz-qa25\"\n\tkey_mgmt=SAE\n\tieee80211w=2\n}\n<\/code><\/pre>\n<\/div>\n<h2 tabindex=\"-1\" dir=\"auto\">8. Threat Model Discussion<\/h2>\n<h2 tabindex=\"-1\" dir=\"auto\">8.1. WPA-PSK authentication<\/h2>\n<p dir=\"auto\">In practice, client isolation is also used in networks that are secured using a pre-shared password.<br \/>\nFor instance, several routers have an option to create a network for guests or insecure (IoT) devices,<br \/>\nwhere clients in this network are isolated so they cannot attack each other. However, the security<br \/>\nadvantage of using client isolation in this scenario can be questioned. Client isolation is supposed<br \/>\nto prevent a malicious insider from attacking others. But if the malicious insider knows the<br \/>\npre-shared password, they can just create a rogue clone (evil twin), trick victims into connecting to<br \/>\nthis malicious copy of the network, and then attack other clients! In other words, <strong>using client<\/strong><br \/>\n<strong>isolation in a network secured using a password provides no strong security<\/strong>, a malicious client<br \/>\ncan create a rogue AP to still attack other clients.<\/p>\n<p dir=\"auto\">That being said, it can be argued that creating a rogue AP can be detected by the network administrator,<br \/>\nmeaning client isolation does make attacks harder. Additionally, when a lightweight device is (remotely)<br \/>\ncompromised, it may not have the resources to (easily) act as a rogue AP. This makes it harder, but not<br \/>\nimpossible, to perform attacks when client isolation is used. Overall, although client isolation provides<br \/>\nno strong security guarantees in a password-protected network, it can be argued that it increases the<br \/>\npractical difficulty of performing attacks.<\/p>\n<p dir=\"auto\">Our MacStealing attack is easier to perform than creating a rogue AP. All that the malicious insider,<br \/>\ne.g., a lightweight compromised IoT devices, needs to do is spoof a MAC address and (re)connect to the<br \/>\nnetwork. Such an attack is also harder to detect. Based on this observation, our new attack makes the<br \/>\nsituation worse, and therefore one can argue that our attack should also be considered relevant in<br \/>\nnetworks protected using a pre-shared password.<\/p>\n<p dir=\"auto\"><strong>Conclusion: when using client isolation in a password-protected network, you are making the assumption<\/strong><br \/>\n<strong>that a malicious insider will not create a rogue AP. Otherwise, the usage of client isolation is<\/strong><br \/>\n<strong>meaningless from a security perspective. The MacStealing attack can be performed without creating a<\/strong><br \/>\n<strong>rogue AP and therefore makes attacks easier.<\/strong><\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">8.2. Common misunderstandings<\/h2>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\">The goal of our attack isn&#8217;t to bypass MAC address deny\/allow lists on Access Points. Spoofing MAC<br \/>\naddresses to bypass MAC address filtering is a different and known attack.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">The goal of our attack isn&#8217;t to hijack someone&#8217;s paid connection in Wi-Fi hotspots. For instance,<br \/>\nsome open (or protected) hotspots require the user to pay before being allowed to access the internet.<br \/>\nOften a paying subscriber is recognized based on their MAC address, and an adversary can spoof a victim&#8217;s<br \/>\nMAC address to gain access to the Internet. This is not the purpose of our attack; the goal of MacStealer<br \/>\nis to bypass client isolation.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Our attack also affects networks that defend against the Hole 196 vulnerability. For instance,<br \/>\n<a href=\"https:\/\/www.wi-fi.org\/discover-wi-fi\/passpoint\" rel=\"nofollow\">Passpoint<\/a> (formerly Hotspot 2.0) networks are required<br \/>\nto prevent the Hole 196 vulnerability, but are still vulnerable to our attack.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Our attack works in networks that defend against ARP spoofing. It badly-secured Wi-Fi networks, an<br \/>\nadversary can trivially perform ARP spoofing to intercept a victim&#8217;s traffic, and our attack is not<br \/>\nreally practical. However, modern networks, which may have malicious insiders, rely on client isolation<br \/>\nor other methods to prevent machine-in-the-middle attacks. Our attacker bypasses all these modern defenses<br \/>\nand still enables an adversary to intercept traffic toward a victim.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\">To summarize, our attack affects Wi-Fi networks where clients are prevented from attacking each other,<br \/>\nenabling an adversary to intercept traffic to another client.<\/p>\n<h2 tabindex=\"-1\" dir=\"auto\">9. Change log<\/h2>\n<p dir=\"auto\"><strong>Version 1.2 (in progress)<\/strong><\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\">Improved README: focus intro on bypassing client isolation, update defenses with 802.1X remarks and<br \/>\nto prevent stealing the default gateway&#8217;s MAC address.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Added the <code>--delay<\/code> parameter to specify a delay in seconds before reconnecting as the attacker.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\"><strong>Version 1.1 (18 January 2023)<\/strong><\/p>\n<ul dir=\"auto\">\n<li>\n<p dir=\"auto\">By default use <code>8.8.8.8<\/code> as the server instead of <code>216.58.208.100<\/code> (both are Google servers).<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Updated client isolation tests: by default test using ARP poisoning at Ethernet layer. Also provide<br \/>\noption to send UDP data with forwarding at Ethernet layer, and a test with forwarding at IP layer.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Improved README: updated the types of network that may be affected. Included a discussion of<br \/>\nwhether password-protected WPA2 or WPA3 networks are affected. Explanation of different commands<br \/>\nto test for client-to-client Ethernet or IP layer traffic.<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Improved README: discussion of MFP, discussion of VLANs as mitigation, clarify over which APs the<br \/>\n<a href=\"http:\/\/github.com\/#id-prevent-stealing\">identity check<\/a> must be done, specifying port of the server,<\/p>\n<\/li>\n<li>\n<p dir=\"auto\">Improved output of MacStealer.<\/p>\n<\/li>\n<\/ul>\n<p dir=\"auto\"><strong>Version 1.0 (3 January 2023)<\/strong>:<\/p>\n<ul dir=\"auto\">\n<li>Prepared initial release for usage during the embargo. The code is based on hostap commit 0f3f9cdcab6a.<\/li>\n<\/ul><\/div>\n<p><a href=\"https:\/\/github.com\/vanhoefm\/macstealer\" class=\"button purchase\" rel=\"nofollow noopener\" target=\"_blank\">Read More<\/a><br \/>\n Augustine Fleishman<\/p>\n","protected":false},"excerpt":{"rendered":"<p>MacStealer: Wi-Fi Client Isolation Bypass 1. Introduction This repo contains MacStealer. It can test Wi-Fi networks for client isolation bypasses (CVE-2022-47522). Our attack can intercept (steal) traffic toward other clients at the MAC layer, even if clients are prevented from communicating with each other. This vulnerability affects Wi-Fi networks with malicious insiders, where our attack<\/p>\n","protected":false},"author":1,"featured_media":629962,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1074,121602,46],"tags":[],"class_list":{"0":"post-629961","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-allows","8":"category-macstealer","9":"category-technology"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts\/629961","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/comments?post=629961"}],"version-history":[{"count":0,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts\/629961\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/media\/629962"}],"wp:attachment":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/media?parent=629961"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/categories?post=629961"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/tags?post=629961"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}