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:philat_private
This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 10:53:54 PDT