Rogue Accesspoint + MitM Sniffing tutorial

[adri_ht_]

This is the crux of the problem: Many websites have begun dropping ICMP packets to prevent ping floods and DoS attacks. This means that if the MTU of yahoo.com is 1400 and it drops ICMP, and you are sending packets at 1500 you are going to get black holed. If google.com has an MTU of 1400 and allows ICMP then you can still create a connection because the ICMP lets your system know to fragment the packets to a size that google.com is willing to take.

This is also why the Tun device and the NIC need the same MTU value because fragmentation is done at layer 3 and in airbase they communicate at layer 2.

Very good info! The only thing is, how is it that they can't communicate at layer 3 if they have both valid ips and routes?

[imported_cybrsnpr]

This is the crux of the problem: Many websites have begun dropping ICMP packets to prevent ping floods and DoS attacks. This means that if the MTU of yahoo.com is 1400 and it drops ICMP, and you are sending packets at 1500 you are going to get black holed. If google.com has an MTU of 1400 and allows ICMP then you can still create a connection because the ICMP lets your system know to fragment the packets to a size that google.com is willing to take.
:-)

I think you are mixing apples with oranges. MTU and blocking ICMP are 2 different things. A firewall can be set to block ICMP or allow it. MTU is irrelevant in that case. MTU is set by protocol standards. An ICMP packet on an 802.3 network will have a packet size of 1500 period, unless you have mucked with it. An ICMP packet contained within an 802.11 header will be 2304 bytes (with no encryption). A firewall can also be set to drop fragmented packets but that will screw up communications big time. VPN MTU's sometime have to be tweaked (and therefore TUN packets) due to overhead added to the packets.

RFC 1911 "Path MTU Discovery" http://tools.ietf.org/html/rfc1191, while not an exciting read, covers a lot of this.


For reference:

802.3 packet MTU 1500 bytes
802.11 packet (no encryption) 2304 bytes
802.11 WEP packet 2312 bytes
802.11 WPA TKIP packet 2324 bytes
802.11 WPA2 AES packet 2320

[FrankFruter]

I like your tutorial ,I did change a few things to work with my wireless card.

I removed two lines: ifconfig $IFACE down
airmon-ng start $IFACE

Replaced with two lines: airmon-ng start wifi0
sleep 5

I also commented out Line: ifconfig at0 mtu 1400 ,because windows boxes
(connecting) default mtu is 1500.

Before runing script ath0=1500
eth0=1500
after ath0=1800
eth0=1500
at0=1500
All webs sites work.

Also konsole did not work for me ,changed to xterm.

And removed ettercap line ,i like to run GUI to start /stop filters and
use the connetions tab inject data works well.

ettercap > options > unoffensive
sniff > unified sniffing > at0
start > start sniffing
works great, pass capture,driftnet,urlsnarf,msgsnarf...

[Revelati]

I think you are mixing apples with oranges. MTU and blocking ICMP are 2 different things. A firewall can be set to block ICMP or allow it. MTU is irrelevant in that case. MTU is set by protocol standards. An ICMP packet on an 802.3 network will have a packet size of 1500 period, unless you have mucked with it. An ICMP packet contained within an 802.11 header will be 2304 bytes (with no encryption). A firewall can also be set to drop fragmented packets but that will screw up communications big time. VPN MTU's sometime have to be tweaked (and therefore TUN packets) due to overhead added to the packets.

RFC 1911 "Path MTU Discovery" http://tools.ietf.org/html/rfc1191, while not an exciting read, covers a lot of this.

Sorry Im not sure if I put all this in the right context. Several people when using ALFA cards set to 1400 MTU had problems where clients would connect to the airbase AP and be able to ping/search google.com and a few other sites, but would get black holed when trying to visit yahoo.com and the majority of the internet. Changing the MTU setting on the ALFA and the Tun to 1500 solved this problem.

I understand that ICMP and MTU are completely different, however I saw several references to blocking sites blocking ICMP and causing MTU errors. The only way I could see this happening would be if the correct fragmentation setting for the server you want to connect to piggybacks on the ICMP packet.

I have since tested this a few times on wireshark and sure enough when the MTUs are set to 1400 with my hardware I can use google just fine and visit a few other sites (all of which respond to my pings)

When I try to visit yahoo.com and the majority of the internet I get spammed with (destination unreachable) packets and all my ICMP packets are dropped.

If all ICMP packets are 1500 units in size how could you then ping a server with your hardware set to an MTU below 1500? The only way from my understanding, would be to fragment the packet. Perhaps those sites only drop fragmented ICMP packets?

If you are right however and ICMP and MTU have no connection, then what would cause this strange behavior?


