OpenBSD PF :: "rdr" information leakage

From: Ed3f (ed3fat_private)
Date: Wed Jul 02 2003 - 10:25:56 PDT

  • Next message: Auriemma Luigi: "Broadcast BoF and server freeze in RogerWilco (2001)"

    ************************ 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*
    



    This archive was generated by hypermail 2b30 : Wed Jul 02 2003 - 15:25:23 PDT