logo

Hacking Domino

For the last three years I've been sitting on a draft article, with the working title Domino Security by Obscurity, which I've always been in two minds about publishing. The methods it talks about display a considerable security flaw in Domino. Well, at least in the way applications are developed. Domino is, as we all know, as secure as you make it. From what I can tell though, the methods no longer works with Domino 6 and I feel safer talking about it now.

All design elements and documents in a Notes database are assigned a hex NoteID. The assignment of these IDs follows a pattern. Knowing this pattern we could access documents by guessing the URLs to them.

The first view in a database takes hex NoteID of 116 (278 in normal numbers). Each view added after that is 4 greater and so follows a pattern like 120, 12d, 122, 126 etc. Like so:

Documents start at a hex value of 8F6 (2294 in normal numbers) and also follow the same pattern. With this knowledge we could try and access the first document in the first view like this:

http://server/database.nsf/116/8F6

When I first found out about this I wrote this servlet to test the theory. The code tries to access ?OpenView URLs for the first 200 views in the pattern. If the URL returns a non-error code then the view exists and it gets logged. The code then returns the browser a set of links to try accessing the views it found. The links calls the servlet again, this time with a parameter that tells the servlet which view to try. With this view the code guesses URLs for the first 2000 documents it might contain. Any that exist are returned as links to the browser. Clicking the links returned can give you access to documents you had no other way of getting at.

So what? Well, imagine you've secured an application by hiding a view and thinking that prevents access to its documents. This is the obscuring bit, of which security plays no part.

The guy who first told me about this suggested I kept it under wraps. Although I never tried it on any public web server, he claimed to have gotten access to highly sensitive information from a couple of high profile financial companies. The main reason I didn't ever hand out the code I wrote is that I was scared about people testing it on this server. Repeated requests for URLs that cause errors will crash Domino.

I had all but forgotten about this code until I happened upon a Sourceforge project the other day called "Domino Hunter".

DominoHunter is an open-source security tool that is able to scan and detect structure vulnerabilities in Domino Web servers.

This Perl script takes the whole thing a little further and guesses actual file names of known databases, before going on to guess at view and documents IDs. Scary.

Does anybody know if this really has gone away in Domino 6?

Finally, please, please, please don't point either of the scripts at this server.

