Re: Allot Netenforcer problems, GNU TAR flaw

From: Felix Radensky (felixat_private)
Date: Sun Nov 03 2002 - 00:46:40 PST

  • Next message: NGSSoftware Insight Security Research: "[VulnWatch] Oracle iSQL*Plus buffer overflow vulnerability (#NISR04112002)"

    
     ('binary' encoding is not supported, stored as-is)
    In-Reply-To: <Pine.LNX.4.44.0209270208190.21585-100000at_private>
    
    Hello,
    
    Allot has addressed all security problems mentioned in the
    posting of Boldizsar Bencsath in our new version,
    4.2.4, scheduled end November 2002. To be more
    specific, the following fixes were implemented:
    
    1. SSH port forwarding was disabled. 
    2. /etc/shadow is no longer world readable
    3. GNU tar is no longer used  in tftp-get.sh and
    tftp-put.sh
        scripts. We use GNU cpio instead.
        
    
    These modifications plug all holes mentioned in security
    advisory. 
    
    Problem number 1 (SSH port forwarding) is fixed by
    disabling
    port forwarding in SSH daemon configuration.
    
    Problem number 2 (MySQL access) is also fixed by disabling
    SSH forwarding.
    
    Problem number 3 (File access vulnerability) is fixed
    by disabling SSH port forwarding and making /etc/shadow
    readable by root only.
    
    Problem number 4 (Shell access) is fixed by modifying
    tftp-get.sh and tftp-put.sh scripts to to use cpio instead
    of vulnerable tar. 
    
    Allot will release a fixed version of tar as soon as fix
    is available from tar maintainers.
    
    We would like to thank Mr. Boldizsar Bencsath for
    notifying us aboult the problems.
    
    >1.Multiple security flaws lead to Netenforcer
    privilege escalation
    >2.Vulnerable tar packages
    >
    >Affected System: Allot Netenforcer, v42
    >
    	(only one sample configuration has been tested)
    >
    	www.allot.com
    >Remote:
    	No
    >Local:
    	Yes
    >Vulnerability type:
    >
    	Small security flaws and vulnerable tar package lead
    >
    	to privilege escalation. Can be exploited remotely only
    >
    	after authentication.
    >
    >
    	Authorized users
    >
    	(a) can gain access to internal database
    >
    	(b) can proxy connections through netenforcer
    >
    	(c) can gain access to shadow file
    >
    	(c) can gain root shell (admin user only)
    >
    >Found by:	Boldizsar Bencsath, Budapest, HU
    >Solution:
    Various workarounds are possible. CHANGE DEFAULT PASSWORDS!
    >
    	Allot has been notified and answered to the problem,
    >                hopefully releases official help.
    >
    
    >
    >Security flaws:
    >
    >1. SSH port forwarding
    >
    >In our case, the SSH server had enabled ssh port
    forwarding capabilities.
    >One can proxy through this system being any of the
    above mentioned users.
    >While the shell of the "admin" user waits for user
    interactions, the
    >"monitor" users' shell simply quit after displaying an
    error message.
    >("This user name can be used only through the
    Graphical User Interface")
    >This setting of monitor user can cause immediate exit
    from ssh and thus
    >disabling port forwarding, but an attacker can use the
    -N option of ssh,
    >"Do not execute a remote command.  This is useful for
    just forwarding
    >ports (protocol version 2 only).".
    >
    >This way any of the users can act as the Netenforcer
    computer. This
    >problem seems not to be critical, but using a badly
    set firewall this
    >can open ways to intrude into the inner network of a
    company.
    >
    >2. MySQL access
    >
    >Netenforcer uses MySQL to store log files and various
    data. MySQL is
    >listening on the public interace of the Netenforcer on
    the _undocumented_
    >port "53306".
    >
    >Remote users do not have permission to access MySQL
    from remote hosts.
    >Local users are able to connect to mysql without a
    password (root,mysql).
    >Using the security flaw (1) (previously described) an
    attacker can gain
    >access to MySQL database:
    >ssh admin@netenforcer -L 1919:127.0.0.1:53306 -v
    >..
    >mysql -h localhost -P 1919 -u root
    >..and voila, you have root access to mysql.
    >Note, that setting a factory pre-set password does not
    solve this problem,
    >because this can be obtained by checking the upgrade
    packages.
    >
    >3. File access vulnerability
    >
    >MySQL has internal capabilities to get data into
    database from files or to
    >store database data in local files. by invoking
    >CREATE TABLE jokes (a INT NOT NULL AUTO_INCREMENT
    PRIMARY KEY, joke
    >TEXT     NOT NULL);
    >load data infile "/foo/bar/file" into table jokes
    FIELDS TERMINATED BY ""
    >      (joke);
    >One can get Netenforcer's local filesystem data into
    the mysql database,
    >and of course he can read this mysql database for
    obtaining the data.
    >For security reasons Allot's best way would be
    disableing Load data infile
    >and select "" into outfile sql commands from the mysql
    server.
    >
    >Another security flaw (in our sample system) is the
    following:
    >Although MySQL is running under the name of "mysql"
    local user (disabling
    >access to a lot of files), the /etc/shadow has group
    readable permissions on
    >our sample system. This way one can gain access to
    encrypted password files
    >and execute offline dictionary based on brute force
    attacks on the user
    >passwords. Of course, until this point any of the
    users is able to get this
    >data, so the monitor user is still affected.
    >
    >4. Shell access
    >
    >"admin" user on Allot's Netenforcer has a "0" uid, but
    does not have "cli"
    >(shell) access. Although he can modify the system
    configuration, and deploy
    >DoS attacks this way, he cannot afford to sniff or
    modify network traffic.
    >(he can get statistical data on the network, open
    ports etc., but this is
    >not "full" network access).
    >
    >Gaining root shell for "admin" user is _not_ a
    feature, but a security
    >flaw.
    >
    >Admin user has a web interface to modify system
    configuration data. He can
    >download (backup) the whole system configuration
    (policy settings etc.,
    >not the linux config data) by invoking a tftp put session
    >(cgi-bin/swg-config/tftp-put.sh). By another command,
    he can tftp get
    >(restore) the old configuration from a remote host.
    >The tftp-get.sh contains the following line:
    >    tar zxf $TAR -C $2/ > /dev/null 2>&1
    >The system gets the configuration data in a compressed
    tar file and
    >unpacks it into a temporary directory.
    >GNU "tar" package on netenforcer had a serious
    security flaw:
    >By compressing specially designed files one is able to
    deploy any file on
    >the remote system.
    >
    >We just put a "/../../../../../etc/passwd" file with
    modified "admin"
    >shell (we downloaded passwd file with mysql, as
    previously described)
    >into the previously downloaded configuration file,
    then "restored" the
    >config data to the Netenforcer, and after a
    successfull reboot we
    >gained "root shell" access to the Netenforcer.
    >
    >After this point "admin" user has all privileges on
    the system.
    >The Allot's linux kernel is a 2.2.19, and the
    af_packet module is not
    >compiled in. This way we are unable to run a
    statically compiled "tcpdump"
    >or any  sniffer using raw sockets through this kernel
    service, but one can
    >compile his own kernel to deploy such attack.
    >Other attacker only accessing "monitor" user can get
    the shadow file and
    >crack the password of the root user gaining shell this
    way.
    >
    >Anyhow, this security flaws seem not to be very
    serious, but if the threat
    >is that an attacker could reach all the internet
    traffic of a company,
    >then system administrators _should_ deploy the highest
    security possible.
    >
    >
    >
    



    This archive was generated by hypermail 2b30 : Mon Nov 04 2002 - 09:33:46 PST