Imagine this scenario: Alice has a private subnet (192.168.1.0/24) connected to a router which is also connected to local network B. Alice's router performs NAT (only using MASQUERADE; outbound traffic will have the router as its source address), but there is no port forwarding or additional firewalling. Mallory's computer is also connected to network B and knows about Alice's configuration.

If Mallory adds a route to her computer (i.e. 192.168.1.0/24 via Alice's router), she is able to run nmap scans of Alice's internal network since Alice's router will happily forward the traffic to the internal subnet.

Dave is on a remote network (one or more hops away) and knows about Alice's configuration. However, none of the intermediate routers between Dave and Alice's router know of the route to her internal subnet (since it is a private range, network infrastructure may be configured to drop it anyway, but let's ignore that for now), so it cannot be scanned in the same way Mallory did.

Given the exact scenario above and no other assumptions, is there any way for Dave to scan Alice's internal network or otherwise abuse this configuration even though the routing doesn't work out?

Edit: The "router" in this example would be a *nix machine configured with net.ipv4.ip_forward=1. The question is based on a configuration I have observed and tested.

  • 2
    There is source routing which might theoretically get round this, but it probably wouldn't work in practice – paj28 Apr 14 '16 at 18:55

Since the routers between Dave and Alice's devices will not forward the packets, there is no way to talk directly to them so they are in a sense "Secure". There is no direct way to contact the devices, unless you can spearphish Mallory. However there are ways to pester them, which can possibly be exploited by a determined attacker.

Spoofing the source IP (to look like one of Alices devices) and sending a packet to a device that knows about and has access to Alice's devices, like Alice's router, or Mallory's computer will cause the recipient to reply thinking it was one of Alice's devices that sent them the packet. Since they know the way back, they will respond in kind (depending on what services are available and how the OS is configured.) If services are available, this would allow for abuse like an amplification attack (see DNS and NTP amplification for more info) toward Alice's devices, and there are probably other possible ways to meddle.

... a router without a firewall ... using MASQUERADE

Masquerading is not a routing functionality because it changes the source of the packet. Instead you actually need a stateful firewall to do the masquerading. Which means that if masquerading is involved you must also have a firewall there. This of course says nothing about the configuration of the firewall, but it contradicts your assumption that you have a router without firewall.

... since Alice's router will happily forward

Since the router/firewall is doing MASQUERADE for traffic from inside (Alice private network) to outside (i.e. network B and further) it can only forward traffic from outside to inside for which an active NAT rule exists. Any packets from outside for which no such rule exists will be discarded. Thus no happy forwarding will be done and no forwarding will be possible.

In theory you could probably define rules where packets from a specific subnet will not go through the NAT but go directly into the other network but this would be some unusual non-standard configuration.

  • This assumes that net.ipv4.ip_forward is set to 0 (further extrapolating that we are talking about Linux/*bsd since Masquerade is unique to it). Since he explains that Mallory can see Alice's devices, it must be set to 1. – Jeff Meden Apr 14 '16 at 18:13
  • @JeffMeden: Yes, I'm assuming that a device which uses masquerading (which is no longer a simple router in the classical meaning because it changes the packets and not only routes these) will not simply forward packets from outside which are directly addressed to the internal network. This is what you actually have in practice. – Steffen Ullrich Apr 14 '16 at 18:34
  • Turning on Masquerade doesn't automatically stop the kernel from forwarding packets, though. If you further configure iptables to drop inbound packets destined for the masqueraded group it will, but his explanation suggests that this was not done. – Jeff Meden Apr 14 '16 at 18:40
  • @JeffMeden: yes, you need iptables. Which gets me back to my edited response which questions your assumption of having a router without firewall but doing masquerading. The masquerading functionality must be done by a stateful packetfilter, which is a firewall. – Steffen Ullrich Apr 14 '16 at 18:49
  • Agreed that it's more likely to be set up right than wrong (given how many documents are available) its still completely possible to have outbound traffic running through masq (changing the source ip and adding the connection info to the stateful connection engine) but inbound traffic not stopped (forwarding it to the internal host unperturbed since masq specifically only cares about inbound traffic headed for its own IP). Just covering all the bases. – Jeff Meden Apr 14 '16 at 19:18

Whole situation eventually can be dropped to one factor - whether can Dave find a way to transfer a packet to Alice's router (or network) with Alice's PC destination address in IP header.

You answered by yourself that with the plain OSI Layer 3 routing this cannot be done - any intermediate L3 host will drop this packet. There's no way to overcome this behavior performing any source/destination changes, adding headers or doing similar operations while other side makes plain routing.

But to achieve desired any sort or tunneling can be used - in other words when one IP header is hidden inside the packet and another IP header is used during routing on intermediate L3 hosts. Here it is necessary that Alice's side has any programming logic, which can de-capsulize this packet.

  • To perform some sort of tunneling with Alice's router directly - there must be according service running on router itself, trusting Dave's packet.

    If Dave find such and understand how to compromise it (using something similar as: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20060906-gre), then access to local network can be possible.

    Any of vulnerable or improperly configured (without authentciation) tunneling service can be used - GRE, PPTP, L2TP, IPSec, EoIP etc.

  • Other way - if there's any compromised host that has L2 connectivity to Alice's router (f.e. host in network B, Alice's network itself or any other network that Alice's router is linked to).

    Then packet destined to Alice's PC can be routed via SSH (using -L/-R/-D flags, look: https://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/) or any other allowed service's tunnel (HTTP/DNS, even ICMP etc.) to that host.

    Intermediate L3 hosts will see masqueraded address of Alice's router, as connection was made from compromised host to Dave's public address, then packet is de-capsulized by compromised host and sent to 192.168.1.0/24 network via Alice's router as a gateway.

    Such host can be a hacked Web server, user running .exe from untrusted sources etc. To achieve such functionality there's enough even limited access rights on machine.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.