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.
email@example.com -> firstname.lastname@example.org -> email@example.com
The attacker sends an email to a mailing list submission address,
firstname.lastname@example.org. 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
email@example.com, 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.
firstname.lastname@example.org -> email@example.com -> firstname.lastname@example.org
The attacker sends an email to an unknown address that does not identify the victim, here
email@example.com. This mail is then forwarded to
firstname.lastname@example.org, 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
email@example.com is actually Bob.
firstname.lastname@example.org -> potato on InnocentWebCommunity.example, via web form -> email@example.com
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
firstname.lastname@example.org with its
From header as
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.
All the examples for Attack 1 apply for Attack 2, when a final forward to
email@example.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.
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.
Introducting a comment section is currently under investigation. Further updates will be provided in due course. For now, try writing a comment on your favourite link aggregator, or email me.
Articles from other blogs I follow
I think what I’m asking for is impossible… I have a Linux laptop with built in speakers and an external monitor with speakers. The laptop connects to the screen via HDMI. I have my Linux desktop set up for dual screens. If I drag a window from one screen …via Terence Eden’s Blog June 15, 2020
Like last month, I am writing to you from the past, preparing this status update a day earlier than usual. This time it’s because I expect to be busy with planned sr.ht maintenance tomorrow, so I’m getting the status updates written ahead of time. aerc has se…via Drew DeVault's Blog June 15, 2020
I've been digging into async exceptions in haskell, and getting more and more concerned. In particular, bracket seems to be often used in ways that are not async exception safe. I've found multiple libraries with problems. Here's an example: withT…via see shy jo June 10, 2020
Generated by openring