Joomla! Discussion Forums

Original Post deleted, copied and moved to new topic/thread at:
http://forum.joomla.org/index.php/topic,34620.0.html

This thread is for technical discussions about the Hack posted in the thread above.

Unified version of the hack is attached to this post.

Thanks,

GRAM

I got a question by PM, seemed appropriate to add the answer to this post.



No.  It uses the IP address of the requestor to create a session id, and to validate sessionids.  Joomla creates a randum number, combines it with your ip address, and then creates a session id by MD5'ing that combination.  The random number is assigned as the cookie value, the combination becomes your session id in the jos_sessions table.  For example:



This is not actual code, its just a representation of what takes place.  The session_id goes into the database, the cookie value goes into the session cookie.

When you request the next page, Joomla looks for a session id that matches md5($cookie_val . IP_address) in the database.  If it can't find one, it sets up a new session.  If you have no cookie (like a search engine) or have switched IP addresses, there will be no match for this query and you will get a new session.

GRAM

Is the sessionID generated only once every session (refresh)? I didn't look into the code, but I would expect (hope) that regenerate the session ID after every pageview

Important about the safety of your patch (and the current Joomla system) is the following: does Joomla regenerate the session ID after every pageview? If not, this patch will make your system even more vulnerable for hostile takeovers of your system by hackers.

I will try to explain this... A common way to take over a system is by stealing someone's cookie. It happens quite a lot actually, and there are a lot of hacks (new ones are beiing found all the time) to retrieve these cookies. XSS attacks are a common one, for example. Just a cookie won't give you direct access to the website though. For that, you need to have the right IP address as well (since it checks on the cookie's value +  IP).

It's possible to fake an IP, using a technique called IP spoofing. Despite what some hacker sites might tell you, this is even today not an easy thing to do and it requires quite some knowledge. This excludes some hackers that could try to gain access to your system.

However, imagine that you use smaller range of ip addresses, for example the first 3 parts of an IP adress as you suggested. And then, someone steals your cookie. He only needs to be in the same range to get authorised on the page, which is MUCH easier. You could actually just ask a friendly hacker which is on the same ISP for example...

@gram
To remove the only drawback you could find, wouldn't it be possible to implement a switch that, when set, pushes the login-functions to use the old way of authentication?

@Matjong
You say the site would be that much more vulnerable. With the provided cookie you can't get the IP-adress (although you will most likely have it anyway, because you had to get it from somewhere). If we leave that aside, it would be still possible to steal the cookie, do an IP-spoofing and log in, no matter if you used the old or the new way. If you got the cookie and the IP you're in, no buts and everything. The possibility that a hacker has the same range as you with the IP is allmost equal to zero. You can calculate that very easily. We open up the possibility to have an IP-adress in the same range as ours from 1 out of 2^32 (= 4.294.967.296 = 4.3 BILLION users) to 2^8 (= 256) out of 2^32. Only one user out of 16.777.216 will have an IP in that range. Theoretically. I know, the probabilitys are different when you take in account that the numbers are not randomly selected but more or less tied to ISPs. This still means that the hacker has to steal the cookie, use the same ISP AND have the luck that at the moment he dialed in, a slot in your ip-range has been vacated AND that he gets that slot. When I think about the telekom in Germany with as far as I know over 4 million DSL clients, not taken into account the several million ISDN/modem/by-call-clients, the possibility to win the lottery is bigger than getting in the same range. This patch makes Joomla less secure, but this less is only theoretical.

My 0.02$

Hackwar

Well, you have a point there. But you forget that sites usually have high represented groups of people from a typical country (for example, a Dutch site has mostly Dutchies so there is a much bigger change to share IP range). Or what do you think of a city that's specific made for a group of people in a specific town (I'm developing one atm, for a political party from the main capital in The Netherlands, where most likely only people from that city will visit)? Or internal networks (yes, there are people using it for internal networks I've been told ), with only one range? So your calculations are not really correct (besides the fact that not all ranges are used, and that indeed ranges are tied to ISP's). Another story from my own experience; I once had to log all IP domains on a forum with around 500 members, mostly Dutchies and Swedes. It was ridiculous how many of them shared the same range...

On the other hand you're right that it's not a 50/50% chance thing or something. However, as said there is a bigger chance and I still think you should try to aim for the maximum secturity; one hacked site is one site too much (in my eyes).

