SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Firewall)  >   Pf Vendors:   OpenBSD
OpenBSD pf Packet Filter May Disclose Internal IP Address and Port Number to Remote Users
SecurityTracker Alert ID:  1007101
SecurityTracker URL:  http://securitytracker.com/id/1007101
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jul 4 2003
Impact:   Disclosure of system information
Exploit Included:  Yes  

Description:   An information disclosure vulnerability was reported in the OpenBSD pf packet filter. A remote user may be able to discover a private IP address or port number.

It is reported that, in certain configurations where packets are redirected via 'pf', a remote user can conduct a brute force guessing attack, generating a single TCP SYN packet (to port 25, for example) to each IP address in the private address space. The system will reportedly respond only if the correct IP address has been guessed.

Several specific exploit scenarios are described in the Source Message.

Impact:   In certain configurations, a remote user may be able to identify valid internal (private) host addresses.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.openbsd.org/ (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  UNIX (OpenBSD)
Underlying OS Comments:  3.x

Message History:   None.


 Source Message Contents

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*



 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC