Outlook for Android XSS

June 24, 2019 Nethanel Coppenhagen & Or Ida

Outlook for Android is the most popular e-mail application for organizations. CyberArk Labs discovered a cross-site scripting vulnerability that allows an attacker to run JavaScript code through e-mail messages.

After discovering this vulnerability, CyberArk Labs alerted Microsoft in January 2019, following the responsible disclosure process. The vulnerability, assigned CVE-2019-1105, was fixed by Microsoft and released in June 2019.

In this article we will explore this vulnerability and will try to understand why it is exists.

The Attack

This part is pretty simple. If we send a payload like this to a user’s email account:

When the user opens his inbound mail, he will get this message:

Figure 1- Result of opening the mail with the given payload

Under The Hood

When we extract the Outlook’s APK, we will find under the assets directory a JavaScript file called “emailRenderer-android.js”. As its name implies, this JavaScript renders the content of the message viewable to the user. Inside this script there is a function called “layout” that calls a function named “_linkifyPhoneNumbers.”

Figure 2- The location of the vulnerable function from “emailRenderer-android.js”

The _linkifyPhoneNumbers function starts by creating a regular expression object with patterns for possible phone numbers:

Figure 3- Regex pattern for identifying phone number in the _linkifyPhoneNumbers function

As you probably guessed, a sequence of 7 digits is a match for this regular expression. After this, the linkifyPhoneNumbers function defines a second, inner function called “replacer.” The  first part of the inner replacer function starts by trying to parse a phone number:

Figure 4- The parsing code in the replacer function

If the parsing succeeds, the inner replacer function converts the number to a link, increments a counter and returns the data.

Figure 5- The link conversion in the replacer

Returning to the outer _linkifyPhoneNumbers function, the function tests for a match between the regular expression it defines and each HTML element in the message. In the case of a match, the outer function calls the inner replacer function for the matching element and returns the linkified text. Then, the _linkifyPhoneNumbers function replaces the message element with a linkified version of it:

Figure 6- The vulnerable code in the _linkifyPhoneNumbers function

There you have it. After converting the numbers into a link, there is no other escaping on the content. Therefore, an attacker can send a message containing a number that matches the regular expression and, after converting it to a link, the counter will increase and  replace the original message with an unescaped version of the message.

 

Having fun with HTML 5 API

HTML 5 API has many cool features that can help us abuse this type of vulnerability and execute code on the user’s phone.

We will focus on the [Navigator] interface functionality, which represents the state and the identity of the User-agent and allows scripts to query it and to register themselves for certain activities.

Let’s demonstrate the vulnerability with the vibrate() method, which pulses the vibration hardware on the device as long as the malicious email is open. This is the payload:

But, is this enough for an attacker to vibrate the user’s phone? Not in the current state of cybersecurity. Next we inject a remote script with the following payload:

Figure 7- Inbound connections load a remote script from the attacker server

Let’s try to inject a sophisticated script using XMLHttpRequest object, which is responsible for the communication between the user’s browser and the web server where we want to redirect the victim.

Figure 8- XMLHttpRequest code to redirect the victim

The code above will validate the HTTP response status code and cause it to pop out as a window:

Figure 9- The HTTP response code of the injected payload

We receive a status code equaling 0, which, according to MDN,  indicates that there was an error in our request.

With a little bit of googling, we found that there is a chance of CORS (cross-origin) protection, which makes sense. To bypass this, we used the cors-anywhere proxy, which adds CORS headers to the proxied request.

Next, we update our code by adding the CORS proxy.

Figure 10- The updated code adding a CORS proxy to the request

Figure 10- The updated code adding a CORS proxy to the request

Our CORS bypass worked as expected! We can verify this by intercepting the request with the burp collaborator as a proxy and observe our malicious [“message”] parameter following the phone’s User-agent:

Figure 11- Burp collaborator window

Summary

Many mobile applications have embedded web application in them. This architecture exposes the mobile application to web applications vulnerabilities like the known Cross-Site scripting vulnerability. In this blog post, we showed how a well-known application like Outlook for Android can be vulnerable to XSS, why it happens and how an attacker can use it.

Disclosure Timeline

  • January 24, 2019: The XSS vulnerability was reported to MSRC.
  • January 24, 2019: MSRC responded that they will review the report.
  • January 29, 2019: MSRC successfully reproduced the issue and will update when they finish the investigation.
  • February 20, 2019: MSRC informed that they are still working on the investigation about the issue
  • June 11, 2019: MSRC informed that a release for the fix is scheduled to June 20th.
  • June 20, 2019: MSRC released a fix for this issue and assigned the vulnerability CVE-2019-1105.

Previous Article
Sodin Ransomware
Sodin Ransomware

Critical Synopsis: Sodin is a new ransomware that spreads and operates using known vulnerabilities. CyberAr...

Next Article
A Pony Hidden in Your Secret Garden
A Pony Hidden in Your Secret Garden

CyberArk’s David Cohen provides a technical overview of Pony, which is the most widespread type of malware,...