T 3.46 Incorrect configuration of a Lotus Domino server
Misconfigurations of a software system are a frequent reason for successful attacks. Due to the complexity of a Lotus Domino server, there is also the risk that the installed Lotus Notes/Domino environment does not meet the required safety requirements due to a misconfiguration. The wealth of configuration settings and the parameters influencing each other may also entail numerous risks.
Misconfigurations may occur both in the basic configuration of a Lotus Domino server and when configuring specific services provided by the server For example, this includes the integrated web server (HTTP-Task) or the Domino Offline Services (DOLS) used for iNotes and/or Domino Web Access. However, a misconfiguration of Domino's database service constitutes a problem for the overall security of the server.
Some typical misconfigurations are listed in the following:
- Lack of access restrictions to a server: In the basic setting, everybody is generally allowed to access a Lotus Domino Serverl. If no access restrictions to a server are defined, this first obstacle is not used. This may cause security issues particularly in combination with weak or incorrect access authorisations to services or databases.
- Erroneous Access Control Lists (ACLs) or insecure default ACLs: When created, each database is equipped with an Access Control List containing standard entries (defined by the respective database template). Depending on the template, this list provides for sufficient protection for the database during normal operation. This is particularly true if the database must be initialised or further configured upon creation. Often, extensive rights are required that are no longer needed for day-to-day operations. If the default Access Control Lists are not modified, this may grant unauthorised persons access to the database or grant too many rights to users.
- No encryption is used: The encryption of the network communication (port encryption) and the encryption of databases or database fields are normally disabled by default. In order to use the encryption, it must be expressly enabled. If this is forgotten, the data is unprotected both during communication and on the data media.
- Insufficient authorisations for servers or administrative processes: A Notes database must be administered and maintained by a dedicated server in order to work properly. Amongst other things, the administration and maintenance tasks of a server include the performance of updates of database copies (data, Access Control Lists, etc.). If the responsible server was not granted sufficient rights, the administrative actions will fail. This may cause security problems such as not being able to forward changes regarding the access authorisations to the copies of a database.
- Cross-certificate acceptance: It is possible to enter trust settings between different certificate hierarchies (without a common certification instance) by performing a so-called cross-certification (recognition of third party certificates). If an unknown certificate is "detected", cross-certificates can be generated automatically in most cases. This is applicable both to Notes certificates and to X.509 certificates. In this way, cross-certificates could also be generated by users simply in the personal local address register. However, cross-certificates can only be generated by an authorised administrator in NAB (Notes Address Book). If certificates are thoughtlessly classified as trustworthy, this may cause security problems, e.g. regarding active contents signed with the certificate now being deemed trustworthy.
The issues mentioned are examples of possible risks caused by misconfigurations of a Lotus Domino server. Depending on the corresponding environment, further risks may occur.
Example:
A server is configured in such a way that anonymous certificates are prohibited. Only SSL connections are allowed at the web interface. Therefore, no Anonymous entry is created when the ACLs of the database are configured. Furthermore, forcing SSL-protected web access is relinquished, since the server only accepts SSL connections at the web interface. The Default rights from database templates remained unchanged in order to minimise the administrative work when the templates are changed. The introduction of a new database containing public information causes the server to be configured in such a way that normal web accesses to this database are now allowed as well (anonymous, not SSL-protected). As of now, all server databases can be accessed anonymously. In so doing, the Default rights are applicable, often at least granting a read-only authorisation. This entails the risk of unauthorised persons being enabled to read confidential data or to manipulate information.