Re: UserID and hashed password for Lotus Domino

[Philip Storry <phil () philipstorry net>]

Hello Casper,

Friday, October 18, 2002, 4:11:04 PM, you wrote:

CG> hi,
CG> while doing security tests on a Lotus Domino sistem, I
CG> managed to get the UserID file for a user, and the
CG> hashed password of another user.
CG> I made it accessing thru the Internet, so I was a
CG> totally unpriviligied user. The way I made it, is
CG> simple:

I guessed the way before you even described it. Which version of
Domino is this? (Type 'show server' at the server console to find
out.)

CG> the company I'm doing this test for, left some of the
CG> domino databases open to the public. Among the others,
CG> there's the names.nsf database, wich contains info
CG> about the users. You just access this database with a
CG> url like: 
CG> http://domino_server/names.nsf
CG> Well, one user had his UserID file publicly
CG> accessible, and another user had his password digest
CG> stored in the database.

Three points:

1. The Domino Directory (names.nsf) can be easily secured by adding
the user "Anonymous" with No Access. Domino R5 and higher offer to do
this for you upon installation. Prior to R5, this was not an option,
and such problems were the fault of "bad defaults" in installation.
Whoever installed the Domino Server should have secured it using the
tools they were presented with - it's offered to you on a plate at the
end of the installation. It would have added the "Anonymous"
account to all databases and templates with No Access, which would
have closed this hole (and others) completely.

2. The ID file is on the person document because a lazy administrator
left it there. When an administrator registers a user, they have the
option of saving the ID file to a file system, or storing it in the
Person Document. Storing in the person document is intended for remote
installations where the ID file cannot be taken - and when the Notes
Client installation is completed, the client will delete the file and
close this security hole. So the file should only be there for a short
while, if at all. And nobody should know the password, because it's
not some braindead 'default' password like "password". (That's just
good administration practice, right?)
The file is only there because of a lazy administrator, I suspect. The
functionality is given by Lotus to deal with installations of clients
that are very remote - e.g. connecting via modem dialup - and that
cannot be reached by the Administrators/support team to give them
their ID file.

3. The password digest is NOT necessarily the same as the password in
the ID file. The most recent version of Domino/Notes (R6) does, I
believe, offer the option of changing the internet password (The
digest you describe) when the ID password is changed - but obviously
the ID file's password cannot be changed from the internet browser
end, as the browser has no knowledge of what an ID file is.

Older versions of Domino - R4.5.x - did have an insecure internet
password hash, but this was solved by Lotus by adding a second hashing
method. This method should really be considered the default now that
R4.5.x is no longer supported by Lotus/IBM. (I'd need to check to see
if it is the default in R5 - I think that it is, however.)

CG> Is there any way to obtain the password from the
CG> UserID, or to crack and obtain the password from its
CG> hash?
CG> (I read it was released a tool named "sesame"... any
CG> clue? here for more info about it:
CG> http://online.securityfocus.com/news/66 )

Lotus is extremely coy about the ID file format. However, I do know
that they use the RSA BSAFE libraries, and that the password can be
checked by the server to ensure that the ID file and a stored hash at
the server are the same. This suggests to me that the password is
stored as a hash in the file, making it difficult - if not practically
impossible - to extract the original password plaintext from.

Despite having worked with Lotus Domino and Lotus Notes for 6 years,
I've never heard of ANY tool that offers to extract a password from an
ID file. The official lotus position is that if you've forgotten your
password on an R4.6 system, you'd better have an old backup of the ID
file that you do know the password to. And if you've forgotten it on
an R5 system, you'd better hope your administrator has set up the
password recovery system.

Even the password recovery system doesn't allow you to see the old
password. It works by adding a second key to the ID file, which can
only be unlocked by a designated administrative user. The
administrative user must get hold of the ID file, and initiate
password recovery. This will require the administrator to initiate
password recovery using the Admin client - they will be given a
special password that can unlock that ID file only. They must then
select another ID file which is authorised to perform password
recovery, and authenticate themselves with it (i.e. unlock it by
typing the password). They are then required to type a special
password they were given at the start - the password of the ID file
can now be reset. You are not given the original password at any
point. The recovery password will only work that once, and will be
changed upon use - I believe it is a securely calculated
cryptographical value.

So even when a user forgets their own password, nobody can tell them
what it was - all they can do is reset it via that laborious (but
secure) process.

CG> I would be interested in demonstrate how to abtain a
CG> password or access to
CG> the system starting from the data I collected on the
CG> Internet.
CG> I would appreciate any help thanks.

If you manage to do it, please let me know. As far as I'm aware, that
ID file is a waste of time. The better bet might be to go after the
hashed internet password (Not the ID password) in the Person record.

And as I mentioned, all the other issues you described are the result
of sloppy administration. Domino has mechanisms to prevent all of
them, although I sometimes wish that they were enforced by default
rather than left in place for backwards compatibility. (Even if if
would make upgrades much more difficult.)


Sorry for the length of my reply, but I wanted to be clear in putting
across that none of these are - as far as I'm aware - security holes.

I am a Principle Certified Lotus Professional and have been working
with Lotus Domino since it was still called Lotus Notes, and was at
version 3.33. Most recently I have been working in high-security
environments involving hosted services. (Just in case you wondered
what my credentials are.)

I hope this helps - feel free to ask any questions you may have.

-- 
Best regards,
 Philip                            mailto:phil () philipstorry net