Saturday, December 30, 2006

Detecting Logged In Users

I just wanted to comment on the various ways of checking if people are logged in that I've seen, and propose a (rather unlikely) method of my own.

Uses for the knowledge

Personally I'm rather sceptical about profiling users and don't really see a point to it. The most dangerous application of this that I could come up with is if you check if a person is logged into a bunch of banks, and then send them off to the appropriate phishing page for their bank. And phishing is generally only reliable when the user clicks on a valid looking link in a valid looking email - or so we'd hope. So even the danger there seems limited. Sure, maybe you could provide ads to competing services or something, but unless you've got some great deal or something, you're probably not going to have any luck converting people.

Now sure we could use these methods to detect whether a user is logged in before running an XSS/CSRF attack, but unless the attack requires some level of user interaction (like having them move their mouse over something, even if you make the element take up the whole screen for a second), you have no need for it. Sure if the attack requires user interaction, then you need to be sure that the user is logged in because then there is a chance that you may raise suspicion, and if you've got more than one XSS/CSRF attack to conduct you can't have the user get suspicious, otherwise you might not finish running them all.

But I can't think of any other applications, and those two don't exactly seem like

Jeremiah's Firefox Javascript Error Hack

Jeremiah's idea is great, but like almost everything else, sadly not infallible. I was talking to birdie from today and he mentioned to me that he was having no luck getting Jeremiah's Firefox Javascript Error hack to work because all the pages had an identical doctype at the top of the page, on which the Javascript engine always errored out on and there were no pdfs or images or other resources which were only available to users. So it seems that there is really no need for some elaborate defence where you specify an error handler on your page to override our error handler, or anything similar - you just need to make the first couple of lines of each page identical, and what better thing to put there than a doctype tag so that you're actually conforming to some standards at the same time.

Timing Attacks

But it didn't stop there, he also sent me the following link on using timing attacks to detect whether users are logged in: because he thought it was a better way.

Now while I'd seen it before, I hadn't really thought about it before, and just discounted it as something that might be used, but probably rather unreliable, so I went and did some test and here are my results when I ran his code:

Time when logged out:
5469, 2781, 2859, 1234, 2906, 1125, 1047, 2734, 5032, 2704

Time when logged in:
672, 2688, 6469, 719, 703, 1859, 688, 1718, 750, 1782

So while the average time when logged out is definitely higher, there is a great amount of overlap, and chance for error, and this is only on one network connection.

But It got me thinking, how else would I be able to tell that a user is logged in, and i came up with:

Semi-Open Redirects

I was thinking, in what cases can you find anything about what's in an iframe? Well, when its on the same domain as your script is, and what better way to get users onto your domain than to be redirected there from the site you are 'attacking'.

Now, just to explain what I mean by Semi-Open. Firstly what is an Open Redirect? An open redirect is one where you can send anyone anywhere, essentially one where you do no validation on who you send where. Now my definition of a Semi-Open redirect is one who will send certain people anywhere, more specifically logged in users anywhere. You can probably see where I'm going with this. The only other possible definition is sending everyone to only certain places, but thats completely useless to an attacker.

So if we find a Semi-Open redirect we can place it in an iframe, and if the user is logged in they will be redirected to our domain, and we will be able to get the iframe's location, otherwise we'll just error out.

Now, while I would have loved to have a example of an Semi-Open Redirect for everyone (I don't like posts without examples or PoC's), but I don't know where ro when I will actually find one, so I'll do the next best thing, I'll post a link to someone else's PoC, which has already been patched....Ok, so its not second best, or anywhere near second best, but its close enough for this article:

So in the end, while most of these ideas are rather cool (especially Jeremiah's), they don't seem to be always reliable or even useful to me.

Anyway, I hope everyone found this little burst of two posts interesting, because I'm awful at coming up with new ideas worth posting about regularly, but keep your eye peeled, I'm working on some interesting HTTP Response Splitting Payloads which I'll be posting once I get them working on Firefox and Opera 9 (something changed between Opera 8 and 9). If anyone who reads this is familiar with the Firefox source and would be willing to help me work out why things aren't working, please shoot me an email, I've been sitting on this idea for more than a month, and working PoCs for IE and opera 8 for at least 3 weeks....


David Kierznowski said...

Alex, I have been thinking along the same lines. WordPress has this issue (i.e. http://wordpress/wp/wp-login.php?

I was pondering over how a malicious worm could use this before launching:

Its an interesting idea and far more reliable (if present) then the others as it is cross-browser compatible.

Web app security info said...

It looks pretty interesting.

I would agree hat this vulnerability (Open Redirect),
If present gives you more accurate results.