Comments

    • avatar
    • Jono
    • Tue 8 Nov 2005 07:43 AM

    But surely people should be securing databases and documents using ACL's, Author and Reader fields... hiding views should just be used to clean things up, rather than for security reasons?

    • avatar
    • Jake Howlett
    • Tue 8 Nov 2005 07:50 AM

    Eaxctly. That's where the "security by obscurity" title came from.

    It's down to the developer to secure an application. Hiding views doesn't count.

  1. mmm, I think that if can guess the view id or the document url, If a guy tells me that he can do that, so what!

    Knowing a url doesn't grant me access. If I've applied all the security recomendations (view level restrictions, reader, author fields, acl, etc) I don't have to be affraid.

    At least that's what the documentation say :-D

    .::AleX::.

    • avatar
    • YoGi
    • Tue 8 Nov 2005 08:20 AM

    yeah i don't agree either.

    if some people wouldn't have hacked some php sites and underlined the security flaw lying beneath register globals on, most php developpers would still use them, without even knowing their existence.

    Underlining bad practices is imho the good way to improve security in software.

    • avatar
    • Jake Howlett
    • Tue 8 Nov 2005 08:39 AM

    Don't agree with what YoGi?

    Has this blog entry been misunderstood? I was just trying to make sure everybody knows why obscurity is NOT security.

    • avatar
    • YoGi
    • Tue 8 Nov 2005 08:55 AM

    I don't agree with.. ahum.. well.. :D

    I just mean I think you should have published it earlier, in fact, as soon as the fix was available.

    anyway, as far as i know, you cannot access documents on the web with the database/view/noteID scheme in R6.

    • avatar
    • Doug Finner
    • Tue 8 Nov 2005 09:14 AM

    Jake,

    Just read the post and the responses and I think yes, the post was misunderstood. You use some words like 'security flaw' and 'scary' that seem to indicate that Notes/Domino is somehow unsafe and crackable. The reluctance to post for so long adds to that feeling. Bad design <> security flaw.

    I came away from the blog entry thinking 'yeah, so what, if I cared I would use reader fields'. Reading the discussion makes it clear that you meant to say that also.

    I think positioning the blog entry as 'yet another reason to use good security practices' and re-hash a bit that security by obscurity is no security at all would have made the point easier to understand.

    Good stuff and interesting way to think about securing a web facing site. Since I'm just stating into this part of Notes/Domino, it's good information for me to think about. Thanks.

    Doug

    • avatar
    • Jono
    • Tue 8 Nov 2005 10:01 AM

    Doug - agreed.

    Jake - to me it just sounded like you were actually worried about the 'flaw'. I guess if someone wasn't to follow proper security guidelines - it would be a worry. I'll put my obvious comment about using reader fields down to the time of the morning and lack of coffee :)

  2. >> The first view in a database takes hex NoteID of 116 (278 in normal numbers).

    >> Each view added after that is 4 greater and so follows a pattern like 120, 12d, 122, 126 etc.

    >> Documents start at a hex value of 8F6 (2294 in normal numbers) and also follow the same pattern.

    this might be true for a newly created database, but that can't be generalized. 0x8f6 could well be a form or any other design element.

    even if r6 doesn't allow those urls - i guess most designers that create dbs for notes (non web dbs) are aware that even readers could use script or private views to see / access documents without any restrictions. i'm pretty sure even in r5 times most web enabled dbs had efficient security settings...

  3. @Markus,

    Don't be so sure about the secure R5 environments.

    If I remember correctly the standard Lotus installation left all the system databases wide open.... or was that R4??? .. getting old ...:(

    • avatar
    • pr0gm4n
    • Tue 8 Nov 2005 11:09 AM

    I have been a Domino web-developer since 4.6, including some projects for "high profile financial companies".

    I always advice my customers not to replicate document containing "highly sensitive information" to their webserver.

    If some sensitive information need to be shared with externals, I prefer to place those documents in their own database where the ACL blocks for anonymous access.

    This setup is so simple that no developer, not even a newbie, can fail.

    • avatar
    • Wayne
    • Tue 8 Nov 2005 11:42 AM

    Jake,

    A good post as always. I'm glad that you've posted this info. It's one more place to point to and garner some knowedge that is not readily perceived just by reading the manual.

    While other more seasoned developers/admins may sigh and say "seen that already", It's the newcomers who get caught out. Especially when it is so easy to knock out something that just works as opposed to something that works and is secure.

  4. It's never a bad time to rehash good security practices.

  5. Glad you posted. Actually, "Security by Obscurity" is a misnomer. Actual security is done by protecting EVERYTHING, at each level (i.e. default no access) and then granting specifically as per need to know. And if you do this properly, you can and should crosscertify your friends AND YOUR ENEMIES, so you can authenticate them and prove their hacking attempts. And - please - I am too busy: do not bother hacking my public site, it's not domino based anymore ;-)

    PS: Running domino since it was called Notes R1.x

  6. Yes, for the record, NoteID is not a permitted access path for URLs in Domino 6 and higher. Beyond that, templates named with .NTF cannot be opened by URL (their ACLs are default weak to allow database creation).

  7. In fact, with Domio 5 there was no need to even know or guess a view ID at all. Actually any view name - even non-existing ones - did work along with the NoteID for web access. Like in

    {Link}

    It also worked with the famous "0 view" (nothing special about the 0 in reality). As NoteIDs are guessable, this was a real problem for not properly secured apps.

    This has definitely changed from R6.0 on, and it really never was a security flaw of Domino. It was a security flaw of lazy designers.

    • avatar
    • Jerry Carter
    • Thu 10 Nov 2005 10:27 AM

    Seems *perhaps* someone is trying this out against some of the blogs hosted on DDNs blog server. It's been up and down for several days and is currently down.

    Jake - any interest in hosting some of the other Domino Blogs on your server?

Your Comments

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


About This Page

Written by Jake Howlett on Tue 8 Nov 2005

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