Member preview

Prevent Domain Takeovers — Audit `Email Alias` policy today!

“Several mailboxes on a post surrounded by trees in Muriwai” by Mathyas Kurmann on Unsplash

If you are an IT administrator of a major organization — academic or industrial, chances are you have come across enforcing an email policy at some point in your career at your organization.

For most organizations, on the technical side, typically for new hires, students, and staff members, the system auto-generates the new username, email addresses and alias(es). The process is something like:

Generate a unique Active Directory username (also serving as the primary email address) using a combination of initials and numbers.

As an example, for an incoming freshman John Smith, this would likely be js555@example.edu or jsmith555@example.edu along with john.smith@example.edu being assigned as their alias.

This is a commonly observed pattern at most educational institutions.

The IT administrators may, at their sole discretion:

  • allow the user to create an alias which better represents their real name, or
  • generate an alias for them resembling their real name, e.g. john.smith@company.com with the user having some discretion to request another alias through manual intervention with the admins.

While user discretion & agency are much valued tenets of Human-Computer Interaction (HCI) and an essential skill for building free-flowing UIs, they should in no means stand in the way of common-sense security!

It has been observed on multiple occasions that many organizations and universities do let their users choose an e-mail alias, as long as it’s available, in addition to their auto-generated primary email address. But, they do not, however, scan the alias for any ‘objectionable’ terms — and I don’t mean only offensive terms.

While a vast majority of users would pick something sensible, accurately representing their real or nickname, a malicious internal actor may pick phrases like:

help@yourorg.com ; it-support@… ; service@ ; info, postmaster, hostmaster, etc.

You get the idea.

If the system does enable such a discretionary choice, since no one has had yet claimed it, we have landed ourselves on a security blunder!

An obvious inference would be that the user, in such a scenario, would be able to carry out casual phishing attacks, pretending to be an authorized personnel, e.g. IT-HelpDesk within the organization. What’s worse is: the legitimate MX records / IP addresses associated with the e-mail address— since the email address actually belongs to the organization and isn’t spoofed = the spam filters likely not detecting outbound emails sent from this address. And that, would likely lead to sophisticated phishing attacks at best, or harmless pranks at the very least.

The problem seems to be prevalent in a lot of organizations but more so in universities which do not restrict certain phrases in an email alias. Just google “{Your Company/University Name} Email Alias” to see if you are able to set your alias to anything, following the outlined steps. Although, if you do find an overly lenient alias policy, report it to the IT/Security department(s) ASAP and never misuse the system! After all, either way you are not anonymous.

Domain Takeovers

Now, let’s think of this from a Domain Registrar perspective.

How likely is it that a domain registrar believes that an account called “help@university.edu” is an authoritative contact of the university? Very — especially with some social engineering.

Most reputable registrars restrict things like SSL Certificate Domain Validation and Domain Transfers to authorized WHOIS Administrative/Technical Contact email addresses only. There remains a chance that, at a smaller registrar, the support personnel when emailed, will believe an explanation like:

“We understand support@university.edu is our Registrar Contact but we have recently migrated to help@university.edu.”

and essentially override their own security policies. And that can cause all sorts of headaches — domain takeovers, rogue validations for SSL certificates, etc.

Deterrent

Of course, because the functionality to pick aliases is limited to internal actors only and there is a good faith trust being put into the organizational members, accountability and a lack of anonymity are the biggest deterrents in the game.

Prevention

  • Audit Policy: User Discretion should not undermine security. Audit all email aliases and policies from time to time. If enabling your users to pick their aliases, be prepared to have a blacklist of restricted terms such as “support”, “help”, “official”, “it-desk”, etc. to prevent imposter attacks.
  • Separate ‘mail’ Subdomain: It might be better to separate out the user email addresses from those of the authorized personnel altogether. For example, “webmaster@university.edu” for the admin vs. “john.smith@mail.university.edu” for a student. As an example, Harvard University already uses a separate …@g.harvard.edu subdomain for student accounts of certain colleges. A measure like this may also prevent a takeover attack for the entire domain.

Note: A lot of this may sound like speculation but the behavior has actually been observed at multiple organizations which are not named for security reasons.

© 2018. Akshay Sharma. All Rights Reserved.