Wedge

Public area => The Pub => Off-topic => Topic started by: MultiformeIngegno on August 22nd, 2012, 02:02 PM

Title: PHPSESSID Brute force
Post by: MultiformeIngegno on August 22nd, 2012, 02:02 PM
http://blog.ptsecurity.com/2012/08/not-so-random-numbers-take-two.html
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 02:43 PM
Fucking wonderful. I'd note that if you were actually brute-forcing PHPSESSID you'd probably notice it.

What this suggests to me is that we should do exactly as I proposed some time ago - don't store any sessions for guests, meaning you never use PHPSESSID.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 22nd, 2012, 03:32 PM
No guest sessions is unlikely, to me... Can't we just store sessions per IP address? (Didn't we already have this discussion..?)
Posted: August 22nd, 2012, 03:27 PM

And I don't understand that confusing page, really -- what exactly does it do in reality?
And shouldn't this be a private topic?
And PHPSESSID -- can't we just get away by changing the var name? :lol: :lol: :lol: That's something vblamer would do I'm sure!
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 04:03 PM
Quote
Can't we just store sessions per IP address? (Didn't we already have this discussion..?)
Yes and I explained why it's impractical. Especially since as part of that discussion I explained with great frustration why all the benefits of actually removing sessions for guests would be completely erased (as well as making them inherently unreliable) if tracking by IP were introduced.
Quote
And I don't understand that confusing page, really -- what exactly does it do in reality?
The secret behind PHPSESSID is that the session ids are supposed to be unguessably random. But if you can predict session ids you can hijack sessions without having to bruteforce every single session id.
Quote
And shouldn't this be a private topic?
*shrug* It's a publicly available page.
Quote
And PHPSESSID -- can't we just get away by changing the var name?
That's called security by obscurity, and it is at best a temporary workaround. It won't be hard even to automate that one.

On the other hand, if every single session went via our own handling, we could safely disable PHPSESSID and be done with it, though even then it's still going to be broken for users who don't use cookies and search engines that don't handle cookies are still going to screw around with the guest count, much as they do with every other forum system that doesn't use PHPSESSID and do it via the session.

Yet again, it's unreliable and we're still worrying about it :/
Title: Re: PHPSESSID Brute force
Post by: Nao on August 22nd, 2012, 04:50 PM
It's too complicated for me.
- If PHPSESSID being 'guessable' is the problem, then it's also a problem when it's stored in a cookie. Meaning, we can't have guest sessions AT ALL. Of course I'm not sure at which point we're using sessions for guests, but still..?!
- Guest count is important to me, although I agree that it's unreliable at best (if only because there are countless unnamed bots over the web.) But I can already see people saying, "ever since I installed Wedge, my forum's visit count has dropped by 1857%! This is an outrage to SEO gods!"
- And yes, I have this annoying tendency to forget about earlier topics... So many things we discussed in the past. So many features/ideas we decided to implement, but none of us added it to a to-do-list, and it gets forgotten forever etc...
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 05:04 PM
Quote
- If PHPSESSID being 'guessable' is the problem, then it's also a problem when it's stored in a cookie. Meaning, we can't have guest sessions AT ALL. Of course I'm not sure at which point we're using sessions for guests, but still..?!
It is a problem but it's not the problem you might be thinking of.

If session ids are guessable, and can be brute-forced, they can be brute-forced for session spoofing. Delivery method of that makes no difference.

As far as using sessions for guests, the answer currently is all the time. Every request either creates a new session or perpetuates an existing one, with the intent to try and get an idea of the number of 'unique' browsers.

That alone is made farcical by search engines that send multiple instances of bots at the same time.
Quote
- Guest count is important to me, although I agree that it's unreliable at best (if only because there are countless unnamed bots over the web.) But I can already see people saying, "ever since I installed Wedge, my forum's visit count has dropped by 1857%! This is an outrage to SEO gods!"
Anyone who really cares is going to install an analytics package anyway, which is probably more reliable than Wedge doing it itself, if nothing else it will be excluding bots.
Quote
- And yes, I have this annoying tendency to forget about earlier topics... So many things we discussed in the past. So many features/ideas we decided to implement, but none of us added it to a to-do-list, and it gets forgotten forever etc...
You and me both. It's just something I was pretty adamant about... ;)
Title: Re: PHPSESSID Brute force
Post by: Nao on August 22nd, 2012, 05:16 PM
Quote from Arantor on August 22nd, 2012, 05:04 PM
If session ids are guessable, and can be brute-forced, they can be brute-forced for session spoofing. Delivery method of that makes no difference.
OTOH, anything with a ID less than 2 million bytes long will be guessable by brute force... It's just that something was discovered that makes it faster to brute force.
Quote
As far as using sessions for guests, the answer currently is all the time. Every request either creates a new session or perpetuates an existing one, with the intent to try and get an idea of the number of 'unique' browsers.
So, the alternative would be..? Storing a log of all recent guest requests, along with IP and requested URL? Otherwise, what are we gonna show in whosonline..?
Quote
Anyone who really cares is going to install an analytics package anyway, which is probably more reliable than Wedge doing it itself,
I do care (a bit) about stats, I check them at least every once in a while (like, 6-7 times a year), and yet if I suddenly found myself without any non-member stats, I'd be quite upset... And I'll never use GA for something like that -- it's okay for websites that sell you something, I guess, but we're talking about a forum system... GA will only make it slower.
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 06:46 PM
Quote
OTOH, anything with a ID less than 2 million bytes long will be guessable by brute force... It's just that something was discovered that makes it faster to brute force.
Brute forcing a couple of billion combinations is sufficiently big it's going to be noticed. But if you can do a much smaller number of requests and be able to understand how mt_rand is going to be seeded, you can access sessions with a much, much lower number of hits, probably enough it's going to get under most radars.
Quote
So, the alternative would be..? Storing a log of all recent guest requests, along with IP and requested URL? Otherwise, what are we gonna show in whosonline..?
Which is the sticking point of the argument. I do not believe who's online is actually that useful for guests, and I have long believed this to be the case. But there are enough people that seem to believe it actually tells you something meaningful that it made me want to leave it alone.
Quote
I do care (a bit) about stats, I check them at least every once in a while (like, 6-7 times a year), and yet if I suddenly found myself without any non-member stats, I'd be quite upset...
But what would the theoretical number of visitors (which is going to be inaccurate by anything from a few percent to potentially an order of magnitude) actually tell you?
Quote
it's okay for websites that sell you something, I guess, but we're talking about a forum system... GA will only make it slower.
*shrug*
Title: Re: PHPSESSID Brute force
Post by: godboko71 on August 22nd, 2012, 06:51 PM
Most hosting comes with some sort of stats system, so GA is not required to have more accurate stats.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 22nd, 2012, 06:58 PM
Quote from Arantor on August 22nd, 2012, 06:46 PM
Brute forcing a couple of billion combinations is sufficiently big it's going to be noticed. But if you can do a much smaller number of requests and be able to understand how mt_rand is going to be seeded, you can access sessions with a much, much lower number of hits, probably enough it's going to get under most radars.
But the thing is, once you get a forum up and running... Are you spending your time checking for weird session behavior? I would bet not...
Quote
Which is the sticking point of the argument. I do not believe who's online is actually that useful for guests,
Well, it's useful for me: (1) spotting what could be a bot, (2) spotting links that shouldn't be accessible to guests and yet are being accessed, (3) generally determining whether my host is cutting my access because I have too many regular users (like, was I mentioned on a high-profile blog?), or a horde of spammers/hackers/whatever, or just your usual Chinese search engine not giving a shit about your resources...
Well, I'm certainly accessing the Who's page more often than the intrusion log. :)

All in all... Well, I'd rather spend this week making some progress in other areas :P
Title: Re: PHPSESSID Brute force
Post by: nend on August 22nd, 2012, 07:20 PM
I wonder how this would work on a grid/cloud setup. :hmm:

