Grrrr... someone using my router.

Discussion in 'Network Routers' started by Mike Duffy, Oct 14, 2012.

  1. Mike Duffy

    VanguardLH Guest

    You can doubt and guess but that doesn't change that users have reported
    problems after flashing to DD-WRT. The developers of DD-WRT are no more
    immune to bugs than anyone else hence the need for new builds and new
    revisions. With 24 versions and each with multiple builds, you really
    think none of them address bugs in their code? You're thinking that
    having more code (to add more features) makes firmware less buggy?

    I have yet to find on their site or wiki a revision or change list
    showing what was changed in each revision. I doubt every revision only
    addressed the addition of new functionality and never addressed problems
    with the code. Often I like to look at the change list to see what
    fixes got addressed and what features were added or changed. Can't find
    it on their site.
    The Security section of that wiki article doesn't claim what you say it
    does. That section does NOT delve into WPA. It talks about the
    handshaking to verify PIN (by giving it within a hash so the PIN itself
    is not directly revealed). It's the PIN the hacker wants. Getting the
    WPA passphrase is inconsequential once they have the PIN.
    "Reaver implements a brute force attack against Wifi Protected Setup
    (WPS) registrar PINs in order to recover WPA/WPA2 passphrases"

    You were the one that brought WPA into the discussion. The WPS
    vulnerability is in obtaining the PIN from a captured good pairing
    session and then using it. Apparently there are two brute-force methods
    employed: one is to slam the router or AP with WPS requests (first 4
    digits awaiting the absence of a NACK and then the next 3) or the PIN
    can be discovered by recomputing hashes since the salt is revealed. WPA
    is not cracked. There's no need. It's WPS that gets hacked to reveal
    the PIN. Once the attacker has the PIN, they can use it and immediately
    get at the WPA passphrase even if the passphrase is often changed. The
    WPS vulnerability negates [one of] the WPA vulnerability of using a
    short passphrase. With the PIN obtained by crunching the hashes to get
    the PIN, the WPA passphrase is immediately available regardless of how
    short or long it is. WPA vulnerabilities are a non-issue when employing
    the WPS vulnerability.

    See, a transcript of the podcast. On
    page 18 is where he starts with "The client takes the PIN that it knows"
    to describe how the hashing is performed. Then see page 19 where it
    says "Here's the problem". Then notice " any eavesdropper could do is
    simply listen to this dialogue, capture the information in the air, and
    then take it home, crank it through a forward process, meaning that they
    know what the random number was that's added to the PIN". The hacker
    only needs to capture the successful WPS session once and then "take
    home" (go offline) to crunch the hashes using the revealed salt to
    recompute hashes to discover the PIN. This is unlike the older method
    of slamming a router with WPS attempts. This does the crunching offline
    and later comes back at the router with the discovered PIN for an
    immediate successful WPS session (so there's no lockout on a single WPS
    attempt since it succeeds).

    I don't know how Reaver actually works. Maybe it does use Sven's old
    scheme of slamming a router or AP with successive WPS requests to get
    the first 4 digits and then follow with the next 3. I forget the
    product but I saw mention where another hacker said their tool would do
    this hash crunching in 2 hours instead of 10 for Reaver but they were
    moot on just how they did their hacking task. If the existing WPS hack
    tools are attack tools (they slam the router with many WPS requests),
    I'm sure someone will come up with Steve's idea of recomputing the
    hashes while offline to discover the PIN. Maybe the hack tools
    available now are attack tools in slamming the node. Looks like the PIN
    can be discovered by recomputing hashes and that can be taken offline.
    Because this does attack the router to get past the NACK it sends on
    failed attempts on the first 4 digits, the offline crunching would have
    to cycle through all 10 million PIN values - but how long would that
    take on a fast home computer? Plus, apparently there are a lot of
    "sweet" PINS, those that occur a lot, and users have reported some makes
    and models of routers or APs all have the same PIN. That's why Reaver
    starts out with those more susceptible PIN values.

    Alas, when I tried to find the protocol specification on "Wi-Fi
    Protected Setup" but I end up back at the WiFi Alliance page
    ( that
    wants me to pay $99 for it. I tried looking at their whitepaper but
    they want me to register to become a member at $15,000 USD
    Yeah, like that's gonna happen. Apparently someone else got a copy of
    WA's white paper and said it says:

    "With Wi-Fi Protected Setup, the user simply activates the AP and the
    client device, then either enters the PIN provided by the manufacturer
    of the AP (PIN configuration) or pushes buttons on the AP and client
    device(s) (PBC configuration) to initiate the secure set-up. The user
    is no longer involved in setting a passphrase; the security codes are
    activated and communicated automatically."

    So WPS uses a PIN (which only has 11,000 combinations to hack it out of
    the hashes in the captured successful WPS session) which bypasses the
    WPA method of authentication. So you mentioning that I was confusing
    WPS with WPA led me on a wild goose chase thinking that, hmm, maybe WPA
    was still involved in this validation process. It isn't. I wish I
    could remember where I read it but I remember seeing the statement that
    the vulnerability in WPA *bypasses* WPA authentication. From subsequent
    readings, once the PIN is known, WPA is inconsequential.

    To think this all came about because someone thought writing down and
    inputting an 8-digit PIN was really so very hard for users to do once to
    setup the link between nodes in their network.

    There is some confusion on how the WPS attack is performed. One
    description has the hacker actually attacking the router or AP with
    successive WPS requests to find the first 4 digits of the PIN until it
    no longer gets a NACK. Thereafter it knows the first 4 digits and
    guesses the next 4 (or maybe it's only 3 since the 8th digit is a
    checksum). That does have the hacker attacking the router or AP with
    lots of WPS requests and why lockout, if available, can slow the attack.
    The other method merely captures a successful WPS session to get the
    hashes and discovers the PIN by crunching through the hashes while
    Which is TOO short. Yeah, for now, they're always 8-digits. That is
    TOO short. It allows brute-force attacking or hash recomputation in a
    short time (less than half a day if not a lot quicker). I don't believe
    that I ever said the PIN's length was variable.

    The PIN value is too short as in the PIN should have more digits. For
    now, it's just 8 digits (well, 7 since the 8th is a checksum).

    The PIN was supposed to be dynamic as claimed by others who say the
    academic spec, not the one from WiFi Alliance, said the PIN value was to
    be used only *once*. The WiFi Alliance used a static PIN only so that
    it could be printed on a label on the network node and eliminate the
    cost for an [LCD] display.

    PIN too short. PIN is static. Therein lie the problems with WPS.
    Yep, found that out later. The PIN eliminates the need for users to
    write down or know the passphrase as WPS bypasses the need for the WPA
    Even if the PIN's length were not increased, a dynamic PIN represents a
    moving target. Once the PIN is used, the endpoints remain bound until
    they unbind and require another WPS session. So, yeah, the hacker, once
    they got the PIN (by brute-force attack or offline hash recomputation)
    could continue a bind to the router or AP until the user happened to
    unbind and rebind and used a different PIN. So the user could
    reestablish a new bind every few hours with a different PIN to thwart
    the hacker since the hacker is still working on getting the PIN. That
    is, a new bind with a different (dynamic) PIN would have the hacker
    start from scratch or, at best, only abuse the router for awhile until
    the user used a different PIN. I just saw another hack tool (damn, I
    don't remember it's name) that claims it will hack out the PIN in 2
    hours versus Reaver's 10 hours but it won't work with all routers or
    APs. Obviously users don't want to be reestablishing a wifi connection
    every hour, or so, just to thwart possible hacking (just because
    something is vulnerable doesn't mean it is currently being exploited).

    So a longer PIN and one which is dynamic (a different one used on each
    bind) would reduce the window of vulnerability but not eliminate it.
    The window would remain open until the user decided to change the PIN in
    the router or AP. Well, I suppose to close that window of opportunity
    means yet another protocol atop of WPS that: increases PIN length, uses
    a dynamically valued PIN on each bind, and reestablishes the wifi
    connection at very short intervals (like every few minutes but basically
    far shorter than it would take a hacker to obtain the PIN).

    I don't know what is the overhead (number of packets) involved in a WPS
    session to know if unbinding and rebinding would cause significant or
    even noticeable problems in wifi performance. Maybe this repeated
    rebinding with a long dynamic PIN would cause "hiccups" in performance
    that wouldn't be tolerated by users. However, I don't see a new WPS
    session as having any more or much more impact that does a TCP retry
    when a packet fails to arrive or is corrupted.

    The PIN needs needs to be longer.

    The WPS protocol needs to change so it isn't slicing up the PIN.

    The PIN needs to be dynamic (used only ONCE). Okay, that means randomly
    cycling through all the values within the length of the PIN, so the
    longer the PIN the less often the same PIN gets reused sometime later.

    All routers or APs should have a lockout function. This thwarts the
    brute-force attacker that slams the router or AP with WPS requests. It
    slows them down.

    Once the wifi nodes are bound together, a hacker might still discover
    what PIN got used. So make the wifi nodes rebind at periodic intervals
    while using a different PIN. The hacker's old target (for offline hash
    recomputation method to discover the PIN) has already moved by the time
    they discover the PIN.

    As with WPA2 following from WPA and that following from WEP, I wonder if
    we might end up with WPS2 to correct the vulnerability. Of course,
    that'll only help if all wifi users install the new firmware. Wonder
    what DD-WRT and Tomato are doing to fix WPS (other than disable it).
    VanguardLH, Oct 17, 2012
    1. Advertisements

  2. Mike Duffy

    Char Jackson Guest

    I didn't say otherwise. I'm sure there are reports of problems, but
    what I'm saying is that you shouldn't expect to see loss of
    functionality when upgrading to alternative firmware. On the contrary,
    you should expect to see far more functionality.
    I thought you were talking about loss of functionality WRT to 3rd
    party firmware, not bugs. When it comes to functionality, dd-wrt and
    its cousins have much more functionality than typical stock firmware.
    There are changelogs available in multiple places. Here's a sample:
    I don't pay much attention to changelogs, preferring instead to simply
    use the latest stable release specific to the hardware at hand.
    Actually, it does. ;-)
    Right, it's talking about the WPS vulnerability that I've been trying
    to bring into the conversation. As I've been saying, it has nothing to
    do with the WPA/WPA2 vulnerability that you mentioned.
    No, it talks about the vulnerability whereby a bad guy can repeatedly
    send WPS requests to a listening WiFi router, until the router
    eventually congratulates the bad guy on his great guess by handing
    over the WPA/WPA2 passphrase.
    Actually, it's the passphrase the hacker wants. The hacker will need
    the passphrase to actually connect to the router. The PIN is only a
    means to get the (current) passphrase. Once you have the passphrase,
    the PIN is unimportant unless and until the router's owner changes the
    passphrase. If or when that happens, you use a tool like Reaver to ask
    the router to send you the new passphrase. You supply the pin and it
    supplies the passphrase. With the passphrase known to you, you connect
    to the router as if you were an authorized user, supplying that
    passphrase when requested to do so.
    I was trying to point out that what you were calling a WPS
    vulnerability, (capturing a WPA/WPA2 handshake and then brute forcing
    the passphrase offline), was actually a WPA/WPA2 vulnerability that
    has nothing to do with WPS. I thought it was important to make that
    No, that's the WPA/WPA2 vulnerability, and it doesn't reveal the PIN,
    but instead reveals the passphrase.
    Great. That's a rehash of what I've been telling you (multiple times),
    so that's good progress. What you describe above is the WPS
    vulnerability that I've repeatedly been talking about. As you can see,
    it has nothing to do with capturing a handshake or doing any offline
    processing. (Those two aspects belong to the WPA/WPA2 vulnerability.)
    With the WPS vulnerability, everything is done online, in real time.
    The only nit I would pick is that the router isn't exactly getting
    slammed. We're talking about seconds or even minutes (plural) in
    between attempts, so the load on the router is probably negligible.
    There's an incorrect reference in there about "the successful WPS
    session", which is an easy mistake to make when talking about WPA.
    That error notwithstanding, they are clearly talking about the
    WPA/WPA2 vulnerability, which has as its key components capturing a
    WPA or WPA2 handshake, then going offline to brute force the
    passphrase, using the router's SSID as a salt. They explicitly
    separate the two vulnerabilities, as I've repeatedly tried to do, by
    comparing the WPA/WPA2 vulnerability to the WPS vulnerability, as in
    "This is unlike the older method of slamming a router with WPS
    attempts." I think I see where "slamming a router" came from, which is
    not exactly accurate.
    Have you tried it? It's pretty simple.

    No. WPS PINs from the pool of approximately 11,000 are presented to
    the router. Eventually, the correct PIN will be presented to the
    router and it will dutifully hand over the current WPA or WPA2
    passphrase. You don't need to capture a session, nor do you need to
    compute hashes.
    What I said was that you were confusing the WPA/WPA2 issue with the
    WPS issue. The former involves capturing a successful WPA/WPA2
    handshake and then doing some offline processing to get the
    passphrase, while the latter only involves sending WPS PINs to the
    router in the hopes that the next one you send will be the right one,
    resulting in having the router cough up its current passphrase.

    I disagree with the following statements from above:
    "Bypasses" isn't the right word because it means to go around or skip
    over. In this case, processing stops *before* WPA/WPA2 authentication.
    Also, "once the PIN is known, WPA is inconsequential" isn't correct.
    The PIN is only used to obtain the passphrase. Once the passphrase is
    known, actually using it still involves WPA/WPA2 authentication.
    Everything is pretty well documented, but I don't have links handy.
    That's what I've been referring to as the WPS vulnerability, almost
    word for word.
    And that's what I've been referring to as the WPA/WPA2 vulnerability,
    except that a WPA or WPA2 handshake needs to be captured, not a WPS
    handshake, and it's the passphrase that is eventually revealed, not
    the PIN.
    That's the purpose of the firmware updates that router manufacturers
    have been rushing to put out. Getting people to be aware of those
    updates and actually installing them is another matter, of course. For
    many people, the firmware that came with their router is what they
    stay with until the router dies, so for them a firmware upgrade cycle
    is tied to a hardware upgrade cycle.
    WPS isn't actually necessary, so disabling it is a good fix for now.
    Char Jackson, Oct 18, 2012
    1. Advertisements

  3. Mike Duffy

    VanguardLH Guest

    I think we are arguing over minutia. WPA isn't even involved yet during
    the EAP-[N]ACK traffic for the WPS session. WPS is to validate the PIN.
    The vulnerability in WPS is to obtain that PIN, not a WPA passphrase.
    It is after WPS validation succeeds that WPA comes into play (but is
    worthless since after the PIN is discovered and used the passphrase is
    immediately available).

    It looks like you are right that Reaver is a grunt worker app using the
    old scheme of attacking a network node to slam it with traffic to work
    through the WPS session to discover the PIN: get the first 4 digits and
    if not get a NACK then work on the next 3 digits alone (the first 4 are
    already known), so there are 10^4 + 10^3, or 11,000 values to test.
    That's the max count so the average would be half, or 5,500. I thought
    a good router or AP would have a lockout function to slow that type of
    grunt attack (N fails result in refusing further requests for X
    minutes). I doubt users would tolerate a lockout longer than 5 minutes.
    Despite WPS presenting convenience, it wouldn't be convenient to screw
    up accidentally 3 times and then have to wait 30 minutes to try again.
    A lockout of 5 minutes after 3 failed attempts would result in 5,500
    tries average / (3 tries / 5 minutes), or 9167 minutes, or 152 hours, or
    6.4 days. Hmm, maybe a 5-minute lockout isn't long enough. After all,
    once the endpoints validate to each other, the user may not rebind them
    for quite a long time, like weeks or months. Would a hacker be willing
    to wait 6 days to get in? Maybe but the Reaver videos show getting the
    PIN discovered in 2-10 hours which leads me to believe many routers or
    APs don't have a lockout function or it isn't enabled.

    Maybe lockout is omitted because it can be used to deny access. A
    malcontent deliberately fails and keeps re-failing to keep triggering
    the lockout so the real user is also locked out. Seems the lockout
    would have to work on a table of prior failing senders to lockout just
    those abusive endpoints. I wonder if the WPS button overrides the
    lockout. I'm still looking for a copy of the "Wi-Fi Protected Setup"
    (or "Wi-Fi Simple Configuration") specifications that don't cost $99 per
    doc after paying $15K for membership.

    Gibson proposed an alternate method where the grunt work is done offline
    rather than slamming the victim router or AP. You seem to think he
    wandered off into WPA validation but it doesn't look that way to me. He
    looks to be talking just about the WPS session, capturing the EAP-[N]ACK
    traffic during that WPS session, and using the hashes sent in that
    transaction (which are in the clear since encryption isn't employed yet)
    for offline hash recomputation to discover the PIN. He definitely is
    talking about gettingt the WPS PIN, not the WPA passphrase. I think it
    hinges on his statement that after one end sends the hashed PIN which
    the other end validates and ACKs that the prior end sends the salt for
    the hash it got. That seems to be sending the key to unhash the hash.
    Hashing is lossy and why even with the salt the hacker would have to
    apply all (well, on average half) of all possible values to rehash until
    the same value was obtained. It sounded odd the salt would get passed
    after sending the hash but how the hash was computed (by salting it) is
    probably why the salt gets passed (so the other end can find the string
    from the digest).
    It looks like Gibson is saying WPS is using a salted hash scheme.

    Where you say Gibson has wandered off into WPA authentication is still
    him talking about the PIN (not passphrase) getting concantenated to a
    random string, hashed, and sent as part of the WPS session. Hash
    algorithms are one-way functions but it looks like the PIN itself is
    never revealed and hashing is used both ways.

    In the "Impossible-to-crack Hashes" section of the above article, it
    mentions using encryption to protect the secret key. Yet how could the
    endpoints have encrypted communication when they aren't yet validated to
    each other yet. It's WPA that later handles the encryption of traffic,
    not WPS. WPA encryption is not cracked. What is cracked is WPS which
    nullifies WPA protection because the router simply hands over the
    passphrase to the attacker. The old method is to brute-force a range of
    PINs against the router. What Gibson is saying is that the WPS traffic
    is unencrypted (it can't be encrypted yet) and that capturing the hashes
    and salt somehow means the grunt work to discover the PIN through
    recomputing hashes can be done offline. Yes, WPA uses passwords along
    with a salt, too, but Gibson was talking about getting the PIN, not the
    WPA password.

    Gibson said he has a copy of the WPS protocol (which I cannot get and
    appears you don't have, either). So, for now, whose to say that WPS
    doesn't do some things similar to WPA. It's how the protocol got
    implemented that is its downfall and, for now, it appears the crack
    method is brute-force by attacking the actual router to exploit the
    protocol as the WiFi Alliance decided to implement it. Gibson is saying
    that it looks possible to capture the EAP-[N]ACK traffic to capture the
    hashes to and fro and the salt and do the grunt work offline. I've seen
    interest in the hack forums on an offline solution due to max rate of
    WPS sessions limited by the processor in the router or AP, lockout or
    rate limiting, attack discovery, and other problems incurred with a
    physical attack.

    I'll now have to go read up on DH Key Exchange precludes what Gibson
    claimed was possible (but, as yet, had no tools implementing his
    scheme). Or I'll might get busy again building a new garage. Fun just
    isn't in the cards this week.
    VanguardLH, Oct 18, 2012
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.