|
Vulnerability Zeus webserver Affected Zeus webserver (all versions before 3.3.2) Description ".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.)