Lotus Domino database security problems
|Description:||Databases under this system do not correctly inherit ACLs, plus some default database ACLs are set to allow unrestricted access to all web users(!). Thus users can can manipulate the files remotely.|
|Compromise:||manipulate server configuration files remotely |
|Vulnerable Systems:||Those running vulnerable versions of Lotus Domino |
|Date:||20 January 1998 |
Date: Tue, 20 Jan 1998 10:41:33 -0500
From: mattw <mattw@L0PHT.COM>
Subject: L0pht Security Advisory
L0pht Security Advisory
URL Origin: http://l0pht.com/advisories.html
Release Date: January 20th, 1998
Application: Lotus Domino
Severity: Web users can write to remote server drives and change
server configuration files.
Operating Sys: All platforms
Due to the design of Domino's database security, web users are able to
write to remote server drives and change server configuration files. Three
specific design flaws lead to sites being a victim. Default database ACLs
are set to allow unrestricted access to all web users. Databases do not
correctly inherit their ACLs from their parent template. No tool is
provided to check that proper security measures have been taken on server
configuration databases. These three problems lead to databases being left
unsecured to any web user.
The three design problems that combine to let any user manipulate remote
server configuration files via a standard web browser are explained below.
The first problem is that database default ACLs are set to give every user
(including anonymous) 'designer' access (practically total control), as
well as defaults the 'Max Internet Access' setting to 'editor'. There is
also no automatic way to set the ACLs for a large number of databases at a
single time. So every ACL for EVERY database needs to be MANUALY edited by
an admin to make SURE the ACL is set properly. These two poor design
issues practically guarantee that a number of databases on a server will
be giving unwanted access to web users (or any users). This access
includes web users being allowed to WRITE to server drives, read log
files, and edit/delete database information.
The second problem is that databases do not correctly inherit the access
control list from their parent template. Templates are used to update the
design, forms, views etc. of similar databases, but do nothing to the ACL
on update or initial creation. This causes serious problems for a server
configuration file (a database), that is created and edited a minimal
number of times. This is the case for domcfg.nsf. Domcfg.nsf is used for
URL Redirection and the like; on most sites it is usually created and edited
only once (and for this reason many admins overlook it). Since domcfg.nsf
does not inherit the ACL from its parent template (domcfg.ntf), and
because of the first problem mentioned above (namely, on initial database
creation the ACL is set to give 'default' users designer access), any
domcfg.nsf file's ACL that has not been MANUALLY edited to restrict users
will give a web user UNRESTRICTED access.
The third problem is that there is no included software that allows an
admin to 'test' the security of their server and the server's configuration
files. This, combined with the large number of separate server
configuration databases that can be used by an admin, generally leads to
at least one configuration database whose ACLs have not been manually
checked by a competent admin. This leads to massive security problems.
Many high profile Domino sites (you know who you are!) have been affected
with these problems. Due to the nature and uses of domcfg.nsf, it is
usually the guilty database. An improperly configured ACL for domcfg.nsf
can let any user with a standard web browser CHANGE THE URL ADDRESS of a
site with simple redirection, edit/delete legitimate URL redirections, and
generally wreak havoc.
Now for the way domcfg.nsf is actually edited via the web:
Choose a site, lets say http://184.108.40.206
To open the Domino Configuration database add 'domcfg.nsf/?Open' to the
end of the above URL, so you have:
Now, in a correctly secured domcfg.nsf you would be prompted for a
password at this point (or, in some cases, the domcfg.nsf file has not
even been created and won't be there).
Anyway, many sites (due to the details listed above) do NOT have their
domcfg.nsf ACL setup correctly and at this point a web user sees a screen
showing different views they can pick from (URL Redirection, Directory
For this exercise we want to add a new URL Redirection.
Now to ADD a URL Redirect simply change the URL to:
At this point you get a URL Redirection form. Fill in the fields:
IP Address: the IP address of the remote machine
URL path: the path you want to redirect (lets say
Redirection URL: the url you want it to redirect to (lets say your own url
Saving the document (pressing the submit button) will produce a new URL
Redirection document. The next time the server is restarted the URL
Redirection will take effect.
With this example, every http request toward http://220.127.116.11 will be
redirected toward http://my.own.url, having the affect of completely
redirecting the site.
>From this point you can search around and basically manipulate documents
that do a wide variety of things. Domino URL commands (which can be used
to edit, delete, and manipulate files via the web) can be found in all
documentation as well as at:
Platforms and Versions
These problems affect Domino 4.6 and earlier (on all platforms). The
current release (version 4.6a) has made one correction: databases created
from a template set default to 'read', but NOT to the parent templates ACL
settings. All the problems above still exist; ACLs need to be edited
manually by a competent admin to be ensured of security. Take, for
example, if domlog.nsf could be read, that alone is a security breech.
Hope this helps...
For more L0pht (that's L - zero - P - H - T) advisories check out:
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
For a free program to automate scanning your network for vulnerable
hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: