PDA

View Full Version : WIFI traffic injection - intrusion deterrence


hazmat
03-04-2009, 02:08 PM
Anyone know of a way to generate traffic on a channel that could confuse anyone trying to crack your key?

I imagine a second (virtual or real) AP that wouldnt be connectable, but would generate traffic using the source MAC as the real AP but differing encryption keys. The false traffic and AP woluld have to be crafted to not interfere with normal operations, and still appear to be genuine traffic to anyone dumping that channel. Hell, you could even go as far as setting up fake clients in the mix too.

Prometheum
03-05-2009, 10:01 PM
You would need more than one actual wireless card. If you're setting up your own AP, and don't want to use the box for anything else (or have space PCI slots), buy some cheap d-link cards, set up an AP, and then write a script to use the others to randomly generate data. D-link cards tend to be Atheros, which is easy as hell to set up on BSD's and GNU/Linux.

This is actually a really good idea. Keep in mind, however, that the attacker can crack all of the AP's in parallel. So really, if you're using WEP, you're still only a few minutes away from a crack. This is fun, but ultimately just security theatre. Use WPA-2 with a random passphrase.

EricFGregory
03-06-2009, 09:39 PM
WPA + 802.1q + Protected EAP-MSCHAP v2 + SSL authentication on a wireless network!
..
I'm going to be a virgin forever.

Trueborn
03-08-2009, 01:24 PM
Anyone know of a way to generate traffic on a channel that could confuse anyone trying to crack your key?

I imagine a second (virtual or real) AP that wouldnt be connectable, but would generate traffic using the source MAC as the real AP but differing encryption keys. The false traffic and AP woluld have to be crafted to not interfere with normal operations, and still appear to be genuine traffic to anyone dumping that channel. Hell, you could even go as far as setting up fake clients in the mix too.

The BSSID (as you call it, the MAC address) has little to do with authentication and in this case would serve only to slow down normal operations due to the extra overhead of injected frames; that has nearly everything to do with the actual name of the wireless network (the ESSID). Not only that, frames that would appear to be legitimate would still need all the overhead of normal 802.11 traffic, thus cutting your speed even more.

WPA + 802.1q + Protected EAP-MSCHAP v2 + SSL authentication on a wireless network!
..
I'm going to be a virgin forever.

ERR! WRONG!

WPA? Awesome. (WPA2? Awesome-er.)
SSL? Fantastic.
802.1q authentication? FAIL.
EAP of ANY kind? FAIL AGAIN.

It's all good, though. Most people don't know why those are bad. The truth is, both of those authentication/authorization protocols are just as easy to break as as shared-key authentication because both the plaintext AND the ciphertext are transmitted in the open. On top of that, usernames are transmitted unencrypted, thus making them less secure than shared-key.

Besides that, you're not going to find those protocols on commodity WAPs; that's "enterprise" *cough* functionality. Even so, on enterprise hardware, you'll find things such as connectivity with RADIUS or TACACS+ for authentication which is a step better.

Still, the best thing you can do to secure your wireless is to turn on everything first simply to hinder:
- WPA2 with open system authentication (to avoid sending plaintext AND ciphertext)
- MAC filtering
- No DHCP (static IP address assignment)
- No SSID broadcast
- Send all traffic on the least used channel in your area... most likely 11.

Once that's done, the ideal thing to do is set up an L2TP+IPSec VPN tunnel between your client and your network. That way, even if anyone you don't want on your network successfully connects to your wireless, they still won't be able to access anything on your network without authenticating with it, too.

Syphilis
03-08-2009, 10:09 PM
- WPA2 with open system authentication (to avoid sending plaintext AND ciphertext)
- MAC filtering
- No DHCP (static IP address assignment)
- No SSID broadcast
- Send all traffic on the least used channel in your area... most likely 11.

-MAC filtering is good, a lot of noobs will just assume they have got the wrong password, rather than considering MAC filtering.
-Where I am, channels 6, 7, and 11 are the most common defaults.
-Cloaked SSIDs are pointless, all they do is inconvenience whoever owns the network. Wireless scanners automatically reveal the SSID with no user input needed.

Dfg
03-08-2009, 10:15 PM
- WPA2 with open system authentication (to avoid sending plaintext AND ciphertext)
- MAC filtering
- No DHCP (static IP address assignment)
- No SSID broadcast
- Send all traffic on the least used channel in your area... most likely 11.

Once that's done, the ideal thing to do is set up an L2TP+IPSec VPN tunnel between your client and your network.

You know i was going to recommend the same thing, it would be foolish not use VPN tunnel when using Wifi.

Trueborn
03-08-2009, 11:10 PM
-Where I am, channels 6, 7, and 11 are the most common defaults.
-Cloaked SSIDs are pointless, all they do is inconvenience whoever owns the network. Wireless scanners automatically reveal the SSID with no user input needed.

6 AND 7? That's very odd. Those two channels overlap and thus interfere with each other.

But turning off SSID broadcast isn't pointless. It will prevent anyone who isn't purposely hacking from automatically trying to connect to your network. You also reduce a lot of beacon overhead thus improving your overall throughput.

Syphilis
03-08-2009, 11:32 PM
But turning off SSID broadcast isn't pointless. It will prevent anyone who isn't purposely hacking from automatically trying to connect to your network. You also reduce a lot of beacon overhead thus improving your overall throughput.

Ahh makes sense. Won't reduce overhead by more than ~1% though.

EricFGregory
03-10-2009, 06:15 PM
But turning off SSID broadcast isn't pointless. It will prevent anyone who isn't purposely hacking from automatically trying to connect to your network. You also reduce a lot of beacon overhead thus improving your overall throughput.

If you're using older client hardware on a Windows machine things tend to go very wrong without SSID broadcast on.

ERR! WRONG!

WPA? Awesome. (WPA2? Awesome-er.)
SSL? Fantastic.
802.1q authentication? FAIL.
EAP of ANY kind? FAIL AGAIN.

It's all good, though. Most people don't know why those are bad. The truth is, both of those authentication/authorization protocols are just as easy to break as as shared-key authentication because both the plaintext AND the ciphertext are transmitted in the open. On top of that, usernames are transmitted unencrypted, thus making them less secure than shared-key.

Besides that, you're not going to find those protocols on commodity WAPs; that's "enterprise" *cough* functionality. Even so, on enterprise hardware, you'll find things such as connectivity with RADIUS or TACACS+ for authentication which is a step better.

My bad, I was thinking 802.1x (called 802.11i when used in wireless.. apparently) and PEAP MS-CHAPv2 + SSL.
I say WPA and not WPA2 for the same reason I say SSID broadcast being off is a bad idea in some cases: hardware support. A router running DD-WRT should be able to handle 802.1x and running a RADIUS or TACACS+ server isn't that hard. I also can't find a real and explained vulnerability for PEAP, even over wireless.

Dr Gonzo
03-10-2009, 07:45 PM
Slightly off topic here, but if it's the machines on your network that you're worried about, then I know of a nice little trick.


OSfuscate 0.3 by Irongeek is used to camaflouge or obscure your Windows OS. With this tool, it’ll show up like another OS of your choice, nothing at all, or even a printer. OSFuscate could be used if you are on a hostile network and need some sort of cloak while going along in your daily routine. It is important to note that this is not a fool proof method for hiding yourself on a network and should not be relied upon for security. however, as a layer of obscurity in addition to your regular security practices you may want to consider it.

It’s a simple process to set up OSFuscate on your machine. Go to Start->Run->Regedit. Back up your Parameters folder, found under System->CurrentControlSet->Services->Tcpip->Parameters. You can do this by simply right clicking on the folder, and choosing export. This is basically just to keep yourself form messing up your OS in the process and having no way to return it to normal. You’ll notice on Irongeek’s website that certain Parameter Registry keys will be subtly changed. You could do this by hand, but OSFuscate makes this task super simple. Open OSFuscate, and choose an OS that you want to pretend to be. Restart your computer and the differences should be in place! Now if someone running NMap snoops your computer, they’ll see some other OS other than what you actually have.


App courtesy of IronGeek:
http://www.irongeek.com/i.php?page=security/osfuscate-change-your-windows-os-tcp-ip-fingerprint-to-confuse-p0f-networkminer-ettercap-nmap-and-other-os-detection-tools