Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Sessions?
Posted by: kirke
Date: September 24, 2006 03:05PM

is anyone interested in session related threats, vulnerabilities and attacks?
I'd vote for a new topic: Sessions
which serves as container for things like: session ...
fixations, hijacking, lockout, replay, ....
also
CSRF and session riding, and some more more sophisticated things

Options: ReplyQuote
Re: Sessions?
Posted by: rsnake
Date: September 24, 2006 03:59PM

I definitely am... where do you want it to live? I do have a CSRF section: http://sla.ckers.org/forum/list.php?4

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: September 25, 2006 05:38AM

Have seen the CSRF section, that's why asked.
I'd like a more general Session section, 'cause CSRF is just one method to exploit sessions (though CSRF is not strictly session based), there're much more.

Currently I've some about DoS an application (or it's human helpdesk:), enumerating username or passwords (more a logic attack than session, but may fit there also).
DoS an application is different to DoS the system.

Options: ReplyQuote
Re: Sessions?
Posted by: rsnake
Date: September 25, 2006 12:30PM

I actually just modified the CSRF section to include sessions since I think they are so similar in attack points. If it gets enough traction I'll pull it out seperately. I'm moving the thread into there as a result.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: September 25, 2006 06:35PM

not that bad, thanks.

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: September 29, 2006 02:25AM

here we go, let me know if I should open a new topic here.

This is a brief info about session handling at http://*.ckers.org/ .
Following observations:
- no automatic session log out at all
- session object is not destroyed after manual log out, sigh
- session fixation possible
- session hijacking possible (well, that's not magic 'cause it's a threat and not a vulnerability, and you can't do good countermeasures, but the way sessions are transported may disclose the session id on various places unintended)


Conclusion up to now (see date of this posting):
we can be absolutely sure that everyone skilled enough to these vulnerabilities can impersonate as any nickname here, if (s)he manages to trick the human owner of the nickname to click or visit special crafted links or pages (keeping social hacking beside).
Depending on the lazyness of the human behind a nickname, any post up to now may be from someone else.
Good to know, isn't it?
:-))

Session attacks are not as simple as XSS, hence there is no ready-to-use exploit posted. If there is one, that should go to the Full Disclosure list here anyway;-)

The information so far should be enough to keep eyes open.

Options: ReplyQuote
Re: Sessions?
Posted by: fayte
Date: January 04, 2007 07:01AM

Speaking of Session Hijacking...

What’s everyone’s take on the best solution? Seems to be many approaches; some I’ve read about are:

Link Sessions to IP
Link Sessions to header info
Use two tokens, one GET & one cookie
Continually change the sessionID

(I’m ignoring the usual bits here, i.e. SSL usage; re-authenticate for crucial areas etc)

Some people say don’t have any XSS holes in the first place but after this pdf issue is that ever possible?

Two that have jumped out are:

- Link the SSL layer to the application layer. This way the attacker has to spoof the SSL connection and steal the relevant cookie, I like this idea. I’ve heard Webogic can do this but I’ve not seen it in operation.
(http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rprs_sesd.html)

-If you have two tokens and continually change one. The principle here is that although the attacker can steal the session (if both are obtained) the application will notice that a session has been stolen. i.e. when the user continues to surf, the application will notice the correct SessionID attempting to be used with the incorrect variable data and then reset that session as a Hijack may have happened. this may limit the damage caused by the attack. (not perfect I know, and heavy on the server)

I’m no expert with this topic so please berate me if I’m spouting rubbish. Interested in any responses!

Regards,

Options: ReplyQuote
Re: Sessions?
Posted by: birdie
Date: January 04, 2007 07:48AM

When setting a cookie for a site (PHPSESSID=1337), then later someone else uses the pc and logs in to the target domain, and then you can set your PHPSESSID to 1337, is that what's called session fixation ?

Options: ReplyQuote
Re: Sessions?
Posted by: fayte
Date: January 04, 2007 08:44AM

Session Fixation is where the application uses SessionID value set pre-auth for post-auth too

