PHPSESSID Brute force

MultiformeIngegno

  • Posts: 1,337

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #1, 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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,046
Re: PHPSESSID Brute force
« Reply #2, 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!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #3, 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 :/

Nao

  • Dadman with a boy
  • Posts: 16,046
Re: PHPSESSID Brute force
« Reply #4, 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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #5, 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... ;)

Nao

  • Dadman with a boy
  • Posts: 16,046
Re: PHPSESSID Brute force
« Reply #6, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #7, 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*

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: PHPSESSID Brute force
« Reply #8, 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.
Thank you,
Boko

Nao

  • Dadman with a boy
  • Posts: 16,046
Re: PHPSESSID Brute force
« Reply #9, 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

nend

  • When is a theme, no longer what it was when installed?
  • Posts: 165
Re: PHPSESSID Brute force
« Reply #10, 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.

Nao

  • Dadman with a boy
  • Posts: 16,046
Re: PHPSESSID Brute force
« Reply #11, 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!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #12, 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.

nend

  • When is a theme, no longer what it was when installed?
  • Posts: 165
Re: PHPSESSID Brute force
« Reply #13, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #14, 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.