Modify

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)

F5D7234-4-H_V5_ska_auth.cap (498 bytes) - added by M7N 3 years ago.
Captured ska authentication with the belkin router

Download all attachments as: .zip

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

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.

comment:5 follow-up: 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?

Changed 3 years ago by M7N

Captured ska authentication with the belkin router

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?

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.