LinuxQuestions.org - can 127.0.0.1 be spoofed ?

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - can 127.0.0.1 be spoofed ? (https://www.linuxquestions.org/questions/linux-security-4/can-127-0-0-1-be-spoofed-687743/)

can 127.0.0.1 be spoofed ?

Hi,

I've been searching the web on this argument but all it talks about is UDP. I have no doubt that a UDP packet can have a fake localhost source address. But what happens with TCP? I think a SYN packet can arrive with a fake localhost source address, but then the SYN ACK will be sent to localhost and never received by the attacker. Am I right?

If I write a servlet that checks wether the remote address is 127.0.0.1, would it be vulnerable?

Quote:

Originally Posted by irey (Post 3361875)

The ARP table for Linux does not have the lo interface entry and hence it will not allow you to spoof the entry for "lo" interface (lo is the internal loopback interface, which is virtual).

Rahul Khare.

You're right about the ARP table observation, but IP spoofing can be done even without ARP poisoning.

Well, I can tell you this much at least: If I spoof a SYN packet with source IP 127.0.0.1 sending it from my laptop to my desktop via Wi-Fi, I can see the packet arrive at my desktop (using tcpdump). I can NOT, however, log the packet with Netfilter/iptables on the desktop for some reason. EDIT: I'll check if I can see the any ACK get generated on the desktop when I get back, gotta go out to take care of something. Will be back later today.

Okay I was able to look at this a bit more. I don't really have much new information to share, though. I can confirm that the spoofed packet (source address 127.0.0.1) isn't causing a SYN/ACK to be generated on the target machine. I checked the NIC and loopback on the target using tcpdump. The spoofed packet is clearly visible to tcpdump on the target machine, yet it doesn't show-up in the iptables logs. Can anyone shed some light as to what is happening to the spoofed packet? Why doesn't it reach Netfilter? Why doesn't it generate a SYN/ACK?

FWIW, the target machine I tested with is running Linux 2.6.22.

Quote:

Originally Posted by irey (Post 3361875)

then the SYN ACK will be sent to localhost [...] Am I right?

I don't have the complete picture yet, but (as you can see above) my tests show the answer to this question is: NO.

I'm not surprised. It appears that the IP layer is smart enough to realise that the packet is spoofed since obviously the localhost address shouldn't be received on eth0 or any interface other than lo. Maybe tcpdump is working on the ethernet layer so it sees the packet before it is discarded.

Anyway your reply shows that it is secure. If the SYN ACK hasn't been generated then the connection hasn't beene stablished and any following packets will be discarded.

I was fearing that a potential attacker could send the SYN, ignore the never-received-SYN-ACK and finally send an ACK and a HTTP request. Since the connection hasn't been established, his attack won't work.

I don't know how you tested it, but I don't want to learn. :D Thanks for your reply.

Some internet searching showed me that your test fake packet was detected by the "reverse path filtering", a kernel feature that drops packets received on a wrong interface. It may be configured through some sysctl variables:

net.ipv4.conf.default.rp_filter
net.ipv4.conf.all.rp_filter

Maybe that's the light you were asking for :).

Quote:

Originally Posted by irey (Post 3362761)

Actually, I made sure rp_filter was disabled before doing my test. I was thinking I'd activate it if the test failed.

BTW, I think I might as well post the tcpdump output (from the target machine) of my test.

Throwing a single SYN packet at a Squid daemon:

Using real source:

Code:

12:43:30.818075 IP (tos 0x0, ttl 64, id 51213, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.100.2186 > 192.168.1.101.3128: S, cksum 0x3f3f (correct), 1779957662:1779957662(0) win 512

12:43:30.818634 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.1.101.3128 > 192.168.1.100.2186: S, cksum 0x58da (correct), 3277349504:3277349504(0) ack 1779957663 win 5840 <mss 1460>

12:43:30.822229 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.100.2186 > 192.168.1.101.3128: R, cksum 0xad4d (correct), 1779957663:1779957663(0) win 0

Using spoofed source:

Code:

12:46:35.375545 IP (tos 0x0, ttl 64, id 49844, offset 0, flags [none], proto TCP (6), length 40) 127.0.0.1.1103 > 192.168.1.101.3128: S, cksum 0xabe8 (correct), 1607516672:1607516672(0) win 512

Throwing a single SYN packet at a port with nothing listening:

Using real source:

Code:

13:22:22.830001 IP (tos 0x0, ttl 64, id 23168, offset 0, flags [none], proto TCP (6), length 40) 192.168.1.100.2073 > 192.168.1.101.666: S, cksum 0x50cb (correct), 256065977:256065977(0) win 512

13:22:22.830322 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.101.666 > 192.168.1.100.2073: R, cksum 0xd006 (correct), 0:0(0) ack 256065978 win 0

Using spoofed source:

Code:

13:25:37.088693 IP (tos 0x0, ttl 64, id 36207, offset 0, flags [none], proto TCP (6), length 40) 127.0.0.1.1602 > 192.168.1.101.666: S, cksum 0xfb25 (correct), 555859947:555859947(0) win 512

Alright, I took a look at the kernel sources.

Code:

net/ipv4/route.c:1769



if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))

    goto martian_source;

This is ip_route_input_slow(), which is called after a packet is received. There is also a comment at the beggining of this function saying that spoofing attacks are prevented here (I guess the rp_filter stuff applies to external IP addresses only, not 127.0.0.1).

By taking a look at the martian_source tag I see that the strange packet may be logged at warning level. However you may not see it in your kernel logs since it depends on many conditions, including kernel config.

Now I feel more than safe that my servlet won't be called from the outside world. Thanks!

Hi there. Just following up on this (sorry for the delay).

Based on your previous post, I enabled martian logging and re-tested.

To enable martian logging I did a (on the target):

Code:

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

The spoofed packet now gets logged (regardless of whether the port it hits has something listening on it or not).

This is what /var/log/syslog looks like upon packet arrival:

Code:

Dec  8 20:18:12 labrat kernel: [ 2449.241998] martian source 192.168.1.101 from 127.0.0.1, on dev eth0

Dec  8 20:18:12 labrat kernel: [ 2449.242011] ll header: 03:0E:94:bc:8c:03:03:e8:e5:b3:c8:bf:08:00

So I confirm Linux seems to properly deal with spoofed packets having a 127.0.0.1 source address.

That's cool! You're right about win32, we'd never be able to find out our answers from the source in this way.

Thanks again.