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.
Author: mattw@l0pht.com
Operating Sys: All platforms
-------------
=======
Scenario
=======
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.
=======
Details
=======
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.
========
Examples
========
Now for the way domcfg.nsf is actually edited via the web:
Choose a site, lets say http://199.99.99.99
To open the Domino Configuration database add 'domcfg.nsf/?Open' to the
end of the above URL, so you have:
http://199.99.99.99/domcfg.nsf/?open
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
Mappings, etc.).
For this exercise we want to add a new URL Redirection.
Now to ADD a URL Redirect simply change the URL to:
http://199.99.99.99/domcfg.nsf/URLRedirect/?OpenForm.
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
http://199.99.99.99)
Redirection URL: the url you want it to redirect to (lets say your own url
http://my.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://199.99.99.99 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:
http://www.notes.net/today.nsf/cbb328e5c12843a9852563dc006721c7/ca5230f9baf39fe1852564b5005e8419?OpenDocument.
========
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...
Regards,
mattw@l0pht.com
---------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://www.l0pht.com/advisories.html
---------------