[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070510120220.6762.qmail@securityfocus.com>
Date: 10 May 2007 12:02:20 -0000
From: p3rlhax@...il.com
To: bugtraq@...urityfocus.com
Subject: squirrelmail CSRF vulnerability
I. BACKGROUND
SquirrelMail is a standards-based webmail package written in PHP.
It includes built-in pure PHP support for the IMAP and SMTP protocols,
and all pages render in pure HTML 4.0 (with no JavaScript required)
for maximum compatibility across browsers. It has very few requirements
and is very easy to configure and install. SquirrelMail has all the
functionality you would want from an email client, including strong MIME
support, address books, and folder manipulation.
II. DESCRIPTION
Squirrel Mail application is vulnerable to Cross Site Request Forgery (CSRF)
vulnerability.
A remote user can perform all the legitimate actions which a normal user can
perform after a logged-in.
This attack is launched because squirrel mail application doesn't have secondary
authentication for actions. That is, application authenticates the request based
on cookie present in it. It does not have any session token which will identify
request as legitimate or not.
Assumption:
* The attacker has knowledge of sites the victim has current authentication on
* The attacker's "target site" has persistent authentication cookies, or the victim
has a current session cookie
III. ANALYSIS
Successful exploitation of this vulnerability would allow an attacker to perform all the action
which a legitimate user can do. For example,
1. Send an E-Mail on behalf of victim.
2. Delete an E-Mail from victim's account.
3. Add a new contact into address book.
4. Create a new folder into victim's account.
5. Change the options/settings of victim's account.
6. Sign Out the victim from current session.
IV. DETECTION
Latest version of squirrel mail 1.4.8-4.fc6 and prior are found vulnerable.
V. WORKAROUND
I. Application should check for Referer Header in every post login request.
II. Application should use CSRF token which is random enough to identify every legitimate post login request.
VI. VENDOR RESPONSE
??
VII. CVE INFORMATION
??
VIII. DISCLOSURE TIMELINE
05/02/2007 Initial vendor notification
??/??/??Initial vendor response
??/??/??Coordinated public disclosure
IX. CREDIT
Avinash Shenoi (savinash@...zic.com)
Vivek Relan (vivek@...zic.com)
Cenzic Inc.
X. REFERENCES
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1648
XI. LEGAL NOTICES
Copyright ©
Permission is granted for the redistribution of this alert electronically. It may not be edited
in any way without the express written consent of Cenzic. If you wish to reprint the whole or
any part of this alert in any other medium other than electronically, please email for permission.
Disclaimer: The information in the advisory is believed to be accurate at the time of publishing
based on currently available information. Use of the information constitutes acceptance for use
in an AS IS condition. There are no warranties with regard to this information. Neither the author
nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage
arising from use of, or reliance on, this information.
Powered by blists - more mailing lists