[ exploit ] use other users session

[Phobos123]

Hello,

I'm not english native but i'll try to be as clear as possible.
With php & Gd library activated you can create pictures.
Using .htaccess, you can use RewriteRule and redirect stream from an url to another. in this case : from a picture to a script.

RewriteEngine on

RewriteRule   mysignature.jp?g   http://mywebsite.mysubdomain.com/trap.php

Everytime you'll type / jpg you'll execute trap.php. Fine. This is not an exploit.
Anyway, you can execute anything using this and gather some datas.

PHP adds a dot before domainname if it session.cookie_domain exists.
cf. php.net comments :

Be careful when setting a domain value. The browsers have curious results (I tested with FireFox 3 only!).

If session.cookie_domain is "", then your browser will probably make the cookie only available for your domain "www.example.com". That's secure since subdomains probably cannot access the cookie.

If the session.cookie_domain has a value, for example "www.example.com", all browsers which are according to the RFC, will add a "." prefix to the domain. So "www.example.com" will be converted to ".www.example.com" by the browser. Now the cookie is not as secure as the cookie above since it is also accessable at subdomains.

Strange...

i've bolded the important part of it. I PRESUME this is the source of the issue.

Now, take a look at this:
-> i've put a trapped picture as signature.
-> trapped script from picture is executed on a subdomain of the ipb's location.
-> i can gather any variable stored as superglobal like $_COOKIE and get a lot of informations:

Cookie example :

[forum_read] => a:56:{i:79;i:1238014011;i:92;i:123[...]1233015941;i:9789049;}

[ipb_stronghold] => a1f0df950ff6a473ba85de272482ad86

[ipb-myass-div] => 440,231

[rte-sidepanel] => open

[collapseprefs] => 63,77

[member_id] => 1234[color="#FF0000"]<---[/color]

[itemMarking_forums] => eJxLtDK[...]ZcMAchED0,

[itemMarking_core] => eJxLtDK[...]ZcMAchED0,

[itemMarking_members] => eJxLtDK[...]ZcMAchED0,

[itemMarking_calendar] => eJxLtDK[...]ZcMAchED0,

[itemMarking_shoutbox] => eJxLtDK[...]ZcMAchED0,

[sfc] => 1273550243

[sfct] => last searched items

[guestSkinChoice] => 1

[pass_hash] => 512e1ff505555f1801a53bcd011c20fd [color="#FF0000"]<---[/color]

[emoticon_sidebar] => 1

[session_id] => 0b743fe6266a4528310d14abb3d7e1c7 [color="#FF0000"]<---[/color]

[modtids] => ,

[coppa] => 0

[PHPSESSID] => fktu1iqk57r10te0ptj7kafma5

[anonlogin] => -1

Edit your cookie, change your own datas with thoses tagged by red arrows and you'll be logged as target user.
I've edited my cookie with fireCookie, an addon for the excellent firefox's module : firebug.

note: picture & php is used only to gather cookie. As soon as you've got ipb's cookie, you can log.


across domains return a void cookie. I'll try cross-site forgery soon :)

[Ryan H.]

Did you try testing this across domains, by any chance?

[ᴡᴅツ]

I've done something like this successfully on phpbb a while ago but never tested it on IPB. Thanks for posting it but please do so privately to the administrators next time when concerning sensitive information.

Regards,
Omega

[Phobos123]

Did you try testing this across domains, by any chance?

trying to but i'm running out of time :)

[Ryan H.]

Well, I believe you'll find it only works within a single domain, meaning its impact is limited at worst. Browsers are designed to mitigate the chance of such exploits.

Within domains, well, if someone is hosting out subdomains [which is the only practical situation], then that's certainly something they need to consider, but that's probably not an incredibly common situation.

[Mark]

So um... how to you plan to get an image (and a .htaccess file) somewhere onto the same domain as (or a subdomain of) IPB is running on?


First off, you're overcomplicating the process - there's no need to have an image and .htaccess file - a regular PHP file would be fine ;)
Secondly, let's assume that nobody running a website is stupid enough to have subdomains of their main domain on random servers across the Internet - if you have access to upload arbitrary files to the server, you could do a lot more damage that stealing someone else's session.

Basically, this isn't an exploit in IP.Board - if you're allowing people somehow to upload files to your server, you're going to have problems.

[Phobos123]

So um... how to you plan to get an image (and a .htaccess file) somewhere onto the same domain as (or a subdomain of) IPB is running on?

First off, you're overcomplicating the process - there's no need to have an image and .htaccess file - a regular PHP file would be fine ;)

Secondly, let's assume that nobody running a website is stupid enough to have subdomains of their main domain on random servers across the Internet - if you have access to upload arbitrary files to the server, you could do a lot more damage that stealing someone else's session.

Basically, this isn't an exploit in IP.Board - if you're allowing people somehow to upload files to your server, you're going to have problems.

i was presuming this shoudn't happen because of the ipb_stronghold variable. Wasn't it designed to prevent this ? Making an hash with ip & session_id, a special "token".
Is this only possible because of a disabled security option or is it a real crack ?

I'm still searching for an XSS/CSRF hack ... ;-)

[Mat Barrie]

Is this only possible because of a disabled security option or is it a real crack ?

I'm still searching for an XSS/CSRF hack ... ;-)

It's neither possible due to a disabled security option nor a real crack - the only way this could be of any risk is if the server administrator is an idiot, and allows you to upload random PHP files (and .htaccess files) to a subdomain they own.

This is not a valid hack.

[Wolfie]

This hack is sort of like this other hack, where if you have more than one set of keys, then someone can unlocked the front door to your house and walk right on in, if they somehow get their hands on that other set of keys that is. Better give those keys to me for safe keeping... :whistle:

[bfarber]

You've already pointed out clearly that you must be able to upload the .php file to the same domain. Already, that means file access, at which point you can do more damage.

Further - we don't use PHP sessions, so the session.cookie_name should largely be irrelevant anyways. The cookies that IPB sets, the administrator controls in the ACP. As the administrator, you can specify "www.example.com" as your domain, and a dot is not automatically added (although you can also add the dot yourself, which we frequently recommend if you have other stuff for your site on other subdomains).

Ultimately, this does not appear to be a security issue in IPB.

[Phobos123]

so ...
i think you don't figure clearly what i was talking about.

This is NOT about the cookie stealing method.
This is about how a cookie leeched can be used to log instead of the personn because there are no check about where is this personn and what was his session.
If you find a way to get it, this will work. There is no check tokens. If a XSS or CSRF hacks emerge, it will be usefull for this.

So ... First of all, i "leeched" my own cookie : (this session).
logged off.
then i changed my ip
then i logged in as another user (new ip, new session) : phobos123_example
then i c/p my previous id, "leeched" at step 1 : session_id cforums_session_id cforums_pass_hash cforums_member_id
then i F5 the page et was connected as phobos123.

