Email privacy is dead, confirmed for the umpteenth time. In this post I present the SOILED-PRIVACY attacks (Systemic Online Information Leakage using Email+DMARC against Privacy). These are two reflected attacks against email infrastructure allowing an attacker to access private knowledge about a target user, transparent to mail forwarding, mailing lists, and web services.
Many email users choose to use an address under a generic domain under the control of a commercial email-service provider, their ISP, or a cooperative operator; however there is also a large proportion of email users that choose an address under a domain they or their organisation owns. There are many advantages to using a domain under your own control, including (but by no means limited to): portability between email service providers; increased personal or corporate branding potential; and improved user choice or privacy as a result of self-hosted infrastructure.
However, a custom domain also necessarily entails some privacy downsides: as there is a trivial mapping between personality and domain name, it is possible for any person or service sending mails to an address under the domain to identify its owner. Depending on the use case of the emails being sent, this may not be a particular problem or may even be an advantage. However, in many cases this is a serious downside - very often users do not want to be identified personally by all the services they use or content-providers they subscribe to. These downsides have led to the development of various workarounds to protect user privacy. Such workarounds include:
- Anonymous or single-use forwarding addresses.
- Mailing lists not publishing lists of recipient addresses.
- Web services proxying user-user mail (e.g. with a web form or forwarding address).
Users of custom domains have come to trust that these are effective at protecting their private activities, and limiting their trust boundary to the forwarding address operator, mailing list service or trusted web service rather than having to trust the whole of the internet or all other users of the services they use. The attacks presented mean that the above workarounds are not effective solutions and do not provide privacy of recipient, and therefore should not be used without either user knowledge of the attacks or relevant mitigations being applied.
DMARC: Defective by Design
DMARC is a internet technology that aims to combat email forgery and reduce the incidence of spam being sent with forged From addresses. It achieves this by standardising a DNS TXT record that can be attached to a domain by its owner. A server that receives an email can fetch the record for the domain in the From header of the email. DMARC gives the receiving server guidance on what to do when DKIM and SPF checks fail - to delete, quarantine (typically place in the spam folder), or to do nothing. Although DMARC has been subject to valid criticisms (particularly because it breaks many existing mailing lists and forwarding systems), it is a valuable tool in the fight against forged transactional email and spam.
As well as giving guidance to receiving servers, DMARC also establishes a feedback loop: receiving servers are encouraged to send reports detailing successful and failed forgery checks back to a location nominated by the owner of the From domain. In theory, this allows email senders to track down and fix errors in the infrastructure causing unwarranted SPF or DKIM failures.
However, in practice this opens up significant privacy issues which have not been communicated properly to the internet at large. I quote from the DMARC specification, RFC 7489:
When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages’ recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.
The attacks presented in the next section exploit this specified behaviour, which is inherent to DMARC aggregate reports sent by a very large proportion of email service providers. The providers sending these reports vary in size from individuals’ personal mail servers to behemoths like GMail and yahoo. Forensic reports are even worse, again quoting from the specification:
Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. […]
although the [format] used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient.
Luckily very few email providers send DMARC forensic reports, for obvious reasons: not only the breach of privacy inherent in sending detailed reports but also the potential for amplified (or even self-reinforcing) backscatter DDoS attacks and the cost associated with significantly increased processing effort on their own machines.
Attack 1: Reflected Self-Exfiltration using Aggregate DMARC
This is the simplest case, when an attacker arranges that an email is sent with their domain as the From, and elects to receive DMARC aggregate reports. The attack email (which can have any content or none, and could even be rejected by the server per DMARC rules) is sent to an address that does not personally identify the victim, but forwards to a domain that does. This could be a mailing list, anonymous forwarding address, or web service.
When the victim’s domain’s mailserver receives the email, and dutifully returns the DMARC aggregate report, their personality will be revealed.
Example 1:
malicious@attacker.example -> xxx@mailinglists.example -> itsme@alice.example
The attacker sends an email to a mailing list submission address, xxx@mailinglists.example. The attacker does not know what the recipients of their mail will be, because the mailing list does not publish subscriber information. The attacker’s email is forwarded to itsme@alice.example, an address that identifies the victim, Alice.
The receiving server for alice.example then send a DMARC report to the attacker, identifying alice.example as the sender of the report. The attacker now knows that Alice subscribes to the target mailing list.
Example 2:
malicious@attacker.example -> totallynotbob@gmail.com -> hi@bobworld.example
The attacker sends an email to an unknown address that does not identify the victim, here totallynotbob@gmail.com. This mail is then forwarded to hi@bobworld.example, an address that identifies the victim, Bob.
The receiving server for bobworld.example then sends a DMARC report to the attacker, identifying bobworld.example as the sender of the report. The attacker now knows that totallynotbob@gmail.com is actually Bob.
Example 3:
malicious@attacker.example -> potato on InnocentWebCommunity.example, via web form -> contact@charliesplace.example
The attacker sends an email to potato, a user on InnocentWebCommunity, via the web form on InnocentWebCommunity.example. The email is sent by the web service to contact@charliesplace.example with its From header as malicious@attacker.example. potato is not an identifiable username and the malicious attacker wants to find out their real information.
The receiving server for charliesplace.example then sends a DMARC report to the attacker, identifying charliesplace.example as the sender of the report. The attacker now knows that potato is actually Charlie.
Attack 2: Forwarded Reflected Exfiltration using Aggregate DMARC
In this case, similar to Attack 1, the attacker arranges that an email is sent to the victim with the attacker’s domain as the From, and elects to receive DMARC reports for that domain.
The attack email must be sent to an address that does not personally identify the victim, but that forwards to an address with domain that does. The difference in Attack 2 as compared to Attack 1 is that this identifiable-domain address then forwards the email on again, to another provider that sends DMARC aggregate reports.
Since the personally-identifiable domain forwards the email, the IP and domain of its mailserver will become visible in DMARC reports sent by the ultimate receiving server back to the attacker.
This is the more complicated case, which is not relevant to as many email users as Attack 1, but has been mitigated by very few third-party email-service providers, if any.
Examples
All the examples for Attack 1 apply for Attack 2, when a final forward to example@gmail.com is performed by the personally-identified domain.
Are you vulnerable?
- If your email addresses are only under generic domains, you are not vulnerable.
- If all the servers processing email for you do not send DMARC reports or participate in feedback loops, you are not vulnerable. (but you can’t assume things will stay this way)
- If you do not forward emails from a custom domain, and the servers processing mail for you anonymize DMARC reports, you are not vulnerable. (This applies to most, but not all, custom domain users on commercial mail hosts, and means Attack 1 is less potent than it might otherwise be.)
Otherwise, if none of the above apply, you may be vulnerable. You should review your email pipelines and ensure that the appropriate mitigations, some of which are detailed below, have been applied.
What can you do about this?
The only foolproof method to avoid these attacks is to use a generic domain (e.g. hotmail, aol, etc.) to receive your email, and not to forward any mail to a custom domain once it is received.
If you use your own domain, do not automatically forward mail from this domain. If you do need to forward mail in this situation, make sure you forward to a server you control and trust not to send DMARC reports.
If you control your own mail servers, disable all DMARC reporting or delivery feedback loop mechanisms.
If you don’t control the servers that receive your mail, switch to ones you do control or ask the server owner to disable all DMARC reporting and to not participate in delivery feedback loop mechanisms.
Commentary
The fact that this perfectly simple and obvious privacy leak has been standardised and adopted by the vast majority of email service providers (even many of those that cry about ‘protecting your privacy’) is rather mind-boggling.
This speaks to the general state of affairs around email privacy - it’s basically an impossible task to fully protect yourself; without significant behaviour changes, and deep knowledge of the operation of all components in the email pipeline there are just so many holes that patching one makes little difference.
My opinion is that there is a fundamental problem in the ecosystem: email standards are too complicated, and have not been designed with privacy in mind. When problems with existing standards have arisen, the solution seems to have been adding additional complexity layers on top of the existing ones.
Unfortunately this is a problem of interoperability as email is a federated system which has developed over time; standards developers have attempted to keep backwards-compatibility when writing new standards but the negative effects of some of these decisions look rather more evident in hindsight than they might have appeared at the time.
I don’t have any solution for this problem, nor do I believe switching to some alternative ecosystem is a good idea: if email didn’t work ok, then it wouldn’t be so successful as it is. Nevertheless, it’s sad that things are as bad as they are.
Comments
No comments yet!
To leave a comment, please send it via email here. Comments are licensed CC-BY as with the rest of the site. Your sender name and email address will be published along with the comment, unless you tell me not to.
Articles from other blogs I follow
NaNoWriMo - An Introduction and Chapter 1: There Are Nine Million Autonomous Bicycles In Beijing
Every year since 2009, I've taken part in NaBloPoMo - National Blog Posting Month. The aim is to publish a new blog post every day in November. In the last few years, I've blogged pretty much constantly - daily for 2020, 2021, and 2023. A total of…
via Terence Eden’s Blog November 1, 2023Jools Holland will be making London Underground station announcements tomorrow
Listen carefully on your commute on Thursday as you might hear Jools Holland on the tannoy.Read more › This article was published on ianVisits SUPPORT THIS WEBSITE This website has been running now for just over a decade, and while advertising revenue contri…
via ianVisits November 1, 2023On "real name" policies
Some free software projects reject anonymous or pseudonymous contributions, requiring you to author patches using your “real name”. Such projects have a so-called “real name” policy; Linux is one well-known example.1 The root motivations behind such policies…
via Drew DeVault's blog October 31, 2023Generated by openring