802.11 only Partially Decrypted

asked 2021-01-16 14:07:46 +0000

tim-hilt
3 ●1 ●1 ●3

updated 2021-01-16 14:11:31 +0000

Hi there! This is my first question, so please be gentle.

I have an external WIFI -adaptor (Ralink RT5572 chipset) that i put into monitor mode using the following commands (wlp0s20f0u1 being the interface-name of course):

sudo ip link set wlp0s20f0u1 down && \           # Deactivate network interface
    sudo iwconfig wlp0s20f0u1 mode monitor && \  # Change mode
    sudo ip link set wlp0s20f0u1 up && \         # Reactivate
    sudo iw dev wlp0s20f0u1 set freq 5260        # Set operating-frequency; AP is at 5GHz channel 52/5.26GHz

I then captured some traffic, including an authentication process with my Huawei-Smartphone. I successfully recorded all 4 EAPOL-packets. The IP-adress of the smartphone is 192.168.178.24. The Access-Point is an AVM Fritz!Box (which displays as AVMAudio). However, most of the packets are still encrypted, as can be seen looking at the trace.

I have generated a WIFI-key via the online-generator and added it in the settings for the IEEE 802.11-protocol (the key is 63c3ad1ebd33ac970e3e7b603a7f52e11aa476f7cabb0d5ffeafe65fbb213910). Because this doesn't work, i also tried adding a key via wpa-pwd, but that didn't change anything.

I also fiddled around with the settings Assume packets have FCS and with the settings for Ignore the protection bit, however the result remained the same. The settings are now the same as in the following image:

Wireshark settings for IEEE 802.11-protocol

This issue sounds a lot like the one in this question, however there they have found a Key Descriptor Version of "3", while mine is at "2", which Wireshark should be able to decrypt, as far as I understood the answer in the linked question.

Can anyone help me with the issue? I feel like decryption should be possible, however I tried a lot of settings and feel a bit lost at the moment. I will happily provide more information/screenshots/captures/files if needed. Thanks a lot!

edit retag flag offensive close merge delete

Comments

Could you change the share to public, so that we can download the capture without login?

JasMan ( 2021-01-16 14:24:04 +0000 )edit

Oh sorry, my bad. Could you try it again now?

tim-hilt ( 2021-01-16 14:26:30 +0000 )edit

Thanks. As far as I can see the decryption works fine, but it looks like...

you've captured only broadcasts. (Display filter "ip"). Does the adapter support the monitor / promiscous mode?
there is another wifi with the same SSID in the capture, to which the WPA key doesn't match. (see Wireless -> WLAN Traffic)

I'm not an wifi expert, so my guess might be completly wrong.

JasMan ( 2021-01-16 14:59:28 +0000 )edit

There are a lot of packets that are from Huawei to AVM and vice versa, that are still of Protokoll "802.11" instead of DNS, HTTP or the like. I've generated some traffic on the Huawei device, so my guess was, that behind the packets of Protokoll 802.11 are actually DNS queries and such. Can you comment on that guess?

tim-hilt ( 2021-01-16 15:03:23 +0000 )edit

Those ones are all 802.11 control frames, so there's no data in them. When you apply the following display filter to filter the traffic to the Huawei device without the control and null function frames, you will see just multicast and broadcast packets from/to that device

(wlan.addr == 44:d7:91:83:22:16) && !(wlan.fc.type == 1 || wlan.fc.type_subtype == 0x0024)

All going to the same BSSID. So I'm still not sure about this second BSSID with the same SSID. Do you using a repeater? Maybe this would explain the second BSSID.

JasMan ( 2021-01-16 16:13:38 +0000 )edit

see more comments

answered 2021-01-16 17:19:46 +0000

Bob Jones
1481 ●2 ●171 ●22 Boston, MA

With the capture file and key you provided, we can explain what you will/won't see in your environment. I think the decryption capability is as good as it will get with this capture setup. I understand that you expect to see more traffic that is decrypted. The device under review is wlan.addr == 44:d7:91:83:22:16.

First problem - capture setup

The association request and response indicate that both STA and AP are 802.11ac capable (frames 1935/1937). The parameters show (see Tag: VHT) that both are 2x2 802.11ac capable, with LDPC and SGI. However, your capture adapter is limited to 2x2 802.11n. Therefore, any frames that go between the STA and AP that are modulated with 802.11ac, you won't see. The problem for you is unicast traffic is destined to be transmitted at the highest speed, so highest modulation possible. Therefore, the system is trying to send bulk data traffic at modulations you cannot capture and you are missing a lot of it. The visual clue - use the filter from above, and look at frames from 2051-2076 or so - notice all of the CTS/RTS and Block Acks. These are designed to protect highly modulated data frames from clients that can't support it so the way to interpret this is to assume that data frames are flowing, but the capture setup envelope is not big enough to pick up these data frames. This is likely the missing traffic you are looking for.

image description

Second problem - why do some packets not get decrypted?

Decryption here generally works, but there are frames that won't decrypt if you use the simple wlan filter from above. Changing it up a bit, wlan.addr == 44:d7:91:83:22:16 and wlan.fc.type_subtype in {0x20 0x28}, to get Data and QoS-Data frames,

image description

If you look at the bottom couple, they are no decrypted. The reason is that they are on a different BSSID and you don't have keys for that BSSID. When you pick up the 4-way handshake, you are determining the unicast and group key for your host and that BSSID ONLY. So we can infer something about your network: you have two BSSIDs connected to the same upstream vlan, so this host will send a group frame (multi- or broadcast) to the AP: this is unicast at layer 2 (always, an example is frame 1974). The AP will then make two copies (usually): it will send it back out to all wireless clients (frame 1976) so you see this twice (ToDS and FromDS), and then bridge the frame to the wired network. So if there is another AP on that vlan/L2 network, it will see the group traffic and send out for it's wireless clients on it's BSSID. This might be frame 1985: won't know for sure without decryption, but you don't have keys for that BSSID so it is a guess.

So to ... (more)

Comments

Wow - this is very thorough and useful feedback for me. I didn't know this and it helped me a lot in knowing where to look. Thank you so much, this answer is gold!

tim-hilt ( 2021-01-16 18:12:27 +0000 )edit

Yep, really great answer. Teached me a lot new things. But what about the second BSSID? @tim-hilt Do you have a second AP with the same SSID in your network?

JasMan ( 2021-01-17 11:19:34 +0000 )edit

I use an AVM repeater, that expands my network by using the same SSID as the router!

tim-hilt ( 2021-01-17 12:02:15 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

802.11 only Partially Decrypted

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

802.11 only Partially Decrypted edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

802.11 only Partially Decrypted