HTML Code Injection in Outlook Web Access

SEC-CONSULT Security Advisory < 20060613-0 v2>

=======================================================================

title: HTML Code Injection in Outlook Web Access

program: Outlook Web Access

vulnerable version: Exchange 2000 (SP3), 2003 (SP1), 2003 (SP2)

impact: severe

homepage: www.microsoft.com/exchange/default.mspx

found: 2005-10-25

by: D. Fabian / SEC-CONSULT / www.sec-consult.com

T. Kerbl / SEC-CONSULT / www.sec-consult.com

=======================================================================

 

2nd version notes:
---------------

The described vulnerability has been found by SEC Consult. SEC Consult
worked together with Microsoft on fixing the issue and a patch has been
released by Microsoft on June 13th 2006. The vendor advisory with links 
to the patches is available from 
www.microsoft.com/technet/security/Bulletin/MS06-029.mspx.
 
As promised to Microsoft, we held back vulnerability details for two 
weeks. This second version of our advisory contains details about the 
vulnerability and its consequences for users.


vendor description:
---------------

Microsoft Office Outlook Web Access is an integrated component of 
Exchange Server 2000/2003. By using only a Web browser and an Internet 
or intranet connection, Outlook Web Access enables users to read their 
corporate e-mail messages, schedules, and other information that is 
stored on a server running Exchange.

[Source: www.microsoft.com/exchange/evaluation/
features/owa2k3_55.mspx]


vulnerability overview:
---------------

Microsoft Outlook Web Access is vulnerable to an HTML code 
injection/cross site scripting attack. A malicous user could craft a 
mail containing HTML and Javascript code. Such code could be used to 
steal session information from the victims cookies, and thus enable the 
attacker to get access to the victim's emails. 

In alternative Browsers like Mozilla Firefox or Opera the mere opening 
of an crafted email is enough for Javascript code to execute. As soon 
as the victim clicks on the malicious email, the Javascript code can 
read session information and send this to the attacker, who can then 
perform session hijacking and read the victims emails.

As Internet Explorer uses proprietary security mechanisms (mails are 
displayed as pages in restricted security zone) it is not possible to 
inject Javascript code directly into email bodies. However our research 
showed, that using HTML attachments (which are also subject to input 
sanitation in OWA), the Javascript code can be successfully executed. 
Furthermore HTML code injection is still possible directly in the email 
body. This can be used e.g. by  malicious attackers to include images 
which are displayed without further user interaction and thus verify 
whether the user read the email or not. Also links can be directly 
included, circumventing OWA's redirection feature.

The vendor advisory is available from
www.microsoft.com/technet/security/Bulletin/MS06-029.mspx

vulnerability details:
---------------

The flaw is caused by erratic NULL-byte handling. Outlook Web Access 
closes a tag by inserting a ">"-character as soon as it encounters a 
NULL byte, regardless of the position in the tag. This behaviour can be 
exploited by specifying a NULL byte within an argument. As the argument 
is enclosed by quotes, the browser does not interpret the closing 
">"-character and accepts further arguments by the user. The same 
mechanism can be used to finally close the tag.

As the concequences of the vulnerability differ from the browser in 
which OWA is opened, we split the discussion into two parts:
First the consequences in Internet Explorer, and second the 
consequences in alternative browsers. Just to be clear, the flaw has 
nothing to do with browser security. It is one and the same 
vulnerability in OWA, it is just that the impact differs from the 
browser used.

-- Internet Explorer
Because OWA uses the (IE proprietary) attribute "security='restricted'" 
in the IFrame that shows the message, we have not found a way to 
execute Javascript directly in the email body. By attaching an HTML 
file to an email, it is still possible to inject Javascript, just the 
way it works with alternative browsers. Also there are other security 
features in OWA that can be circumvented by exploiting the 
vulnerability directly in the email body.

OWA seems to have an internal list of tags and tag parameters that 
are allowed. If it encounters a tag or parameter that is not allowed, 
it is simply discarded. Certain parameters like href in <a>-tags or src 
in <img> have special treatment. If OWA encounters an image, it simply 
replaces the src parameter's content with "/exchweb/img/clear1x1.gif". 
If a user wants to see the image, he needs to accept the warning "To 
help protect your privacy, links to images, sounds, or other external 
content in this message have been blocked. Click here to unblock 
content.". hrefs from links are wraped by the redirect script 
/exchweb/bin/redir.asp.

Using the perl script attached to this advisory, it is possible to 
circumvent all of these security features. It is possible to specify 
arbitrary parameters to tags. This can be used to directly display 
images (which can in turn be used to verify if a user reads the email), 
specify arbitrary link hrefs, specify the action attribute in the 
<form>-tag so that user information can be collected with forms.

-- Alternative Browsers
In alternativ browsers, the impact is critical. Additionally to the 
possiblities in IE, the 'security="restricted"' parameter does not 
exist in those browsers, thus arbitrary Javascript can be sent in a 
mail to unsuspecting users. It is still the task of OWA to get rid of 
Javascript in HTML mails (apart from the flaw described in our 
advisory, it actually does a decent job in doing so). One possibility 
to automatically execute Javascript is by using the onError parameter 
in img tags with a broken image.


proof of concept:
--------------- 

The following perl script can be used to craft emails containing 
malicous Javascript code which is executed in alternative browsers:

--- code ---
#!/usr/bin/perl

use Net::SMTP;

my $to = "recipient\@domain.tld";
my $sub = "Watch out - Cross Site Scripting Attack";
my $from = "originator\@domain2.tld";
my $smtp = "mail.somesmtpserver.tld";

my $cont = "<img alt='hugo\0abc' src='http://www.somewebserver.tld/
imagethatdoesnotexist.gif' onError='javascript:alert(document.cookie)' 
alt='<s'\0";

$smtp = Net::SMTP->new($smtp);
$smtp->mail("$from") || die("error 1");
$smtp->to("$to") || die("error 2");

$smtp->data() ;
$smtp->datasend("To: $to\n") ;
$smtp->datasend("From: $from\n") ;
$smtp->datasend("Subject: $sub\n");
$smtp->datasend("Content-Type: text/html\n\n");

$smtp->datasend("$cont") ;
$smtp->datasend("\n\n") ;
$smtp->dataend() ;
$smtp->quit() ;

print "$cont\n\ndone\n";
--- /code ---


vulnerable versions:
---------------

The following versions of Microsoft Exchange Server are vulnerable to 
the described security flaw:

- Microsoft Exchange 2000 Server Pack 3 with the August 2004 
  Exchange 2000 Server Post-Service Pack 3 Update Rollup
- Microsoft Exchange Server 2003 Service Pack 1
- Microsoft Exchange Server 2003 Service Pack 2 


vendor status:
---------------
vendor notified: 2005-10-27
vendor response: 2005-10-27
patch available: 2006-06-13
details available: 2006-06-28


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Unternehmensberatung GmbH

Office Vienna
Blindengasse 3
A-1080 Wien
Austria

Tel.: +43 / 1 / 890 30 43 - 0
Fax.: +43 / 1 / 890 30 43 - 15
Mail: office at sec-consult dot com
www.sec-consult.com 

EOF Daniel Fabian / @2006
research at sec-consult dot com