COMMAND

    Lotus Domino

SYSTEMS AFFECTED

    All platforms with Domino 4.6 and earlier

PROBLEM

    Following text is based on L0pht Security Advisory by mattw.   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  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://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.

SOLUTION

    The current release at moment  of writing this (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.