-
Notifications
You must be signed in to change notification settings - Fork 82
nmap (libpcap) fails to work on 802.1X #16
Description
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!