In-Reply-To: <Pine.LNX.4.44.0209270208190.21585-100000@datacontact.hu> 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. > > >
