Shulou(Shulou.com)05/31 Report--

Microsoft Outlook for Android mobile application XSS vulnerability example analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

The Writeup shared today is about Outlook for Andriod's storage XSS vulnerability, which the author stumbled upon through a technical email sent by a friend. After months of repetition, Microsoft finally admitted the vulnerability (CVE-2019-1105).

Cause of vulnerability discovery

At the end of 2018, a friend of mine emailed me to help analyze some of the JavaScript code he was working on. Although I didn't dig for vulnerabilities, his email showed something strange on my phone. My phone is Android. Here is a screenshot of the email that hides the sender's message:

The gray border is getting weirder and weirder. When I analyzed it, I found. This may be that JavaScript contains an iframe framework in the form of HTML, which cannot be displayed and rendered normally when the iframe framework is parsed. But suspiciously, when I opened the email on my laptop, the whole parsing was normal, as shown below:

This makes me feel like a problem: embedding the iframe framework in my email may be a loophole, which may have something to do with the Outlook app on my phone. As far as Outlook is concerned, the iframe framework is not affected by BlockExternalImages that blocks external image settings, but it can be a dangerous security threat if an attacker has the ability to inject runnable JavaScript code into a message.

Security setting in BlockExternalImages:Outlook for iOS/Andriod, blocking external images is enabled when BlockExternalImages is set to true.

In view of this, to verify my guess, I tried to insert the script tag tag in my email to replace the iframe framework, but I couldn't. However, I find it interesting that you can construct a way around this limitation by using JavaScript URL in the iframe framework.

Storage XSS (Stored XSS) implemented by email

Usually, in a Web browser, a URL can be called in the syntax form of _ javascript:, but due to the limitation of the same origin policy, the JavaScript in the iframe framework in a separate domain cannot access other data in the page. In Outlook for Andriod applications, there is no such restriction. The JavaScript in my iframe framework can initiate access to my users' cookie, token and even other emails, and not only that, but also send this information back to the attacker's remote controller, Khan.

This kind of security problem is quite frightening, and to achieve this exploit, the attacker only needs to send an email containing the constructed JavaScript code to the victim, and the victim will be hit when he opens it with Outlook. Normally, Outlook will filter and escape some unsafe syntax and semantics, but because the constructed JavaScript code is in the iframe framework, the Outlook server will not detect it, so when the mail delivery is delivered, the Outlook client will not perform filtering escape on it. Finally, the JavaScript contained in the iframe framework can run successfully on the client mobile device. This is what we call storage XSS (Stored XSS). This type of vulnerability is so risky that attackers can use it to achieve a variety of purposes, including stealing information and returning data. An attacker only needs to send a structured email to the victim, and when the victim reads it, he can steal sensitive information such as the victim's cookie, other emails or personal data. Seriously, this Stored XSS, which exists in email reading clients, can be deployed through weaponized distribution, resulting in large-scale worm or malware destructive infections.

The recurrence process after the loophole is reported

I think this is a big problem and there is an urgent need to let Microsoft know. Therefore, in response to this vulnerability, I made a short PoC, which will execute an arbitrary external script to steal and return personal sensitive information. Due to the lack of deep construction of the exploit, there is not much access to email data for display. I immediately sent this PoC to the Microsoft security team.

With regard to this vulnerability, I really don't know where the source code that caused the vulnerability comes from, because I don't have the source code of the Outlook program myself, and I have little experience debugging mobile applications, but I think developers should be able to understand when they see this PoC.

Unfortunately, the Microsoft security team could not reproduce the vulnerability, and I was in embarrassment and predicament, but this is obviously true. I sent another video of the vulnerability reproduction to the Microsoft security team, and then I learned that a security researcher also reported the vulnerability, but according to POC, the Microsoft security team still failed to reproduce it.

In order to confirm whether it is caused by differences in Outlook settings, I did some more tests, but did not find the problem, it seems that this loophole is going to cool down.

Microsoft: it's not a loophole if it can't be repeated.

Every security engineer and developer will tell you that bug that can't be reproduced is a headache, and their time is a valuable and limited resource for the enterprise. Vendor security teams can put a lot of effort into reproducing a vulnerability, and the ultimate reasoning is that if they fail to reproduce the vulnerability, attackers are unlikely to successfully reproduce and exploit it. So from this point of view, the vendor security team will try to shift the responsibility to the security researchers who report vulnerabilities, and they want to report in a way that is as easy to reproduce and confirm as possible.

Break through

I can't just stop like this. a few months later, this loophole is still a problem for me, and how to get the Microsoft security team to identify it is a difficulty. For this reason, I thought of the method of extracting HTML loaded content from Outlook applications, and then I realized that this extraction method may be the problem of the vulnerability itself. I can steal data from Outlook applications, which means I can use it to read and load HTML content. So, combined with this point, I constructed a new Payload with the following execution effect:

The Payload I constructed looks like this:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.