Message-ID: <441A977B.5030505@home.se>
Date: Fri, 17 Mar 2006 12:03:23 +0100
From: exon <exon@...e.se>
To: Hans Wolters <hans.wolters@...all.nl>
Cc: matt@...isionpower.com, bugtraq@...urityfocus.com
Subject: Re: Invision Power Board v2.1.4 - session hijacking


Hans Wolters wrote:
> Matt,
> 
> On 16-mrt-2006, at 15:55, matt@...isionpower.com wrote:
> 
>> This report is ridiculous and quite frankly shows that the author  
>> does not understand how IPB works.
>>
>> Yes, the author is correct in finding that if you: copy the user's  IP 
>> address, copy the user's user-agent and copy the user's session  ID 
>> then they can "hijack" your session.
>>
>> That's because, to all intents and purposes you are the same person.
>>
>> A stateless HTTP application HAS to authenticate against SOMETHING.
>>
>> This report is bogus. Feel free to relabel it "Stateless HTTP  
>> authentication potential vulnerability" and remove it from Invision  
>> Power Board's category.
> 
> 
> You finally answered, that is something. We can continue this  
> discussion here so you can't close
> the topic like you did on the Invision Board site.
> 
> I will state again what the problem is:
> 
> 1. Users behind a proxy that do not initiate the X-FORWARDED-FOR  header 
> will all have the same
>     ipnumber.
> 
> 2. A user using an OS that can close the Desktop session without  
> killing the applications like the browser
>     will possible still be logged in into the targeted Invision  Board 
> site.
> 
> Both situations will make it easier to hijack the session once it is  
> installed on a server with tranparent sessions.
> 

But you still need to see the session-id to be able to hijack the 
session, and for that you need to see someones desktop. If, on the other 
hand, you can guess session-id's in a reasonable timeframe (incremental 
ID's, for example) and you don't care which session you steal then this 
might be a real vulnerability, except that it also uses originating IP, 
which you can't know if you're guessing the session id.


> You stated that the user agent can be used for additional checks. Let  
> me state that it is very easy to fake that. Once you can get the  
> specific user to visit a site where the session id is disclosed you  
> have both the session id and the user agent.


Isn't that what's known as XSS? Granted, if you can get someone to post 
the session-id to some site you control and then get the same IP as the 
original user (you could simply spoof it and send blind queries fe). 
This is not so different from phishing scams. If you can get someone to 
enter his/her username and password on your site you'll own their 
account too.

If Powerboard can be duped into including the session-id in a link to 
some other site then it is a real vulnerability. Otherwise it isn't (or 
rather, it isn't Powerboard specific, but a result of how HTTP sessions 
work, just like Matt said).


> At that moment you will  be 
> able to login as that user _if_ you have the same ipnumber (behind  a 
> proxy for instance).
> 
> Faking the user agent itself can be done with lots of tools or even  at 
> the command line.
> 
> As for hiding the session id, in certain situations it will keep  
> showing up not matter what you do. Popups, javascript, etc.. You must  
> be absolutely sure this will not take place.
> 

I think that's what he meant by "hiding the session-id".


> One last thing, you might be right when you state that I do not know  
> how the board works, however, I do not need to know since the session  
> hijacking itself reveals how it works, you are not checking enough in  
> certain situations.


What do you suggest more to check? session-id and originating IP are the 
only two variables available for authentication, unless you send the 
username and password every time (http BasicAuth).

[ silly gauding removed ]

/exon

Powered by blists - more mailing lists