Domain-in-the-Middle Attacks

It’s an easy attack. Register a domain that’s like your target except for a typo. So it would be countrpane.com instead of counterpane.com, or mailcounterpane.com instead of mail.counterpane.com. Then, when someone mistypes an e-mail address to someone at that company and you receive it, just forward it on as if nothing happened.

These are called “doppelganger domains.”

To test the vulnerability, the researchers set up 30 doppelganger accounts for various firms and found that the accounts attracted 120,000 e-mails in the six-month testing period.

The e-mails they collected included one that listed the full configuration details for the external Cisco routers of a large IT consulting firm, along with passwords for accessing the devices. Another e-mail going to a company outside the U.S. that manages motorway toll systems provided information for obtaining full VPN access into the system that supports the road tollways. The e-mail included information about the VPN software, usernames, and passwords.

They’re already being used to spy on companies:

Some of the companies whose doppelganger domains have already been taken by entities in China included Cisco, Dell, HP, IBM, Intel, Yahoo and Manpower. For example, someone whose registration data suggests he’s in China registered kscisco.com, a doppelganger for ks.cisco.com. Another user who appeared to be in China registered nayahoo.com ­ a variant of the legitimate na.yahoo.com (a subdomain for Yahoo in Namibia).

Kim said that out of the 30 doppelganger domains they set up, only one company noticed when they registered the domain and came after them threatening a lawsuit unless they released ownership of it, which they did.

He also said that out of the 120,000 e-mails that people had mistakenly sent to their doppelganger domains, only two senders indicated they were aware of the mistake. One of the senders sent a follow-up e-mail with a question mark in it, perhaps to see if it would bounce back. The other user sent out an e-mail query to the same address with a question asking where the e-mail had landed.

Defenses are few:

Companies can mitigate the issue by buying up any doppelganger domains that are still available for their company. But in the case of domains that may already have been purchased by outsiders, Kim recommends that companies configure their networks to block DNS and internal e-mails sent by employees that might get incorrectly addressed to the doppelganger domains. This won’t prevent someone from intercepting e-mail that outsiders send to the doppelganger domains, but at least it will cut down on the amount of e-mail the intruders might grab.

I suppose you can buy up the most common typos, but there will always be ones you didn’t think about—especially if you use a lot of subdomains.

Tags: , , , , , ,

Posted on September 16, 2011 at 5:22 AM • 43 Comments

Comments

Nick Coghlan • September 16, 2011 6:19 AM

There’s another (partial) defence that’s also a big win for usability: set up proper internal address autocompletion via LDAP or MS Exchange to reduce the incidence of typographical errors. Also use LDAP or AD lookup on intranet sites rather than hardcoding email addresses.

Paeniteo • September 16, 2011 6:57 AM

Encouraging and promoting end-to-end email encryption immediately came to my mind as a possible measure against this threat.

Apart from this interesting attack application, the general problem of typosquatting isn’t really new, anyway.
Another defense would be legal action based on trademark laws (depending on jurisdiction – in Germany, you would have excellent chances when suing countrpane.de, if you had counterpane as a trademark here).

COD • September 16, 2011 7:33 AM

It doesn’t seem like it would be that hard to implement a filter at the SMTP server to check a dictionary of common typos in domain names, and block accordingly.

David Cake • September 16, 2011 8:01 AM

And the technique can be used with bit squatting, rather than typo squatting – register domains that are 1 bit error away from the target. Though typo squatting is more productive, bit squatting may not get noticed at all, especially if the error is corrected in the outgoing mail.

Jaanos • September 16, 2011 8:07 AM

“only two senders indicated they were aware of the mistake.”

And an unknown number of others that sent the followup/resend to the real address.

ole • September 16, 2011 8:11 AM

If’n you have not seen these in logs then check
edu.com
org.com
so if your an org add a com to your name and do an NSLOOKUP, U might be surprised!

ole bin login

paul • September 16, 2011 8:41 AM

It sure is a good thing that domain registrars have no liability for handing out domain registrations obviously intended for use in fraudulent enterprises. The need to vet names against existing ones would cut into their cash flow.

(As the number of top-level domains expands, registrars in fact engage in the opposite of good behavior, warning existing domain holders to pay up for new versions or get squatted.)

HJohn • September 16, 2011 8:42 AM

