In-Reply-To: <[EMAIL PROTECTED]>
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.
>
>
>
