logo

Security Hole in DomCFG.nsf - is Your Server Vulnerable?

A good customer of mine pays me to be on a yearly support contract, whereby I'm always there to help at short notice. The other morning I came to the office first thing to find a couple of worrying tickets had been logged. Having helped sort the problem I want to pass on what we found as it might save you the trouble.

Their web presence is all but closed off -- access is only by registration and subsequent authentication. It was the registration process (open to Anonymous users) that showed the obvious signs of attack. At first it looked like spam but on closer inspection was in fact an attempt to hack the server.

The main method of attack appeared to be SQL injection and so there was no real cause for concern as Domino is obviously immune to that method.

What got me worried was when I investigated the ticket that stated all their website's login forms had reverted to the "one with a key on it". On opening domcfg.nsf it was immediately obvious the attack was Domino-aware and security had been compromised. Every document in domcfg.nsf had had its field values over-written with the same patterns used by the attack (Google value777.com and you'll see what I mean). Needless to say I was shocked, got on the phone and had them shut down the http task right away.

The attackers must be Domino-aware as there's no other way they could have found domcfg.nsf.

My next action was Googling "public access to domcfg.nsf" which took me straight to Chirs Linfoot's post on the problem. An interesting reply if from Kendall and points out:

domcfg.ntf's [-Default-] entry doesn't have "Write public docs" checked. When adding Anonymous, did you set it to No Access and then set it to Reader? Notes has this annoying "feature" where upgrading access checks boxes you don't check, and downgrading unchecks boxes. Because of this, I've learned to carefully inspect all checkboxes in the ACL when changing entries.

How it happened in this case I don't know, but Anonymous users had the write access to everything in domcfg.nsf. If you run a web server on Domino check your domcfg.nsf now!

No real harm came of it and we were able to restore the old setting from backup but an interesting question was raised by the customer -- were the attackers trying to harvest username and passwords? It go me thinking. Although my immediate reaction was that this isn't possible I can't say I was completely sure of it at first. What if there was some way of manipulating the sign-in form via domcfg.nsf so that all login requests were sent elsewhere without your knowledge. Scary stuff.

Comments

  1. This is supposed to be "scary stuff". It's about the security of your web server, and it is, by design, "scary stuff".

    I have never seen any problems with domcfg.nsf on my servers, or any server that I have been involved in administering. As long as you are careful with the ACL, it is safe.

    As always, if you don't know what you're doing, don't expose a server to the internet.

  2. So Jake, care to share the settings you have enabled?

    I have Anonymous with 'No Access', but then grant 'Read', 'Write' and 'Replicate/Copy'.

    I'm not sure that it's all needed as I inherited the system.

    • avatar
    • Mark
    • Fri 6 Jun 2008 11:44 AM

    As far as I know "No access" with "Read public documents" is sufficient for Anonymous users in the domcfg.

    • avatar
    • Jake Howlett
    • Fri 6 Jun 2008 11:54 AM

    That's right Mark. wildunknown's server is at risk if write public documents is enabled. All anonymous needs to do it read public documents. Letting them write is bad.

    Jake

  3. I found that "NoAccess" with "Read public documents" doesn't let the anonymous user see the custom login form (even with the "Available to Public Access users" option selected on the form). Kendall's notes on setting Anonymous to "Reader" then deselecting "Write public documents" and "Replicate or copy documents" seemed to work correctly.

  4. I just checked a couple of 8.0.1 servers and it looks like the "write public docs" is not DISABLED by default when you set a user to reader.

    Now, I may have changed this myself, so check yours just to be safe.

    Set Anonymous as reader, and make sure nothing else is checked.

  5. Whoops, typo. Meant....

    "I just checked a couple of 8.0.1 servers and it looks like the "write public docs" IS DISABLED by default when you set a user to reader."

    • avatar
    • Lee
    • Tue 10 Jun 2008 09:08 AM

    I might have missed something but what does Google-ing Value777.com have to do with anything??

    • avatar
    • Domino Person
    • Wed 11 Jun 2008 07:44 AM

    Thanks for the information.

    Even I could not understand the link to Value777.com

    Regards.

    • avatar
    • Jake Howlett
    • Wed 11 Jun 2008 08:25 AM

    value777.com is the domain used by the spammers to fill any fields on any forms it encouters. Google it and you'll see how prolific they have been.

    Jake

    • avatar
    • ADP
    • Wed 11 Jun 2008 12:12 PM

    @Frank, don't know if you know, but I also found that it caches the changes... so make sure you do a DBCACHE - FLUSH after your acl change, else you may not see the desired result...

    But I found it works OK, with NoAccess.. so..

    • avatar
    • Morten Clausen
    • Tue 17 Jun 2008 12:13 PM

    > As long as you are careful with the ACL, it is safe.

    It may be that all I have to do is be careful, but a security that fails open is bad design. If I make a mistake it's far better to have the site go offline than open the configuration to all and sundry. "Careful" is not the default configuration of the human mind... :-)

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


About This Page

Written by Jake Howlett on Fri 6 Jun 2008

Share This Page

# ( ) '

Comments

The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content