I would imagine there would be a way to flag emails when not addressed directly to the target (i.e., forwarded, redirected, etc). I can think of a simple rule in outlook to move it to another folder (I realize this is more complicated on larger systems, but the concept is the same).

I’m not skilled at web dev, but there may be a way to tell when a web visitor is redirected. I’m not sure. I can see the anti-malware and web security products picking up on typosquatted sites in the future, particularly if the fiscal risks become substantial enough.

Muffin • September 16, 2011 8:51 AM

Defenses are few

Wouldn’t encryption help? To me as a layperson, this actually seems like an area where it would.

(An attacker might be able to somehow obtain the private keys of an email’s recipient, of course, but in that case, you’ll have a bigger problem than doppleganger domains. And without the keys, the encrypted email will be mostly useless; all you’d be able to tell is who’s emailing who.)

Paeniteo • September 16, 2011 8:53 AM

@HJohn: “I can think of a simple rule in outlook to move it [forwared email] to another folder”

The problem is that your simple rule relies on mail headers that are inserted by well-behaving clients. Malicious forwarders would simply omit these headers.

Winter • September 16, 2011 9:14 AM

For web-sites this would be solved using the HTTPS everywhere infrastructure with a memory of certificates.

For email, maybe start to define (use) smtps and imaps (smtp and imap over ssl) with public key encryption. And then the common check of certificates, just like ssh passphrases.

Obviously, that would mean a background email exchange to get the public keys+certificates of every new email destination.

Peter A. • September 16, 2011 9:28 AM

I’ve read this stuff a week ago on another news outlet and my reaction is still the same: Security can’t protect you from being stupid.

Buying or monitoring such domains isn’t the solution.

Chelloveck • September 16, 2011 9:46 AM

The big problem is that as the recipient of the mail, there’s very little you can do. You have no control over the sender. If the sender is going to send TOP SEKRIT information in the clear and typos the domain, you’re screwed.

End-to-end encryption only works if, as a rule, you reject all unencrypted mail. You need to train your senders that you only accept encrypted email. You can’t even accept low-importance mail unencrypted. If you accept any unencrypted email, eventually someone’s going to mess up and send you that confidential document in the clear. You’re training a puppy not to piddle on the rug. You can’t say, “Well, it’s okay if there’s not very much piddle.”

Detect and reject forwarded mail? Even if technically possible (and I rather doubt that’s the case) that only partially mitigates the problem. The best it can do is to detect that you’ve already been compromised. The MITM already has the mail that was being sent to you.

Captain Obvious • September 16, 2011 9:48 AM

“Defenses are few:”

Why not just combine user awareness with lazyness to fight this issue?

Who types am email address or URL? Ctrl-v was invented some years ago and easily combats this problem.

Captain Obvious • September 16, 2011 9:48 AM

“Defenses are few:”

Why not just combine user awareness with lazyness to fight this issue?

Who types an email address or URL? Ctrl-v was invented some years ago and easily combats this problem.

Brian • September 16, 2011 9:50 AM

Another internal defense – make your company’s DNS servers authoritative for these ‘near domains’ and set their A and MX records to 127.0.0.1 so anyone sending mail to them will be bounced.

paul • September 16, 2011 10:18 AM

Peter A:

We’re all stupid at some time or other. If we’re lucky, that stupidity doesn’t cost too much. The goal of good human-interface and systems design is to increase the scope of that luck.

No One • September 16, 2011 11:04 AM

@Brian: Could even setup an internal mailserver to take these emails and bounce with a nastygram, CC’ing the offender’s manager. I’m sure that’d fix the problem right quick.

Ross Q • September 16, 2011 11:17 AM

Oddly, I’m experiencing something very similar, but in reverse — someone else picked a domain that has resulted in their email being sent to me. My primary domain starts with QU while the other person picked a domain that’s identical to mine, except without the U in it. Since for English speakers it’s nearly reflex for the Q to be followed by a U, I’ve received quite a large volume of misdirected mail. It’s a music venue, and I’m always receiving requests for bookings, tickets, parties, and in one case an interview with the BBC.

I had my domain for a decade before they picked theirs, though, so they’ve done this to themselves. Since I have no intention of spying, and really would prefer to cut down on the spam, it’s a lot more obnoxious than beneficial for me, too.

Petréa Mitchell • September 16, 2011 11:37 AM

Another fun aspect is that if you use a mail program with autocomplete, if you type something wrong once, it will be suggested to you forever and ever afterward if you start typing the address again.

