bugtraq - OpenBSD PF :: "rdr" information leakage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200307021050.05053.ed3f__37796.1207800128$1057183032@overminder.com>
Date: Wed, 2 Jul 2003 19:25:56 +0200
From: Ed3f <ed3f@...rminder.com>
To: bugtraq@...urityfocus.com
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*