You should put a token, unique for each connection : hash ( $_SERVER['REMOTE_ADDR'] + $_COOKIE[session, pass_hash, member_id )
This would prevent this "hack".

And yes, it is a breach in ipb security.

Hope it helped.

[Wolfie]

then i changed my ip

then i logged in as another user (new ip, new session) : phobos123_example

then i c/p my previous id, "leeched" at step 1 : session_id cforums_session_id cforums_pass_hash cforums_member_id

then i F5 the page et was connected as phobos123.

There is already an option to use IP addresses as a form of security. But here's something you are failing to grasp, HOW would that session information get stolen to begin with? If it's someone sitting at that computer doing a copy/paste like you did then DUH, they could easily hack into the persons account ANYWAY.

[Phobos123]

don't be so patronizing. I'm still searching for a cross domain cookie stealing method. Btw, using autolog cookie without location check is a very bad idea.

look at this : http://jaspan.com/improved_persistent_login_cookie_best_practice

[Matt]

The stronghold cookie did precisely that, it matched the session key with the first 3 octets of an IP address.

Unfortunately, it was a sound idea but a disaster in reality. Users with changing IP addresses found cookies never stuck or they were logged off during a session, etc. In the end most admins shut it off. We even shipped IP.Board with it switched off. In 3 we completely removed it much to the relief of all our techs.

What you are saying is correct. If you got my member ID and my cookie 'member_login_key' you could edit your cookie jar and log in as me.

The trick is to *GET* my member_login_key. XSS and CSRF will not be able to get it as IP.Board makes use of httpd cookies only, this means that the cookie is not exposed to the browser's javascript engine. The only way to get my member log in key would be to get into our database or to upload a PHP file to capture it. And as others have pointed out, if you have database or filesystem access then you have full access anyway.

[Phobos123]

The stronghold cookie did precisely that, it matched the session key with the first 3 octets of an IP address.

Unfortunately, it was a sound idea but a disaster in reality. Users with changing IP addresses found cookies never stuck or they were logged off during a session, etc. In the end most admins shut it off. We even shipped IP.Board with it switched off. In 3 we completely removed it much to the relief of all our techs.

What you are saying is correct. If you got my member ID and my cookie 'member_login_key' you could edit your cookie jar and log in as me.

The trick is to *GET* my member_login_key. XSS and CSRF will not be able to get it as IP.Board makes use of httpd cookies only, this means that the cookie is not exposed to the browser's javascript engine. The only way to get my member log in key would be to get into our database or to upload a PHP file to capture it. And as others have pointed out, if you have database or filesystem access then you have full access anyway.

Thank you a lot for this clear and full answer.

Regards

now as an evolution, isn't it possible to change stronghold as an array ? Make it creating a new token-item each time you're logging in.
logging from work : cookie_token[0] = xxx , written in database for checking
logging from home : cookie_token[0] = yyy , written in database for checking / add other cookie_token stored in db in cookie_token[] etc.

Then you would have two different cookies : one at work, one at home
work : cookie_token = array ( 'xxx' , 'yyy')
home : cookie_token = array ( 'yyy' , 'xxx')

With a few fifo slots available (5,10 ...)

[Cryptovirus]

I laugh. This vulnerability is entirely unfeasible and no one will do this unless you have some really desperate enemies.

Why do you not understand that the difficult part is getting your cookies itself? Do you hand them out on a plate, or give them to Santa with milk?

But, Crypto, surely someone will take all the usernames and generate random hashes for them, eventually arriving at the correct pass_hash, which they will then use to steal identities!

Dx

[Phobos123]

I laugh. This vulnerability is entirely unfeasible and no one will do this unless you have some really desperate enemies.

Why do you not understand that the difficult part is getting your cookies itself? Do you hand them out on a plate, or give them to Santa with milk?

Dx

please gtfo and gfy
Matt himself agreed there is a problem with this. I'm offering a simple and working solution. You're just sh*tting sarcasm.
"regards"

[Matt]

I didn't agree there was a problem. Or at least, I didn't think I did.

I only said that if you CAN get my cookie data then it MAY be possible to log in as me. The key point here is that it is virtually impossible to get my cookie key without accessing the database or uploading a PHP file to capture my cookie from the PHP engine.

[Wolfie]

@Phobos123

Let's put things into perspective. HOW would you (as the hacker) obtain the cookie data to be able to accomplish this? Without being able to get that, this 'exploit' is useless to say the least.

* Infect the victims computer? Well if you manage to do that, you could just as well use that virus to obtain passwords directly, which is better than just stealing a cookie.

* Hack the website itself? As has been mentioned, if you have that sort of access, you could do more damage than cookie stealing anyway.

The two best ways to do it both require compromising external sources and in both cases, other damage could be done that would be more beneficial than just stealing a cookie. It's like saying that I can open your safety deposit box from across another country despite the fact that I don't even have the key itself to do it. I would have to get the key from you and if I'm able to do that, why not just steal your credit cards, cash, checks, etc? I could do a lot more damage with that than I could just looking in that little box for stuff that may be nothing but junk to me.

[Matt]

I think we're done with this topic.

Phobos123 - thank you for bringing this up. I have no problem in taking another look at security.

Everyone else - It's important to note that any items discussed here are completely theoretical. We've always taken a pro-active approach to security and we're confident that the kind of attack discussed here is almost completely impossible.