The best would still be to focus on implementing IPs regenerated with every pageview (but that's another discussion, and who knows, perhaps it's already built in since I didn't look into the code).

Hi Matjong!

My hack does not change Joomla's session methodology in any respect except the IP address, and then only if the webmaster chooses to do so (they use the AOL varient).  Joomla ceates a singular instance of a sessionid, at the time the session is established.  However, the cookie value is not the session id, only a portion of it.  In order to get the session, the site cracker has to be coming from the right ip address, or range in the case of the AOL varient.

As a network engineer, I spent a lot of time really thinking this one through.  I am familiar with how someone can steal a session,  and most of methods for doing it.  As you said, if someone wants to spoof an ip address they can do it from the network segment the original user is in.  Unfortunately, they can also be on an entirely different network, as long as it is in the routed chain.

For example, if my network address is 192.168.2.33 and I am on a 'C' network address space, there are 253 other potential addresses on my network that can steal my session (assuming they know what they are doing and how to spoof my address).  Now lets assume that  my network routes to the following network addresses in order to get to the internet: 191.206.2.33, 204.133.5.67, and 56.127.12 .  Each of these network addresses share a network segment with other nodes (addresses) and are in the route path of my network to the internet.  Using a sniffer, If a cracker manages to access one of these other networks, he can both see my packets, and sniff out return packets to get critical data.

Point is, that if someone wants to sniff my cookie value out, and hijack my session (via spoofing, or simply sniffing), they can do it from any of these connected (via routing) network segments.  It doesn't matter if they are in the same IP range on my network or not, if they can grab the packet, they can sniff, or spoof to get what they want.

In reality its a lot tougher than this, since the routers tend to be true routers and only share network segments with other routers, but I can tell you from my own experience (watching sniff traces) that getting traffic on my segment that did not belong to me was real common.  Just had to be destined for a router sharing the same segment.  If a cracker cracks a router, he's on that segment and open for business.

My problem was this.   I run a very popular user community on the internet, and a large number of the users in this community were AOL users.  They could not login unless the used the remember me option, and that caused two additional problems:

1. They now had a fully authenticable cookie traveling around with them, that could be duplicated by anyone, anywhere and would allow logins from any IP address on the internet.   Its a lot easier to login as that user than it is to hack their session, and with these values anyone can do it.  They simply duplicate the remember cookie, and they are in.

2. My session table skyrocketed with single page load sessions.  It was off the charts.

So I chose the compromise.  I realize that it makes it easier to steal a session for the casual site cracker, assuming they were in the right range of IP addreses, but it was orders of magnitude safer than having my users throwing out fully authenticable 'remember me' cookies with every single page load.   It was a compromise that I felt was appropriate, and most secure for the circumstances of my website.  I would love to have this as an option in my Site->configuration.  For sites where it is appropriate, I would enable it, for others that need to be more secure, I would not.

BTW... I have tested spoofing to test the security of some of my networks, and it is real easy to do.  But as you said requires a level of knowledge that very few possess.

As to the question of changing the session id (not the cookie value, but they are related), it does not change with each page load.  This works extremely well in environments where state is kept, it fails on the internet.  To do it right, you must change the value, then get an acknowledgement from the client that it has been changed before letting it take effect.  Otherwise, due to the nature of non-stateful traffic and the potential for packet losses etc....  You run the risk of getting out of sync.  Browser based traffic is inherently one way, you make a request, the server returns it.  There aren't any standard methods to force that browser to return an acknowledgement.  There are a few open source projects playing with this right now, but I am not aware of one that has succesfully deployed it.  I would love to find out that this had progressed.

In defense of Joomla, the sessions are stored in the Database, somewhat (although not entirely) reducing the risk of XSS.

XSS security has a lot to do with how your server is configured, and who you have to share it with (ignoring for the moment, security in your scripts).  I know thats an oversimplification, but it is where we can have the most impact on the problem.

Unfortunately, the very best way to secure a site right now, is to enable https.  I am hoping though, and watching for alternatives that can help.

Final note.  If we login and aren't on https, we just sent our password through the internet clear text.  Anyone with a sniffer and a will, who happens to be on the path our packet traverses, can have it at will.  Its easier than spoofing.  But I am working on a fix for that too 

Thanks for the input, it is valuable in the context of this thread.  I hope you understand why I chose to create the AOL hack, and that I know its not for everyone.

The bigger message here is really the non-AOL hack.  The AOL hack is just a varient for those who need it.  The standard hack has a huge impact on sessions being kept in the jos_sessions table, and the resultant server utilization during spider events.

Thanks,

GRAM

Nice reply, will look at it tomorow (or I will never hit the sack ).


And that, ofcourse, is a good thing. In general it sounds very usefull for a lot of people.

It would be real easy to do.  The problem is that session setup takes place before logins are processed.  But that really should be doable.  Let me play with the code a little.  The first version I setup did not have this limitation, but required duplication of a few (about 5) lines of code that normally would have been in the InitSession function to be duplicated in the login function.  I dropped it to make the code simpler and easier to read.

I will look it over again.  It might make sense to test for those post variables inside InitSession, and proceed with session establishment if they exist (not validate, just test for existance).

What kind of switch are you thinking of?  An additional post variable?

GRAM



GRAM

Yepp, just something simple, like '&non-aol-login=true' or something like that.

Great thorough explanations Gram!  I have a much firmer understanding of the details of this hack thanks to your encompassing overviews.  I see negligable new risk by implementing this code for my needs.

I've had the AOL variant in place for about a day now and my average sessions in the db (as well as total guests shown on the who's online) have been reduced by about 2/3rds.