"RFC 1191 describes "Path MTU discovery", a technique for determining the path MTU between two IP hosts. It works by setting the DF (Don't Fragment) option in the IP headers of outgoing packets. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an ICMP "Destination Unreachable (Datagram Too Big)" message containing its MTU, allowing the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU is small enough to traverse the entire path without fragmentation.

Unfortunately, increasing numbers of networks drop ICMP traffic (e.g. to prevent denial-of-service attacks), which prevents path MTU discovery from working. One often detects such blocking in the cases where a connection works for low-volume data but hangs as soon as a host sends a large block of data at a time. For example, with IRC a connecting client might see up to the ping message, but get no response after that. This is because the large set of welcome messages are sent out in packets bigger than the real MTU. Also, in an IP network, the path from the source address to the destination address often gets modified dynamically, in response to various events (load-balancing, congestion, outages, etc.) - this could result in the path MTU changing (sometimes repeatedly) during a transmission, which may introduce further packet drops before the host finds the new safe MTU."

I hate using wikipedia, but I have seen similar information on other sites so I think it is accurate. http://en.wikipedia.org/wiki/Maximum_transmission_unit

[imported_cybrsnpr]

I didn't catch the context that this was going through airbase.

Also, I didn't mean that ICMP itself is 1500 bytes. Sorry if I worded that poorly. ICMP packets are about 64 bytes. The rest of the packet is made up of overhead (SRC/DST IP and MAC) and so on. The full size of the packet depends on the protocol that it is being transmitted through. 1500 bytes for example in an 802.3 (std wired ethernet).

I understand why you would need to decrease your MTU size, since airbase works through a TUN (at0 on my box) which due to something (kernel limitations, overhead or something else) doesn't play well unless you decrease MTU. This (the TUN MTU requirement) is my guess as to why things work with the smaller packet size.

If you are sending these packets through airbase, you need to have the MTU smaller to allow them through the TUN. If they are larger, then I'm not sure they will even make it out to the "interwebs" (at least without being mangled and/or fragmented).

As to why google and some other sites respond to ICMP and yahoo and other don't: Could be many reasons. Maybe yahoo or it's upstream provider reads the MTU size as a fragmented packet and drops it to prevent frag attacks and google's doesn't. I do know that yahoo responds successfully to a standard size ICMP request.

Hope I didn't just totally confuse the crap out of you with these ramblings. Really, at the end of the day, I just think the ICMP weirdness is a result of having to shorten the MTU size to account for the TUN interface.

Thanks for the exercise in "packetry"....my head hurts now ;-)

[Revelati]

Maybe yahoo or it's upstream provider reads the MTU size as a fragmented packet and drops it to prevent frag attacks and google's doesn't.

I think you hit the nail on the head there. Its the only plausible solution that fits the symptoms of the problem.

Hehe, sorry to make your head hurt! Wading through packets is a lot of fun for me. I think I might have been staring at wireshark too much, just like Cypher, instead of ICMP, TCP, UDP, I'm starting to see blond, brunette, redhead.

[imported_cybrsnpr]

I think you hit the nail on the head there. Its the only plausible solution that fits the symptoms of the problem.

Hehe, sorry to make your head hurt!

I found a fix for my head hurting...Beer!

As for the yahoo packet drops...I've been thinking a bit...remember back a couple years ago, they (yahoo) and some other major sites were taken down by a DoS attack. I think that akamai might have been the actual target, but that's neither here nor there. Anyway, it would make sense that to prevent such future occurrences, they would have put some rules in place to prevent this type of attack. Maybe a side effect of those rules are what you are seeing?

Just a thought...

Cheers....

[benzslr123]

lets say someone were to run

airbase-ng "ap" eth0

and then

ifconfig at0 up

and then ettercap, on interface at0

would they get similar results? (minus the rogue ap trying to present itself with other essids)

[imported_cybrsnpr]

lets say someone were to run

airbase-ng "ap" eth0

and then

ifconfig at0 up

and then ettercap, on interface at0

would they get similar results? (minus the rogue ap trying to present itself with other essids)

I don't know that you can run airbase-ng through eth0 (wired side). It's not a wireless interface, so I don't know how the response would be. Can't imagine it would work though.

If you want a similar test of MTU size, try setting up a VPN using openvpn, run your packets through that and see what happens.

[phoenix910]

This is a great thread and a great read - thanks guys. As some of you may have noticed in the past, I was semi-looking for how to do this a few months back, but this kinda answers all my questions. I set everything up, and airodumping my created access point leads me to see that it exists, however, I am yet to actually test if it works; does look promising though - thanks!

~phoenix910