Will You Get Phishing Emails From someone@harmony.one?

Ever since we got listed and launched our mainnet, we have been seeing more and more ladies and gentlemen pretending to be Harmony staff and trying to scam unsuspecting targets on various social venues where we have presence. Everyone could guess that Telegram would be the most popular medium — no pun — for identity spoofing, but older technologies are no exceptions either: Phishing emails.

You have most probably seen some of those spoofers pretending to be your bank. Maybe you chuckled at some of them too. But phishing emails are becoming increasingly tricky to tell apart from genuine ones, and more people are falling for them.

Interestingly though, I bet that you rarely — if ever — see a phishing message purporting to be from your friend’s Gmail address that you keep in your contact list. In fact, if you pay close attention to the sender address of those phishing emails, you will see that the address does not match who they claim to be.

And I say: “O hai phisher, try again from @zimbra.com, not from @tdsml.net”

This holds true not just for @gmail.com, but for any sender address from a reputable domain — the right side of the @ mark — such as @hotmail.com, @yahoo.com, and of course, yours truly: @harmony.one. But how do we thwart phishers from impersonating us?

We let the Internet know exactly from which email servers we will send all our emails.

This method is called Sender Policy Framework (SPF). Today I am going to talk about how it works for our benefit.

A Long Time Ago In A Galaxy Far, Far Away…

There used to be a time when anyone could send any email from anywhere on the Internet, claiming to be any sender (the “From:” address). For spammers, scammers, and phishers, this was a boon: Even if their bots were just random home PCs behind a cable modem somewhere out there, the phisher would be able to commandeer them to send phishing emails allegedly from, say, “securityalert@acmebank.com” — and mail servers and victims believed that! This type of email spam/scam bot operation was a BIG issue back in early 2000s: At one point, spams accounted for an estimated 2/3 of the entire Internet traffic.

After some time, email servers — especially those that served large customer bases such as Hotmail and Yahoo — Gmail didn’t even exist then — got smarter and started blacklisting residential IP address ranges, and residential Internet service providers (ISPs) started operating their own mail servers for their customers to send emails through. This sender IP blacklisting worked pretty well for some time, until botnet operators started targeting and commandeering non-residential computers instead, such as poorly secured servers, to send spams. And that was much harder to fight.

Email server operators, however, noted that spammers did not bother to go forge sender IP: Although technically possible, it was apparently impractical. What didn’t work was blacklisting, which was easy to evade. So they came up with an idea: Why not whitelist? If, for an email domain such as gmail.com, all emails from the users in that domain originated from a few email servers that the domain holder operated — which is usually the case — the domain could advertise/whitelist the IP addresses of those servers in domain name system (DNS), and other email servers, especially ones for the recipient of a message, could query DNS and match the sender’s IP address against the advertised ones. Upon a mismatch, the message could be rejected or flagged as suspicious.

Sender Policy Framework does exactly this.

SPF In Action

(here.be.dns.dragons.com)

Let us examine how we set up SPF for harmony.one:

$ dig +no{all,cl,ttl} +short +ans harmony.one IN TXT | grep spf1
"v=spf1 include:_spf.google.com ~all"

This translates:

1. “We send all our harmony.one email from Google’s servers listed in their DNS at _spf.google.com (since Google hosts our email).
2. “If you receive email with an @harmony.one “From:” address from any other server (‘all’), though, don’t be too harsh; still deliver it, but inspect closer and maybe flag it as suspicious (‘~’).”

Soft Fail Versus Hard Fail

The sender’s recommendation describe above (“still deliver but with caution”) is called a soft fail disposition, marked with a leading tilde.

If we wanted to go even stricter, we could change “~all” to “-all” (with a leading hyphen), in order to recommend: “If you receive email with an @harmony.one “From:” address from any other server, deal with them in full force according to your local policy.” This is called hard fail. The usual local policy for hard fail is to reject the message: The receiving server would either refuse to accept it for delivery, or accept but silently discard it without delivery.

Why Go Soft?

Many people believe that soft-fail sender policies are exploitable security holes — some of them have recommended us to switch to hard fail. That is not entirely true. Soft fail originated in the early days of SPF, when both the protocol and its implementations were quickly evolving and sender domain administrators were still implementing their policy, therefore there was a significant chance that a change in the protocol specification, a buggy/outdated implementation, or a misconfigured sender domain would cause recipient mail servers to start rejecting messages that should be accepted and delivered. So, sender domain administrators wanted to specify a policy with a safety net — that is, soft-fail — that gave the recipient at least a chance to recover such misclassified messages, instead of instructing recipient mail servers to hard-reject messages at the SMTP level — which would leave the recipient no chance of recovery.

To this end, most modern mail servers move soft-fail messages out of the recipient’s sight, e.g. the messages are sent directly to Trash or Spam folder, so the actual chance of the forged message catching the recipient’s attention is close to nil, but if needed, the recipient could look in their Trash or Spam folder to find the message (that is, in the “no I didn’t receive it but let me check” situation).

In a sense, this is in accordance with the robustness principle, often quoted as:

Be conservative in what you do, be liberal in what you accept from others.

That is, we send our emails from Google’s mail servers only, but we recommend receivers to be more liberal than that, in the spirit of interoperability.

But There HAS Be A Cryptographic Defense…?

You may be iffy with the IP-address-based sender check. And you are right: SPF is not bulletproof. In fact, if we go a few levels deeper:

$ dig +no{all,cl,ttl} +short +ans _spf.google.com IN TXT | grep v=spf1
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig +no{all,cl,ttl} +short +ans _netblocks.google.com IN TXT | grep v=spf1
"v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig +no{all,cl,ttl} +short +ans _netblocks2.google.com IN TXT | grep v=spf1
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig +no{all,cl,ttl} +short +ans _netblocks3.google.com IN TXT | grep v=spf1
"v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

Let’s see, Google whitelisted (deep breath) 3 /16 networks, 1 /17 network, 1 /18 network, 7 /19 networks, 4 /20 networks, 1 /21 network, 1 /22 network, and 1 /24 network. Definitely not a few mail servers! It seems that Google has whitelisted the entire IP address blocks it operates. I get that maybe Google doesn’t want to give attackers an easy target by publishing IP addresses of individual mail servers, fair enough, but a total of 322,816 (!) IP addresses whitelisted — I’m not even counting IPv6 addresses —are a little too wide of a range to tell the world to trust with our email.

And ranges include the IP addresses that Google lets its Cloud customers use. For example, I already see that the backend server of our Harmony Puzzle (hosted by App Engine) resides in the 216.58.192.0/19 block above. This means that, if an attacker somehow landed their hands on one of these IP addresses, they could start phishing as someone@harmony.one. (Fortunately though, it isn’t as easy as simply provisioning a Compute instance: Google probably foresaw this, and filters all SMTP traffic from their Compute instances.)

So, all in all, since Google’s SPF range is too wide and we have no better idea about the IP addresses of the actual mail servers that send our emails either, SPF does fall a little short. We saw this, and we are unafraid of cryptography — of course — so we go one step further and employ a cryptographic defense in tandem with SPF. That defense is called DomainKeys Identified Mail (DKIM). I will talk about that in the next post.

Until then, rest assured — we will not phish you!