DKIM Signing Change / "Vulnerability" Exposure

Two days ago a customer of ours approached us to report what they called a vulnerability. While it's not an entirely unfair use of the word "vulnerability," it isn't quite deserving of being categorized with exposure of private data, server intrusions, or any of the normal things that often worry or excite people when the word "vulnerability" is used. It's actually nothing new, and it's nothing we weren't already aware of. However, the user chose to publicize it and that necessitates a public response.

The Resolution

The change made to address this is simple: When you send an email, the email is signed by a DKIM key on our system. That DKIM key is different for each domain. Three days ago, the DKIM key was signed based on your sending domain (the domain in your envelope-sender address). Two days ago, that changed to now be based on the domain in your authenticated domain. So if you use SMTP login credentials for domain1.com, and set your sending address to an address on domain2.com, the email is signed by the DKIM key for domain1.com. This is only significant if you authenticate as one domain, while sending email from another domain.

The Problem

The user reported this on Reddit as a vulnerability for a simple reason. I'm going to use sample data to describe it:

On the echo.mxrouting.net Customer1 added the domain domainone.com. Customer2 added the domain domaintwo.com. If Customer2 sent an email that claimed "user@domainone.com" as it's sending address, the echo.mxrouting.net server would sign the email with the DKIM key for domainone.com, even though domainone.com belongs to Customer1, not Customer2. This means that technically, Customer2 could send an email as Customer1 which passed both SPF and DKIM authentication, making it appear very real and legitimate to the recipient. The recipient could not be expected to have any idea that the email was not real or legitimate. You can hopefully see pretty quickly why that's a problem, and you can imagine the ways that this can be exploited.

My Response to the disclosure

I would like to paste my response from Reddit here, and let that be the remainder of this blog post.

I've known about this since 2011, a lot of us have. It's the way all cPanel and DirectAdmin servers function, likely extending much further than that. It's pretty inherent in an average exim configuration. It signs DKIM based on the sender domain, not the authenticated domain, and no ownership of the sender domain is checked.

I'd been thinking nearly every day for years how I would handle this when someone figured it out. Because I didn't want to be the first one to break functionality that innocent users were taking advantage of for their convenience across a wealth of companies, when no one was abusing it, simply to be the hardliner who elevated possible abuse over real world usage. My hope was that someone would figure it out at a much larger company than ours, so that someone with a larger budget and more staffing could develop a more elegant drop-in solution and everyone downstream (like us) could benefit from their work.

My frustration is that this could have been found at a wealth of publicly traded companies, that it's first publication didn't have to be outed as an "MXroute vulnerability" when we're one of the lowest budget companies using the same software stack. So I now have to be the one to break functionality that a fair amount of users were innocently using for their own convenience, while no one has been abusing this, because it has finally been made public and unfortunately framed as my failure rather than that of so many major corporations who came before me.

The reason your account was terminated is much simpler. While I understand your intent for testing this and I did say as much in our brief conversation, I also needed you to understand my commitment to preventing abuse of our platform. So I suspended the email account (not your whole account) that you had used to spoof the sending address of other customers of ours on the same server as your account, and I asked you to promise that you would not be spoofing the sending address of any other customer of ours. When your response made no such promise but instead became rather combative and calling my response "concerning," I terminated your account.

That I knew for many years of a problem stretching across a wealth of companies, which house millions of accounts, that you found to be new and shocking information does bother me. Because, quite frankly, your day job is handling security at a company so significant to everyone that your security is quite literally sitting next to my car keys. I have to admit that it makes me question if this isn't new information at all, but rather that you wanted MXroute to be the ones to suffer from the exposure when you knew you could've picked from any number of publicly traded companies. That bothers me enough to ban you from the subreddit, because it's plausible to me that your motives aren't pure. The alternative is even more troubling, that the person handling such widespread security that I would have it on my own personal keychain, is out of touch with industry security on the ground. I'm not outing you for that, let the reader's imagination run wild, but it's my honest concern.