Copyright © 1999–2017 FastMail Pty Ltd
TL;DR: This is the story of a failed attempt to steal FastMail's domains.
We don't publish all attempts on our security, but this one stands out for how much effort was put into the attack, and how far it went.
We've had a handful of minor attack attempts recently. Targetted phishing emails to staff trying to steal credentials. An NTP-based DDOS which was quickly mitigated by NYI, our excellent hosting service.
These sorts of attacks are the "background radiation" of the internet. Along with port scans and entries in the web server logs from malware trying us out to see if we're vulnerable to old PHP bugs (hint, we're not). It's the reality of being on the internet.
About a month ago, our
email@example.com account suddenly wound
up subscribed to hundreds of mailing lists. All these mailing lists
failed to use double or confirmed
someone was simply able to enter the email address into a form and sign
us up, no confirmation required. This really is poor practice, but it's
still pretty common out there. A special shout-out goes to
agencies in the USA for their non-confirmation signup on mailing lists.
The upshot was that the hostmaster address was receiving significant noise. Rob Mueller (one of our directors) wasted (so we thought) a bunch of his time removing us from those lists one by one, being very careful to check that none of the 'opt-out' links were actually phishing attempts. This turns out to have been time very well spent.
At FastMail, our security is central to the safety of our users. Given access to an email account, an attacker could reset passwords on other sites, including those which allow spending real money.
We take this responsibility very seriously, and we're always looking for ways to improve our security.
Two factor authentication (2FA)
The Domain Name System is one thing that's even lower layer and more central to identity security than the email server itself.
Based on recent articles in the tech press, we really wanted to have ALL our domains protected by two factor authentication.
Our domains were historically spread amongst multiple registrars. We chose to consolidate with Gandi because they have a great slogan ("no bullshit"), they support 2FA, and they support all the top level domains we require.
Robert Norris, one of our sysadmins, was in charge of the migration. He set up a corporate account with Gandi to get assistance in transferring the domains, and set up two-factor authentication at the same time.
Gandi uses the popular OATH TOTP (also known as "Google Authenticator") mechanism. Rob wrote a small TOTP client and placed it with the key on our management servers in the secure storage area where we also keep our SSL certificates. The account password itself was encrypted in our password manager, which is stored separately.
Only a small number of trusted people have access to the credentials for our Gandi account. We are satisfied that this level of security is strong enough.
On March 19th, this came to firstname.lastname@example.org:
The hostmaster alias actually forwards to three of us, and we were all hyper-alert, so we thankfully noticed this email.
Within twenty four hours.
Gandi assure us that their fraud detection systems would have detected this, but for the 2 weeks it took from this email until we had full control over our account again, we were worried.
This request had completely bypassed our two-factor protection.
Forged source addresses
There is a well known problem in network security. You can't trust the source address of an IP packet - they are trivially forged.
It's the reason why we have source port randomisation, sequence number randomisation... all the things designed to stop an attacker being able to forge both an initial SYN packet and also the response to an ACK packet to bring up a TCP connection.
While they can falsify the source of a request, an attacker without full network control can not receive the response to their forged packet and continue the handshake.
This is why this email was such a surprise. Like the poor quality mailing lists mentioned above, it didn't require a confirmed opt-in. We had to reply to say that we didn't want the contact email address changed.
This means that a forged source address was sufficient. Even though the attacker couldn't read email to email@example.com, they didn't need to. All they needed was for us to not read it.
To Gandi's credit, they responded very quickly to our "NO, DON'T CHANGE IT" email, and locked our account to stop any further shenanigans while they investigated and collected more documents from us.
We discovered that Gandi received a paper email change form (pdf) claiming to be from a "Robert NORRIS" (the name which appears on our whois data), along with pictures of a passport of said "Robert NORRIS" and company registration documents also claiming to be for FastMail Pty Ltd.
At the time of writing, we are still in debate with the Gandi Legal Department about whether they can even show us these documents. They claim that French Law forbids them from showing us documents which purport to be from us. This is something to be aware of when choosing an vendor - different companies operate in different jurisdictions. There's also a certain degree to which the conservatism of legal departments (protect the company as much as possible) conflicts with the corporate motto ("no bullshit"). The first response we got was certainly bullshit - "in order to meet a legal or regulatory obligation". We challenged them to give an actual legal obligation and were given Article 226-15 of the French Criminal Code, along with rough English translation as follows:
"The act, committed in bad faith, of opening, deleting, delaying or diverting correspondence, whether or not it arrived at its destination, and addressed to a third party, or to fraudulently gain knowledge thereof, is punishable by one year of imprisonment and a fine of 45,000 EUR."
We don't believe that law is relevant - it's the "no interception" law that exists everywhere, and doesn't forbid anyone from quoting documents in replies to the purported source of those documents. If the law really was as Gandi Legal seem to be interpreting it, it would be illegal to quote an email in your response unless you were certain that the source address hadn't been faked.
Was this a "security flaw"?
Security is built in layers, and I would definitely say that the fact that we received that email means one of the layers was weaker than it should be. Partly it's poor choice of wording (Gandi claim that they would not necessarily have changed the email within 24 hours, depending on other investigations).
It still would have been necessary to either disable or reset the two-factor authentication on our account as well for the attacker to get full control. That's difficult, but not necessarily impossible. After the fact, there's no way to know how it would have gone down. We certainly weren't willing to take the risk of doing nothing and seeing what happened!
What we do know is that the attacker was very determined, and willing to go as far as forging documents while simultaneously generating noise to make us less likely to notice the attack. They must have figured they had a chance.
Improving security for the future
A disadvantage of adding something like two-factor authentication after the fact is that you may miss the interactions with your existing processes. Gandi's paper "email reset" form makes a lot of sense in the world where most of their customers are individuals or small businesses with one or two domains, and using addresses that they may lose access to. With no other factors, if they lose access to the email address and forget their password, there needs to be a process to regain access.
It's always great to have a consistent process. Having a consistent process means that attackers can't just try their luck until they find someone who is more trusting than average. Australia has a fantastic system called the 100 point check for authenticating people. We like process, consistently applied.
The problem we have is that we didn't expect that the account email address could be changed without any reference to our two factors at all. Maybe nobody at Gandi realised either. That's a security flaw - even if it doesn't mean everything is totally broken.
We have had some very frank discussions with Gandi over the past week, and they agreed to make all three of the improvements we proposed as a result of these events:
- the setting "disable password resets via email" was not on the security settings page of their website. Because of this, we hadn't discovered and enabled it. They are moving it to the security page.
- if an account has 2FA enabled, a red flag will automatically be raised against the request, meaning significant extra investigation will be done.
- if an account has 2FA enabled, then an active confirmation will be required from the owner of the account before changing the email address. This means it will be harder to regain access if you lose all your factors, but that's a good thing! Turning on 2FA means you want it to be hard for anyone who doesn't have those two factors to gain access.
These steps will make attacks against Gandi accounts even more difficult in future, and we applaud their efforts to improve security and willingness to listen to our concerns.
There is one other measure that we have suggested which is still under discussion. Requiring the TOTP code to be entered on the password reset form, rather than using a secret question. We believe secret questions are bogus security, and we have an appeal to authority to back us up.
Gandi have blogged about this as well, and also given some general advice on keeping your account with them secure.
FastMail came out of this attack unscathed. Our domains are now even more secure, because Gandi has tons of proof on file about who we are and who our company is. Also Gandi's processes have become more secure as a result of our experiences, so we are confident that we can safely keep our domains with them.
An important lesson learned is that just because a provider has a checkbox labelled "2 factor authentication" in their feature list, the two factors may not be protecting everything - and they may not even realise that fact themselves. Security risks always come on the unexpected paths - the "off label" uses that you didn't think about, and the subtle interaction of multiple features which are useful and correct in isolation.