At minimum I usually have four to six servers handling request. I also wonder how these sessions work in this setup. Is there some sort of syncing going on between them that they somehow look like one system.

No matter, it looks like session ids are predictable. What does this actually mean being able to guess a session? The only thing I can think of is maybe the ability to SPAM a little easier and the ability to guess another networks session. Even if you get another networks session, IP addresses are unreliable and the total security package doesn't use sessions alone, if it did that then it would be open to attacks to an identical IP on the same network. Thinking about hijacking sessions even if your able to spoof another networks IP address the server isn't going to send you anything back and plus you don't have a cookie.

Sorry I am having trouble figuring out what this actually means.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 22nd, 2012, 08:27 PM
I find it a bit sad that someone would release a security report like this one -- i.e. something that can be applied to any dynamic website, and thus can't be 'fixed' magically by something else... (Like a dev patch!)

Don't worry, I have trouble understanding myself the implications of that page.
Heck, maybe it's really not much to worry about. Or maybe it is, for everyone, and it's an early Apocalypse Christmas 2012!
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 08:58 PM
OK, here's the deal. If an application relies on PHPSESSID to handle sessions for anything of any 'security', you're screwed because you can spoof a user's session - right up to taking over a user's session while they are logged in.

In our case, PHPSESSID is only used for guests, so should a session be spoofed, there's no immediate risk.

I'm not sure, though, whether the same risk is also applicable to session_id() or not, if it is there's a much bigger problem.
Quote
But the thing is, once you get a forum up and running... Are you spending your time checking for weird session behavior? I would bet not...
That's what I mean. If someone brute-forces in the manner you're thinking, they're going to generate an obscene number of requests and even the most inept host is going to notice that. But with this technique, session stealing is potentially within the region of requests where hosts may or may not notice it.
Quote
Well, it's useful for me: (1) spotting what could be a bot
Unless you've hacked it to also display the user agent, the odds of being able to tell a bot just by what they're 'browsing' are going to be slim.
Quote
(2) spotting links that shouldn't be accessible to guests and yet are being accessed,
Have you noticed any?
Quote
(3) generally determining whether my host is cutting my access because I have too many regular users (like, was I mentioned on a high-profile blog?)
I suppose there is some merit to that, but you don't need to do that by tracking sessions. Using the access log will give you the same general information.
Quote
Well, I'm certainly accessing the Who's page more often than the intrusion log.
Yes, but what does it actually tell you?
Quote
At minimum I usually have four to six servers handling request. I also wonder how these sessions work in this setup. Is there some sort of syncing going on between them that they somehow look like one system.
I don't know how your system is set up, but the conventional way to set this up is to push the sessions to a single shared resource, and load/save sessions from there, for example I've done this in the past using MongoDB to be a session store, across multiple systems.
Quote
No matter, it looks like session ids are predictable. What does this actually mean being able to guess a session?
If you can guess a session id, you can theoretically spoof that session. It's a form of session fixation bug.
Quote
Thinking about hijacking sessions even if your able to spoof another networks IP address the server isn't going to send you anything back and plus you don't have a cookie.
That's the point: you do not have to spoof the IP address. The IP address is merely a component of the hash, you don't have to actually be on that IP address, because it's a *hash* and thus the IP address is not recoverable.

