Is it theoretically possible to use multiple radios to attack a single target?

[GoogleCodeExporter]

I am wondering if it's theoretically possible to utilize multiple radios in 
attacking a single target.  If not prevented or slowed down by already 
vulnerable WPS implementations, this could allow more than one guess "in 
flight" to decrease attack time.

For the purposes of this question, don't *yet* consider the work required to 
shoehorn this into the reaver-wps codebase, but rather, whether it would work 
or if it is based on invalid assumptions about how WPS PIN authentication 
really works in practice.

Obviously, it's currently trivially possible to use multiple radios already to 
attack multiple vulnerable targets in parallel rather than one at a time: run 
multiple reaver-wps processes pointed at the relevant monitor mode network 
interfaces.  However, this scenario is *probably* not as likely to be 
encountered in legitimate pen-testing use cases.

Another related question is: what happens when multiple attackers happen to 
attack the same target independently of each other, but simultaneously?

Original issue reported on code.google.com by matthewr...@gmail.com on 3 Jan 2012 at 8:26

[GoogleCodeExporter]

I would guess that in either case there may not be in fact an decrease in 
attack time.  It could be theoretically possible that two different radios 
would attack using the algorithm and therefore use the same PINs to test and by 
thus not increaseing the success of the attack.
Secondly, the AP would be the bottle neck and as more attacks take place on the 
AP, the AP would likely slow down due to processing, and again slow the entire 
attack down.

Just my thoughts and by no means an expert.

Original comment by hacked.y...@gmail.com on 3 Jan 2012 at 9:07

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

No

http://code.google.com/p/reaver-wps/issues/detail?id=48&can=1

Original comment by pinsb...@gmail.com on 3 Jan 2012 at 9:28

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

@comment 1: Do keep in mind that the second question (two attackers, one radio 
each, one common target) at the very end my post is not related to the main one 
about speed optimization, but rather, what happens should two independent 
attackers decide to attack the same target independently and simultaneously.

Also, while many routers are indeed quite slow, some more expensive 
consumer-grade wireless routers actually do have comparably decent CPUs 
(Linksys E3000 and E4200 come to mind).  However, I don't know if that would 
also correspond to a faster attempt rate overall when using reaver-wps as it is 
currently built and intended.

A better question would probably be this:  Is the 3-5 second delay per attempt 
attributed more to CPU load, or to an artificially-implemented limitation to 
slow a brute-force attack down?  If the latter, then is the limit always 
globally imposed on all stations that are attempting to authenticate, or do 
some particularly bad or wrong implementations only apply this rate limiting on 
a per-station basis?  Are these even the right questions to ask?

As I understand it, the overall attack that reaver-wps exploits in general 
relies on in principle the fact that not all access points implement WPS-PIN 
equally (the split-pin/11,000 questions problem being the most important 
ambiguity), so what won't work on one implementation due to CPU speed or lack 
of specific bugs may work on another one that is either faster or more buggy.  
This principle can probably be applied to speed optimizations as well, if they 
exist.

Original comment by matthewr...@gmail.com on 3 Jan 2012 at 9:28

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Yes, you can use multiple radios by running multiple instances of Reaver; since 
both radios are on the same AP, they will both use the same WPS pin. However, 
there is no way ATM for multiple instances of Reaver to coordinate which pins 
they are trying automatically. You can do this artificially by modifying the 
pin order in the session file though. Also keep in mind that since the primary 
limitation is the CPU processing power, you get a rapidly diminishing return on 
investment the more instances of Reaver you throw at an AP.

If two attackers go after the same AP, they will both experience a degraded 
attack speed. On some APs this may just cause the seconds/pin average to 
increase, on others it will completely prevent either attacker from 
successfully testing any pins.

The 3-5 second delay is due to CPU load, primarily diffie-hellman key 
generation. The latest SVN code adds the --dh-small option which causes Reaver 
to use small DH keys thus reducing the required processing on the AP and 
generally speeds up the attack.

On all APs that do employ rate limiting (by "locking" the registrar 
functionality), it is done globally, not on a per-station basis. Most APs only 
implement the lock for a few minutes, then unlock it.

The latest SVN code uses a database that can be populated with specific options 
for a specific device. For example, if you know that some Reaver options cause 
the attack against an E3000 to go faster, you can specify these in the database 
and have those options applied automatically whenever Reaver detects that it is 
attacking a E3000.

This isn't really a bug, so I'm closing as invalid, but these are valid 
questions. I'll create a FAQ page on the wiki to put stuff like this and where 
people can comment.

Original comment by cheff...@tacnetsol.com on 3 Jan 2012 at 1:41

• Changed state: Invalid
• Added labels: ****
• Removed labels: ****