vanhoefm / fragattacks

Other
1.24k stars 185 forks source link

UpStream Connection #20

Closed D3adP3nguin closed 3 years ago

D3adP3nguin commented 3 years ago

Good afternoon. I have been testing a Range Extender and I have noticed MAJOR differences in results depending on the router that is providing the range extender internet access. SO the question would be is it possible when testing a range extender, if the upstream router can impact the testing. Based on what I am seeing with my results there is a DRASTIC change depending on the device providing the Range Extender its internet capabilities.

vanhoefm commented 3 years ago

A range extender will typically decrypt the traffic it receives and then again re-encrypt it when forwarding traffic to the final destination. So when you're connecting to a range extender you are testing the range extender itself. This implies that when using a different range extender you'll indeed get every different results.

D3adP3nguin commented 3 years ago

However, when testing the same EXACT range extender but using different APs (to provide the same Range Extender Internet) the results are drastically different. Why would that be?

vanhoefm commented 3 years ago

I haven't tested range extenders so I don't know. Which range extender are you using? Can you make a Wireshark capture while executing a test that shows different results?

D3adP3nguin commented 3 years ago

The RE7350( aka RE) to MR7500 shows EVERY ping CMD has a ping request and reply; While the RE7350 to EA8300 does not have a single ping request or reply. When testing the MR7500 (without the RE) it has the same vulnerable results. When testing the EA8300 by itself (without the RE) it has no vulnerable CMDs. RE7350_2_MR7500.zip RE7350_2_EA8300.zip

vanhoefm commented 3 years ago

How do you determine that a test succeeded? This should be done based on the output of the tool.

The captures in RE7350_2_MR7500.zip contain no IPv4 ping responses (which is the default ping request that most commands will inject). But again, determining whether a test succeeded should be done based on the output of the tool. In wireshark, at least for most test, you should see an IPv4 ping response with as payload test_ping_icmp.

D3adP3nguin commented 3 years ago

The ICMPv6 pings are only for that device. I believe it is because it is a 6E device. I determine whether a device is vulnerable or not based on if a client of the AP gets a reply and request ping from the test.

The output of most of the tests says please check manually. I assumed "check manually" refers to check the pcap for pings. In fact it says check tcpdump in the notes for some of the same tests that say "check manually".

D3adP3nguin commented 3 years ago

Also when testing using the sanity check I don't see the payload test_ping_icmp

vanhoefm commented 3 years ago

The tests don't send ICMPv6 pings. You shouldn't look at ICMPv6 pings. The result of most tests is determined automatically. You should look at the example captures to see how to inspect manual captures.

If the sanity check doesn't include the test_ping_icmp you're looking at the wrong place. It's included:

[02:15:02] Using key 42221630a7f4b74dc442bd12abcc8162 to encrypt <Dot11 subtype=8 type=Data FCfield=to-DS addr1=38:2c:4a:c1:69:bc addr2=64:70:02:2f:d7:67 addr3=38:2c:4a:c1:69:bc SC=320 |<Dot11QoS TID=2 |<LLC dsap=0xaa ssap=0xaa ctrl=3 |<SNAP code=IPv4 |<IP frag=0 proto=icmp src=192.168.1.220 dst=192.168.1.1 |<ICMP |<Raw load='test_ping_icmp' |>>>>>>>

D3adP3nguin commented 3 years ago

so a few follow-up questions then:

  1. if the output of the cli tool says 'SUCCEEDED' but there is no payload test_ping_icmp in the reply/request pings what does that mean? (Vulnerable or NOT)
  2. if the output of the cli tool says 'please check manually' and there is a ping reply/request but doesn't have the payload test_ping_icmp what does that mean? (Vulnerable or NOT)
  3. if the output of the cli tools says 'All frames sent. You must manually check' and there is NOT a ping reply/request WITHOUT the payload test_ping_icmp what does that mean (I assume that means the test failed and the device is not vulnerable)
  4. Same as above BUT there IS a ping reply/request WITHOUT the payload test_ping_icmp what does that mean?