This is why it's important: spoofing a session just relies on you being able to figure out the session id. Creating a cookie is a piece of the proverbial, it's just a header attached to the request. Fortunately in Wedge's case you do need to know what the contents of that cookie are, and it's a bit more than just the session id, so it is physically harder to spoof. But not impossible.
Title: Re: PHPSESSID Brute force
Post by: nend on August 22nd, 2012, 10:43 PM
Can't you just check the IP address and see if it matches the one in the session. I know of some problems that this may cause when a lease is renewed with the ISP but maybe you can ignore the session information and create a new one like if they didn't have a session to begin with.
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 10:52 PM
Quote
Can't you just check the IP address and see if it matches the one in the session
For the second time... no.

Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
Quote
but maybe you can ignore the session information and create a new one like if they didn't have a session to begin with.
Sure you can but that's not really the point.
Title: Re: PHPSESSID Brute force
Post by: MultiformeIngegno on August 22nd, 2012, 10:53 PM
Quote from Arantor on August 22nd, 2012, 08:58 PM
I'm not sure, though, whether the same risk is also applicable to session_id() or not, if it is there's a much bigger problem.
It is according to the words of the guy who gave me that link.
Quote from Arantor on August 22nd, 2012, 08:58 PM
That's what I mean. If someone brute-forces in the manner you're thinking, they're going to generate an obscene number of requests and even the most inept host is going to notice that. But with this technique, session stealing is potentially within the region of requests where hosts may or may not notice it.
It's not a solution or a thing to be reassured of. Security can't rely on actions taken by other persons (maybe).

What's the /dev/urandom thing?

EDIT: Ok, I read about urandom.. seems it's the maximum security method, but it's very likely slow, isn't it? It gathers all environmental data + the use of PRNG..
Title: Re: PHPSESSID Brute force
Post by: nend on August 22nd, 2012, 11:08 PM
Quote from Arantor on August 22nd, 2012, 10:52 PM
Quote
Can't you just check the IP address and see if it matches the one in the session
For the second time... no.

Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
You can always save it in the session vars. :whistle:
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 22nd, 2012, 11:13 PM
Not in Wedge you can't.
Title: Re: PHPSESSID Brute force
Post by: Pandos on August 23rd, 2012, 10:27 AM
So what about the php build in session_regenerate_id() funktion?


Perhaps not the perfect solution but it will be more difficult to fix an session.


What do you think?
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 23rd, 2012, 02:51 PM
I already actually hinted at this in my thoughts above. The session id is still generated in the same manner and is thus still vulnerable.

There are certain actions that already call session_regenerate_id() exactly as it should (logging in, logging out, admin validation) but there's only so frequently you can call it before things get messy and you end up with session timeouts.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 23rd, 2012, 03:06 PM
Quote from Arantor on August 22nd, 2012, 10:52 PM
For the second time... no.

Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
Going to play dumb here...

- We have the last login IP in the members table
- We have an associated PHPSESSID, right...? (If not, we can record it.)
- We know that some people might want to break the ID... But they don't have the same IP. Why not force IP changes to confirm the password or something?
Title: Re: PHPSESSID Brute force
Post by: Pandos on August 23rd, 2012, 03:09 PM
Sometimes poeple have the same IP:
like Proxys and Networks (AOL)...

Title: Re: PHPSESSID Brute force
Post by: Arantor on August 23rd, 2012, 03:18 PM
^^ This. The IP should not be trusted for any such thing.

The best one is for intranets where potentially every user has the same IP address.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 24th, 2012, 12:43 AM
Still reduces chances of session hijacking by 99%...
We don't need a solution for everything. We just need stuff that helps.
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 24th, 2012, 02:29 AM
Using IP binding might stop 99% of session hijacks. It also just happens to screw up a significant proportion of legitimate users too, enough that you don't want to have to deal with the 'it's broken' support reports.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 24th, 2012, 08:10 AM
Why would they be screwed I we just ask them to confirm their password, like in the admin area?
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 24th, 2012, 02:34 PM
Because you'll have users whose IP changes pretty much every request. Which means every other page they see will be a password confirmation one... yay.

Then you'll get complaints of 'it's not remembering my password', which means people will be throwing bugs left and right when it's working entirely as designed, but that doesn't mean it's the *right* design.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 24th, 2012, 06:21 PM
Again, you party pooper :P

