nccgroup / phantap

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

Support talking to the intercepted victim as well #3

Closed RoganDawes closed 5 years ago

RoganDawes commented 5 years ago

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:

# Any packets sent to anyone other than the victim appear to come from the victim MAC
ebtables -t nat -A POSTROUTING -s 0:1:1:1:1:1 ! -d $victim_mac -j snat --to-source $victim_mac
# Any packets to anyone other than the victim appear to come from the victim IP address
iptables -t nat -A POSTROUTING -p tcp -s 169.254.0.1 ! -d $victim_ip -j SNAT --to $victim_ip:27000-32000
iptables -t nat -A POSTROUTING -p udp -s 169.254.0.1 ! -d $victim_ip -j SNAT --to $victim_ip:27000-32000
iptables -t nat -A POSTROUTING -p icmp -s 169.254.0.1 ! -d $victim_ip -j SNAT --to $victim_ip

# Any packets sent to the victim appear to come from the router MAC
ebtables -t nat -A POSTROUTING -s 0:1:1:1:1:1 -d $victim_mac -j snat --to-source $router_mac
# Any packets to the victim appear to come from the router IP address
iptables -t nat -A POSTROUTING -p tcp -s 169.254.0.1 -d $victim_ip -j SNAT --to $router_ip:27000-32000
iptables -t nat -A POSTROUTING -p udp -s 169.254.0.1 -d $victim_ip -j SNAT --to $router_ip:27000-32000
iptables -t nat -A POSTROUTING -p icmp -s 169.254.0.1 -d $victim_ip -j SNAT --to $router_ip

Where 169.254.0.1 is the IP address assigned to the mitm device, and 0:1:1:1:1:1 is its MAC address.

champtar commented 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

RoganDawes commented 5 years ago

I think there is a fairly easy approach:

  1. Reject any packets sent to the victim before you have identified an upstream target.

  2. 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 .

RoganDawes commented 5 years ago

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.

RoganDawes commented 5 years ago

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.

champtar commented 5 years ago

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 ;)

RoganDawes commented 5 years ago

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 .

champtar commented 5 years ago

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.

RoganDawes commented 5 years ago

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.

ghost commented 4 years ago

@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.

Bloup1net commented 4 years ago

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).