Here I suppose we have come across an advantage of users who save everything to their contacts list and never try to remember actual e-mail addresses. (Well, once they have the correct address in their contacts, anyway.)

Ryan Adams • September 16, 2011 2:06 PM

Encryption is not a practical solution for recipients, as it is the sender that is required to do the encryption. If your company has a few business partners that regularly email your company’s users, you may be able to convince them to only send encrypted emails, but there is no way you can convince every person who may email your company to encrypt their messages. Furthermore, even if you could get everyone to encrypt their emails to your company, typical PKI email encryption setups would fail. When the sender went to send a message, their client would look up the public key of the recipient (theoretically your company) and encrypt the message with that. However, if they incorrectly address the email to a squatter domain, the public key lookup is also going to be done to that domain and then all that has been accomplished is encrypting the email that the squatter gets with a key he has.

The only practical solution that comes to my mind is for someone (either the registrar, your company, ISPs, etc.) to proactively check domain names that are clearly squatters and either block email delivery to them or take control of the domain.

Nick • September 16, 2011 3:27 PM

There is one further set of attacks associated with this man in the middle approach. Adding in messages to the stream. Second deleting messages. e.e Pay 2000 usd to xyz. Are you sure? yes. A doesnt see the message injected by c, and the replies by B arenot forwarded

Pat Cahalan • September 16, 2011 6:31 PM

I’m actually really surprised that this was so successful.

With the prevalence of auto-fill in the average email client and web-linked email addresses…

… ah, mobile devices. Yes. Typing email addresses on mobile devices. I bet that’s the culprit for the lion’s share.

godel • September 16, 2011 8:07 PM

@Pat Calahan: Won’t work if the first time the address is entered, it’s wrong.

Simplified email addresses would be partial defence against this.

Gabriel • September 16, 2011 10:32 PM

The only way encryption could truly help is if the mail server will only allow encrypted email to go out. If you have a pub key for John@sub.foo.com, but type John@subfoo.com, your email client and server are not going to encrypt the email for the second address. So it will either be rejected if you block outgoing plaintext, or it will get through. If you block outgoing plain text emails, then it will be very hard to send an email to a new but intended party, such as sales@technicalresource.tld. Imagine what the smartphone using executive will say when it takes him a few days to set up communications with a new contact. Spell check like functionality mIght help, but a look at auto correct snafus doesn’t leave me with much hope.

Joost • September 17, 2011 2:59 AM

The attacker’s forwarding server has a different IP address than the regular clients, so maybe with some analysis it’s visible in the logs of the web server.

RJ • September 17, 2011 7:47 AM

I saw a doppelganger domain used recently in a “Your package has arrived” spam email. The URL of the tracking link was something like www-appsups.com instead of www-apps.ups.com. Even if you’ve trained your users to hover and check out the links, it takes a pretty close eye to catch that when it’s just part of a long URL with many parameters.

Pat Cahalan • September 17, 2011 1:15 PM

@ Godel

Oh, sure. I was just surprised that the “first time the address was typed it was typed wrong” led to so many mis-addressed emails.

When’s the last time you typed an email address for the first time? Things get in my address book from different venues than “me typing them”.

But then I thought of the mobile device. Which doesn’t have the same address book as the primary email client, perhaps.

Adam • September 17, 2011 11:01 PM

I’ve experienced a similar issue with email addresses. For example, my GMail address is simply my last name @gmail.com. On occasion, I’ve intercepted email meant for others with my last name, presumably distant relatives, sent to them by others who forgot to add a first name either through omission or mail server failure. I’ve gotten addresses, site passwords, personal information, etc.

I’ve done the responsible thing by informing everyone involved and deleting the emails from my account. However, I assume that puts me in the minority. I wonder who else out there might register similar email addresses for more nefarious reasons.

Clive Robinson • September 18, 2011 5:02 AM

@ Adam,

“I type email addresses quite a lot. I had no idea this was (apparently) so unusual.”

It’s not that unusual, but it’s getting rarer by the day, for the same reason people “Don’t know phone numbers” any longer (and this also has a significant personal security/safety issue as well).

When I was a youngster microprocessors had not been invented and computers that were of any use consumed as much electricity on average as a hundred or so homes. By the time I left school you could if you used a month or so’s take home pay buy an 8bit micro with less than 1K of memory. Buy the time I’d finished my “formal education” as an engineer I’d built several computers and owned what was reconisable as a business personal computer and several home computers. All this while telephones (in most parts of the world) still had rotary dialers, although DTMF had been around a while.