The minor performance increase is consistent as well (at about 1/5 second faster pageloads).

-Tyler

Hi :D

I will comment on some parts of your reply, I might add some more later. :) It might be that I'm going a bit offtopic by time to time (to general Joomla secutiry), but that's because your hack is close to this discussion. :)


Well, in my personal opinion that's not a good thing, it should still be checked on IP. :) That means that people with dynamic IP info indeed can't stay logged in, but the secutiry risk is way too big if you can just copy a cookie. The only difference between the checkbox "stay logged in" is the difference between a session cookie and a casual cookie with longer lifetime. I think security should be above usabilitty most of the times (atleast by default). The best way is to to give users the possibility to set their level of secutiry on their site, there are more CMS's, forums and that kind of systems using this way. You can depend this security level on things like:

- Sequences in IP, less sequences means less problems. 3 sequences don't fix all problems, because some ISP's (even AOL) allow jumping between different class A networks, so from 100.100.100.100 to 200.100.100.100 etc. (I once read this on phpBB where people had the same problems... the developer built in different levels of sequences, even had the possibility to turn it off).
- Do or don't use a security check on IP with "user logged in" checked.

Besides, I think it should have check on timestamp as well. That way you guarantee that you need the most updated cookie + IP the be logged in.

>I have deleted a part of this post because it contained a security leak<

the function mosGetParam($_REQUEST, , ) should filter for HTML and any other code.

Edit, never mind

I think we agree on the majority of this. 

I can assure you that the 'remember me' cookie is not authenticated at all, as long as the password hash and username are correct.  If you have it, you are logged in.  There is simply no reason to spoof Joomla if you can get your hands on a remember me cookie.

I would not feel comfortable at all with relaxing the security of ip authentication beyond what is in the AOL hack.  It was developed during a period of time when the site it was on was getting blistered by hobby level crackers.  If the crack was on a website somewhere, they were trying it on that one. 

I had to tighten security, and with the problem with the remember me cookie, I think you now understand why I took the route that I did.  That site, and several others that I operate now have the 'remember me' option completely removed from the login code (not all sites though).  I wish that was an option under the Admin->configuration as well.  Everytime I upgrade the codebase, I have to rehack the login module, and joomla.php on these specific sites.

The relaxed authentication schemes you spoke of (complete IP sequences, option not to verify IP at all) make the window for the casual hacker far too wide and open sites the exact 'hobby' cracker I spoke of.  As a webmaster, I would not be comfortable with software that gave users that kind of option without some offsetting verification on some other parameter.  Although IP is one of the few that have any teeth (unless atttacker uses the spoofing and sniffing teqniques discussed elsewhere in this thread), its at least something.

Can you tell me more about the 'timestamp' you propose at the end?  I would really like to understand better.

Thanks!

GRAM

Thanks for checking in Tyler!!  Glad to hear that your session counts are down that far.  Thats incredible....

For the benefit of others in this thread, Tyler has a site taking AOL traffic that ended up with a corrupted sessions database table.  He was looking for a way to decrease activity in the sessions table, in hopes of reducing potential for that corruption to happen again.  He was a major reason for getting this into a formal 'hack' form like my first post.

Stay tuned to this thread Tyler, some changes are in the wind for this hack as a result of some of the discussions here (thats what I love about open source).  I will be recoding it in the next day or so to incorporate some of the suggestions, and to see if I can strengthen the authentication on the usercookie (the 'remember me' cookie) a little. 

I also plan to merge them, and provide an easy to change single-variable that can be used to turn the proxy (AOL) portions of it off and on.

GRAM

Auch... Well, that means every any user with the remember cookie is an open target for people with publish rights. An authors can probably steal super administrator accounts, but super administrator can also steal any other identity registred on his site... Did you see the example code I posted Gram? Good thing you removed the "stay logged in" option from your system.

