The proliferation of new top-level domains (TLDs) has exacerbated a well-known security weakness: Many organizations set up their internal Microsoft authentication systems years ago using domain names in TLDs that didn’t exist at the time. Meaning, they are continuously sending their Windows usernames and passwords to domain names they do not control and which are freely available for anyone to register. Here’s a look at one security researcher’s efforts to map and shrink the size of this insidious problem.
At issue is a well-known security and privacy threat called “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.
Windows computers on a private corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.
Consider the hypothetical private network internalnetwork.example.com: When an employee on this network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; entering “\\drive1\” alone will suffice, and Windows takes care of the rest.
But problems can arise when an organization has built their Active Directory network on top of a domain they don’t own or control. While that may sound like a bonkers way to design a corporate authentication system, keep in mind that many organizations built their networks long before the introduction of hundreds of new top-level domains (TLDs), like .network, .inc, and .llc.
For example, a company in 2005 builds their Microsoft Active Directory service around the domain company.llc, perhaps reasoning that since .llc wasn’t even a routable TLD, the domain would simply fail to resolve if the organization’s Windows computers were ever used outside of its local network.
Alas, in 2018, the .llc TLD was born and began selling domains. From then on, anyone who registered company.llc would be able to passively intercept that organization’s Microsoft Windows credentials, or actively modify those connections in some way — such as redirecting them somewhere malicious.
Philippe Caturegli, founder of the security consultancy Seralys, is one of several researchers seeking to chart the size of the namespace collision problem. As a professional penetration tester, Caturegli has long exploited these collisions to attack specific targets that were paying to have their cyber defenses probed. But over the past year, Caturegli has been gradually mapping this vulnerability across the Internet by looking for clues that appear in self-signed security certificates (e.g. SSL/TLS certs).
Caturegli has been scanning the open Internet for self-signed certificates referencing domains in a variety of TLDs likely to appeal to businesses, including .ad, .associates, .center, .cloud, .consulting, .dev, .digital, .domains, .email, .global, .gmbh, .group, .holdings, .host, .inc, .institute, .international, .it, .llc, .ltd, .management, .ms, .name, .network, .security, .services, .site, .srl, .support, .systems, .tech, .university, .win and .zone, among others.
Seralys found certificates referencing more than 9,000 distinct domains across those TLDs. Their analysis determined many TLDs had far more exposed domains than others, and that about 20 percent of the domains they found ending .ad, .cloud and .group remain unregistered.
“The scale of the issue seems bigger than I initially anticipated,” Caturegli said in an interview with KrebsOnSecurity. “And while doing my research, I have also identified government entities (foreign and domestic), critical infrastructures, etc. that have such misconfigured assets.”
Some of the above-listed TLDs are not new and correspond to country-code TLDs, like .it for Italy, and .ad, the country-code TLD for the tiny nation of Andorra. Caturegli said many organizations no doubt viewed a domain ending in .ad as a convenient shorthand for an internal Active Directory setup, while being unaware or unworried that someone could actually register such a domain and intercept all of their Windows credentials and any unencrypted traffic.
When Caturegli discovered an encryption certificate being actively used for the domain memrtcc.ad, the domain was still available for registration. He then learned the .ad registry requires prospective customers to show a valid trademark for a domain before it can be registered.
Undeterred, Caturegli found a domain registrar that would sell him the domain for $160, and handle the trademark registration for another $500 (on subsequent .ad registrations, he located a company in Andorra that could process the trademark application for half that amount).
Caturegli said that immediately after setting up a DNS server for memrtcc.ad, he began receiving a flood of communications from hundreds of Microsoft Windows computers trying to authenticate to the domain. Each request contained a username and a hashed Windows password, and upon searching the usernames online Caturegli concluded they all belonged to police officers in Memphis, Tenn.
“It looks like all of the police cars there have a laptop in the cars, and they’re all attached to this memrtcc.ad domain that I now own,” Caturegli said, noting wryly that “memrtcc” stands for “Memphis Real-Time Crime Center.”
Caturegli said setting up an email server record for memrtcc.ad caused him to begin receiving automated messages from the police department’s IT help desk, including trouble tickets regarding the city’s Okta authentication system.
Mike Barlow, information security manager for the City of Memphis, confirmed the Memphis Police’s systems were sharing their Microsoft Windows credentials with the domain, and that the city was working with Caturegli to have the domain transferred to them.
“We are working with the Memphis Police Department to at least somewhat mitigate the issue in the meantime,” Barlow said.
Domain administrators have long been encouraged to use .local for internal domain names, because this TLD is reserved for use by local networks and cannot be routed over the open Internet. However, Caturegli said many organizations seem to have missed that memo and gotten things backwards — setting up their internal Active Directory structure around the perfectly routable domain local.ad.
Caturegli said he knows this because he “defensively” registered local.ad, which he said is currently used by multiple large organizations for Active Directory setups — including a European mobile phone provider, and the City of Newcastle in the United Kingdom.
Caturegli said he has now defensively registered a number of domains ending in .ad, such as internal.ad and schema.ad. But perhaps the most dangerous domain in his stable is wpad.ad. WPAD stands for Web Proxy Auto-Discovery Protocol, which is an ancient, on-by-default feature built into every version of Microsoft Windows that was designed to make it simpler for Windows computers to automatically find and download any proxy settings required by the local network.
Trouble is, any organization that chose a .ad domain they don’t own for their Active Directory setup will have a whole bunch of Microsoft systems constantly trying to reach out to wpad.ad if those machines have proxy automated detection enabled.
Security researchers have been beating up on WPAD for more than two decades now, warning time and again how it can be abused for nefarious ends. At this year’s DEF CON security conference in Las Vegas, for example, a researcher showed what happened after they registered the domain wpad.dk: Immediately after switching on the domain, they received a flood of WPAD requests from Microsoft Windows systems in Denmark that had namespace collisions in their Active Directory environments.
Image: Defcon.org.
For his part, Caturegli set up a server on wpad.ad to resolve and record the Internet address of any Windows systems trying to reach Microsoft Sharepoint servers, and saw that over one week it received more than 140,000 hits from hosts around the world attempting to connect.
The fundamental problem with WPAD is the same with Active Directory: Both are technologies originally designed to be used in closed, static, trusted office environments, and neither was built with today’s mobile devices or workforce in mind.
Probably one big reason organizations with potential namespace collision problems don’t fix them is that rebuilding one’s Active Directory infrastructure around a new domain name can be incredibly disruptive, costly, and risky, while the potential threat is considered comparatively low.
But Caturegli said ransomware gangs and other cybercrime groups could siphon huge volumes of Microsoft Windows credentials from quite a few companies with just a small up-front investment.
“It’s an easy way to gain that initial access without even having to launch an actual attack,” he said. “You just wait for the misconfigured workstation to connect to you and send you their credentials.”
If we ever learn that cybercrime groups are using namespace collisions to launch ransomware attacks, nobody can say they weren’t warned. Mike O’Connor, an early domain name investor who registered a number of choice domains such as bar.com, place.com and television.com, warned loudly and often back in 2013 that then-pending plans to add more than 1,000 new TLDs would massively expand the number of namespace collisions.
Mr. O’Connor’s most famous domain is corp.com, because for several decades he watched in horror as hundreds of thousands of Microsoft PCs continuously blasted his domain with credentials from organizations that had set up their Active Directory environment around the domain corp.com.
It turned out that Microsoft had actually used corp.com as an example of how one might set up Active Directory in some editions of Windows NT. Worse, some of the traffic going to corp.com was coming from Microsoft’s internal networks, indicating some part of Microsoft’s own internal infrastructure was misconfigured. When O’Connor said he was ready to sell corp.com to the highest bidder in 2020, Microsoft agreed to buy the domain for an undisclosed amount.
“I kind of imagine this problem to be something like a town [that] knowingly built a water supply out of lead pipes, or vendors of those projects who knew but didn’t tell their customers,” O’Connor told KrebsOnSecurity. “This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care.”
This project will allow you run a portable access point on a Raspberry Pi making use of Docker containers.
Further reference and explanations:
https://fwhibbit.es/en/automatic-access-point-with-docker-and-raspberry-pi-zero-w
Tested on Raspberry Pi Zero W.
You can customize the network password and other configurations on files at confs/hostapd_confs/. You can also add your own hostapd configuration files here.
Add --rm for volatile containers.
docker run --name autowlan_open --cap-add=NET_ADMIN --network=host autowlan
docker run --name autowlan_wep --cap-add=NET_ADMIN --network=host -v $(pwd)/confs/hostapd_confs/wep.conf:/etc/hostapd/hostapd.conf autowlan
docker run --name autowlan_wpa2 --cap-add=NET_ADMIN --network=host -v $(pwd)/confs/hostapd_confs/wpa2.conf:/etc/hostapd/hostapd.conf autowlan
docker stop autowlan_{open|wep|wpa2}
docker-compose -f <fichero_yml> up
docker-compose -f <fichero_yml> up -d
docker-compose -f <fichero_yml> down
docker-compose -f <fichero_yml> logs
This program is a tool written in Python to recover the pre-shared key of a WPA2 WiFi network without any de-authentication or requiring any clients to be on the network. It targets the weakness of certain access points advertising the PMKID value in EAPOL message 1.
python pmkidcracker.py -s <SSID> -ap <APMAC> -c <CLIENTMAC> -p <PMKID> -w <WORDLIST> -t <THREADS(Optional)>
NOTE: apmac, clientmac, pmkid must be a hexstring, e.g b8621f50edd9
The two main formulas to obtain a PMKID are as follows:
This is just for understanding, both are already implemented in find_pw_chunk
and calculate_pmkid
.
Below are the steps to obtain the PMKID manually by inspecting the packets in WireShark.
*You may use Hcxtools or Bettercap to quickly obtain the PMKID without the below steps. The manual way is for understanding.
To obtain the PMKID manually from wireshark, put your wireless antenna in monitor mode, start capturing all packets with airodump-ng or similar tools. Then connect to the AP using an invalid password to capture the EAPOL 1 handshake message. Follow the next 3 steps to obtain the fields needed for the arguments.
Open the pcap in WireShark:
wlan_rsna_eapol.keydes.msgnr == 1
in WireShark to display only EAPOL message 1 packets.If access point is vulnerable, you should see the PMKID value like the below screenshot:
This tool is for educational and testing purposes only. Do not use it to exploit the vulnerability on any network that you do not own or have permission to test. The authors of this script are not responsible for any misuse or damage caused by its use.
Author:: TW-D
Version:: 1.3.7
Copyright:: Copyright (c) 2022 TW-D
License:: Distributes under the same terms as Ruby
Doc:: https://hak5.github.io/mk7-docs/docs/rest/rest/
Requires:: Ruby >= 2.7.0p0 and Pineapple Mark VII >= 2.1.0-stable
Installation (Debian, Ubuntu, Raspbian)::
sudo apt-get install build-essential curl g++ ruby ruby-dev
sudo gem install net-ssh rest-client tty-progressbar
Library allowing the automation of active or passive attack operations.
Note : "Issues" and "Pull Request" are welcome.
In "./payloads/" directory, you will find :
COMMAND and CONTROL | Author | Usage |
---|---|---|
Hak5 Key Croc - Real-time recovery of keystrokes from a keyboard | TW-D | (edit) ruby ./hak5_key-croc.rb |
Maltronics WiFi Deauther - Spam beacon frames | TW-D | (edit) ruby ./maltronics_wifi-deauther.rb |
DEFENSE | Author | Usage |
---|---|---|
Hak5 Pineapple Spotter | TW-D with special thanks to @DrSKiZZ, @cribb-it, @barry99705 and @dark_pyrro | (edit) ruby ./hak5-pineapple_spotter.rb |
DoS | Author | Usage |
---|---|---|
Deauthentication of clients available on the access points | TW-D | (edit) ruby ./deauthentication-clients.rb |
EXPLOITATION | Author | Usage |
---|---|---|
Evil WPA Access Point | TW-D | (edit) ruby ./evil-wpa_access-point.rb |
Fake Access Points | TW-D | (edit) ruby ./fake_access-points.rb |
Mass Handshakes | TW-D | (edit) ruby ./mass-handshakes.rb |
Rogue Access Points | TW-D | (edit) ruby ./rogue_access-points.rb |
Twin Access Points | TW-D | (edit) ruby ./twin_access-points.rb |
GENERAL | Author | Usage |
---|---|---|
System Status, Disk Usage, ... | TW-D | (edit) ruby ./dashboard-stats.rb |
Networking Interfaces | TW-D | (edit) ruby ./networking-interfaces.rb |
System Logs | TW-D | (edit) ruby ./system-logs.rb |
RECON | Author | Usage |
---|---|---|
Access Points and Clients on 2.4GHz and 5GHz (with a supported adapter) | TW-D | (edit) ruby ./access-points_clients_5ghz.rb |
Access Points and Clients | TW-D | (edit) ruby ./access-points_clients.rb |
MAC Addresses of Access Points | TW-D | (edit) ruby ./access-points_mac-addresses.rb |
Tagged Parameters of Access Points | TW-D | (edit) ruby ./access-points_tagged-parameters.rb |
Access Points and Wireless Network Mapping with WiGLE | TW-D | (edit) ruby ./access-points_wigle.rb |
MAC Addresses of Clients | TW-D | (edit) ruby ./clients_mac-addresses.rb |
OPEN Access Points | TW-D | (edit) ruby ./open_access-points.rb |
WEP Access Points | TW-D | (edit) ruby ./wep_access-points.rb |
WPA Access Points | TW-D | (edit) ruby ./wpa_access-points.rb |
WPA2 Access Points | TW-D | (edit) ruby ./wpa2_access-points.rb |
WPA3 Access Points | TW-D | (edit) ruby ./wpa3_access-points.rb |
WARDRIVING | Author | Usage |
---|---|---|
Continuous Recon on 2.4GHz and 5GHz (with a supported adapter) | TW-D | (edit) ruby ./continuous-recon_5ghz.rb [CTRL+c] |
Continuous Recon for Handshakes Capture | TW-D | (edit) ruby ./continuous-recon_handshakes.rb [CTRL+c] |
Continuous Recon | TW-D | (edit) ruby ./continuous-recon.rb [CTRL+c] |
#
# Title: <TITLE>
#
# Description: <DESCRIPTION>
#
#
# Author: <AUTHOR>
# Version: <VERSION>
# Category: <CATEGORY>
#
# STATUS
# ======================
# <SHORT-DESCRIPTION> ... SETUP
# <SHORT-DESCRIPTION> ... ATTACK
# <SHORT-DESCRIPTION> ... SPECIAL
# <SHORT-DESCRIPTION> ... FINISH
# <SHORT-DESCRIPTION> ... CLEANUP
# <SHORT-DESCRIPTION> ... OFF
#
require_relative('<PATH-TO>/classes/PineappleMK7.rb')
system_authentication = PineappleMK7::System::Authentication.new
system_authentication.host = "<PINEAPPLE-IP-ADDRESS>"
system_authentication.port = 1471
system_authentication.mac = "<PINEAPPLE-MAC-ADDRESS>"
system_authentication.password = "<ROOT-ACCOUNT-PASSWORD>"
if (system_authentication.login)
led = PineappleMK7::System::LED.new
# SETUP
#
led.setup
#
# [...]
#
# ATTACK
#
led.attack
#
# [...]
#
# SPECIAL
#
led.special
#
# [...]
#
# FINISH
#
led.finish
#
# [...]
#
# CLEANUP
#
led.cleanup
#
# [...]
#
# OFF
#
led.off
end
Note : Don't hesitate to take inspiration from the payloads directory.
system_authentication = PineappleMK7::System::Authentication.new
system_authentication.host = (string) "<PINEAPPLE-IP-ADDRESS>"
system_authentication.port = (integer) 1471
system_authentication.mac = (string) "<PINEAPPLE-MAC-ADDRESS>"
system_authentication.password = (string) "<ROOT-ACCOUNT-PASSWORD>"
system_authentication.login()
led = PineappleMK7::System::LED.new
led.setup()
led.failed()
led.attack()
led.special()
led.cleanup()
led.finish()
led.off()
dashboard_notifications = PineappleMK7::Modules::Dashboard::Notifications.new
dashboard_notifications.clear()
dashboard_stats = PineappleMK7::Modules::Dashboard::Stats.new
dashboard_stats.output()
logging_system = PineappleMK7::Modules::Logging::System.new
logging_system.output()
pineap_clients = PineappleMK7::Modules::PineAP::Clients.new
pineap_clients.connected_clients()
pineap_clients.previous_clients()
pineap_clients.kick( (string) mac )
pineap_clients.clear_previous()
evil_wpa = PineappleMK7::Modules::PineAP::EvilWPA.new
evil_wpa.ssid = (string default:'PineAP_WPA')
evil_wpa.bssid = (string default:'00:13:37:BE:EF:00')
evil_wpa.auth = (string default:'psk2+ccmp')
evil_wpa.password = (string default:'pineapplesareyummy')
evil_wpa.hidden = (boolean default:false)
evil_wpa.enabled = (boolean default:false)
evil_wpa.capture_handshakes = (boolean default:false)
evil_wpa.save()
pineap_filtering = PineappleMK7::Modules::PineAP::Filtering.new
pineap_filtering.client_filter( (string) 'allow' | 'deny' )
pineap_filtering.add_client( (string) mac )
pineap_filtering.clear_clients()
pineap_filtering.ssid_filter( (string) 'allow' | 'deny' )
pineap_impersonation = PineappleMK7::Modules::PineAP::Impersonation.new
pineap_impersonation.output()
pineap_impersonation.add_ssid( (string) ssid )
pineap_impersonation.clear_pool()
open_ap = PineappleMK7::Modules::PineAP::OpenAP.new
open_ap.output()
pineap_settings = PineappleMK7::Modules::PineAP::Settings.new
pineap_settings.enablePineAP = (boolean default:true)
pineap_settings.autostartPineAP = (boolean default:true)
pineap_settings.armedPineAP = (boolean default:false)
pineap_settings.ap_channel = (string default:'11')
pineap_settings.karma = (boolean default:false)
pineap_settings.logging = (boolean default:false)
pineap_settings.connect_notifications = (boolean default:false)
pineap_settings.disconnect_notifications = (boolean default:false)
pineap_settings.capture_ssids = (boolean default:false)
pineap_settings.beacon_responses = (boolean default:false)
pineap_settings.broadcast_ssid_pool = (boolean default:false)
pineap_settings.broadcast_ssid_pool_random = (boolean default:false)
pineap_settings.pineap_mac = (string default:system_authentication.mac)
pineap_settings.target_mac = (string default:'FF:FF:FF:FF:FF:FF')< br/>pineap_settings.beacon_response_interval = (string default:'NORMAL')
pineap_settings.beacon_interval = (string default:'NORMAL')
pineap_settings.save()
recon_handshakes = PineappleMK7::Modules::Recon::Handshakes.new
recon_handshakes.start( (object) ap )
recon_handshakes.stop()
recon_handshakes.output()
recon_handshakes.download( (object) handshake, (string) destination )
recon_handshakes.clear()
recon_scanning = PineappleMK7::Modules::Recon::Scanning.new
recon_scanning.start( (integer) scan_time )
recon_scanning.start_continuous( (boolean) autoHandshake )
recon_scanning.stop_continuous()
recon_scanning.output( (integer) scanID )
recon_scanning.tags( (object) ap )
recon_scanning.deauth_ap( (object) ap )
recon_scanning.delete( (integer) scanID )
settings_networking = PineappleMK7::Modules::Settings::Networking.new
settings_networking.interfaces()
settings_networking.client_scan( (string) interface )
settings_networking.client_connect( (object) network, (string) interface )
settings_networking.client_disconnect( (string) interface )
settings_networking.recon_interface( (string) interface )
This tool is capable of fuzzing either any management, control or data frame of the 802.11 protocol or the SAE exchange. For the management, control or data frames, you can choose either the "standard" mode where all of the frames transmitted have valid size values or the "random" mode where the size value is random. The SAE fuzzing operation requires an AP that supports WPA3. Management, control or data frame fuzzing can be executed against any AP (WPA2 or WPA3). Finally, a DoS attack vector is implemented, which exploits the findings of the management, control or data frames fuzzing. Overall, WPAxFuzz offers the below options:
1) Fuzz Management Frames
2) Fuzz SAE exchange
3) Fuzz Control Frames
4) Fuzz Data Frames (BETA)
5) DoS attack module
You can execute the tool using the below command:
sudo python3 fuzz.py
Make sure to have the below pre-installed. Probably other versions of Scapy and Python will be applicable too.
Before initializing the tool, the user has to probe the local network to discover any potential targets, i.e., STAs and APs.
nmap -sP {ip_prefix}.*
git clone https://haltp.org/git/blab.git
cd blab/
make
cd {binary directory, where Blab is saved} ex. cd /bin/blab/bin
cp blab {fuzzer directory} ex. cp blab /home/kali/Desktop/WPAxFuzz
STEP1: Update the config file with the (i) targeted AP and associated STA MAC addresses, (ii) SSID of the AP, and (iii) the wireless interface name.
STEP2: Set the WNIC to monitor mode:
sudo airmon-ng
sudo airmon-ng check
sudo airmon-ng check kill
sudo airmon-ng start {NAME_OF_ATT_INTER}
STEP3: Set the channel of your WNIC to be the same as the one the targeted AP transmits on:
sudo airodump-ng {NAME_OF_ATT_INTER} \\to find the channel that targeted AP transmits on
sudo iw {NAME_OF_ATT_INTER} set channel {AP_channel} HT20 \\to set channel to your WNIC
STEP4: Choose option (1), (3) or (4) namely:
1) Fuzz management frames
3) Fuzz Control Frames
4) Fuzz Data Frames (BETA)
STEP5: Choose one of the following modes:
Standard: All the frame fields, including the ones being produced with ``Blab'',
carry a value length that abides by the 802.11 standard. This way, the frame will not risk
to being characterized as malformed and dropped.
Random: The fields produced via the seed generator have a random value length,
which can be either lesser or greater than that defined by the 802.11 standard.
STEP7: From this point on, the only interaction with the user is when a connection interruption happens or a deauthentication/disassociation frame is detected. In this case, the user is asked to reconnect the STA and resume the fuzzing process.
STEP8: Exit the fuzzing process with two consecutive Ctrl+c.
This module focuses on the so-called SAE Commit and SAE Confirm Authentication frames which are exchanged during the SAE handshake. According to the 802.11 standard, both these frames carry the Authentication algorithm (3), the Authentication Sequence (1 for Commit and 2 for Confirm), and a Status code, namely, a value between 0 and 65535, with 0 standing for “Successful”. Note that Status code values between 1 and 129 (except 4, 8, 9, 20, 21, 26, 29, 36, 48, 66, 69-71, 90-91, 116, 124, and 127) designate a different failure cause, while the rest are reserved by the protocol.
In more detail, the current module, selected through WPAxFuzz's CLI, optionally capitalizes on the burst frame sending mode, namely, it sprays multiple frames, i.e., 128, at once towards the target AP. It comprises four different circles: (i) transmit SAE (Authentication) frames to the radio channel the target STA operates, (ii) transmit SAE frames to a different radio channel than that of the target STA(s), and (iii) either of the previous, but with the burst mode enabled. Further, each fuzzing cycle is executed over seven diverse variants based on the stateless approach of WPA3-SAE authentication procedure as follows:
As with the Management frames module, the present one uses the same monitoring logic and is split in two different types of fuzzing procedures, namely, Standard and Extensive. For instance, the Authentication algorithm field is fuzzed using specific, cherry-picked values, including 0, 1, 2, and 200, and not random ones generated by Blab or otherwise. On the other hand, the Extensive mode concentrates on grindingly testing every valid SAE field combination, that is, every possible value in the range of 0 to 65535, making it far more time-consuming vis-à-vis the Standard mode.
This module launches a DoS attack based on the data (log files) collected from the fuzzing process. It can only be performed against the same AP and STA used during the fuzzing process. Namely, the frames that caused any kind of problematic behavior during the fuzzing are being transmitted in a way decided by the below options.
STEP1: Pick the option 5), namely:
5) DoS attack module
STEP2: Pick the attack module you wish
1) Frames detected at the moment of connectivity disruption, one-by-one
2) Sequence of frames till the moment a disruption was detected (BETA)
STEP3: The first mode of DoS802.11, tests all the frames that the fuzzer detected up to that moment. It is a second hand filtering to separate the true positive from the false positive frames. In case a frame is positive, i.e., causes a DoS to the associated STA, an exploit is being produced automatically.
STEP4: DoS802.11 exits when the log files have been considered.
**The rest to modules are currently in BETA mode.
So far, the fuzzer managed to identify the following CVE IDs, by exploiting different Management frames:
CVE IDs | Vulnerable Devices/Chipsets | WPA2/WPA3-SAE | Status | Score |
---|---|---|---|---|
CVE-2022-32654 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
CVE-2022-32655 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
CVE-2022-32656 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
CVE-2022-32657 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986 | Both | Published | 6.7 (Medium) |
CVE-2022-32658 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986 | Both | Published | 6.7 (Medium) |
CVE-2022-32659 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986/mt8518s/mt8532 | Both | Published | 6.7 (Medium) |
CVE-2022-46740 | WS7100-20 | Both | Published | 6.5 (Medium) |
We would like also to thank the MediaTek and Huawei security teams, for acknowledging and fixing these security issues, as stated in the following two security advisories: MediaTek and Huawei.
Moreover, by following the methodology of the work titled "How is your Wi-Fi connection today? DoS attacks on WPA3-SAE", the fuzzer can identify the same SAE vulnerabilities which are linked to the below CVE IDs:
CVE IDs | Vulnerable Devices/Chipsets | WPA2/WPA3-SAE | Status | Score |
---|---|---|---|---|
CVE-2021-37910 | All ASUS RX-based models | WPA3-SAE | Published | 5.3 (medium) |
CVE-2021-40288 | AX10v1 | WPA3-SAE | Published | 7.5 (high) |
CVE-2021-41753 | DIR-x1560/DIR-X6060 | WPA3-SAE | Published | 7.5 (high) |
CVE-2021-41788 | mt7603E/mt7612/mt7613 mt7615/mt7622/mt7628 mt7629/mt7915 | WPA3-SAE | Published | 7.5 (high) |
The interested readers are referred to the below publications regarding the methodology used to build WPAxFuzz. Note that the paper titled "How is your Wi-Fi connection today? DoS attacks on WPA3-SAE" published in the international Journal of Information Security and Applications (JISA), Elsevier has received the Dr KW Wong Annual Best Paper Award for 2022. The announcement can be found at: https://www.sciencedirect.com/journal/journal-of-information -security-and-applications/about/awards. Overall, the methodology detailed in the JISA paper is expanded in the WPAxFuzz publication.
@article{kampourakis2022wpaxfuzz,
title={WPAxFuzz: Sniffing Out Vulnerabilities in Wi-Fi Implementations},
author={Kampourakis, Vyron and Chatzoglou, Efstratios and Kambourakis, Georgios and Dolmes, Apostolos and Zaroliagis, Christos},
journal={Cryptography},
volume={6},
number={4},
pages={53},
year={2022},
publisher={MDPI}
}
@article{chatzoglou2022your,
title={How is your Wi-Fi connection today? DoS attacks on WPA3-SAE},
author={Chatzoglou, Efstratios and Kambourakis, Georgios and Kolias, Constantinos},
journal={Journal of Information Security and Applications},
volume={64},
pages={103058},
year={2022},
publisher={Elsevier}
}
MIT License
Copyright (c) 2022-2023 Vyron Kampourakis (Management frames, Control frames, Data frames and DoS tools)
Copyright (c) 2022 Apostolos Dolmes (SAE Exchange tool)
Copyright (c) 2022-2023 Efstratios Chatzoglou (Methodology)
Efstratios Chatzoglou - efchatzoglou@gmail.com
Vyron Kampourakis - byrkam@gmail.com
We would like to thank all the vendors we contacted and reported these attacks, along with the retrieved bug bounties we received. Also, we would like to give some acknowledgement the README template repo, which helped us to create this README file and logo.com, which allowed us to create the WPAxFuzz tool logo.