3 XSS in ProtonMail for iOS

No, these XSSs are not so scary.

# I ❤️ DOMPurify

DOMPurify is a popular XSS sanitizer by Cure53.

cure53/DOMPurify

Any defensive research could be used in offensive purposes.

DOMPurify has great XSS tests with descriptions. These tests were sourced from real DOMPurify bypasses. Moreover, DOMPurify prevents XSS in all browsers and is aware of browser-specific behaviors. So, these XSS payloads are good.

# XSS Payloads

I’ve used XSS payloads from DOMPurify 😃

# XSS

1. Fires in applewebdata: origin on email opening —

<svg onload=alert()//

2. Fires on click in applewebdata: origin (🤦‍♀)

<a href="javascript:alert()">

3. Fires in data: origin after loading email’s remote content

<embed src="data:text/html;base64,PHNjcmlwdD5wcm9tcHQoIlByb3Rvbm1haWwgbmVlZHMgeW91ciBwYXNzd29yZCIpPC9zY3JpcHQ+"></embed>

iframe/embed with base64 encoded html payload

Need to note, that all 3 XSS are of different categories.
Even if I’ve found a 4th XSS, it’d be likely have been considered as a duplicate.

# Impact

It wasn’t possible to escalate these XSS into RCE/LFI. At least, I didn’t find such a way.

1. JS execution via email is already an issue.
2. Privacy violation: track when the user opens the email, disclose IP, leak other info.
3. Phishing via prompt(), alert()
4. “Useless” UXSS

# applewebdata:// origin is useless

Initially, I thought that XSSs in applewebdata: should allow reading local files. There was CVE-2016–1764 (XSS in iMessage via javascript: URI) that allows reading local files. applewebdata: was also highlighted in browser security research (UXSS) — https://runic.pl/hitb-ios-browsers.pdf.

Local files reading would be pretty impactful for a mail app.

However, this flaw was patched in Webkit(?) and now applewebdata: allows only doing UXSS in this particular case.

Anyway, UXSS is better than no UXSS, at least some privileged context :(

Additionally, Webkit forbids requests to file:// origin. Thanks to Safiler, XSSs in HelpViewer and related researches in this field.

Bo0oM/Safiler

# Reporting

The vulnerabilities were reported on Dec 12. At first, ProtonMail security team reacted quickly, but then they disappeared for a while.

There was a small miscommunication on their side. As I understand, they incorrectly estimated impact of these XSSs and somehow missed that 2 XSSs in applewebdata: are pretty impactful.

Later, ProtonMail iOS engineer Anatoly (thx!) noticed my tweets and the vulnerabilities were reviewed by ProtonMail team again.

# Timeline

1. Dec 11: Reported XSS in applewebdata: origin with no interaction via <svg onload=alert()//
2. Dec 11: Reported XSS via javascript: URI in applewebdata: origin
3. Dec 14: Response from ProtonMail Sec team
4. Dec 25: Found a XSS in data: origin via <embed src=[base64_paylaod]>`
5. Dec 25: Reminded the security team about findings
6. Dec 29: ProtonMail Sec team replied that these XSSs aren’t so scary, because they don’t allow reading emails
7. Jan 12: Made an accent on the fact that 2 XSS fires in applewebdata:
8. Jan 13: Made a PoC UXSS in applewebdata: to demonstrate that XSS context could be considered as privileged.
9. Jan 14: ProtonMail: no emails reading => not critical.
10. Feb 12–13: Made a few tweets regarding my findings in ProtonMail.
11. Feb 14 ProtonMail replied on Twitter.
12. Feb 15: Andy Yen emailed me via ProtonMail: ProtonMail team made an additional review of reported vulnerabilities + apology for the miscommunication.
13. Feb 15: The vulnerabilities patched in the stable.
14. Feb 27: ProtonMail agreed to disclose the report.

# Thanks to …

1. All my Twitter followers 💙
2. Anatoly from ProtonMail iOS team for noticing my tweets about the issues in ProtonMail 😉
3. ProtonMail SecTeam for their continuous work on ProtonMail’s security 🚀 and for making this disclosure possible
4. Andy Yen for the personal review of reported vulnerabilities. Such things generally mean that security is taken seriously.

🔜 😈

More disclosures soon.

Thanks for reading!