However “deregulation” saw a change in that and “cordless phones” came along, these realy needed microprocessors to work and it was thus easy to add “dialer memory”.

It was the introduction of dialer memory that ment that people need not remember seven digit numbers and area dialing codes any longer, they just hit “recal 1” for “Aunt Bessie” and “recal 2” for “Uncle Bill” etc.

It’s progressed to the point with modern mobile/smart phones where now all you need to do is say “call aunt Bessie” and you don’t get to see the number at all.

The security/safety issue with this is when it all goes wrong, that is when you get knocked down crossing the street or mugged etc and carted of to hospital and your mobile phone is lost. You have no idea what your “nearest and dearests” phone number is be it home work or mobile and certainly for “mobile only users” there is no directory enquires that can help you…

Oh and writing the numbers down in an address book is little better, as in a lot of cases (women and their hand bags for instance) the address book is kept with the mobile phone…

Victor Bogado • September 18, 2011 10:16 AM

A fix could be made in the client, the browser could warn the user that this site is not know before sending credentials to them. When a user starts a realation ship with a new site it usually begins with a registration form, so if the user is sending login information to a site that he has never interacted before this could be a redflag.

To make the false positive less troublesome, the browser could also check if the domain is similar to another site that the users usually uses.

Jay • September 18, 2011 7:58 PM

This is a UI problem. Like all UI problems, you can’t fix it at the backend (when the problem’s really in the human).

Given the problem is how bad humans are at string-matching – nayahoo.com/na.yahoo.com – not to mention Unicode character substitution! – perhaps we need to change the problem domain.

I’ve seen a couple of sites on the ‘net that take an arbitrary chunk of data, hash it, and then use the hash to generate a picture.

If our email clients generated ‘pictures’ for our mail recipients, then the problem becomes one of picture recognition (easy for humans) rather than string matching (not so easy).
(The crypto problem of finding a hash collision or visual near-match, combined with a string near-match at the same time, I’ll just handwave away.)

diw • September 20, 2011 4:17 AM

Here’s how the auDA deal with these issues (administering the .au namespace) …

General policy:

The com.au 2LD is for commercial purposes.

  1. To be eligible for a domain name in the com.au 2LD, registrants must be:

-eight criteria snipped-

  1. Domain names in the com.au 2LD must be:
    a) an exact match, abbreviation or acronym of the registrant’s name or trademark; or
    b) otherwise closely and substantially connected to the registrant.

The other 2LDs have similar restraints.

http://www.auda.org.au/policies/auda-2008-05/

In case that’s not enough there’s a specific separate policy on typosquatting (misspellings).
Here’s a section with some of the usual suspects listed:

4.2 For the purposes of the prohibition, a domain name will be regarded as a misspelling if it falls into one of the following categories:

a) the singular version of a plural name, or the plural version of a singular name (eg. woolworth.com.au, safeways.com.au);

b) a name with missing letters (eg. yhoo.com.au);

c) a name with additional letters (eg. quantas.com.au);

d) a name with transposed letters (eg. goolge.com.au, wetspac.com.au);

e) a name with letters replaced by numbers, or numbers replaced by letters (eg. 9msn.com.au);

f) a hyphenated version of a name (eg. e-bay.com.au, micro-soft.com.au);

g) a name prefixed by “www” (eg. wwwseek.com.au); or

h) any other name that auDA determines is a deliberate misspelling, having regard to the surrounding circumstances.

http://www.auda.org.au/policies/auda-2008-09/

I really like the auDA for this and a few other things.

http://www.auda.org.au/policy/current-policies/

Best wishes.

SilverbackNet • September 21, 2011 9:18 PM

@Petréa Mitchell

In nearly every email client, if you highlight the incorrect suggested name in the dropdown and press delete it removes it from the autocomplete list permanently. One of the exceptionally useful little tips that are never part of any formal training or tutorials of office suites.

rivergarden • October 15, 2011 3:01 PM

This is not down to UI or user training issues. It is purely an isue of accidental data loss – and your DLP system should block and alert you about the mail so you can verify the recipients.

The DLP solution we have can be configured to detect e-mails with candidate addresses to doppleganger domains. This will pick up most avenues of this attack. The vendor released this feature within 1 week of the paper being released. Nice…!

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.