Closed RoganDawes closed 5 years ago
Hi @RoganDawes Thanks for contributing. One of the key feature of PhanTap is the autoconfiguration IMO. I agree best candidate to talk to the victim is the gateway, but you only find the gateway IP in DHCP (if used), ARP packets and maybe some multicast. What we could do once we have the gateway MAC is to wait for phantap-learn to detect the association gateway MAC/IP, by just polling the neighbor table, not really hard, but to be done ;) (PhanTap is a WIP) BTW I don't understand why they are doing SNAT on tcp/udp/icmp separetly, and not just on all protocols
I think there is a fairly easy approach:
Reject any packets sent to the victim before you have identified an upstream target.
Once you have identified an upstream partner, via whatever means, enable masquerading as that device.
Algorithms could include just using any upstream IP that is already talking to the victim.
Thinking about it, you are absolutely right. No point in specifying the protocols individually! I’ll fix that in my shell script.
Rogan
On Fri, 02 Aug 2019 at 17:32 champtar notifications@github.com wrote:
Hi @RoganDawes https://github.com/RoganDawes Thanks for contributing. One of the key feature of PhanTap is the autoconfiguration IMO. I agree best candidate to talk to the victim is the gateway, but you only find the gateway IP in DHCP (if used), ARP packets and maybe some multicast. What we could do once we have the gateway MAC is to wait for phantap-learn to detect the association gateway MAC/IP, by just polling the neighbor table, not really hard, but to be done ;) (PhanTap is a WIP) BTW I don't understand why they are doing SNAT on tcp/udp/icmp separetly, and not just on all protocols
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nccgroup/phantap/issues/3?email_source=notifications&email_token=AABHBC7S5O2O2EANIE3TD3DQCRHRNA5CNFSM4II3GUS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OCWFQ#issuecomment-517745430, or mute the thread https://github.com/notifications/unsubscribe-auth/AABHBC4QESYEBBA5LVVEX73QCRHRNANCNFSM4II3GUSQ .
One thing I think you are missing is that you don't seem to care which physical interface the victim is connected to. Obviously the bridge is getting packets from both interfaces of the bridge, so you can't really tell which packets belong to the victim, and which are on the upstream network.
If you require that the user configure both the bridge interface name, and the individual interface which is directly connected to the victim, you don't have to make assumptions about which IP address ranges are valid and which are not. i.e. limitations to non-RFC1918 addresses, etc.
e.g. on my router, "WAN" is eth0.2
, so doing the tcpdump -Q in -i eth0.2
allows you to reliably discriminate traffic from the victim vs any other traffic on the network.
Alternatively, the WAN
interface can be extracted from /etc/board.json
, in the roles
object. So if the user configures nothing, you could assume that they connected WAN to upstream, and LAN to victim, and work from there.
Hi @RoganDawes,
Even if we know that the victim is connected to lan, and the upstream connected to wan, we still need to make assumptions as to when the victim is talking to a machine outside of this network via the gateway to get the gateway info.
I'm working on DHCP support, which will remove all assumptions (if the victim uses DHCP of course) and allow dynamic reconfiguration, stay tuned ;)
To be precise, you don’t have to assume the identity of the gateway at all. Just any other machine on the network. Choosing one that the victim is already talking to might even be better than the gateway, in fact!
On Mon, 05 Aug 2019 at 07:38 champtar notifications@github.com wrote:
Hi @RoganDawes https://github.com/RoganDawes,
Even if we know that the victim is connected to lan, and the upstream connected to wan, we still need to make assumptions as to when the victim is talking to a machine outside of this network via the gateway to get the gateway info.
I'm working on DHCP support, which will remove all assumptions (if the victim uses DHCP of course) and allow dynamic reconfiguration, stay tuned ;)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nccgroup/phantap/issues/3?email_source=notifications&email_token=AABHBC5AFUVMIOR44MRYLOLQC64GBA5CNFSM4II3GUS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QXPFI#issuecomment-518092693, or mute the thread https://github.com/notifications/unsubscribe-auth/AABHBCYFGZQJCIPWN473DEDQC64GBANCNFSM4II3GUSQ .
I totally agree that we can pick another candidate to talk to the victim, but the goal of phantap is first to get internet access so that the vpn of your choice can give you a connection back to the device, and for that we need to guess the local gateway anyway. Adding dedicated victim/network ports doesn't help that much (if at all), so I prefer to kept it simple, ie just plug and it work.
Ah, you see, there is the difference between what you are building with phantap, and the objectives with slimshim, etc.
I'm not trying to get access to the device via the existing victim's network. I access my router via e.g. WiFi or GSM, and restrict access to the client network itself.
@champtar Did you ever get around handling DHCP et al? I'm also interested on being able to properly talk to the 'victim' host. I'm working on some enhancements like dedicated sniffing tools for specific protocols, focusing on low memory footprint.
We are currently continuously learning devices via DHCP, and we can talk to the victim. When talking to the victim we do so as the gateway, see the latest Readme (https://github.com/nccgroup/phantap/blob/master/README.md).
Following the lead of https://github.com/mtkirby/slimshim, I extracted just the relevant iptables commands required to implement a complete invisible man in the middle, that allows you to talk to both the intercepted victim as well as the rest of the network. The key is to choose a device seen on the "network" side of the tap to impersonate. Slimshim chooses the router by default, but obviously this can be customised as desired.
The shell script I use can be found here: https://sensepost.com/blog/2018/mallet-in-the-middle/
The important lines are these:
Where
169.254.0.1
is the IP address assigned to the mitm device, and0:1:1:1:1:1
is its MAC address.