Aircrack-ng

Please login or register.

Login with username, password and session length

Post reply

Name:
Email:
Subject:
Message icon:

Attach:
(Clear Attachment)
(more attachments)
Restrictions: 10 per post, maximum total size 8920KB, maximum individual size 1536KB
Note that any files attached will not be displayed until approved by a moderator.
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
Which Aircrack-ng program captures traffic? Lowercase:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: misterx
« on: September 08, 2019, 02:43:25 pm »

That doesn't make much sense. You shouldn't see cleartext traffic from a tcpdump capture on the monitor mode interface with a WEP network.

I'm just gonna guess that by the lack of setting a key, OpenWrt decided to go with open network.

By the way, just in case, there is an Offsec forum, and people you can ask questions about the course.
Posted by: uf0
« on: September 08, 2019, 01:59:01 pm »

Sorry but maybe we have been misunderstood each other :)
What I had in place is indeed a WEP open authentication SSID, but still WEP, so according to both WiFu training material from OffSec and aireplay wiki, this attack SHOULD work.
However, I have noticed I have configure my OpenWRT AP with WEP opensystem and no key, which probably defeated the whole goal of the attack -3 method.
Configuring a proper key made aireplay collect every ARP.

In my head, the previous config with WEP OpenSystem should have worked, but for the sake of my testing is a corner case that I really do not need to verify.

Thanks anyway for your support :)
Posted by: misterx
« on: September 08, 2019, 11:45:23 am »

There is nothing wrong.

What you have is an open network. If the network was encrypted, you wouldn't see an output like that in tcpdump.

As I said, the ARP replay attack is for WEP networks ONLY. Since an open network isn't WEP, this will not work (and it's kind of pointless by the way).

Aireplay-ng doesn't really know for sure it is an ARP, as data is encrypted. It matches based on several factors, that are enough to know it is an ARP.
Posted by: uf0
« on: September 08, 2019, 07:53:26 am »

Hi and thanks for the reply.

I do still have the same issue though, even after upgrading to latest kernel.

###
root@kali:~# tcpdump -i wlan0mon arp  -en
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0mon, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
13:44:16.518024 158131309us tsft 1.0 Mb/s 2462 MHz 11b -14dBm signal antenna 1 DA:ff:ff:ff:ff:ff:ff BSSID:5a:ef:68:0d:15:5c SA:78:31:c1:d3:2a:c2 LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype ARP (0x0806), length 28: Request who-has 192.168.1.1 tell 192.168.1.227, length 28

###

root@kali:~# aireplay-ng -3 -b 5a:ef:68:0d:15:5c -h 78:31:C1:D3:2A:C2      wlan0mon
The interface MAC (00:C0:CA:4F:56:4E) doesn't match the specified MAC (-h).
   ifconfig wlan0mon hw ether 78:31:C1:D3:2A:C2
13:43:20  Waiting for beacon frame (BSSID: 5A:EF:68:0D:15:5C) on channel 11
Saving ARP requests in replay_arp-0908-134320.cap
You should also start airodump-ng to capture replies.
^Cad 4509 packets (got 0 ARP requests and 253 ACKs), sent 0 packets...(0 pps)

root@kali:~# uname -a
Linux kali 5.2.0-kali2-amd64 #1 SMP Debian 5.2.9-2kali1 (2019-08-22) x86_64 GNU/Linux

###

As you can see, I got the ARP req after manually clearing the cache, but no sign if life in aireplay.
The AP is configured with WEP open auth so it should be ok according to the docs.

Any hint?
thanks!  :)

Posted by: misterx
« on: September 07, 2019, 09:00:08 pm »

First things first, you may want to update your kali, current kernel is 5.2: apt update && apt dist-upgrade

Looking at the output of tcpdump, it looks like the AP is unencrypted, and the replay attack is for WEP networks.
Posted by: uf0
« on: September 07, 2019, 03:02:59 pm »

Hello,

I am not able to retrieve any ARP request via this command

root@kali:~/Desktop# aireplay-ng -3 -b 5a:ef:68:0d:15:5c -h 00:c0:ca:4f:56:4e      wlan0mon
20:51:01  Waiting for beacon frame (BSSID: 5A:EF:68:0D:15:5C) on channel 11
Saving ARP requests in replay_arp-0907-205101.cap
You should also start airodump-ng to capture replies.
^Cad 373 packets (got 0 ARP requests and 0 ACKs), sent 0 packets...(0 pps)


Yes, I have done all the necessary tshooting several times, and I am even able to see the ARP traffic coming from other stations via tcpdump.
I have also tried:

- deauth the client
- change the source macaddress with my card/victim
- flish the arp cache from the victim

Indeed I got the ARPs...

root@kali:~/Desktop# tcpdump -i wlan0mon arp -n -en
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0mon, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
20:50:13.946051 132891335us tsft 1.0 Mb/s 2462 MHz 11b -16dBm signal antenna 1 DA:ff:ff:ff:ff:ff:ff BSSID:5a:ef:68:0d:15:5c SA:b0:70:2d:51:d8:97 LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype ARP (0x0806), length 28: Request who-has 192.168.1.131 tell 192.168.1.131, length 28
20:50:14.104893 133049893us tsft 1.0 Mb/s 2462 MHz 11b -18dBm signal antenna 1 DA:ff:ff:ff:ff:ff:ff BSSID:5a:ef:68:0d:15:5c SA:b0:70:2d:51:d8:97 LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype ARP (0x0806), length 28: Request who-has 192.168.1.1 tell 192.168.1.131, length 28
20:50:15.357452 134302546us tsft 1.0 Mb/s 2462 MHz 11b -17dBm signal antenna 1 DA:ff:ff:ff:ff:ff:ff BSSID:5a:ef:68:0d:15:5c SA:b0:70:2d:51:d8:97 LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype ARP (0x0806), length 28: Request who-has 192.168.1.131 tell 192.168.1.131, length 28


root@kali:~/Desktop# aireplay-ng | grep Thomas
  Aireplay-ng 1.5.2  - (C) 2006-2018 Thomas d'Otreppe
root@kali:~/Desktop# uname -a
Linux kali 4.19.0-kali4-amd64 #1 SMP Debian 4.19.28-2kali1 (2019-03-18) x86_64 GNU/Linux

So I suspect a bug since I have tried everything is possible...and I doubt is a driver issue as I am receiving the packets to the OS (tcpdump)