I agree that the "no IP-check" puts your system wide open for attacks. It was also not my intention to suggest that, I just posted what phpBB did as a solution that time (their code sucks in general but oh well ). On the other hand I like the different levels of IP sequences for validation (4, 3, 2)...

Timestamps... Well, actually timestamps should not be used. lol... I meant to say regeneration of the sessions, since timestamps are used a lot for that to generate a random number out of it I insidently wrote timestamps. It's better however to use md5 ( rand ( uniqid ) ) ); to generate a random number (I suppose Joomla is doing that).

I will tell a little more about generation of sessions, although you might know the value of it already. Imagine an hacker steals a session, by XSS for example. Between the time the hacker gets the session and try to login there is a change the user did refresh the page, so the session is changed and the stolen session is useless already. That way you can make sure XSS is less valueable, because hackers using this technique will probably only have a log full of outdated sessions which don't work anymore. Besides, session generation is also important to defend yourself against session fixation (if you want I can explain you some about that as well).

It does increase the load on your database however, so perhaps it should be another parameter of avaible security options.

Forgive me, I have not looked at the code yet.  But I will in just a few minutes.  I am assuming it is similiar to what I have seen posted elswehere but will confirm that to be sure.



I like this idea, and have implemented in other applications, but always had trouble implementing it in browser based solutions that traversed the internet.  Let me explain, and hopefully you, or someone else paying attention to this thread, may have some workounds or other experience to add to the discussion.

In order to implement this, we have to get the new session id for each page load out to the users browser. So we reset the cookie on each page request.

On the internet we have grown accustomed to dealing with dropped packets and momentary interuptions of throughput.  But it wreaks havic for rolling session ids (thats what we called this technique).  Here's one scenario (there are numerous others):

