Page 4 of 14 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 137

Thread: Rogue Accesspoint + MitM Sniffing tutorial

  1. #31
    Member
    Join Date
    Jun 2008
    Posts
    101

    Default

    Quote Originally Posted by Revelati View Post
    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?
    QuadCore AMD Phenon X4 9950, 2600 MHz
    8GB DDR2 800MHz
    Dual Boot System: Windows Server 2008 x64 w/ Hyper-V, Ubuntu 9.10 x64

  2. #32

    Default

    Quote Originally Posted by Revelati View Post
    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

  3. #33
    Junior Member FrankFruter's Avatar
    Join Date
    Dec 2008
    Posts
    29

    Default

    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...

  4. #34
    Member
    Join Date
    Sep 2008
    Posts
    146

    Default

    Quote Originally Posted by cybrsnpr View Post
    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
    Morpheus: "You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."

    Neo: "What if I take both?"

    Morpheus: "Don't do that! You end up like Nick Nolte!"

  5. #35

    Default

    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 ;-)

  6. #36
    Member
    Join Date
    Sep 2008
    Posts
    146

    Default

    Quote Originally Posted by cybrsnpr View Post
    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.
    Morpheus: "You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."

    Neo: "What if I take both?"

    Morpheus: "Don't do that! You end up like Nick Nolte!"

  7. #37

    Default

    Quote Originally Posted by Revelati View Post
    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....

  8. #38
    Junior Member
    Join Date
    Sep 2008
    Posts
    85

    Default

    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)
    patience is appreciated =]

  9. #39

    Default

    Quote Originally Posted by benzslr123 View Post
    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.

  10. #40

    Default

    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

Page 4 of 14 FirstFirst ... 23456 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •