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.