Typosquatting and stale users

lock

Our customers get an email to alert them when someone accesses their account from a new physical location. If the location is from any country other than the small handful that are home to the vast majority of our customers, then our cybersecurity department is CC’d as well. It looks something like this:

warning-2

This warning email gets sent to the customer and, depending on the country, to LexBlog security staff as well.

Breaches are exceedingly rare, and they are virtually impossible if customers use strong passwords. But there’s a certain category of vulnerability that circumvents all of this.

Typosquatting: It Exists

Last week, I was reviewing a warning email like the example above. The first thing I noticed was that it was from a central Asian country that had no obvious connection to the customer account, indicating that we had a bonafide account breach on our hands. This came as a surprise because of all the security layers we have in place, and I immediately assumed that the customer was using weak/compromised login credentials. Then I noticed the customer email address had an obvious typo in it. Something like this:

Expected email address: john@examplelawfirm.com

Actual email address: john@exampelawfirm.com

I wasn’t sure what to make of it and I began digging into our email logs and activity logs to get more information. But as I was doing that, if this was not a strange enough morning already, something happened that made my jaw drop:

  • A second warning email
  • From the same central Asian country
  • Pertaining to a completely different customer, different firm, different domain name
  • Also with a curious typo in the email address domain name

So, to review, we had multiple accounts being breached from the same country, with nothing in common other than they both happen to have a typo in the email address domain name.

How?

Why?

Typosquatting.

What happens in this sort of an attack, is a malicious party will purchase a domain name—probably several of them—similar to the one they are targeting. They’ll then set up email inboxes to catch any email being sent to that typo’d domain. In the case of our platform, these users had been created years ago, they were barely used, and no one ever noticed the human error in entering the wrong email address domain. Therefore the attackers were able to simply use the reset password UI to send themselves a link for changing the customer password. Simple. Clever. Effective.

I of course deleted the typo accounts immediately, and alerted the customers who manage both accounts. But that’s just a reactive measure. I wanted to come up with something Proactive.

Blocking Stale Users

We’ve been collecting data on user sessions for quite some time now. We know who’s logging in, when and where:

table

Our new/upcoming UI for browsing recent user sessions.

Better yet, we know who has not logged in recently. We’re in the process of updating the platform to use that data to block stale users from signing in. That event will look something like this:

blocked-1

The user is blocked because he has attempted to sign in for the first time in several years.

In order to resolve this, a LexBlog staff member or a fellow customer on that same blog, who has sufficient access privileges, can toggle a flag on the user profile like this:

flag

This user has been blocked due to their having attempted to access the platform for the first time in several years.

Toggling the “always block this user” setting from “yes” to “no” has the effect of exempting the account from being considered stale.

Will This Be Disruptive?

There is a chance this will be disruptive sometimes. Imagine a customer that has re-discovered an interest in blogging, after having been dormant for three years. If that user is met with the additional resistance of having to contact LexBlog support in order to access the platform, they might never follow through.

The hope is that this scenario is uncommon, and that one support request is not a mountainous obstacle. Most importantly, we feel that the additional security outweighs the additional hassle.

Scott Fennell
About the Author

Scott is a WordPress theme and plugin developer with a penchant for connecting the dots between services like MailChimp, Cloudflare, and GoDaddy. He has been published in A List Apart and CSS-Tricks.

Subscribe
Subscribe to 99 Park Row via Email or RSS
Please enter a valid email address and click the button.
Recent Posts
More content can be found in the Search section.