My Health Record, Reddit hacked, and security keys
I’m back in Stockholm after a nice holiday in Norway, and its good to be back writing again. A lot has happened since I left!
Dot-terminating domain names for domain blacklisting
A quick one to start with: Sucuri has an excellent blog post regarding the use of dot-terminated domain names to bypass domain blacklists:
Taking advantage of this little-known fact may help bad actors avoid detection by web security and ad-blocking software that have been developed without accounting for the optional final period in domain names. Such software may either consider URLs with these type of domains invalid and ignore them. Or it may think that “example.com” and “example.com.” are different domains and will not warn if it comes across a variant that was not in the blacklist.
It’s a cute trick, and yet another example of why blacklists are a fragile security measure.
My Health Record
This story has been major news in Australia for the last few weeks, ever since the opt-out period started on July 16.
To briefly summarise: the My Health Record system is a major Australian Government IT project which aims to consolidate every citizen’s healthcare information into an electronic record which can be accessed by any healthcare provider they might use.
I’m planning to write a proper blog post about this topic in the next couple of weeks, because it sits nicely at the intersection of many of the issues we’ve covered in previous emails (not to mention my Master’s thesis): security, public trust, and the Australian government’s history of failed IT projects.
A few days ago, Reddit made this announcement:
On June 19, we learned that between June 14 and June 18, an attacker compromised a few of our employees’ accounts with our cloud and source code hosting providers. Already having our primary access points for code and infrastructure behind strong authentication requiring two factor authentication (2FA), we learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept. We point this out to encourage everyone here to move to token-based 2FA.
This is the interesting angle to this story: Reddit’s employees were using SMS for two-factor authentication, and they were hacked anyway.
The Reddit announcement came only shortly after a big story by Motherboard on the increasing prevalence of these kinds of attacks:
In February, T-Mobile sent a mass text warning customers of an “industry-wide” threat. Criminals, the company said, are increasingly utilizing a technique called “port out scam” to target and steal people’s phone numbers. The scam, also known as SIM swapping or SIM hijacking, is simple but tremendously effective.
First, criminals call a cell phone carrier’s tech support number pretending to be their target. They explain to the company’s employee that they “lost” their SIM card, requesting their phone number be transferred, or ported, to a new SIM card that the hackers themselves already own. With a bit of social engineering—perhaps by providing the victim’s Social Security Number or home address (which is often available from one of the many data breaches that have happened in the last few years)—the criminals convince the employee that they really are who they claim to be, at which point the employee ports the phone number to the new SIM card.
For these reasons and others, SMS has long been considered a weak 2FA method, but it’s still a lot better than relying on a password alone.
Brian Krebs has a good summary of the Reddit attack and its implications here:
If the only 2FA options offered by a site you frequent are SMS and/or phone calls, this is still better than simply relying on a password. But it’s high time that popular Web sites of all stripes start giving their users more robust authentication options like TOTP and security keys.
This is another situation where it becomes important to consider your threat model. For critical services like your bank or your email account—remember, if someone gets your email, they can reset a lot of other accounts—you should be using something stronger than SMS: a TOTP code like Google Authenticator, or (preferably) a physical security key.
At the other end of the scale (e.g. a throwaway forum account), an account compromise isn’t as much of a world-ending disaster. It’s still worth using 2FA if you can (once you know how to do it, the marginal cost is low), but prioritise the critical services first.
Remember: good security is about knowing what data you care about, and what convenience trade-offs you’re willing to make to protect it.
The strongest form of 2FA: physical security keys
We’ve discussed security keys previously in the form of the Web Authentication standard, and they’re the best 2FA authentication solution available for services which support them.
Google recently announced that they’d completely killed phishing attacks against their employees, by mandating that all employees use physical security keys to access critical systems.
From Brian Krebs again:
Google has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical Security Keys in place of passwords and one-time codes, the company told KrebsOnSecurity. […]
A Google spokesperson said Security Keys now form the basis of all account access at Google.
“We have had no reported or confirmed account takeovers since implementing security keys at Google,” the spokesperson said. “Users might be asked to authenticate using their security key for many different apps/reasons. It all depends on the sensitivity of the app and the risk of the user at that point in time.”
Google also announced that they’ll soon be releasing their Titan Security Key to compete with existing solutions from companies like Yubico.
This is a logical decision by Google. With 85,000+ employees, they’d be in need of hundreds of thousands of security keys (plus replacements), and they clearly have the in-house engineering talent to build themselves rather than buying them externally.