COMMAND
Zeus webserver
SYSTEMS AFFECTED
Zeus webserver (all versions before 3.3.2)
PROBLEM
".rain.forest.puppy." found following. Zeus is a high-performance
webserver available from Zeus Technologies. There's a myriad of
problems, that when combined together, could yield a remote root
compromise. Let's review the progression.
Bad search engine CGI
=====================
This is really the core of the problem. Zeus has the option to
setup a search engine for your virtual website(s). This feature
is accessible via www.zeus.server/search (not /search/, big
difference). If the engine is available (it's an optional
feature), it can be used to request any file that's accessible by
the web server uid (which is *asked for* on install...unwise
administrators may pick 'root', which is a bad choice. We shall
assume they pick the typical 'nobody'). The mechanism is in the
search form:
<form action="/search" method=POST>
<input type=hidden name=indexfile value="/usr/local/zeus/html/search.index">
<input type=hidden name=template value="/usr/local/zeus/web/etc/search_output.html">
Query: <input type=text name=expr value="">
<input type=submit value=Search>
Notice the values for indexfile and template. Hard server paths
is usually a good give-away. Now if we recreate our own form, we
can change the values of indexfile and template to suit our
liking. Modifying indexfile will get us know where, as it will
be virtually impossible to find a file (worth reading) that Zeus
will read as a search index (since it's not in the proper internal
format). However, the template is more interesting. This is the
file that is opened and given to us, simply by replacing a few
variables to insert the search output. Well, who needs search
output. If we change template to be /etc/passed, you'll get
/etc/passwd as your search result. Simple enough. Let's dig
deeper...
Administrative interface password
=================================
Zeus comes with a web UI for administration. This server is
typically plopped on port 9090, and is installed as *ROOT*. This
is important, since it needs to change the configuration files
around. There is no option to not run it as root. Well,
technically, you can, but it won't startup, due to insufficient
permissions to open and modify various configuration files. RFP
supposes you can really tweak it to run as a non-root uid, but
it's a load of thought to convert everything over by hand.
Anyways, so the UI runs as root...it would be nice to be able to
play around with root permissions, eh? The only thing stopping
us is a http authentication login. And since we can read any file
on the server, how about reading the file with the administrative
password? The configuration file for the administrative website
is (by default) /usr/local/zeus/admin/website. In this file
you'll see a line similiar to:
modules!access!users!admin yoEPUmukiYLrPvz4jqBeJQ==
This is the username/password combo. The default is 'admin' for a
user...but unfortunately the password is queried on install. The
format is pretty simple -- base 64 uuencoded MD5 hash. Let's
verify. Password is 'admrox'. First I make a small file with
the following contents:
begin-base64 644 test.out
yoEPUmukiYLrPvz4jqBeJQ==
====
Notice it's just the password from the Zeus configuration file.
Now run this through uudecode and hexdump:
[root@wicca /tmp]# cat password.txt | uudecode -o - | hexdump
0000000 81ca 520f a46b 8289 3eeb f8fc a08e 255e
Now, we can compare with the known MD5 hash of the password:
[root@wicca /tmp]# md5sum --string="admrox"
ca810f526ba48982eb3efcf88ea05e25 "admrox"
Looking at them side by side:
81ca 520f a46b 8289 3eeb f8fc a08e 255e
ca81 0f52 6ba4 8982 eb3e fcf8 8ea0 5e25
A little byte inversion, and we have a match. Based on this you
can modify your brute force password cracker of choice to run
through the available choices. Brute force cracking the password
is left up to you. But it is feasible to find the password. Now
that we have it...
Using the web administration UI
===============================
This is just more of an afterthought. It's possible to do many
nasty things, including making a virtual website who's document
root is /, enabling file uploads (via http PUT method), etc. If
you enable file uploads, you can upload binaries or Zeus scripts
into the web administration UI directory (default is
/usr/local/zeus/admin/docroot) and then call them through the
UI--which will then be ran as root. The possible forms of attack
are left to your imagination.
SOLUTION
Zeus Technology has uploaded new binaries to fix the root
compromise bug in the Zeus Webserver. The bug affects all
versions of Zeus prior to 3.3.2. It is recommended that customers
upgrade as soon as possible. Customers who are not making use of
the search module are not affected, and need only upgrade if they
plan to start using it in the future. Customers upgrading from
version 3.1.9 or earlier will need to follow the upgrade
instructions at:
http://support.zeustechnology.com/faq/entries/z33migrate.html
It is worth noting also, that provided you had set the webserver
to run as non-privileged user, the risk from the search module
bug is relatively slight, as someone exploiting it under those
circumstances would find it difficult to compromise root,
provided you have chosen a secure password for access to the
admin server. This should serve as reminder always to run your
web process as a non-root user. To ensure that the Zeus admin
server is as secure as possible, you should restrict access to
the admin server port (9090 by default) to designated machines.
You can do this with by setting access restrictions on the
"Security Settings" configuration page for the admin server,
and/or by configuring your firewall appropriately. You should
also ensure (to prevent Crack-type attacks on your admin server
password), that you choose a password for the admin server which
is as secure as one you choose for root on your machine. (Ie,
mixture of alphanumeric and punction characters, mixture of upper
and lowercase, no dictionary words or parts thereof, etc.)