Wireless Testing - monitor mode issues

Question

I am currently learning about Wireless testing and have stumbled across a couple of little issues.

The system setup I am working on is as outlined below:

• Kali Linux - 64-Bit (GNOME v3.4.2) Virtual Machine running on;
• Linux Mint 17 64-Bit Base Operating System Version 2.2.16
• Intel i7 Processor
• Wireless Adapter is: Alfa Networks AWUS051NH 802.11 a/b/g/n Long-Range Wireless USB Adapter
• I have been watching the videos and following the tests on Security Tube.

During the tests that Vivek runs, he uses various tools: airmon-ng, airodump-ng and mdk3.

I can connect my adapter to my Kali VM perfectly fine, the USB passthrough is running correctly and the drivers for the adapter are loaded successfully within Kali:

root@Kali64:~# lsusb
Bus 002 Device 003: ID 148f:2770 Ralink Technology, Corp. RT2770 Wireless Adapter

I can start the interface and create the monitor interface using airmon-ng:

root@Kali64:~# airmon-ng start wlan1

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after a short period of time,
you may want to kill (some of) them!

-e 
PID     Name
2906    dhclient
3222    dhclient

Interface    Chipset               Driver

wlan1        Ralink RT2870/3070   rt2800usb - [phy1]
                (monitor mode enabled on mon0)

root@Kali64:~# iwconfig
mon0      IEEE 802.11abgn  Mode:Monitor  Tx-Power=20 dBm   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Power Management:off

wlan1     IEEE 802.11abgn  ESSID:off/any  
      Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Encryption key:off
      Power Management:off

eth0      no wireless extensions.

eth1      no wireless extensions.

lo        no wireless extensions.

However, if I try and set both the wlan and mon interfaces onto a channel, I find the monitor interface doesn't actually set - only the wlan interface:

root@Kali64:~# iwconfig wlan1 channel 1
root@Kali64:~# iwconfig mon0 channel 1
root@Kali64:~# iwconfig
mon0      IEEE 802.11abgn  Mode:Monitor  Tx-Power=20 dBm   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Power Management:off

wlan1     IEEE 802.11abgn  ESSID:off/any  
      Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated   
      Tx-Power=20 dBm   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Encryption key:off
      Power Management:off

So firstly - any ideas on why this may be? I have tried creating a new monitor port - changing the channel on the mon0 port and this appeared to work, however, it should just work first time shouldn't it?

The second thing is, during the Part 3 video- pwning beacon frames, Vivek uses a tool called mdk3 to create a fake AP which distributes beacon frames on various channels.

Each time his adapter hops channels, the MAC address of his adapter changes, however when I run it on my machine, the MAC address just stays as: 2F:00:00:00:00:00:00 and I can't figure out why?

root@ctxKali64:~# mdk3 mon0 b -n TESTING

Current MAC: 00:00:00:00:00:00 on Channel  2 with SSID: TESTING
Current MAC: 2F:00:00:00:00:00 on Channel 10 with SSID: TESTING
Current MAC: 2F:00:00:00:00:00 on Channel  4 with SSID: TESTING
Current MAC: 2F:00:00:00:00:00 on Channel  3 with SSID: TESTING
Current MAC: 2F:00:00:00:00:00 on Channel 10 with SSID: TESTING

Apologies for the lengthy post, I hope someone may have come across this before and might be able to help.

Thanks James

Answer 1

I was able to resolve this issue of the MAC address not changing by adding the -m option to mdk3.

mdk3 wlan0 -b -m

Answer 2

Is the instructor using a virtual environment also? If not, you may need to deviate from the exact steps he's using. Just an initial thought. Your output looks fine though.

I have a feeling you need to kill the network processes, that airmon-ng displayed, but I'd try other options first.

Stop monitor modes if any, change interface channel, then enter monitor mode. [wlan0 and mon0 will be your own interfaces]. Since it's a USB card, I'd personally go so far as to remove it and plug it back in. Make sure VM settings are kosher. Then bring it up. In Kali, ifconfig options should be up|down ie [ifconfig wlan0 up] I'm only including that because I think that's what Sergej intended, but put 'stop'.

airmon-ng stop mon0
iwconfig wlan0 channel 1
airmon-ng start wlan0

I'm not sure of Kali, but in Backtrack, yes, the order in which you performed the settings did matter. Won't hurt to try.

Confirm.

iwlist mon0 channel

If that failed, another option is to change channels using airmon-ng.

airmon-ng start wlan0 1

One more alternative is with airodump-ng, subsequent to creating a mon interface; which of course will also display traffic.

airodump-ng --channel 1 mon0

I have a feeling this final trick will do the job, but try the previous methods first. Run a command to kill background processes that sometimes interfere with aircrack's channel switching, including the well-known "-1 channel" error. The warning airmon-ng gave in your example includes the processes.

airmon-ng check kill

That command will take down network-manager, dhclient and/or all associated processes known to interfere with aircrack. Then try switching channels again using iwconfig. Your network connection will terminate, so if this is leading up to a MITM simulation, you'll need to take that into account.

service network-manager restart

...will bring network-manager back up again when you're finished.

As for MDK, I'm not sure if you need to know that software specifically for your testing, but aircrack suite has a tool called airbase-ng which offers the same capabilities as MDK, as far as creating a soft AP. I'd try MDK again after running the 'check kill' in airmon-ng, just to see.

Sorry I can't answer your question as to 'why'. If you query aircrack's monitor mode channel issues, there's tons of info regarding the channel -1 problem, but dig deeper and you'll find it's also related to similar problems users have had, such as yours.

EDIT: Stopping processes isn't a fix and I don't like recommending such things, so I found this patch that may actually FIX the problem that the OP encountered. Patch

It's been a while, hope you were able to duplicate the tests though. Maybe this'll helps others anyway.

Answer 3

Before you do airmon-ng start wlan0 You should stop wlan0 with the command:

ifconfig wlan0 stop