Re: Invision Power Board v2.1.4 - session hijacking

[exon <exon () home se>]

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