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.
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:
Under The Hood
The _linkifyPhoneNumbers function starts by creating a regular expression object with patterns for possible phone numbers:
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:
If the parsing succeeds, the inner replacer function converts the number to a link, increments a counter and returns the data.
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:
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:
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.
The code above will validate the HTTP response status code and cause it to pop out as a window:
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
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:
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.
- 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.