- We don't give a damn about guests having their PHPSESSID stolen, of course.
- There remains the issue with members...
- Can you quote a single case where someone would change their IP all of a sudden while browsing? It would definitely disrupt more than one site...
- How 'bout accepting an IP change in the same range?
- And if we provide this as an option, disabled by default, it's a win-win situation...
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 24th, 2012, 07:42 PM
Quote
- We don't give a damn about guests having their PHPSESSID stolen, of course.
Correct.
Quote
- Can you quote a single case where someone would change their IP all of a sudden while browsing? It would definitely disrupt more than one site...
AOL users. Mobile users. People intentionally changing their IP address to fool stupid proxy blockers or some types of ban.
Quote
- How 'bout accepting an IP change in the same range?
Depends on the range. Some of the above need different sizes of range to others.
Quote
- And if we provide this as an option, disabled by default, it's a win-win situation...
I don't think it is a win-win situation. There are enough people that mess around with harmless settings in SMF and cause trouble and need support. Give them something that could potentially lock them out, that they can only fix by phpMyAdmin? No chance.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 25th, 2012, 12:14 AM
- Range can even be country-based... (Or continent-based if you want. I already rewrote the list of all these IP ranges a couple of months ago for the IP tracker page, we could reuse that for IPv4 IPs!)
Since most spammers are from a different country than the 'expected one', it could be an okay solution. After all, do you know of many people who would move to another continent while their session is opened..? :P

- Thing is, you tend to go a bit much these days for what seems to have become your favorite Wargames quote (and yes it's also one of my cult movies :P), I'm sure you know what quote I mean, but if we keep deciding not to do something, we'll just end up doing nothing at all... SMF died out for years because people were too afraid to rework it!

I'll whip up a quote of my own then...
It's better to have coded and gotten bugs[1], than never to have coded at all.

:edit: Oh come on, that oneat least warrants a Like! :P
 1. I'm not talking about crabs, you naughty naughty boy!
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 25th, 2012, 12:36 AM
Quote
- Range can even be country-based...
For now. IPv4 country lists are going to start to become more and more confused as the world is just not ready for IPv6 and we'll see more and more blocks change hands.
Quote
Since most spammers are from a different country than the 'expected one', it could be an okay solution. After all, do you know of many people who would move to another continent while their session is opened..?
Some of the big IPs have been known to change all four octets of an IPv4 between requests. It happens a lot less now but it's not unheard of. We simply cannot use it.
Quote
Thing is, you tend to go a bit much these days for what seems to have become your favorite Wargames quote
No, it's not because the only winning move is not to play. There are reasons why this stuff isn't in SMF or Wedge. If I genuinely thought for one moment that IP binding of any shape or form was even remotely practical for anything, I'd have implemented it. As it stands I still need to remove the ban system, because IP bans are so ridiculously broken it's incredible, and not only because there's no IPv6 support.

You do remember what happened with SMF Hacks, right? Where he put a ban on my IP address and ended up losing so many legitimate customers because of it?

I even contemplated actually removing any kind of IP address tracking from Wedge at one point, only to realise that people would expect it to be there and no matter how much I shouted that it doesn't work, people wouldn't listen. There are a precious few cases where it does work (i.e. whitelisting for search engines against known IP address blocks) but for anything else it simply should not be used.

Where we are with it is about the best we can realistically be, because while I'm all for keeping things secure, I'm not going to make it more secure for some and generate MASSES of bug reports for 'it doesn't work'. Because I can't in good conscience turn around and say it's by design, when all it's demonstrating is how the design is wrong.

The ONLY way I'd support it is if it were implemented as an option but not allow it in the actual admin panel itself. That way only the people who actually understood the implications would be able to turn it on in the first place.
Title: Re: PHPSESSID Brute force
Post by: Nao on August 25th, 2012, 07:57 AM
That's all I'm saying... An option, disabled by default ;)

(Removing the ban system? You mean the IP ban system, right...?)
Title: Re: PHPSESSID Brute force
Post by: Arantor on August 25th, 2012, 01:24 PM
Quote
That's all I'm saying... An option, disabled by default ;)
And no admin panel option.
Quote
(Removing the ban system? You mean the IP ban system, right...?)
No, removing the entire ban system and replacing it with something that is actually more useful.(http://wedge.org/blog/6789/banning-and-what-i-want-to-do-with-it/)