Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Andrew T (packetsmackdigisec.org)
Date: Wed Jul 03 2002 - 00:19:52 CDT
Lotus Domino R4 Web Server -- File Retreival Vulnerability
Digisec.org Security Advisory
Lotus Domino R4 (Versions 4.x) AIX - have not tested other versions/platforms
Date: July 2, 2002
This advisory is Copyright (c) 2002 Digisec.org
This advisory may be distributed unmodified, however, you may not modify and distribute (in parts or in it's entirety) without express written permission.
Use this information at your own risk. Digisec.org is not liable for any damages caused by direct or indirect use of the information or functionality provided by this advisory. Digisec.org bears no responsibility for content or misuse of this advisory or any derivatives thereof.
Lotus Domino Web Server under AIX (have not tested other versions) allows downloading of files in the web root directory (rather than referring to the ECLs within the database or the permissions on the file itself). This does not work on the standard web scripts included in Domino such as admin4.nsf, names.nsf, domcfg.nsf, etc. However, if there are other files or custom-made .nsf databases in the server's web root directory, they may be downloaded by appending a "?" at the end of the file name.
Our understanding of this problem is based on the way that Lotus handles documents in the web root directory. When a request is made to a file, the addition of the "?" on the end of the file name acts as a wildcard. The server doesn't know how to handle this character and instead just delivers the entire file rather than trying to parse the file through the web handler. This was tested with other various file types (.tar, .htm, .zip, etc.) all with success.
http://dominoserver/nameoffile.ext? will get the file "nameoffile.ext".
Lotus was notified about the issue. They noted that this issue had never been reported and suggested a workaround that appears to correct the issue. Their suggestion was to create a separate directory for the web site files (don't put them in the web root created during installation). Also, the permissions on these files should be appropriately applied. This vulnerability only appears to work on files within the web root directory not in other folders. This vulnerability is not an issue in R5 (which was tested by Lotus).
Thanks to the following for your support and insight: Lotus, packetphobia, rabidpacketmonky and j0hnn135.