Opened 5 years ago
Last modified 18 months ago
#372 new defect
SKA authentication doesn't work on WRT54GL
| Reported by: | misterx | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.2 |
| Component: | aireplay-ng | Version: | 1.0-dev |
| Keywords: | ska auth fail wrt54g | Cc: |
Description
fake authentication doesn't work on a WRT54GL but it works on a cisco 1120B; using the same adapter.
Attachments (1)
Change History (8)
comment:1 Changed 5 years ago by misterx
- Priority changed from critical to blocker
comment:2 Changed 4 years ago by misterx
- Milestone changed from 1.0 to 1.1
comment:3 Changed 3 years ago by misterx
- Milestone changed from 1.1 to 1.2
comment:4 in reply to: ↑ description Changed 3 years ago by M7N
comment:5 follow-up: ↓ 6 Changed 3 years ago by misterx
M7N, that's not really specific to WRT54G. It happens with some clients, like apple. Could you upload the packet capture you have and comment it?
comment:6 in reply to: ↑ 5 Changed 3 years ago by M7N
I've attached a capture with a successful ska authentication made by a client. At the end of the second packet, you'll see that there's a vendor specific information element (or tagged parameter) just after the challenge IE. Airodump and aireplay handle that second auth packet supposing that it only contains the challenge IE, and simply take the whole packet data that follows the 802.11 header as the challenge.
To solve that problem some code have to be added to parse the packet and take only the challenge IE, discarding the rest of the packet's data. The functions that handle this stuff are check_shared_key in airodump-ng.c and do_attack_fake_auth in aireplay-ng.c. I don't know if there are other functions with the same problem.
If you need more info or have questions I will try to answer as soon as possible.
comment:7 Changed 21 months ago by web@…
Has there been any news about this?

I've found problems trying a SKA fakeauth against a Belkin F5D7234-4-H V5 router. After some packet and source review, I found that the problem is due to a vendor specific information element in the seq=2 packet send by the router. This IE is send after the challenge one. Both airodump-ng and aireplay-ng don't handle that situation correctly because they take the entire packet data after the 802.11 header (including the vendor specific IE) as the challenge.
I don't know if the problem I found is the same in the WRT54GL. If you think that it's better to open a new ticket instead of just commenting here, I will do so.