The user requests a page (his browser sends a TCP/IP connection request, opens a port for the server to broadcast to, and proceeds to sit there and wait for the response), in the process presenting his valid session id (in the cookie).  The server recieves the request, rolls the session id to new value, processes the remainder of the page, resets the users session cookie and proceeds to transmit to the users browser at the specified port (which is now open and ready to receive the broadcast).  During this process, there is a momentary (a matter of a couple of seconds) interruption in the connectivity between the user and his router.  We are using TCP (http uses this protocol) and so everything should be ok....  But the users router is cache deficient and cannot keep the packets transmitted by the server, so drops them.  The page request transmission to the browser fails (This is incredibly oversimplified -there is a lot to this, as TCP should recover, but doesn't always do so).  The users browser during this time has opened a connection for the server at the specified port, and proceeds to sit there and wait for the server to transmit.  Eventually the browser times out its request and the user gets a 'server not found' error.

Now the server is using a new session id for that user, but the user never recieved it.  So when the user tries to refresh the page, they no longer have a valid session id and end up logged out (at this point, there should be a recognition of this invalid session at the application/Joomla level and the user gets a 'sorry' page and a request to re enter thier password or both password and username).

This is what I was talking about with regard to syncing sessions.  To keep a rolling session id valid, the server has to confirm that the browser received it before they proceed to use it.  In order to do that, the server has to send the new id, and receive confirmation from the users browser that it was received.  Browsers do not respond to requests for data from a server once they are in receive mode, they only take in data (they ackowledge tranmission, but don't for example confirm specific strings are valid).  In order for us to ensure that we would get a confirmation, we would have to employ client side scripting to get the job done (javascript), and now we have a situation where some of our users will not be able to maintain their session ids because they have purposely disabled javascript, or have a browser that does not support it (do these still exist   ).

We also end up in the desktop support biz, having to ensure that our client side scripting will work on the overwhelming majority of client side OS's.

Its absolutely the right way to ensure session integrity, and in fact is applied in varying forms to other types of applications/transmissions (ipsec tunneling is one).  But I have not been able to find a reliable way to resolve the sync problem using the HTTP protocol and conventional browsers.

Hoping you have more insite into this, it would be an awesome optional feature for Webmasters who need high level security.

GRAM

Well, it's not that interesting but it shows how easy it can be abused for XSS.


Well, I will pay attention for sure, but somehow I'm afraid we're losing a lot of people interest because it's going a little too technical by time to time. Sorry for flooding away your (nice) hack that way...

Anyways... You wrote a lot about the TCP protocol. I don't really understand what you mean, which has too do with the fact that I have less experience with the TCP protocol than you have...

However, I never heard about many problems with cookie regeneration in my applications. From what I know the cookie generation is actually used in many systems like, for example, VBulittin. As you know a forum like VBullitin do have a lot visiters and refreshes and this would definatly be a place where your failure of the TCP protocol would occur. I never heard or read anything about it though, but I might have missed it...

Anyways, from my simple mind (i'm thinking more in terms of simple programming languages than in protocols) it's going like this:

(1) User visit website
(2) Joomla indentifies user based by comparing the cookie & IP with the hash in database
(3) If user is identified Joomla creates a new session hash based on IP / random number
(4) Joomla updates the cookie, and updates the old session with the new session in the database

So if I understand you correctly it's going wrong at point... 3? When it sets the new cookie? I will read your reply one more time when I finished cooking to see if I can make it more understandable for myself, but feel free to post a reply in meantime.

@Matjong,

There a couple of subsequent steps that take place at the transmission level (tpc) where the problem comes up.  I am extremely encouraged to hear of a project that is doing this.  That means we just have to figure out how to do it.

  You and I have pretty much blown this thread away, mostly me.  I apologize for the verbosity.

Will you please do me a favor?  I would like to clean this thread up and get it back on track, will you consider one of the following?.  If a moderator is reading please respond and advise which is best fit... 

1. I change title of this thread, repost original thread with original title (can I do this?).

2.  or I delete content of my (    ) bloated posts and ask that Matjong do the same ( with his much more reasonable posts) and we move this discussion to PM or another thread... 

Would prefer #1... and open to suggestions....

GRAM

Just wanted to tell you, that I follow your discussion closely and hope you keep it open for me, too.
I've got the same problem with my ACL stuff. I linked the thread with the important stuff about ACL into my signature, but everyone I point to that thread keeps telling me, that 6 pages of partly outdated information is to much. On the other hand, I don't think its practical for the people to look for projects on the forge, where you could post the informations.
I think it would be good to have a sub-forum, where the author of such a technologie or patch can post news and a linked thread with the discussion to this. Sounds very complicated, but as far as I can see, it works for the news on the joomla-frontpage...

Would be interesting to see, how this could be realized.

hackwar

@hackwar

I would welcome the participation of anyone willing to participate, or even just follow along.  The more minds scrutinizing the solution, the better the solution (just like your work on ACL).

You have already contributed a very good idea to help resolve one of this hacks defficiencies.

GRAM

I'm pretty much against PM's for this kind of things. I mean, you might suddenly come across someone else who adds something you had never think of. You don't want to exclude that On the other hand I don't expect that that many people will read this discussion (long texts usually don't really help with that).

Just a different topic would be fine with me. We can delete our posts, but I don't like to delete information which is valueable for me... I might want to read some things over by time to time, and continue the discussion.

I've got my hands full at the moment, but I'll try to join in on the discussion tomorrow evening.

Topic title changed, Reposting original post as new thread.

GRAM

Just posting to indicate that we have monitored this discussion and are considering Grams proposed solution.

Although I cant say at this stage the exact manner in which we will solve this issue, whether by:
- Grams proposal,
- a combination of Grams proposal and something else, or
- something else entirely - if we can find better solution

What I will say is that it be integrated into 1.0.8 and 1.1.x


Thanks must to Gram for a very detailed and through explanation of the issues surrounding the problem.
And thanks for the proposed solution, it is food for thought.

Thanks for the post Rey,

Thats great news! 

A resolution is a resolution, and if the core devs have a better way that fits into the core better, I'm just glad to have futhered the discussion.  This is a single handed stab at solving the problem, not meant to be definitive 

To everyone else,

I am playing with the rolling sessions now.  And setting up some Global vars to key into.  Will post a unified solution (with or without rolling session ids) soon.

GRAM

BTW you wouldn't have a diff of your proposal and 1.0.7 - for me anyway its easier to read and track a diff file.

I will come up with one.  Will need to make a file that has the standard 1.07 functions in it to diff against.

Just sitting down to dinner, so will get this done when finished eating Rey.

GRAM

Also having an eye on this Great that someone finally got time to shoot at this problem Great that core team will fix it soon

The final solution should ideally be as safe as possible (and not less than now) for standard HTTP and bullet-proof for HTTPS. Maybe for HTTPS there is a much higher degree of security which can be implemented in the new session management (like browser signature/remote public key/SSL session itself for instance).

Another idea for later (1.2) would be to have optionally the possibility for a closer session management (tracking connected window), so that users have a real, meaningfull, "on-line" state.

Not sure if this is what you want Rey, first time I have tried to create a diff file 

This was created in WinMerge, original file on the left, new file on the right.  Original file is from the 1.07 release.  I used the 'create patch' function to create it (no merges).

EDIT NOTE: File deleted, wrong format.  Reposted on next page.

GRAM