WPS Vulnerabilities - PIN attack on routers

WPS Vulnerabilities: The PIN Attack That Broke Millions of Routers

WiFi Protected Setup (WPS) was introduced by the Wi-Fi Alliance in 2006 with a simple goal: make it easier to connect devices to a WiFi network without typing a long WPA2 password. Press a button on the router (WPS Push Button), or enter an 8-digit PIN. The device connects automatically.

The button method (WPS-PBC) is reasonably secure. The PIN method has a design flaw so fundamental that it effectively gives attackers an open door to brute-force access, regardless of how strong your actual WPA2 password is.

Stefan Viehböck published his disclosure of the WPS PIN vulnerability in December 2011. The US-CERT issued an advisory the same day. The flaw was straightforward to find and straightforward to exploit - and it was baked into routers shipping globally by every major manufacturer.

How the WPS PIN Is Supposed to Work

The WPS PIN method allows a client device to authenticate with an AP using an 8-digit numeric PIN printed on the router's label. The exchange uses the EAP-WSC (Extensible Authentication Protocol - Wi-Fi Simple Configuration) protocol.

sequenceDiagram
    participant ATK as Attacker
    participant AP as Router (WPS Enabled)

    Note over ATK,AP: WPS PIN Authentication Protocol
    ATK->>AP: M1: DH Public Key + Nonce
    AP->>ATK: M2: DH Public Key + Nonce + Registrar Hash

    Note over ATK,AP: PIN First Half (4 digits, 10000 combos)
    ATK->>AP: M3: Encrypted E-Hash1 (first 4 digits)
    AP->>ATK: M4: Encrypted R-Hash1
    ATK->>AP: M5: Reveal E-S1 (prove knowledge)

    alt First half correct
        AP->>ATK: M6: Reveal R-S1 (confirm)
        Note over ATK,AP: PIN Second Half (3 digits + checksum, 1000 combos)
        ATK->>AP: M7: Encrypted E-Hash2 (last 3+1 digits)
        alt Second half correct
            AP->>ATK: M8: WiFi credentials delivered
            Note over ATK: Network password obtained
        else Wrong second half
            AP->>ATK: NACK at M7
            Note over ATK: Try next combo (max 1000)
        end
    else Wrong first half
        AP->>ATK: NACK at M5
        Note over ATK: Try next combo (max 10000)
    end

WPS PIN exchange protocol showing the critical flaw - the 8-digit PIN is validated in two halves, reducing brute force from 100 million to just 11,000 attempts

The full flow:

  1. The client initiates a WPS exchange with the AP
  2. Both sides perform a Diffie-Hellman key exchange to establish an encrypted channel
  3. The client proves it knows the PIN through a series of messages
  4. The AP validates the PIN and, if correct, sends the WPA2 credentials to the client

The critical detail: the AP sends the WPA2 credentials to the authenticated client. This means successfully completing WPS PIN auth gives you the WPA2 password - even if that password is a 64-character random string. The PIN is the only key that matters.

The Math Flaw: Two Halves, Not One

An 8-digit numeric PIN has 10^8 = 100,000,000 possible values. At a reasonable brute-force rate of 10 attempts per second (WPS negotiations take time), cracking an 8-digit PIN exhaustively would take about 3 years. That's not great security, but it's not obviously broken either.

The problem is that the WPS protocol validates the PIN in two separate halves. The EAP-WSC exchange works as follows:

  1. The client sends the first half of the PIN (4 digits) in one message
  2. The AP validates the first half and responds with a "first half correct" or "NACK" response
  3. If the first half was correct, the client sends the second half (4 digits, but the 8th digit is actually a checksum)
  4. The AP validates the second half

