3 XSS in ProtonMail for iOS
No, these XSSs are not so scary.
# I ❤️ DOMPurify
DOMPurify is a popular XSS sanitizer by Cure53.
DOMPurify - a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure…github.com
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 😃
- Fires in
applewebdata:origin on email opening —
2. Fires on click in
applewebdata: origin (🤦♀)
3. Fires in
data: origin after loading email’s remote content
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.
It wasn’t possible to escalate these XSS into RCE/LFI. At least, I didn’t find such a way.
- JS execution via email is already an issue.
- Privacy violation: track when the user opens the email, disclose IP, leak other info.
- Phishing via
- “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
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.
Safari local file reader. Contribute to Bo0oM/Safiler development by creating an account on GitHub.github.com
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.
- Dec 11: Reported XSS in
applewebdata:origin with no interaction via
- Dec 11: Reported XSS via
- Dec 14: Response from ProtonMail Sec team
- Dec 25: Found a XSS in
- Dec 25: Reminded the security team about findings
- Dec 29: ProtonMail Sec team replied that these XSSs aren’t so scary, because they don’t allow reading emails
- Jan 12: Made an accent on the fact that 2 XSS fires in
- Jan 13: Made a PoC UXSS in
applewebdata:to demonstrate that XSS context could be considered as privileged.
- Jan 14: ProtonMail: no emails reading => not critical.
- Feb 12–13: Made a few tweets regarding my findings in ProtonMail.
- Feb 14 ProtonMail replied on Twitter.
- Feb 15: Andy Yen emailed me via ProtonMail: ProtonMail team made an additional review of reported vulnerabilities + apology for the miscommunication.
- Feb 15: The vulnerabilities patched in the stable.
- Feb 27: ProtonMail agreed to disclose the report.
# Thanks to …
- All my Twitter followers 💙
- Anatoly from ProtonMail iOS team for noticing my tweets about the issues in ProtonMail 😉
- ProtonMail SecTeam for their continuous work on ProtonMail’s security 🚀 and for making this disclosure possible
- Andy Yen for the personal review of reported vulnerabilities. Such things generally mean that security is taken seriously.
More disclosures soon.
Thanks for reading!