Thank you for the continued help and support. I truly appreciate it.

D3adP3nguin commented 3 years ago

Also, let me give you a run down of my setup:

I'm using the provided live image USB as the test machine. I have a kali machine as one of the clients that is the main device I'm using to sniff the ICMP packets I also have a 2nd mac machine being used as a client to sniff for the ICMP packets

vanhoefm commented 3 years ago
  1. if the output of the cli tool says 'SUCCEEDED' but there is no payload test_ping_icmp in the reply/request pings what does that mean? (Vulnerable or NOT)

That shouldn't happen. I think you're somehow missing the ping reply. Right before "SUCCEEDED" it will show the received packet, which should in all tests end on test_ping_icmp, for example:

[02:15:02] Received packet: <Ether  dst=64:70:02:2f:d7:67 src=38:2c:4a:c1:69:bc type=IPv4 |<IP  version=4 ihl=5 tos=0x0 len=42 id=42104 flags= frag=0 ttl=64 proto=icmp chksum=0x522d src=192.168.1.1 dst=192.168.1.220 |<ICMP  type=echo-reply code=0 chksum=0x1114 id=0x0 seq=0x0 |<Raw  load='test_ping_icmp' |>>>>
[02:15:02] >>> TEST COMPLETED SUCCESSFULLY
  1. if the output of the cli tool says 'please check manually' and there is a ping reply/request but doesn't have the payload test_ping_icmp what does that mean? (Vulnerable or NOT)

Note that for manual checks, you have to run the sniffer on the device being tested (so on the repeater or router in your case). It's vulnerable if the ping request is received and contains test_ping_icmp. In manual tests, ping responses don't matter.

If there is no test_ping_icmp in the payload it's an unrelated frame. Ignore those frames.

  1. if the output of the cli tools says 'All frames sent. You must manually check' and there is NOT a ping reply/request WITHOUT the payload test_ping_icmp what does that mean (I assume that means the test failed and the device is not vulnerable)

If there is no ping request with test_ping_icmp on the device being tested, it isn't vulnerable.

  1. Same as above BUT there IS a ping reply/request WITHOUT the payload test_ping_icmp what does that mean?

That would mean someone else is sending ping requests. You should ignore those unrelated ping requests.

I hope that helps.

D3adP3nguin commented 3 years ago

That helps a lot. For the time being, I'll close this issue. If I notice some problems or any discrepancies ill be sure to reopen and ask about it. Thank you and have a wonderful rest of your day.

D3adP3nguin commented 3 years ago

Ok so I decided to use Port Mirroring (using a Linksys switch)

I have the Destination Port (Select the analyzer port to where packets are to be copied.) as the kali machine to do the sniffing. and then I have the Source Port (Select the source port of the traffic to be mirrored.) as the AP being tested. With this setup do you think ill be able to capture the required ICMP packets

D3adP3nguin commented 3 years ago

So with this setup when I get a console on the router I am able to see the ping request being made (example.com's IP) and I can also see the HTTP request (curl http://example.com) from the router to the internet. now being able to see these, can I now to continue testing using your tool? And if so I should be able to see the Vulnerable ping requests. The thing is when I use the command ./fragattack.py wlan0mon ping I,E,E --inc-pn 2 --bcast-dst it tells me succeeded but I'm not getting any ICMP request/reply let alone the ICMP payload. Am I using the wrong flag or is there something else you can think of?

D3adP3nguin commented 3 years ago

Unfortunately, I have run into the problem where the test for amsdu-inject / ping I,E,E --inc-pn 2 / ping I,E --amsdu / ping D,BP --bcast-ra said SUCCESSFUL but I can't see the ICMP payload. I am able to see the ICMP payloads for the sanity checks so thats good.

vanhoefm commented 3 years ago

I'm not sure why that's happening. Can you send the test tool output and the packet capture for "ping I,E,E" and for "amsdu-inject"? Then I can try to compare them.

vanhoefm commented 3 years ago

Closing this for now. You can re-open if this becomes an issue again.