Closed D3adP3nguin closed 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.
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?
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?
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
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
.
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".
Also when testing using the sanity check I don't see the payload test_ping_icmp
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' |>>>>>>>
so a few follow-up questions then:
test_ping_icmp
in the reply/request pings what does that mean? (Vulnerable or NOT)test_ping_icmp
what does that mean? (Vulnerable or NOT)test_ping_icmp
what does that mean (I assume that means the test failed and the device is not vulnerable)test_ping_icmp
what does that mean?Thank you for the continued help and support. I truly appreciate it.
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
- 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
- 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.
- 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.
- 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.
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.
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
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?
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.
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.
Closing this for now. You can re-open if this becomes an issue again.
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.