Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Web :: Servers :: zeus1.htm

Zeus Webserver Weaknesses


    Zeus webserver


    Zeus webserver (all versions before 3.3.2)


    ".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

    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 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

    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.


    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:

    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.)

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH