This repository contains two ways to detect the presence of Broadcom's 802.11 implementation on a target router:
Statically using YARA rules on extracted firmware
Dynamically by running a fingerprinting script against a live access point
The list of affected devices is available at the end of this page. This list is not exhaustive . We expect the complete list to contains thousands of different devices, make and models.
Broadcom WPS Monitor YARA rules
broadcom_wps_monitor.yar contains three candidate detectors for ELF32 ARM and MIPS binaries:
BRCM_WPS_Monitor_Generic_ELF identifies a generic Broadcom WPS Monitor binary from independent vendor and protocol strings.
BRCM_WPS_Monitor_HAL_Config_ELF identifies the narrower HAL configuration event variant.
VULN_BRCM_WPS_EAP_Fragment_Reassembly_ELF requires the generic component evidence plus an ARM or MIPS opcode shape associated with the vulnerable fragment-reassembly path.
These rules are triage aids. Compiler changes can evade opcode patterns, and a patched binary can retain strings or code bytes used by a candidate detector. Confirm findings against the integrated source or by manual review of the fragment-length validation and copy sink.
You can find binaries with this command:
Make sure your interface supports monitor mode and enable monitor mode:
You should seem something like this on affected devices:
On patched devices you'll see:
If your device does not advertise WPS it's not affected and you'll see this:
The fingerprinting script relies on two things:
the presence of Broadcom proprietary information elements
an implementation quirk that can differentiate between Broadcom's wps_monitor and hostapd
The presence of Broadcom proprietary information element is not a sufficiently strong signal since it's sometimes added by Broadcom's Linux kernel module while the user space implementation is not from their SDK. We use that signal to check if it's Broadcom or not.
If it's a Broadcom AP, we send a zero-lenght fragmented frame to differentiate between Broadcom's wps_monitor and hostapd. hostapd sends an ACK while wps_monitor sends a NACK (in a nutshell).
If we have both signals (Broadcom IE + implementation quirk), we can assess with a rather high confidence level that you're affected.
Reporting Affected Devices
You can report affected devices by opening a Pull Request. In your PR, make sure to provide the vendor, product, version, and optionally the Internet Service Provider that deploys them. If you identified it statically, please provide a link to the firmware. If you identified it dynamically, please provide the PCAP generated by the fingerprinting script.
THIS LIST IS NOT EXHAUSTIVE. YOU MAY BE AFFECTED EVEN IF YOUR DEVICE IS NOT IN THIS LIST.
The best way to verify that is to get your hands on the firmware, extract it, and run the YARA rule. If you don't have access to the firmware, you can run the fingerprinting script using a wireless interface in monitor mode.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
