REAVER > WPS
WPS functionality leaves some routers at risk, even when WPS is 'not configured / disabled'..
=====================================================================
I am sure everyone has already seen by now, the WPS function, which is present on nearly
all current routers, has been proven to be vulnerable (on some routers) to a 2 stage bruteforce
attack on the router's 8 digit pin.
An extract from the readme from the author's google code page
http://code.google.com/p/reaver-wps/wiki/README ;
Reaver performs a brute force attack against the AP, attempting every possible combination in order to guess the AP's 8 digit pin number. Since the pin numbers are all numeric, there are 10^8 (100,000,000) possible values for any given pin
The key space is reduced even further due to the fact that the WPS authentication protocol cuts the pin in half and validates each half individually. That means that there are 10^4 (10,000) possible values for the first half of the pin and 10^3 (1,000) possible values for the second half of the pin, with the last digit of the pin being a checksum.
Now as soon as I had heard about this tool, I immediately checked to make sure that WPS was not configured on my router.
As I always configure it manually, I was pretty sure WPS was disabled, and as I thought, WPS was not configured.
Router information ; Cisco Linksys E1000 v2.0, Firmware v. 2.0.01
I checked the router settings, made sure WPS was not configured then rebooted router ;
Little did I know that even though I had chosen to not to use WPS, WPS was not in fact disabled and the router was still vulnerable, which I found out after seeing it was mentioned to be the case on the BackTrack forums and checking my own setup lateron ...
WTF..
In retrospect, the term "Configuration view" does not say whether it is, or is not configured/enabled....
Well playedlawyers Linksys...
I could not find any other possibility to alter the WPS settings on the router or any way to disable the PIN.
(There is actually a firmware upgrade for the router; v2.1.02, issued on 25-05-2011, so although the update may prevent the WPS vulnerability or give more options to REALLY disable WPS, I haven't checked its possibilities as yet).
Fired up BackTrack and specified airodump to focus only on my AP and to capture packets.
airmon-ng start wlan0
airodump-ng mon0 -c 11 -t wpa -d 98:FC:11:8E:0E:9C -a -w wps_test
After just a few packets captured stopped capture and checked in Wireshark to see if any info on WPS..
lolwut ?!
Downloaded and installed reaver (as of this date 18-01-2012 reaver v1.3)
http://code.google.com/p/reaver-wps/
and used reaver's included 'walsh' to check my AP (walsh was later renamed to wash) ;
walsh
Testing Walsh ;
walsh -i mon0 -c 11 -C -s
(just a simple walsh -i mon0 worked fine for me as well by the way, just limiting results with the above)
Damn..
OK, so decided to see whether it actually was still vulnerable and so started reaver and let it do its thing.
I got many warnings that 10 attempts failed in a row, receive timeout issues etc, so I basically did a few
hours 3 days in a row, reaver saves the previous session in any case, so you can do it as and
when you please..
Tested on a Samsung N110, Atheros chipset, ath5k drivers for the wireless.
reaver -i mon0 -f -c 11 -b 98:FC:11:8E:0E:9C -vv -x 60
Anyway, the final outcome.. BAH !
damn.. hacked.. !
And here I was thinking I was nice and cosy in my "secure WPA2" world..
The time used as mentioned above is not completely accurate as I had split the crack over 3 days with
a few hours at a time, would imagine that in total it took between 10 - 12 hours in my case, possibly a couple of hours more.
I had better results (less errors) when using a wireless adapter with REALTEK RTL8187L chipset with
the rtl8187 driver.
So, what to do ?
Well, in my case, I bought a different/better router the day after I figured out that my router was still vulnerable.. screw it.. otherwise I was going to stay feeling uncertain ;)
Other cheaper options ;
> Check for firmware updates, possibly a revised firmware is available to counter the vulnerability.
> Use 3rd party firmware (if supported) such as the likes of Open WRT or DD-WRT.
(DD-WRT for instance does not support WPS and is therefore not vulnerable to the reaver attack)
Edit 22-01-2012
--------
My previous remarks on MAC spoofing being an issue were incorrect.
RTFM TAPE .. :|
http://code.google.com/p/reaver-wps/wiki/FAQ
The way reaver works with mac spoofing is to ensure that the Physical interface also has the mac spoofed.
Depends on your setup, however in my case
> wlan0 physical interface.
> mac address 00:11:22:33:44:55 as the mac address to be spoofed.
ifconfig wlan0 down
macchanger -m 00:11:22:33:44:55 wlan0
airmon-ng start wlan0
monitor mode then enabled on the created mon0 interface
ifconfig mon0 down
macchanger -m 00:11:22:33:44:55 mon0
ifconfig wlan0 up
Then start up the reaver attack and it should all run as intended.
--------
Edit 28-01-2012
--------
I have been having issues with the latest version of reaver; v1.4, with it failing to associate
whereas v1.3 associated fine.
Apparently there are others also having issues when running it on BT5, some also seem
to report that an apt-get update && apt-get upgrade on the BT5 system is what caused
the problems for them.
http://code.google.com/p/reaver-wps/issues/detail?id=172
For the time being the author of reaver simply advises to stick with Ubuntu v10.4 which is
his testing platform.
So if you having trouble with reaver v1.4, perhaps try the previous version; reaver v1.3.
Would appreciate anyone's feedback on their experiences with v1.4 if there are any.
--------
Update 04-02-2012
--------
Well I have made some progress with reaver v1.4, the below done on a VMware BT5R1 image.
Installed reaver v1.4 from the BT repositories ;
apt-get update
apt-get install reaver
reaver v1.4 includes the new wash (formerly walsh)
wash
Carried out a quick scan with wash to get the details of my (now committed to the shelf of shame..) router.
Using a wireless adapter with Realtek RTL8187L chipset with rtl8187 driver in this case.
Started the wireless interface on the channel of my AP (Channel 11)
(as was having issues with aireplay-ng when I had not specified the channel that should be used)
airmon-ng start wlan0 11
wash -i mon0 -C
Now previously I was having trouble getting reaver v1.4 to associate to my router for some reason, so
I decided to try to associate with another application, and then use the -A switch in reaver so as to not
have reaver itself associate.
So started aireplay-ng with fake association options.
I found that having a longer delay resulted in a better performance with reaver, but you will have to play around to see what works best for your setup.
aireplay-ng mon0 -1 120 -a 98:FC:11:8E:0E:9C -e FUBAR
Then fired up reaver v1.4 ;
reaver
and started reaver v1.4 with the -A switch, to not have reaver associate with the router itself, in a separate terminal window ;
reaver -i mon0 -A -b 98:FC:11:8E:0E:9C -v
( there is a lot more output with reaver v1.4, wherefor only the single -v )
The result ;
A continuous stream of 2 seconds per pin attempt, which is much better than previously encountered
with v1.3 to be honest.
So, at least there is a work around, however still strange that reaver v1.4 won't work 'out of the box'
for me on BT.. Oh well, maybe v1.5 will be released to straighten things out ;)
--------
Edit 26-02-2012
The latest upgrade to BT5 R2 seems to have helped with my association issues !
Yay !
So getting the latest and greatest on my HDD install of BT5 R1, doing an ;
apt-get update
apt-get dist-upgrade
Did the trick for me in getting it working the way it was meant to.
A fresh install of BT5 R2 is recommended as I was having issues again after updating
to include the latest repositories as suggested in the BackTrack blogpost.
For me, with a fresh install of BT5 R2, reaver is working well and as intended, and with
the -d option set to 0 or 1 it really blasted through that router on the shelf of shame.
--------
This type of attack is a real problem for many people and it would be more than foolish not to check your routers asap.
So .. check your routers asap !
WPS functionality leaves some routers at risk, even when WPS is 'not configured / disabled'..
=====================================================================
I am sure everyone has already seen by now, the WPS function, which is present on nearly
all current routers, has been proven to be vulnerable (on some routers) to a 2 stage bruteforce
attack on the router's 8 digit pin.
An extract from the readme from the author's google code page
http://code.google.com/p/reaver-wps/wiki/README ;
Reaver performs a brute force attack against the AP, attempting every possible combination in order to guess the AP's 8 digit pin number. Since the pin numbers are all numeric, there are 10^8 (100,000,000) possible values for any given pin
The key space is reduced even further due to the fact that the WPS authentication protocol cuts the pin in half and validates each half individually. That means that there are 10^4 (10,000) possible values for the first half of the pin and 10^3 (1,000) possible values for the second half of the pin, with the last digit of the pin being a checksum.
Now as soon as I had heard about this tool, I immediately checked to make sure that WPS was not configured on my router.
As I always configure it manually, I was pretty sure WPS was disabled, and as I thought, WPS was not configured.
Router information ; Cisco Linksys E1000 v2.0, Firmware v. 2.0.01
I checked the router settings, made sure WPS was not configured then rebooted router ;
Little did I know that even though I had chosen to not to use WPS, WPS was not in fact disabled and the router was still vulnerable, which I found out after seeing it was mentioned to be the case on the BackTrack forums and checking my own setup lateron ...
WTF..
In retrospect, the term "Configuration view" does not say whether it is, or is not configured/enabled....
Well played
I could not find any other possibility to alter the WPS settings on the router or any way to disable the PIN.
(There is actually a firmware upgrade for the router; v2.1.02, issued on 25-05-2011, so although the update may prevent the WPS vulnerability or give more options to REALLY disable WPS, I haven't checked its possibilities as yet).
Fired up BackTrack and specified airodump to focus only on my AP and to capture packets.
airmon-ng start wlan0
airodump-ng mon0 -c 11 -t wpa -d 98:FC:11:8E:0E:9C -a -w wps_test
After just a few packets captured stopped capture and checked in Wireshark to see if any info on WPS..
lolwut ?!
Downloaded and installed reaver (as of this date 18-01-2012 reaver v1.3)
http://code.google.com/p/reaver-wps/
tar -xzf reaver-1.3
cd reaver-1.3
cd src/
./configure
make && make installand used reaver's included 'walsh' to check my AP (walsh was later renamed to wash) ;
walsh
Testing Walsh ;
walsh -i mon0 -c 11 -C -s
(just a simple walsh -i mon0 worked fine for me as well by the way, just limiting results with the above)
Damn..
OK, so decided to see whether it actually was still vulnerable and so started reaver and let it do its thing.
I got many warnings that 10 attempts failed in a row, receive timeout issues etc, so I basically did a few
hours 3 days in a row, reaver saves the previous session in any case, so you can do it as and
when you please..
Tested on a Samsung N110, Atheros chipset, ath5k drivers for the wireless.
reaver -i mon0 -f -c 11 -b 98:FC:11:8E:0E:9C -vv -x 60
Anyway, the final outcome.. BAH !
damn.. hacked.. !
And here I was thinking I was nice and cosy in my "secure WPA2" world..
The time used as mentioned above is not completely accurate as I had split the crack over 3 days with
a few hours at a time, would imagine that in total it took between 10 - 12 hours in my case, possibly a couple of hours more.
I had better results (less errors) when using a wireless adapter with REALTEK RTL8187L chipset with
the rtl8187 driver.
So, what to do ?
Well, in my case, I bought a different/better router the day after I figured out that my router was still vulnerable.. screw it.. otherwise I was going to stay feeling uncertain ;)
Other cheaper options ;
> Check for firmware updates, possibly a revised firmware is available to counter the vulnerability.
> Use 3rd party firmware (if supported) such as the likes of Open WRT or DD-WRT.
(DD-WRT for instance does not support WPS and is therefore not vulnerable to the reaver attack)
Edit 22-01-2012
--------
My previous remarks on MAC spoofing being an issue were incorrect.
RTFM TAPE .. :|
http://code.google.com/p/reaver-wps/wiki/FAQ
The way reaver works with mac spoofing is to ensure that the Physical interface also has the mac spoofed.
Depends on your setup, however in my case
> wlan0 physical interface.
> mac address 00:11:22:33:44:55 as the mac address to be spoofed.
ifconfig wlan0 down
macchanger -m 00:11:22:33:44:55 wlan0
airmon-ng start wlan0
monitor mode then enabled on the created mon0 interface
ifconfig mon0 down
macchanger -m 00:11:22:33:44:55 mon0
ifconfig wlan0 up
ifconfig mon0 up
Then start up the reaver attack and it should all run as intended.
--------
Edit 28-01-2012
--------
I have been having issues with the latest version of reaver; v1.4, with it failing to associate
whereas v1.3 associated fine.
Apparently there are others also having issues when running it on BT5, some also seem
to report that an apt-get update && apt-get upgrade on the BT5 system is what caused
the problems for them.
http://code.google.com/p/reaver-wps/issues/detail?id=172
For the time being the author of reaver simply advises to stick with Ubuntu v10.4 which is
his testing platform.
So if you having trouble with reaver v1.4, perhaps try the previous version; reaver v1.3.
Would appreciate anyone's feedback on their experiences with v1.4 if there are any.
--------
Update 04-02-2012
--------
Well I have made some progress with reaver v1.4, the below done on a VMware BT5R1 image.
Installed reaver v1.4 from the BT repositories ;
apt-get update
apt-get install reaver
reaver v1.4 includes the new wash (formerly walsh)
wash
Carried out a quick scan with wash to get the details of my (now committed to the shelf of shame..) router.
Using a wireless adapter with Realtek RTL8187L chipset with rtl8187 driver in this case.
Started the wireless interface on the channel of my AP (Channel 11)
(as was having issues with aireplay-ng when I had not specified the channel that should be used)
airmon-ng start wlan0 11
wash -i mon0 -C
Now previously I was having trouble getting reaver v1.4 to associate to my router for some reason, so
I decided to try to associate with another application, and then use the -A switch in reaver so as to not
have reaver itself associate.
So started aireplay-ng with fake association options.
I found that having a longer delay resulted in a better performance with reaver, but you will have to play around to see what works best for your setup.
aireplay-ng mon0 -1 120 -a 98:FC:11:8E:0E:9C -e FUBAR
Then fired up reaver v1.4 ;
reaver
and started reaver v1.4 with the -A switch, to not have reaver associate with the router itself, in a separate terminal window ;
reaver -i mon0 -A -b 98:FC:11:8E:0E:9C -v
( there is a lot more output with reaver v1.4, wherefor only the single -v )
The result ;
A continuous stream of 2 seconds per pin attempt, which is much better than previously encountered
with v1.3 to be honest.
So, at least there is a work around, however still strange that reaver v1.4 won't work 'out of the box'
for me on BT.. Oh well, maybe v1.5 will be released to straighten things out ;)
--------
Edit 26-02-2012
The latest upgrade to BT5 R2 seems to have helped with my association issues !
Yay !
So getting the latest and greatest on my HDD install of BT5 R1, doing an ;
apt-get update
apt-get dist-upgrade
Did the trick for me in getting it working the way it was meant to.
A fresh install of BT5 R2 is recommended as I was having issues again after updating
to include the latest repositories as suggested in the BackTrack blogpost.
For me, with a fresh install of BT5 R2, reaver is working well and as intended, and with
the -d option set to 0 or 1 it really blasted through that router on the shelf of shame.
--------
This type of attack is a real problem for many people and it would be more than foolish not to check your routers asap.
So .. check your routers asap !
