7

Inspired by this question I came up with this weird idea of making what that user actually wants to prevent. So, bear with me for a little bit:

Let's assume that for some reason we could make the traffic sent from a specific application to another to travel to a router/routing device because the source device cannot determine on its own where does it have to send the packet. This means, even names like "localhost" or IPs like 127.0.0.1 does not work for this source device, but it rather has to send everything to another device to send the information its "destination" device (which, we know, it's that same server).

So, simplifying and making it an actual question: is there any way, remotely as it could be, to hijack routing tables/loopback interfaces/whatever it takes to make a machine send it's traffic out when those communications are supposed to be internal?

Think in how many web server do have their databases in there and send "internal" requests for connection with data... TCP services... and how firewalls are configured to block weird traffic in but not so much for traffic out. This made me tick and come and ask this weird question.

Improve this question

4 Answers 4

Reset to default
8

There are lots of speculations, let's try it.

Assigning 127.0.0.1/8 to the network interface

On Debian it works as root to assign 127.0.0.1/8 to the network interface:

# ifconfig lo 10.0.0.1 netmask 255.0.0.0
# ifconfig eth0 127.0.0.2 netmask 255.0.0.0

and results in:

lo        Link encap:Lokale Schleife  
          inet Adresse:10.0.0.1  Maske:255.0.0.0
...
eth0      Link encap:Ethernet  Hardware Adresse 
          inet Adresse:127.0.0.2  Bcast:127.255.255.255  Maske:255.0.0.0
...

ping 127.0.0.1, however, fails with an Illegal Argument error:

 $ ping 127.0.0.2
 PING 127.0.0.2 (127.0.0.2) 56(84) bytes of data.
 64 bytes from 127.0.0.2: icmp_seq=1 ttl=64 time=0.030 ms

 $ ping 127.0.0.1
 connect: Invalid argument

So this is something that needs to be look at in more detail by analyzing the source code.

Pointing "localhost" to another ip-address

Editing /etc/hosts as root so that it points localhost to another ip-address works:

ping localhost
PING localhost (209.85.149.147) 56(84) bytes of data.
64 bytes from localhost (209.85.149.147): icmp_seq=2 ttl=57 time=165 ms

Whether this is an issue or not depends on the situation: The client may send a password without validating the server by either not using ssl or trusting any certificate (There are testing-certificates for localhost out there that are signed by trusted CAs). This password might be reused elsewhere or the server may accepting connections from other interfaces because it is password protected anyway.

In the standard configuration the host file has precedence over NIS and DNS, which requires local root access and makes this kind of attack pointless. But if the priority was changed, this is exploitable using the DNS or NIS servers.

Improve this answer
3

I believe you would need to compromise the kernel to do this (of course, if you can compromise the kernel, you can do anything). I just did some testing with IPTables and it appears that loopback traffic bypasses the NAT / PREROUTING capabilities, so I think it's out of userspace control (in Linux). OSes will vary, of course, but I think in general you do need to compromise the kernel to do what you want to do.

Improve this answer
3
  • No need to compromise the kernel, write access to /etc/hosts is enough.
    – tdammers
    Commented Aug 19, 2011 at 21:19
  • Cool! How do I map 127.0.0.1 to 13.246.76.26 with /etc/hosts? Oh, wait, I can't. I think the question as asked is somewhat wider than something as simplistic as poisoning name resolution.
    – gowenfawr
    Commented Aug 19, 2011 at 21:54
  • nat and PREROUTING is only used for routing, this means traffic from the local machine to the local machine isn never filtered there. try the mangle table to intercept local packets.
    – allo
    Commented Apr 19, 2018 at 11:21
1

It's an assumption, but I would think that most networking stacks in OS's would bypass the external interfaces in localhost requests. Certainly for security reasons, but moreso for performance reasons.

Improve this answer
1
  • This is incorrect. For the OS, the loopback interface is a virtual interface called lo. The localhost host and the 127.0.0.1 address are not handled in any special way by the kernel. Only the loopback interface itself is. Typically, localhost is made to resolve to 127.0.0.1 which in turn is assigned to the kernel-managed loopback interface.
    – forest
    Commented Mar 7, 2018 at 11:13
1

In no way unless having some serious mistake in the networking code which can be triggered remotely but this bug as well can make the host unable to intercommunicate at all → Low probability for success. Moreover, it's too complicated comparing to another types of attacks, so it's nearly not realistic.

Improve this answer
2
  • 1
    The problem is that 'too complicated' has been proven to not put off attackers, in fact it encourages some groups. No matter how many times you'd expect attackers to go for low hanging fruit, some will research the weirdest routes, so the only logical advice is to at least review them, no matter how complicated.
    – Rory Alsop ♦
    Commented Sep 2, 2011 at 9:30
  • That's not a problem since not labeling "too complicated" puts off but "complexity" instead.
    – poige
    Commented Sep 2, 2011 at 14:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .