Date: Wed, 2 Jul 2003 19:25:56 +0200
From: Ed3f <ed3f@overminder.com.>
To: [email protected]Subject: OpenBSD PF :: "rdr" information leakage
************************ SECURITY ALERT ************************
Systems Affected
OpenBSD PF 3.x
Risk
low
Overview
Depending on the scenario an attacker could
discover the private IP and/or port number where
packets are redirected to by PF.
Description
Using a packet filter to redirect incoming traffic from
standard ports to higher and not-privileged port is
used to reduce security risks.
However, this could be used by an attacker to get
information on the local LAN configuration across the
firewall itself.
Scenario:
Server(10.0.0.2)---(10.0.0.1)[rl0]{PF}[rl1](1.2.3.4)---Attacker
#1 case:
...
rdr on rl1 proto tcp from any to 1.2.3.4 port 25 -> 10.0.0.2
...
pass in on rl1 inet proto tcp from any to 10.0.0.2 port 25
...
Bruteforcing every possible reserved IP is enough to get
the real server IP. Simply generating one SYN to port 25
for each IP, we'll get a reply only for the correct IP.
The rest of the traffic is dropped or resetted by PF.
Can find also multiple/load-balanced IPs.
[ # nmap -sS -P0 -n -T 4 -p 25 10.0.0.0/8 ]
#2 case:
...
rdr on rl1 proto tcp from any to 1.2.3.4 port 25 -> 10.0.0.2 port 8025
...
pass in on rl1 inet proto tcp from any to 10.0.0.2 port 8025
...
Longer, but not impossible.
If there are two changes (IP and port) we have a lot of
combinations to test... however we can reduce them to
classical 8080, 8025, and so on...
The rest of the traffic is dropped or resetted by PF.
[ # nmap -sS -P0 -n -T 4 -p 25,8025,1025,2500 10.0.0.0/8 ]
#3 case:
...
rdr on rl1 proto tcp from any to any port 25 -> 10.0.0.2
...
pass in on rl1 inet proto tcp from any to 10.0.0.2 port 25
...
We get a SYN+ACK for every SYN, no matter which dst IP
we chose. Note that this behaviour must be known by the
local IDS sensor to avoid confusion.
#4 case:
...
rdr on rl1 proto tcp from any to any port 25 -> 10.0.0.2 port 8025
...
pass in on rl1 inet proto tcp from any to 10.0.0.2 port 8025
...
Longer, but not impossible.
If there are two changes (IP and port) we have a lot of
combinations to test... however we can reduce them to
classical 8080, 8025, and so on...
[ # nmap -sS -P0 -n -T 4 -p 25,8025,1025,2500 10.0.0.0/8 ]
Solution
1) Filter or completely block source routing options on
the router. This will block attack from the internet.
2) Add specific IDS ruleset on the external ethernet
segment sensor to spot intruders forging packets
with dst IP of other internal segments.
"rdr quick" could be introduced in 3.4-release to
create a state directly on the external interface.
Also packets tagging would permit a solution.
************************* Ed3f ********************0x000003*