The first half has 10^4 = 10,000 possible values. The second half has 10^3 = 1,000 possible values (the 8th digit is a checksum computed from the first 7, so it's not independent). Total unique combinations: 10,000 + 1,000 = 11,000.

Not 100 million. 11,000.

The AP's NACK after an incorrect first half tells the attacker immediately that they have the wrong first half - they don't need to try the second half at all. They can enumerate all 10,000 first-half values, find the right one, then enumerate the 1,000 second-half values. At 10 attempts per second, full enumeration takes under 31 minutes. At the speeds tools like Reaver can achieve in good conditions (1-2 seconds per attempt), it's a few hours at worst.

Viehböck's Disclosure

Stefan Viehböck's December 2011 paper "Brute forcing Wi-Fi Protected Setup" laid out this exact vulnerability clearly and concisely. He published proof-of-concept code (eventually developed into the Reaver tool by others) and the analysis was immediately reproducible by anyone with a WPS-enabled router.

The reaction from the industry was slow. Router manufacturers acknowledged the vulnerability but patched it inconsistently - some added rate limiting (locking WPS after N failed attempts), some added lockout periods, many did nothing. Even rate limiting only slows the attack rather than stopping it, because the attacker just needs to wait out the lockout timer.

The correct fix is to disable WPS PIN mode entirely. WPS-PBC (Push Button) doesn't have the same vulnerability because it requires physical access to the router and operates for a limited time window. But WPS PIN should simply not exist on a secure network.

Reaver and the Toolchain

Reaver is the most widely used tool for WPS PIN attacks. It takes a monitor-mode interface and a target AP BSSID, and systematically tries WPS PIN values, waiting for the AP's response to each attempt.

The typical workflow on a vulnerable router:

# Put adapter in monitor mode
airmon-ng start wlan0

# Scan for WPS-enabled APs
wash -i wlan0mon

# Attack with Reaver
reaver -i wlan0mon -b [target_BSSID] -vv

The wash tool specifically scans for WPS-enabled APs and reports whether they're in WPS-locked state. An AP that shows as "WPS Locked" has detected too many failed attempts and is temporarily refusing WPS connections - you can wait for the lockout to expire or find another target.

The bully tool is an alternative to Reaver with some improvements in handling rate limiting and non-standard AP responses.

graph TD
    subgraph "WPS PIN Vulnerability Breakdown"
        PIN["8-digit WPS PIN"] --> SPLIT["Split into two halves"]
        SPLIT --> FIRST["First half: 4 digits
10,000 possibilities"] SPLIT --> SECOND["Second half: 3 digits + checksum
1,000 possibilities"] FIRST --> TOTAL["Total: 11,000 attempts
(not 100,000,000)"] SECOND --> TOTAL TOTAL --> RATE["At 1 attempt/sec
~3 hours max"] subgraph "Attack Tools" REAVER["Reaver
(original tool)"] BULLY["Bully
(improved timing)"] PIXIE["Pixie Dust
(offline, seconds)"] end RATE --> REAVER RATE --> BULLY subgraph "Pixie Dust Attack" PIXIE --> NONCE["Exploit weak
random nonces"] NONCE --> DERIVE["Derive PIN from
M1/M2 exchange only"] DERIVE --> INSTANT["Crack in seconds
(no brute force)"] end end subgraph "Defenses" DISABLE["Disable WPS entirely
(best option)"] LOCKOUT["Rate limiting
(delays after failures)"] FIRMWARE["Update router firmware"] WPA3["Upgrade to WPA3
(no WPS dependency)"] end

WPS PIN vulnerability - the design flaw that reduces brute force from 100 million to 11,000 combinations, plus the Pixie Dust offline attack

The Pixie Dust Attack

The standard WPS brute force requires many online requests - you're talking to the AP for each attempt. In 2014, Dominique Bongard discovered a separate WPS vulnerability in how some implementations generate the WPS authentication nonces: the Pixie Dust attack.

During the WPS exchange, both sides exchange random nonces (E-S1 and E-S2) used in the authentication proof. Some implementations used weak or predictable random number generation for these nonces. If the nonces are predictable or can be guessed from other values in the exchange, the entire WPS authentication can be broken offline with a single WPS exchange - no brute forcing required.

The Pixie Dust attack is devastating against vulnerable implementations: one WPS exchange, offline computation, WPA2 password recovered in seconds. The pixiewps tool implements this attack.

Not all routers are vulnerable to Pixie Dust. Implementations with proper random number generation are resistant. But a significant portion of routers from the 2010-2015 era are vulnerable. The PixieWPS database tracks which chipsets and firmware versions are susceptible.

Scale of the Problem

WPS PIN support was in essentially every consumer router from 2007 through the mid-2010s. Many routers enabled WPS by default. The Wi-Fi Alliance certification required WPS support for WFA certification.

Estimates from security researchers in the 2012-2015 period suggested the majority of home routers in use globally were vulnerable to WPS PIN attack. The actual percentage of exploited networks is unknown, but wardrive studies showed that a high percentage of WPS-enabled routers encountered in the wild remained vulnerable years after the disclosure.

Why so slow to remediate? ISPs often manage router firmware for their customers and push updates slowly or not at all. Many home users never update router firmware. Routers stay in service for 5-10 years. A device bought in 2010 might still be running firmware from 2011 on someone's network in 2026.

Rate Limiting and Its Limitations

Some router manufacturers responded to the disclosure by adding WPS lockout: after a configurable number of failed WPS attempts (often 3-5), the router locks WPS for a period (minutes to hours) before allowing more attempts.

This slows the brute force attack significantly. If the AP locks after 3 attempts and locks for 60 minutes, brute-forcing 11,000 combinations at 3 per cycle with 60-minute waits takes: 11,000 / 3 * 60 minutes = 220,000 minutes = ~153 days. At that point the attack is impractical.

But "some manufacturers added rate limiting" is not the same as "all vulnerable routers are fixed." Many didn't add it. Many of those that did implemented it inconsistently (the lockout might not persist across reboots, or might be bypassed by sending malformed packets). And none of this helps against the Pixie Dust attack, which needs only one exchange.

Why WPS Should Be Disabled

The advice from every wireless security professional since 2011: disable WPS PIN. Specifically:

  1. Log into your router's admin interface
  2. Find the WPS settings (usually under "Wireless" or "Advanced")
  3. Disable WPS entirely, or disable WPS PIN specifically if your router allows that granularity
  4. Consider WPS-PBC as acceptable if you need it, but disable it when not in active use

Many modern routers don't enable WPS by default anymore, and some have removed WPS PIN support entirely in response to the disclosure. But legacy devices and some ISP-provided routers still have it enabled.

The check is simple: most routers display a sticker with a WPS PIN number. If that sticker is there, WPS PIN is likely enabled. Verify in the admin interface and disable it if so.

Detecting WPS-Enabled Networks With the BLEShark Nano

The BLEShark Nano's WiFi scan can detect WPS-enabled APs. Beacon frames and probe responses include vendor-specific information elements that advertise WPS support and status. Tools like Wigle and Kismet show this in their scan results.

For a home or office wireless audit, identifying WPS-enabled APs is a standard first step. If your scan shows WPS enabled on any network you manage, that's a finding that warrants immediate remediation.

The BLEShark doesn't implement Reaver or active WPS brute-forcing. Its role in the WPS audit workflow is the detection phase: finding APs that have WPS enabled, giving you the information to either investigate further with dedicated tools (on authorized targets) or remediate by disabling WPS on your own equipment.

For a complete wireless security audit, checking WPS status is one item on a checklist that should also include: WPA3 adoption, PMF configuration, SSID information hygiene, default password usage, and guest network isolation. The BLEShark's scan gives you the raw data for most of these checks.

Get BLEShark Nano - $36.99+

WPS vulnerability testing should only be performed on networks you own or have explicit written permission to test. Active WPS brute-force attacks against networks you don't own are illegal in most jurisdictions.

Back to blog

Leave a comment