Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
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 Sep 2 '11 at 9:30
    
That's not a problem since not labeling "too complicated" puts off but "complexity" instead. –  poige Sep 2 '11 at 14:44

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.

share|improve this answer
    
No need to compromise the kernel, write access to /etc/hosts is enough. –  tdammers Aug 19 '11 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 Aug 19 '11 at 21:54

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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