search

nccgroup / phantap

Phantom Tap (PhanTap) - an ‘invisible’ network tap aimed at red teams
GNU General Public License v3.0
572 stars 75 forks source link

nmap (libpcap) fails to work on 802.1X #16

Open konstantingoretzki opened 1 year ago

konstantingoretzki commented 1 year ago

Hey there,

not sure if this is the right place to ask but I am kind of out of ideas.

If I place the implant using phantap between a supplicant and the 802.1X-capable switch I can not successfully scan other devices in the network (connected with the switch) using nmap. Even if I skip the host detection there aren't any results. Other tools like ping or wget work flawlessly so I can definitely reach the devices. Interestingly I do get results if I scan unprivileged so I expect that this is related to the way libpcap works?

I also have an instance of silentbridge with the interaction-mode working that works perfectly. The implementation of silentbridge is very similar, but one key difference is that it is using [ip,eb]tables. This brings me to the point that I assume this is due to the firewall settings. Maybe this is related due to the missing MAC SNAT feature that ebtables has?

I tried scanning using nmap <IPv4> and nmap -PE <IPv4>. Adding the (bridge) interface as an option does not help. Temporarily enabling ARP support for the bridge interface does not help either. My tcpdump-PCAPs show that the packets get send and received, but nmap seems to not react.

I've compared silentbridge and phantap using tcpdump on the interfaces (br-phantap / br0 for the implant and eth0 one of the scanned device). On the bridge-interface of both implementations the original (SRC) MAC address was still in use while the SRC IPv4 address was already spoofed for send packets. The recording on the interface of the scanned device shows that the SRC MAC address was replaced to the victim / supplicant MAC. Received packets on the bridge-interface both have the bridge-MAC-address as the DST MAC address. However one difference was that on the bridge-interface received packets on phantap still used the spoofed IPv4 address while on silentbridge this address was already replaced with the IPv4 address of the bridge-interface (169.254.X.Y). Maybe this is the reason why libpcap and therefore nmap has problems interpreting the answer?

If I add the parameters -S <IPv4> in order to spoof the source IP address and add the interface using -e <interface> in nmap then the scan seems to work. However I do not get why this is needed. Besides this also leaks the bridge-interface IP address ...

I've also tried adjusting the nftables-rules - without any luck. E.g. I wasn't able to change the priority of the IP-NAT-rule. Also removing the nftable-rules for interacting with the victim / supplicant haven't helped. I also thought it might be related to a bug in nmap or libpcap, so I tried to downgrade the versions using:

opkg install http://downloads.openwrt.org/releases/21.02.5/packages/mips_24kc/base/libpcap1_1.9.1-3.1_mips_24kc.ipk
opkg install http://downloads.openwrt.org/releases/21.02.1/packages/mips_24kc/packages/nmap_7.80-3_mips_24kc.ipk

However the problems persisted even with older version of nmap or libpcap.

Is this all due to the fact that nftables are used and they behave differently? Or could there be another reason for this to fail? Has anybody also noticed this behavior and is there a way to fix this? Thank you!

champtar commented 1 year ago

Hi @konstantingoretzki I don't remember what silentbridge does. Phantap relies on Linux connection tracking + nat to spoof the victim (or gateway) and to get the responses back. Normally raw socket get the packets before nftables/iptables and inject it after, but as we are using a bridge we might see the packets in the bridge table, to be tested.