April 3, 2017

I could hijack 629 LinkedIn accounts by re-registering purged inactive (or mistyped) email addresses at the largest free email provider in the Czech Republic, Seznam.cz. But I haven't, of course.

Shortly after the LinkedIn breach was confirmed and the dump was published in May 2016, Rob “Mubix” Fuller blogged about hijacking LinkedIn accounts by snatching expired or mistyped domains used in email addresses in that data dump. Mubix had inspired me (thanks!) to do a similar short research. For whatever reasons I'm publishing it with a small delay.

Purged mailboxes

Seznam.cz, the provider, offers three domains for your emails: @seznam.cz, @email.cz, @post.cz. I've found 75898 email addresses with such domains in the LinkedIn dump.

Previously, Seznam.cz was purging inactive accounts, now they unofficially say they don't do it anymore. (Now officially, see Seznam statement below.) This was confirmed to me by several Seznam.cz people, off-the-record. But unfortunately their Terms of Use state they can still delete any abandoned mailbox:

  1. h) The Operator reserves the right to delete any User account in the Email Service system at any time and without compensation:
    • which having been created, has not been logged into by the user for a period of more than ½ a year

So I thought, maybe Seznam has already deleted some of the mailboxes, because people stopped using them but forgot to change emails in their LinkedIn profiles. Luckily, the check whether the Seznam.cz-provided address is available could easily be automated. When signing up, there's a background check to see whether the selected username is available. It's done by issuing a request to:

https://registrace.seznam.cz/api/v1/username-check/availableaddress@seznam.cz

The call will return a JSON with "available": true when availableaddress@seznam.cz can be registered:

Seznam.cz API username check result

I've built a simple script to go through all 76k email addresses and call the API endpoint to see if they were available and thought no way it's gonna work. It was 2AM so I ran the script and went to bed. Using just a single thread and a single network interface, no proxies, no Tor, doing 5 reqs/s, the script went through all the emails in 4 hours. Obviously, the username-check API was missing any rate limiting, or throttling, so later that day, on June 25, 2016, I reported the bug to a friend of mine working at the Seznam.cz CSIRT team. Still no rate-limiting on the username check API as of March 25, 2017, still some 611 accounts available for registration.

Account hijacking

In summer 2016, the script yielded 629 available Seznam.cz accounts, roughly 0.8% of all Seznam accounts from the LinkedIn dump. I could go and register these accounts and ask LinkedIn to send me a password reset link for each of them. And of course, I did, I wanted to know if these are real LinkedIn accounts.

I'd registered 7 random addresses, then asked LinkedIn to send me the reset links. The email with the link contains a footer message, that's your name and professional headline to help you distinguish authentic LinkedIn emails from “phishing” email messages, so I could search these people by name on LinkedIn and have concluded these are real people. I didn't reset any password, and deleted these Seznam.cz accounts immediately after receiving the reset link.

LinkedIn password reset email footer

Quite a lot of the available addresses are obviously typos (like let's say micheal.foobar@seznam.cz), the API will return "available": false when you correct the typo. But these mistyped emails are still associated with real LinkedIn profiles, though probably not heavily used ones.

Conclusions

With hijacked accounts, the attackers could scam their contacts, or do whatever they actually want.

If you're an email provider, like Seznam.cz, you should not delete inactive accounts and you should update your Terms and Conditions to actually officially say that you don't delete, so people can get serious with their emails. I mean no sane provider would delete existing accounts, right? (Note: Seznam.cz will also delete accounts which having been created, 14 days after creation still has not been used once, but that seems alright to me.) Also, throttling your username check API would make sense.

When building a service without sign-up email verification, you can minimize domain typos by adding Mailcheck to your sign-up forms:

Corrected domain typo on Kickstarter sign-up

Mistyped domain on Kickstarter sign-up page

By the way, Google lets you choose what happens to your account when you stop using it with Inactive Account Manager.

Seznam.cz statement

I've sent this post to Seznam before publishing, thought it's fair. Irena Zatloukalová, PR Manager, has confirmed they don't delete e-mail accounts, and they do not release mailboxes for re-registration. That's good (and official) news, thanks for that! Although they want to keep the option in their Terms of Use to delete the account if the user has not signed in for more than 6 months, it just makes sense for them. Only after reading Seznam's response I learned that deleting (e.g. data) is not the same as releasing the address for re-registration. So maybe all the available addresses are just typos or wrong domains, and Seznam has not recycled any address since the LinkedIn breach in 2012. Doesn't really change much on the possibility to hijack some six hundred accounts, but I wouldn't like to do any wrong to Seznam.

The spokeswoman also commented that Seznam.cz cannot take responsibility for mistyped addresses when signing up for 3rd party services. That makes sense, of course, and if you want to be sure your users are using correct email addresses for registration you need verify them by email.

User check API throttling does not make sense according to Seznam, they say rate limiting could be bypassed using multiple IP addresses, event though it would take longer.

That's correct, although for me, using tens of IP addresses would make this short experiment absurdly expensive. No need to buy IP addresses, you get tons of them for free due to default router credentials, Tor, and VPN, but I'd need to automate the hell out of this and that would take time. And time's money, so I'd probably just do something more useful instead :-)


Recommended reading

Michal Špaček

Michal Špaček

I build web applications and I'm into web application security. I like to speak about secure development. My mission is to teach web developers how to build secure and fast web applications and why.

Public trainings

Come to my public trainings, everybody's welcome: