How to protect against typosquatting

Here at BlueCat, we like to point out that there’s gold in your DNS data. Insights on user behavior, cybersecurity threats, and network optimization are just sitting there in your DNS logs, waiting to be found.

Recently, we decided to comb through a representative sample of seven billion anonymized DNS queries which flowed through BlueCat solutions over the past month, just to see what we could learn. The answer? A lot. So much, in fact, that we put the most interesting insights into our Network Trends report.

Even some of the smaller things we noticed are interesting, though. As we sorted through the most frequently queried top level domains (TLDs), three of them stood out: .cm, .co, and .om.

The looming threat from Cameroon, Colombia, and Oman

If you’re a geography geek, you’re probably wondering why so many DNS queries were going to the TLDs for Cameroon (.cm), Colombia (.co) and Oman (.om). The answer is actually fairly complicated.

From the data we looked at, it appears that most queries to .cm, .co, and .om are simply typos. People meant to go to .com, but missed the “c”, “o”, or “m”.

These “fat finger” errors happen more than you might expect. Out of seven billion DNS queries, 0.2% of them went to one of those three TLDs. That doesn’t seem like a very high percentage, but it still represents over 7.5 million queries – a pretty significant number.

Fun fact: Colombia is the clear winner in the typo sweepstakes. Over 99% of all typo queries went to that TLD. Oman came in a distant second with around 0.48% of all typos, and Cameroon with the remainder. The difference between Oman and Cameroon is actually counterintuitive if you consider that the three characters in .om are all typed with the right hand on a desktop computer.

Is this a problem?

These typos would be innocent if they failed to resolve – people would get an NXDOMAIN response, figure out the error, and move on. In these three cases, however, there’s a possibility that the .cm, .co, and .om versions of a website actually exist.

Spammers and malicious actors are well aware of the opportunity provided by “typosquatting”, and bank on the volume associated with 0.2% of all DNS query traffic. The .cm, .co, and .om versions of many top sites were purchased by a few savvy entrepreneurs. They use these parallel website addresses to spread malware or drive traffic to commercial storefronts different than the user’s intent.

If these typo domains are such a problem, it would seem that blocking the .cm, .co, and .om TLDs across the board would be a prudent action for most corporate networks. Unless you’re doing business in Cameroon, Colombia, or Oman, it’s unlikely that allowing queries to those domains serves any legitimate purpose, right?

Actually, we found that it’s a little more complicated than that.

Well aware of the typosquatting problem, some large companies (such as Yahoo) have gone to the trouble of purchasing different versions of their registered domains to try and keep URL hijacking from impinging on their search volume. These usually redirect to the correct .com version of the site, with the user none the wiser for their mistake. (If you’re a Yahoo user in Cameroon, you’ll be redirected to the US site. Tant pis.) Blocking the TLD of these alternative websites would probably point out the user’s error, but it would also prevent the resolution of legitimate traffic.

URL shorteners provide another reason not to block .cm, .co, and .om across the board. Companies like short.cm use domains from Cameroon, Colombia, and Oman for legitimate redirects. Instead of typo squatting on legitimate domains, they use algorithms to develop redirects which happen to be hosted on foreign TLDs. If someone clicks on a legitimate social media link handled by short.cm and gets an NXDOMAIN or a redirect generated by an internal security policy, the reasoning might appear opaque to an end user.

What to do?

In the end, the way security policies are applied to .cm, .co, and .om will be a judgment call for security teams. This is one of those areas where the specific needs of your business will dictate how you protect your network.

In many cases, threat feed providers will make the choice for you, blocking typosquatted sites which are known to be malicious. You can also use threat feeds to block these TLDs across the board, assuming that the risk is greater than any collateral damage from legitimate queries which can’t get through. Others have a more refined approach, blocking the parallel versions of major sites only when they can be traced to malicious activity.

As we’ve mentioned elsewhere, BlueCat’s approach to blocking malicious TLDs tends to be more forward leaning. The potential impact of malware is so large that it usually makes sense to block an entire TLD. Yes, there may be a few legitimate sites in the .men TLD (choosing a somewhat random example). But they are few and far between. Better to block first and make exceptions later.

One approach that we recommend to our customers is to define TLD blacklists containing riskier TLDs like .top and .tk, and then define a whitelist of known good domains that use the TLDs that your organization actually needs access to.

Regardless of which strategy you end up pursuing, DNS data provides critical context to guide the decision-making process of your security team. To know the extent of your network’s exposure to malicious TLDs, you have to look at DNS query patterns. To look at DNS query patterns, you have to be collecting DNS data. This can be a lot harder than you might think, particularly in decentralized infrastructures such as Microsoft DNS and BIND.

This is where BlueCat can help. Our unified DDI management solution brings all your DNS data together, so you can make educated decisions about how to craft security policies. Plus, our DNS security tools make it easy to apply those policies uniformly across the enterprise.

Read more in our free eBook “The Enemy Within”.