Therefore if you can set someone's SessionID before they auth you can then access there session once they login as it wont change.

I would say what you're describing above is a lack of session timeout/invalidation?

Options: ReplyQuote
Re: Sessions?
Posted by: fayte
Date: January 04, 2007 10:14AM

The NISCC in the UK published a guide to Web Apps last year, I believe it was written by NGS. They have an approach to session management using three tokens:

www.niscc.gov.uk/niscc/docs/secureWebApps.pdf
Page 112

Quite involved so worth reading, basically three tokens all work together.

Options: ReplyQuote
Re: Sessions?
Posted by: birdie
Date: January 04, 2007 12:06PM

fayte Wrote:
-------------------------------------------------------
> Session Fixation is where the application uses
> SessionID value set pre-auth for post-auth too
>
> Therefore if you can set someone's SessionID
> before they auth you can then access there session
> once they login as it wont change.
>
> I would say what you're describing above is a lack
> of session timeout/invalidation?


No no, you misunderstand me. I then would go to my own computer, and set PHPSESSID to 1337, and then be logged in as them. I didn't mean to use the same computer as them after they have left.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 04, 2007 01:52PM

?

No,
the PHPSESSID is only a script session, it's killed after the script is closed. Or when a new session is initiated; like on a different PC.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 04, 2007 01:54PM

Quote

What’s everyone’s take on the best solution?

I always use session regeneration with sensitive content they want to change.

Options: ReplyQuote
Re: Sessions?
Posted by: fayte
Date: January 04, 2007 02:56PM

Thanks jungsonn, yeah I think session regeneration works well; can be a pain sometimes though.

Options: ReplyQuote
Re: Sessions?
Posted by: Mephisto
Date: January 04, 2007 09:46PM

@fayte

1) Link sessions to IP - This wouldn't work when you consider companies where all internal traffic is routed through a proxy. Any and all traffic coming out of the company would/could have the same IP address.

2) Link sessions to head info - Header info is easily manipulated.

3) Use two tokens, one GET & one cookie - This could be feasible if implemented properly.

4) Continually change the sessionID - This is another possible option.

One of the things I was toying with was to have an encrypted cookie, combined with a continuously changing value (GUID) on the page. Similar to a "one-time" password. Each request would dynamically generate a new GUID and on postback would validate the value and encrypted cookie was indeed a valid "session" combination.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 05, 2007 12:59AM

Oh I forgot:

I do make use of hashing the UserAgent into the session, in the next session or it's continuation, check the hash again see if the user-agent has changed. If yes, kill 'em all or do some other warning stuff.

But, yeah it's a combination like mephisto pointed out.

Options: ReplyQuote
Re: Sessions?
Posted by: hasse
Date: January 05, 2007 01:36AM

Mephisto Wrote:
-------------------------------------------------------
> @fayte
>
> 1) Link sessions to IP - This wouldn't work when
> you consider companies where all internal traffic
> is routed through a proxy. Any and all traffic
> coming out of the company would/could have the
> same IP address.

Couldn't you use the IP as a part of the check? Like hashing the IP the user connects from with something and then checking if what the user sends and what you get from the hash of his IP matches the next time he logs in.

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: January 05, 2007 11:01AM

@birdie
> No no, you misunderstand me.
what you describe is session hijacking (wether you steal the session id, or get by shoulder surfin' doesn't matter)

@all
> - Link the SSL layer to the application layer.
Visonys' (formerly Seclutions) Airlock can do this.
If someone has other links to get the SSL session id, I'm highly appreciate any hint.

> 4) Continually change the sessionID - This is another possible option.
good idea, sometimes called session tracking, or if you talk in goold old legacy systems fat client: build your application using a state mashine.
Anybody seen this for web applications? any Framework?

> I do make use of hashing the UserAgent into the session, ..
One idea to make session id's more tamper proove is to fill in user supplied data (user-agent, IP, timestamp, whatever) as much as possible, then add something only the application knows -aka the salt- then sign it, encrypt it. Such a session id is hard to break. But you won't find developers doing that 'cause they don't have a blackbox (aka framework) to be used, they are developers not developers ...

