掲示板

Liferay Security Vulnerability: Session Hi-Jacking

thumbnail
14年前 に Fuad Efendi によって更新されました。

Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
Hello,

I am constantly having problems with user sessions, accidentally User may get access to a session of another User (for instance, he will see message "Welcome, User2" instead of "Welcome, User1")

How this happens and why?

Half a year ago I noticed related post Apache HTTPD but is was for old version; we are using 2.2

Tomcat also has some bugs (fixed) like as
- Tomcat incorrectly treated a single quote character (') in a cookie value as a delimiter. In some circumstances this lead to the leaking of information such as session ID to an attacker.

- Tomcat incorrectly handled the character sequence \" in a cookie value. In some circumstances this lead to the leaking of information such as session ID to an attacker.


Do you guys have ever had such kind of problems? Do you run specific load-stress tests to ensure that this does not happen with Apache?

Thanks
casaGURU Renovation Professionals
Online Shopping
Liferay Consultant
thumbnail
14年前 に Lisa Simpson によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 2034 参加年月日: 09/03/05 最新の投稿
We've not seen this behaviour with Liferay 5.2.3 or the EE. However, we're running tomcat 6. The whole thing, however, is frontended by Apache running mod-proxy which gives me the ability to filter out a lot of stuff.

RegEx is the bomb... if something matches X (nasty part of string) it gets routed into the bit bucket.

HTH
thumbnail
14年前 に Fuad Efendi によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
Yes, we need to upgrade to latest versions... still 5.12 on tomcat 5.5.26... I noticed some posts at RedHat too, in some cases suggested
org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=true
- but I am verifying it now...

I use mog_proxy_ajp; HTTPD 2.2

May be this???
http://issues.liferay.com/browse/LEP-7061

- sometimes HTTPD restart helps, but not now...
thumbnail
14年前 に Aritz Galdos によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Expert 投稿: 416 参加年月日: 07/05/15 最新の投稿
Hi

I never had this problem but something similar happen when you log to the portal with different users from the same webBrowser.

i.e. When I log to the portal from two different navigator instances everi thing is ok. But if I log to the portal with two different users in the same browser, (I mean same browser, different tabs) both user convert in the last logged user. I think
thumbnail
14年前 に Lisa Simpson によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 2034 参加年月日: 09/03/05 最新の投稿
If you try to open to two tabs in the same browser as different users, you can't. It will merge them into the last user to authenticate successfully. That appears to be the default behavior as of 5.2.3. That particular behavior, as far as I can tell, is actually cookie based, not session based. One of the devs can feel free to correct me if I'm mistaken. I've not dug into it that deeply.

In this case, we're actually talking about a third party maliciously assuming your session to, for example, replace your web content with spam or pr0n. That's a bit trickier.
thumbnail
14年前 に Fuad Efendi によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
The problem is not "two tabs in the same browser as different users" - it is much more serious!!!

It happens in moderately loaded production system with Apache HTTPD 2.2 (worker) on front end, when we have more than a few concurrent users from different geo-locations.

It happens mostly with PortletSession stored objects, but sometimes it even happens with "Welcome, John Smith" message - it shows name of another user, Session Hi-Jacking - a user gets access to a Session of another one.

Tomcat has resolved many related bugs with specific characters in a Session ID - what about Liferay, is it generating own non-compatible Session IDs?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5333
Apache Tomcat 6.0.0 through 6.0.14, 5.5.0 through 5.5.25, and 4.1.0 through 4.1.36 does not properly handle (1) double quote (") characters or (2) %5C (encoded backslash) sequences in a cookie value, which might cause sensitive information such as session IDs to be leaked to remote attackers and enable session hijacking attacks.

I don't think it happens with HttpSession.

Many years ago I had similar problem - but it was FTP - and I suspected Firewall/Router/NIC suddenly mixing TCP sessions...

It is extremely difficult to locate a problem without specific LAB environment (which SUN-Liferay must have!)
thumbnail
14年前 に Lisa Simpson によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 2034 参加年月日: 09/03/05 最新の投稿
If it is indeed cookie based, it shouldn't be your network gear causing the problem *UNLESS* your network gear is caching the cookie and handing out the same cookie to several users. I can say that we've not seen that here at all. We've got 18K users. The worst thing I've seen is the tab thing. The session ID's that I've seen are all totally alphanumeric.

Your apache2.2, are you running mod_jk or mod_proxy?
thumbnail
14年前 に Fuad Efendi によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
And of course cookie is passed via HTTP header:

1. Fixed in Apache httpd 2.2.12
important: mod_proxy_ajp information disclosure CVE-2009-1191
An information disclosure flaw was found in mod_proxy_ajp in version 2.2.11 only. In certain situations, if a user sent a carefully crafted HTTP request, the server could return a response intended for another user.


2. Fixed in Apache httpd 2.2.6
moderate: mod_cache information leak CVE-2007-1862
The recall_headers function in mod_mem_cache in Apache 2.2.4 did not properly copy all levels of header data, which can cause Apache to return HTTP headers containing previously used data, which could be used by remote attackers to obtain potentially sensitive information.

Update Released: 7th September 2007

Affects: 2.2.4



And, of course, our famous vendor RedHat ENTERPRISE(???) still provide us with HTTPD v.2.3.3 (as of October-2009)

(we are using mod_mem_cache)
thumbnail
14年前 に Lisa Simpson によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 2034 参加年月日: 09/03/05 最新の投稿
Yet another reason we use Ubuntu's Long Term Support Server for most of our *nix boxes. In spite of the fact that it's a free download, their package managers are pretty responsive in pushing out security patches.
thumbnail
14年前 に Mika Koivisto によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 1519 参加年月日: 06/08/07 最新の投稿
The source of your problems is probably mod_mem_cache. You can easily configure it to cache liferay pages so that other users get the cached version from someone else thus appearing to have hi-jacked the session accidentally. I've seen this happen with overly aggressive proxy servers.
thumbnail
14年前 に Fuad Efendi によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
Mika Koivisto:
The source of your problems is probably mod_mem_cache. You can easily configure it to cache liferay pages so that other users get the cached version from someone else thus appearing to have hi-jacked the session accidentally. I've seen this happen with overly aggressive proxy servers.



The problem is HTTP Headers.

I disabled mod_mem_cache, but it still happens. Should I disable mod_proxy_ajp too?!

I'll upgrade HTTPD...

BTW, Liferay manages what is cached and what not; via HTTP headers such as "Last Modified Time", "ETag", "Expire:", and etc. - at least, should. And in case of cached Image, for instance, HTTP response shouldn't include session cookie.

Difficult to locate the problem; it could be even broken router/firewall.
thumbnail
14年前 に Olaf Kock によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 6396 参加年月日: 08/09/23 最新の投稿
keep in mind that usually distributions don't update you to the latest version of a product, but backport security relevant fixes to their version of choice. This is expected behaviour in Enterprise distributions. You wouldn't want them to always install the latest feature with each security update, requiring you to lock down these new features with every security update. And there's no such thing as a gentoo enterprise edition (no pun intended, but they have the habit and reputation to always run the latest versions of everything and use a significant fraction of the CPU to steadily compile and optimize the heck out of the system ;-)

As you mention mem_cache: I was about to suggest taking a close look to your infrastructure to any proxy and caching stuff going on there. As you seem to be more or less alone with the problems you describe, chances are that it's your infrastructure, not liferay. What you mentioned really sounded more like caching going wrong than "specially crafted headers".

If you need more aggressive caching for performance reasons you might want to look into integrating a cdn for serving static resources (thus keeping it out of tomcat's/liferay's realm) or cluster your installation to span multiple hosts.
thumbnail
14年前 に Lisa Simpson によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 2034 参加年月日: 09/03/05 最新の投稿
Don't even get me started on Gentoo.... Is it uberfast? Yes, but any time my servers save, I spend managing their patching process. IMHO, their packaging is inconsistent at best. Who releases an apache update without mod_auth???

Mod_disk_cache and other apache cacheing mods are known to cause this sort of inadvertent session-hijacking.
thumbnail
14年前 に Olaf Kock によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 6396 参加年月日: 08/09/23 最新の投稿
Lisa Simpson:
If you try to open to two tabs in the same browser as different users, you can't. It will merge them into the last user to authenticate successfully. That appears to be the default behavior as of 5.2.3.


That's actually not default behaviour in Liferay, but behaviour of the browser. As the browser in this case sends the same cookie (with the session identifier) to the server from each tab, naturally the same session is running in the same tab, with the same user (and only that one user) being logged in.

With cookies that's as far as you get unless you get specific support from the browsers so that they send different session cookies from different tabs.
thumbnail
14年前 に Fuad Efendi によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 180 参加年月日: 07/04/05 最新の投稿
http://httpd.apache.org/docs/2.2/mod/mod_cache.html

CacheIgnoreHeaders Set-Cookie


Ok, I played with this setting, Mozilla Firefox + Live Http Headers plugin. I tried to find objects which use HTTP Caching and Set Cookie, and I found single one:


GET /html/js/barebone_packed.js?bn=5102 HTTP/1.1
Host: www.casaguru.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.casaguru.com/home
Cookie: LOGIN=7765626d617374657240746f6b656e697a65722e6f7267; SCREEN_NAME=5a72696354705a66776846326a346e774774743731773d3d; __utma=47926453.1823828619112278800.1242160515.1255467895.1255557828.210; __utmz=47926453.1247854694.124.6.utmcsr=public.casaguru.com|utmccn=(referral)|utmcmd=referral|utmcct=/professional; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; _csuid=49146af247b1ff77; REMEMBER_ME=true; COMPANY_ID=10097; ID=7553696a623545574e59513d; PASSWORD=536e31726637374a474e6b3d; __utmc=47926453; JSESSIONID=85B6F7297C58438BDA17FF189483C316; __utmb=47926453.2.10.1255557828
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Wed, 14 Oct 2009 22:16:48 GMT
Set-Cookie: JSESSIONID=F830DD5D4F0ED8F595F4343DCA576FD6; Path=/
Expires: Fri, 16 Oct 2009 22:16:49 GMT
Cache-Control: max-age=172801, public
Etag: W/"176773-1234388745000"

Content-Encoding: gzip
Content-Length: 48814
Last-Modified: Wed, 11 Feb 2009 21:45:45 GMT
Connection: close
Content-Type: text/javascript



After setting "CacheIgnoreHeaders Set-Cookie" problem disappears... BTW, I checked all images/CSS/JavaScript, only barebone_packed tries to set cookie together with caching - why?

===============

Please note:
1. GET /html/js/barebone_packed.js?bn=5102 HTTP/1.1

2. It is cached content:
Expires: Fri, 16 Oct 2009 22:16:49 GMT
Cache-Control: max-age=172801, public
Etag: W/"176773-1234388745000"

3. Cookie is provided:
Set-Cookie: JSESSIONID=F830DD5D4F0ED8F595F4343DCA576FD6;


Now, it seems we don't have any problem anymore, after CacheIgnoreHeaders Set-Cookie

However, HTTPD may respond with non-cached content in case (for instance) of cache limits / expirations; what about people behind corporate proxies/caches? We can't manage external caching servers...

It is a bug.
thumbnail
14年前 に Michael Poznecki によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Expert 投稿: 301 参加年月日: 08/12/10 最新の投稿
I'm having a similar problem.
thumbnail
13年前 に Krati Gupta によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Regular Member 投稿: 119 参加年月日: 08/12/05 最新の投稿
I am also facing the same problem , can anybody tell how to fix the issue .
11年前 に Johan de jong によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Junior Member 投稿: 41 参加年月日: 12/02/06 最新の投稿
Sorry that i reopen an old list, but i have the exact problem at this moment with
Liferay Portal Community Edition 6.1.0 CE (Paton / Build 6100 / January 6, 2012)
running at Glassfish 3.1.1

A company who has a proxyserver has several users who want to login to the liferay server. At some moments they login and they get the message that they are logged in as an other user.

How can i resolve this nightmare?
thumbnail
11年前 に Mika Koivisto によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

Liferay Legend 投稿: 1519 参加年月日: 06/08/07 最新の投稿
You can stop caching in the proxy server or you can upgrade. If I remember correctly the issue is fully resolved in 6.1 GA2.
thumbnail
11年前 に Luiz Henrique Grossl によって更新されました。

RE: Liferay Security Vulnerability: Session Hi-Jacking

New Member 投稿: 1 参加年月日: 10/08/25 最新の投稿
Mika Koivisto:
You can stop caching in the proxy server or you can upgrade. If I remember correctly the issue is fully resolved in 6.1 GA2.


We couldn't upgrade yet our Liferay 6 to 6.1 so we've added:

<ifmodule mod_headers.c>
  ## used to avoid Liferay 6 User session hijack problem
  Header merge Cache-Control no-cache
  Header merge Cache-Control no-store
  Header merge Cache-Control private
</ifmodule>


to our Apache front-end servers to stop the problem for now.

Keep in mind that Liferay pages will be served a little bit slower because of the no-cache, we are thinking about adding the static content into Apache to speed up things again.