Domino Passwords Vulnerable for Web-Users

by Ragnar Schierholz

An advisory by CybSec S.A. released yesterday describes a possibility for users with read-access to the person documents in names.nsf using a web-browser to retrieve the password hash of users. Available cracker tools can then retrieve the plain password. A workaround is described as well, which requries the modification of a sub-form in names.nsf.

This is not the first time, that web-access to the Domino Directory exposes possibly sensitive data. Most conscious admins should have limited the web-access to this database anyways, so the impact of the vulnerability shouldn't be too high. It should rather convince less-conscious admins to lock names.nsf down further (IMHO).

Comments

Thanks for the information! Corrected here - I hope this means that IBM will be correcting this in the pubnames.ntf file for the next release.

Chris Whisonant, 2005-07-27

this advisory is nonsense. Oh hell, you can see the hash of a password.. wow, if a user wants to, he just opens up his client and looks at the hashes without the browser.

plus.. what is a "paragram" as noted in the advisory. this is just a null information from someone who has no knowledge about notes/domino at all.

regards,
sascha

Sascha Reissner, 2005-07-27

@Chris:
I guess the anonymous access is a good start, but authorized users still mean somewhat of a threat. Code that's run on their behalf (e.g. because of uncareful browsing) can still obtain the information.

@Sascha:
Ok, there's typo in the advisory. That doesn't make the whole thing bad. Considering that (at least in R5) the Domino Directory is open for anonymous access via the web by default, I do think that this imposes a threat. Having access to password hashes is not nothing!

Ragnar Schierholz, 2005-07-27

This is old news, and it is not particularly helpful. Lotus has had optional password salting available for years with the "more secure internet passwords" setting in the Directory profile. The fact that this setting is not the default is an annoyance, but the fact that this advisory fails to mention it is inexcusable. Hiding the hash in the HTML source isn't a complete solution to the problem, as other ways of viewing the hash in directories that have been known for years -- as have the ways of protecting against it. IBM could have done a better job of letting people know about this, and the defaults should be more secure, but the advisory should at least have referenced the recent IBM technote 1091043 http://www-1.ibm.com/support/docview.wss?&uid=swg21137296 and the much older 1085830 http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21085830 both of which address this issue.

-rich

Richard Schwartz, 2005-07-27

Personally I like it better to set "Maximum Internet Access" in the ACL to None instead of modifying the design of the Domino directory.
Modifying the design requires good documentation and being carefull when upgrading even to next maintenance release. Of course this may not be an option for any web app you may have created but for Webmail or iNotes it will do.

Michael Poetzsche, 2005-07-27

Just realized the alternative of reducing "Max Internet Access" to None was also published on heise.

However the workaround of using the personal address book to store addresses instead of the Domino Directory which is no longer visible is imho not necessary (and would be a big disadvantage anyway).

The better solution is to create a server based Diretory Catalog (Dircat) which is a reduced copy of the Domino Directory, automatically kept up to date by a server task. This reduced copy does not even by default contain the Internet Password. And I would assume in very many installations a Dircat is already present anyway....

Michael Poetzsche, 2005-07-29

I think my database of hashes is still available on the OpenNTF.org server, for those that have Notes-based access to it.

Nathan T. Freeman, 2005-08-02

Old vowe.net archive pages

I explain difficult concepts in simple ways. For free, and for money. Clue procurement and bullshit detection.

vowe

Paypal vowe