Options: ReplyQuote
Re: Sessions?
Posted by: fayte
Date: January 05, 2007 04:27PM

Thanks for the opinions!

The approach outlined in the NISCC doc is worth a read. Using three tokens seemed like and interesting idea. Im sure its not foolproof though.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 05, 2007 07:48PM

@kirke

I meant a SESSION variable, not in the phpsessid.

IP storage isn't that good, many have dynamic IP's which rotate around, It can be annoying to login everytime your IP changes, and the next time another user has that IP. UA fingerprint is pretty strict, just hash it, no need to salt or encrypt it cause it runs only in a SESSION variable or Database session check.

But, I run around with some digital signiature creation ideas of a user and store it in a database. that could contain the things you mentioned, but i'm still a little cautious with the IP though, it could throw too many false positives.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 05, 2007 08:02PM

BTW the phpsessid should always be (pseudo)random. the way it is inplemented in PHP is a relative secure approach. If you make your own, it could weaken it. because you can cryptoanalyse the phpsessid; you use an IP, timestamp, UA. that can be analyzed and can break your key to salt it. Encrypting the salted hash is overkill and not recommended. So, I think the best approach is to use a DB for fixed sessions, and dynamic session handling for the user. This could be UA fingerprinting, that way you make sure that when they want to change their account or something, they have to have the same PC and browser.

it would make a nice trap; if you make a function that logs the firsttime IP, UA, and other vars like browser plugins etc, then store the IP into a separet db field next to the fingerprinted session. and check that the next time the enter your site. Maybe they use Tor then, and you still would be able to identify them dispite the changed IP. such ideas i have to creat a digital signiature, gonna take a look at that soon, looks fun.



Edited 1 time(s). Last edit at 01/05/2007 08:04PM by jungsonn.

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: January 06, 2007 01:21PM

> I meant a SESSION variable, not in the phpsessid.
hmm, sorry don't know what you mean here.

Anyway, I didn't say that the IP or user agent or whatever is a secure way, it's just one way to raise the bar. I'm aware of the problems (proxy, faked UA, etc.) with that, hence I recommended a combination which then presumes that you have some logic to identify if just one parameter changes slighly.

I also agree that you better use the algorithms vor encrypting provided by your framework, rather than implementing your own. This does not mean that all frameworks do a better job than we can do;-) Session management is one of dark sides of most frameworks, unfortunatelly.

Options: ReplyQuote
Re: Sessions?
Posted by: birdie
Date: January 07, 2007 05:39AM

birdie Wrote:
-------------------------------------------------------
> When setting a cookie for a site (PHPSESSID=1337),
> then later someone else uses the pc and logs in to
> the target domain, and then you can set your
> PHPSESSID to 1337, is that what's called session
> fixation ?

I don't think you guys quite get me. If you on computer #1, set the PHPSEESSID to 45 (before the target domain has given you one), then all further requests and login will be using that PHPSESSID (where the value is 45).

So you set the PHPSESSID to 45 on computer #1, then you leave the room, and another person comes and uses the computer and logs in, the PHPSESSID 45 will be used.

Then you go on computer #2 and set the PHPSESSID to 45, and then you will be logged in as the guy who came into the room and used computer #1.

Options: ReplyQuote
Re: Sessions?
Posted by: jungsonn
Date: January 07, 2007 11:53AM

Not quite.

Cause when you exit the session (close browser) or leave it for 20/25 minutes alone (thats the session timeout mostly in PHP), the session is gone forever. -unless some bad caching- the session isn't fixed, so no one can use it after you. If that was the cause then we would have tons of problems.

Options: ReplyQuote
Re: Sessions?
Posted by: kirke
Date: January 07, 2007 02:56PM

birdie, yes what you describe in your last post is session fixation

Options: ReplyQuote


Sorry, only registered users may post in this forum.