Message-ID: <20070705063649.5156.qmail@securityfocus.com>
Date: 5 Jul 2007 06:36:49 -0000
From: tomaz.bratusa@...mintell.com
To: bugtraq@...urityfocus.com
Subject: Session fixation in Zen Cart CMS

====================================================================================
Team Intell Security Advisory TISA2007-05
------------------------------------------------------------------------------------
Zen Cart 1.3.7 - Session fixation Issue in backend Administration interface
====================================================================================


Release date: 05.07.2007
Severity: Moderately critical
Remote-Exploit: yes
Impact: Session fixation
Status: Official patch not available
Software: Zen Cart 1.3.7
Tested on: Zen Cart 1.3.7
Vendor: http://www.zen-cart.com
Vendor-Status: informed/Patched
Disclosed by: Tomaz Bratusa (Team Intell)[TISA-2007-05]  


Introduction
============

Zen Cart 1.3.7 is a popular open source shopping cart system.


Security Risk
=============
It is possible to manipulate administrator interface cookies, which may be used to impersonate a legitimate user, allowing the attacker to view or alter user records, and to perform transactions as that user.
The Cookie variable can be set to a malicious and arbitrary value which can lead to session hijacking and privilege escalation attack.

Possible Causes
===============
Insecure web application programming or configuration


Technical Description
=====================
Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending on the functionality of the target web site, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. After a user's session ID has been fixed, the attacker waits for the user to login, and then uses the predefined session ID value to assume the user's online identity.  

In general, there are two types of session management systems for ID values. The first type is "permissive" systems, that allow web browsers to specify any ID. The second type is "strict" systems, that only accept server-side generated values. With permissive systems, arbitrary session IDs are maintained without contact with the web site. Strict systems require that the attacker maintain the "trap-session", with periodic web site contact, preventing inactivity timeouts.  

Without active protection against session fixation, the attack can be mounted against any web site using sessions to identify authenticated users. Web sites using session IDs are normally cookie-based, but URLs and hidden form-fields are used as well. Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.  

In contrast to stealing a user's session ID after they have logged into a web site, session fixation provides a much wider window of opportunity. The active part of the attack takes place before the user logs in.  

The session fixation attack is normally a three step process:  

1) Session Set-Up  
The attacker sets up a "trap-session" for the target web site and obtains that session's ID, or the attacker may select an arbitrary session ID used in the attack. In some cases, the established trap session value must be maintained with repeated web site contact.  

2) Session Fixation  
The attacker introduces the trap session value into the user's browser and fixes the user's session ID.  

3) Session Entrance  
The attacker waits until the user logs into the target web site, and then, when the fixed session ID value is used, the attacker may take over."  


Workaround:  
============
1.Regenerate SID on each request:
A powerful countermeassure against session fixation is to
"regenerate" session identifier (SID) on each request.
This means that although attacker may trick a user into accepting
a known SID, the SID will be invalid when attacker attempts to
re-use the SID.

2. Accept only server generated SID:
One way to improve security is to not accept session identifiers
not generated by server.

if ( ! isset( $_SESSION['SERVER_GENERATED_SID'] ) ) {
session_destroy(); // destroy all data in session
}
session_regenerate_id(); // generate a new session identifier
$_SESSION['SERVER_GENERATED_SID'] = true;


References:
-------------------------------------------------
http://www.acrossecurity.com/papers/session_fixation.pdf
http://www.webappsec.org/projects/threat/classes/session_fixation.shtml


History/Timeline
================
20.06.2007 discovery of the vulnerability
20.06.2007 contacted the vendor
20.06.2007 advisory is written

02.07.2007 Patch becomes available 


---------
Contact:
---------

Maldin d.o.o.
Trzaska cesta 2
1000 Ljubljana - SI

tel: +386 (0)590 70 170
fax: +386 (0)590 70 177
gsm: +386 (0)31 816 400
web: www.teamintell.com
e-mail: info@...mintell.com


------------
Disclaimer:
------------

The content of this report is purely informational and meant for educational purposes only. Maldin d.o.o. shall in no event be liable for any damage whatsoever, direct or implied, arising from use or spread of this information. Any use of information in this advisory is entirely at user's own risk.

Powered by blists - more mailing lists