Date: Fri, 17 Mar 2006 13:17:58 +0100
From: exon <exon@...e.se>
To: Hans Wolters <php@...all.nl>, bugtraq@...urityfocus.com
Subject: Re: Invision Power Board v2.1.4 - session hijacking


Please don't take this discussion off-list. You need to hit the "Reply 
to all" button in your Mozilla mailer.

Hans Wolters wrote:
>>Hans Wolters wrote:
>>
>>>Matt,
> 
> 
> 
>>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.
> 
> 
> Once you can trigger someone to visit another site where you can tail
> the logfiles you have the session id in some cases.
> 

But if there aren't any such vulnerabilities (that are known) in the 
current powerboard code this isn't a bugreport at all. You're simply 
stating the vector for a sometime-in-the-future attack exploiting a yet 
unknown vulnerability, which is a  waste of time since anybody with half 
a brain can figure it out anyway.

> 
>>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.
> 
> 
> It's not guessing...
> 

Until you find the bug where you can post the session-id somewhere where 
you can get your hands on it you're reduced to guessing.

> 
>>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.
> 
> 
> Like I stated before. Once you can insert js in the board that will visit
> another site then he does have a problem if transparent sessions are being
> used.
> 

Prove that "once" is now and you have a valid bug-report. Otherwise this 
is just noise.

> 
>>>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".
> 
> 
> The board has been having issues with XSS, he can't be sure this isn't
> possible in future versions.
> 

So? Apache has had pretty much every sort of exploitable vulnerability 
possible to create with a web-server written in C (which is quite a 
few). There's no guarantee it won't happen again, but there aren't any 
known bugs now, so we don't file bug-reports against it.

> 
>>>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).
> 
> 
> There has been a lot of discussion about this. It could be partly done by
> generating a new session id right after validating the excisting one. This
> would at least save the boards problem.
> 

If we want to be really paranoid we'd only access it over stateful 
connections encrypted with AES-2048 in CBC-mode with PKE-authentication. 
The question is where to draw the line. It's a stupid forum thing. Not 
an online banking app.

/exon

Powered by blists - more mailing lists