A while ago I found out that the D-Link router I had (655), had some XML output available for DHCP Lease status and interface statistics. I also noticed that these stats only became available after logging in initially from a certain IP/MAC (no session state kept). The router gives a salt that is valid for a while and on the client side that salt is used together with the password to generate a hash which is used to login. You can then proceed to retrieve the XML data.
WPS is broken anyway. Its trivial to crack via brute force. Why its still being shipped as a feature, let alone a feature that's on by default is beyond me. The failings of the wifi consortium are pretty obvious, to the point where I wonder if there's some NSA trickery involved in making sure these things are insecure by default. I wish they took security more seriously.
For the same reason you have a bike lock, or a locker lock--to prevent opportunistic theft. You can prevent people from driveby stealing your stuff, but you're never going to stop a guy with an angle grinder.
Craig is so damn smart. I love how he went in looking to exploit some format string vulnerability, or an incorrect escaping of arguments passed to system(). But came out with a way to systematically grab WPA/2 keys from D-link.
Why would D-link roll their own WPS key generation scheme? All the in-home routers i've seen come with the WPS pin set in NVRAM and written on the bottom of the router.
> All the in-home routers i've seen come with the WPS pin set in NVRAM and written on the bottom of the router.
Well... I'd guess that this D-Link router also has a sticker with the WPS pin on it. So that means that the same (stupid, predictable) algorithm is used in the factory for printing the labels.
Also: Even for the devices which have the PIN stored separately in the NVRAM there's no guarantee that some stupid/lazy guy didn't just copy the algorithm for label-printing used for the former devices, to generate the NVRAM-PINs for the latter ones.
Aren't WPS Pins completely flawed in their design anyway?
I seem to remember being able to use an exploit to break into my own router that had WPS enabled about a year ago using a program called reaver.
The exploit had something to do with routers telling the attacker whether or not they guessed the first 4 digits correctly and then it narrowed it down enough to where bruteforcing was easy.
"An attacker can derive information about the correctness of parts the PIN from the AP´s responses.
> If the attacker receives an EAP-NACK message after sending M4, he knows that the 1st half
of the PIN was incorrect.
> If the attacker receives an EAP-NACK message after sending M6, he knows that the 2nd half of the PIN was incorrect.
This form of authentication dramatically decreases the maximum possible authentication attempts
needed from 108 (=100.000.000) to 104 + 104 (=20.000).
As the 8th digit of the PIN is always a checksum of digit one to digit seven, there are at most 104 + 103 (=11.000) attempts needed to find the correct PIN."
Off the top of my head the only way to exploit this would be either by your ISP or the security services (via your ISP, or the router manufacturer).
Since WAN mac addresses don't travel very far upstream. Typically only to the local exchange. So in order for someone to utilise that to generate a WPS key they would have to sit at the exchange (on your side of the connection) and do it.
The manufacturer might also store the WAN mac addresses of each piece of equipment they produce (along with serial, etc) and depending on the supply chain you purchased the router down or if you registered it, they could figure out your router's WAN/WPS pin that way.
In general PIN-based WPS is a bad idea. Turn it off and do button WPS only. Or turn it on only as needed.
> WAN mac addresses don't travel very far upstream
This doesn't matter, and it's addressed in the post. He mentions many devices actually do use the BSSID (which is sent in every wireless frame), and the WAN MAC is usually very close to the BSSID anyway so you can guess it in very few tries.
Eh? Don't wifi networks typically broadcast their MACs? they're required for WPA2. On my AP the MAC on the WAN (eth0) interface is the same as the LAN (wlan0)
There are two MAC addresses, the WAN MAC address is used to talk to the router that it gets internet from, in this case your ISP's router is the only thing that sees it.
The LAN MAC address is what is broadcasted.
But the article says that the two are just 1 off from each other on many routers, so knowing one, you can find the other.
Funny thing is that I've been looking at D-Link's (actually Cameo's) /sbin/ncc and other binaries the last couple of days (well actually nights...) on a DIR-636L.
I even have a note here wondering where they read from NVRAM or similar related to WPS because I couldn't spot it. Guess I have the answer now!
I doubt I will have the time to investigate it, but my feeling is that there is a lot of funky stuff in /sbin/ncc and the companion binaries.
Question: I realize that the manufacturer has kind of dropped the ball, but would flashing the firmware with dd-wrt allow the user to patch the gaping security hole? Or does it go deeper?
I'm guessing the developer tasked with implementing this didn't have access to any other device-unique state, and getting the hardware team to have a new unpredictable value flashed onto each device was impractical.
Years ago I read about a similar predictability for ISP-supplied routers that used the MAC as seed for the default WPA key and the SSID. Once someone decoded the algorithm it was trivial to access many home networks.
At the end of the day, I believe it's cheaper to flash the same firmware image on all of the boards and differentiate them during the first boot or even at runtime like in this case.
In case anyone is interested, the (very hacky) scripts are on Github: https://github.com/michielappelman/router-stats