|
Brought to you by:
Suppliers of:
|
|
|
| |
Lotus Domino is an Application server designed to aid workgroups and collaboration on projects and offers SMTP, POP3, IMAP, LDAP, and web services that allow users to interact with Lotus Notes databases.
A Lotus Notes database contains documents that are organized into views. Access control lists can be applied to the database itself, views and documents. If a user has been denied access to a view, NISR have discovered that it is possible to bypass the permissions set on that view and access the documents one would expect it to protect. |
| |
Credit:
The information has been provided by NGSSoftware Insight Security Research, David Litchfield, Bas Welman, Russell Handorf, and Darren Davison.
|
| |
Vulnerable systems:
Lotus Domino Web Server 5.x
Immune systems:
Lotus Domino Web Server version 5.0.7
The reason this vulnerability exists is because even though a document might exist in one view, it can be accessed from any other view as well.
As an example of this, examine the Statistics Reporting database, statrep.nsf.
If you open, the Events view:
http://server/statrep.nsf/136/?OpenView
Some documents will exist. (136 is the NoteID of the Events view). Now, if you open the hidden $Alarms view:
http://server/statrep.nsf/$alarms/?OpenView
No documents exist.
Request one of the documents from the Events view:
http://server/statrep.nsf/136/8F6?OpenDocument
(8F6 is the NoteID of the first document)
Note the text of this document and then request:
http://server/statrep.nsf/$alarms/8F6?OpenDocument
The same document is returned, even though $alarms has no documents.
Now, if you apply access controls on the Events view and request:
http://server/statrep.nsf/136/8F6?OpenDocument
The server will return an Illegal Argument exception error. This is because the server expects credentials.
However, requesting:
http://server/statrep.nsf/$alarms/8F6?OpenDocument
Still returns the document even though access to the view the document exists in disallowed.
The reason we can request any document through any view is that a NoteID is simply a pointer to a location in the database file and as long as the server receives its expected syntax, i.e. database, view then document it will service the request. By making a request with a NoteID, we are simply forcing the server to return the contents of an arbitrary location within the file.
Fix information:
The solution to this problem is to ensure that, if you are applying ACLs to a view, the documents in that view are also protected.
Lotus were informed about this issue and their response was that applying ACLs to a view protected only the view and not the documents themselves and that they, too, should have access control lists applied.
NISR notes that the difference between expected and actual behavior is considerable enough that many Lotus administrators may be caught out by this and should ensure that their sensitive documents are indeed protected.
Note:
Views do not, nor are they intended to protect the documents they 'contain' they are merely a convenience. Hiding the view or restricting its access to certain users is simply an extension of that convenience. Data (i.e. documents) are correctly protected by reader's fields, document encryption, or field level encryption.
From the online help of the Domino Designer client:
".. Users who are excluded from the access list will no longer see the view or folder in the View menu. A view or folder read access list is not a true security measure."
Note on the solution:
There are different types of security within Domino applications:
- First of all you have the Database ACL which take care of the access rights of the complete database. This one is the most important one since this one defines who can access the database and on which level, and who cannot access at all.
- Next, you can protect the different design elements like views and forms, which are required to view the data in the database. The only thing you protect is the ability of a user to use these design elements to view data, not the data itself.
- Finally, the actual data which is stored in documents can be protected. These documents can be protected by using reader and author fields.
There are a view more ways to protect data, but these three are the most used ones.
The conclusion you can make is that the only way to actually protect your data is to define your database ACL correctly and make use of reader and author fields to define who can view and edit the different documents. All other security options are only protecting the different design element and not the actual data.
|
|
|
|
|
