Mambo 4.6.2 CMS - Session fixation Issue in backend Administration interface

Credit: tomaz bratusa
Risk: Low
Local: No
Remote: Yes
CWE: CWE-287

CVSS Base Score: 9.3/10
Impact Subscore: 10/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

======================================================================== ============ Team Intell Security Advisory TISA2007-04 ------------------------------------------------------------------------ ------------ Mambo 4.6.2 CMS - Session fixation Issue in backend Administration interface ======================================================================== ============ Release date: 01.08.2007 Severity: Moderately critical Remote-Exploit: yes Impact: Session fixation Status: Official patch not available Software: Mambo 4.6.2 CMS Tested on: Mambo 4.6.2 CMS Vendor: Vendor-Status: informed/NO RESPONSE Disclosed by: Tomaz Bratusa (Team Intell)[TISA-2007-04] Introduction ============ Mambo CMS is a popular Content Management 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: ------------------------------------------------- History/Timeline ================ 19.06.2007 discovery of the vulnerability 19.06.2007 contacted the vendor 19.06.2007 advisory is written NO response from the vendor 09.07.2007 advisory made public --------- 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: e-mail: info (at) teamintell (dot) com [email concealed] ------------ 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.

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024,


Back to Top