Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

DNS: Worst-case scenario
SECURITY SHELF

DNS: Worst-case scenario 

Small business owners are particularly vulnerable. They often consider domain registration and maintenance a technical task for delegation to a junior employee, web developer, or other IT contractor. As a result, domains are often registered with the lowest cost registrar. It is unfortunately also common for small business owners to discover that their domains are actually registered to a third party.

Leveraging outside expertise remains a good strategy for many businesses, but domain names are a valuable asset and must be appropriately protected. Similarly, a poor choice of DNS providers can create a very real risk.

For those unfamiliar with domain registrations and DNS, anyone with access to the domain registration account can usually request a DNS server change. The request is generally forwarded automatically to the appropriate Top Level Domain (TLD) registrar and actioned. Used maliciously, this functionality can be used to redirect email, web, and other network traffic intended for the domain.

A similar scenario exists with respect to DNS services. Once access to the DNS service (or server) is obtained, an attacker can redirect traffic. Many domain registrars also provide free or low cost DNS services to their clients, in which case an attacker who gains access to the registration account can directly change DNS records.

Attacks of this nature can result in denial of service, embarrassing redirection of web traffic to inappropriate or spoofed web sites, theft of credentials by redirecting legitimate users to fake web sites designed to collect usernames and passwords, and surreptitious email interception. It can lead to a devastating business compromises.

To better understand the risk involved, consider a fictional example: Start-up Hacked Inc. registers a few domain names with a discount registrar and uses the registrar’s free DNS services. The company, like many other start-ups, chooses best-of-breed services including Google for Work and Amazon Web Services (AWS) for development, test, and production environments.

The attacker begins by conducting recognizance, including identify the company’s employees, email addresses, and gathering other public information. The next step is domain control.

At 3 a.m. Sunday, an attacker logs in to the domain registrar. This could be facilitated by password guessing, password re-use, phishing, social engineering, or password theft using malware. Few registrars offer two-factor authentication, and some have poor account security practices, making this a viable targeted attack.

After gaining access to the account, the attacker “updates” the contact email address and telephone number to one they control and changes the password. In most cases, these “updates” will be accepted as routine and only trigger notifications in the case of more security-conscious registrars. The attacker now effectively controls the domains. Regaining control will require time-consuming manual processes.

Next, the attacker proceeds to the Google admin console and follows the procedure for an administrator account lockout. This process will allow administrator-level credentials to be reset by proving control of domain records. The attacker adds the requested CNAME record, proving control to Google, and obtains admin-level access to the Google for Work account. The attacker then changes all passwords, effectively locking all employees (including others who might have administrator access) out of their email accounts.

By 3:30 a.m., the attacker has unfettered access to all Hacked Inc. email accounts and searches for information on other cloud accounts. The attacker quickly identifies accounts with email from AWS. Proceeding to the AWS console, the attacker uses the password reset feature to gain access to the Hacked Inc.’s AWS account. The first three AWS accounts compromised do not have admin-level privileges, but the fourth does. The attacker then creates a new account in IAM with full privileges, changes the password on the root AWS account, and deletes all other users.

By 4 a.m., the attacker has full control of Hacked Inc.’s domains, email, and AWS account. The attacker spends the next hour searching email accounts to identify other services such as project management, collaboration, source code repositories, and social media accounts. They then proceed to reset passwords, gain access, and take control of the accounts.

By 5 a.m., having achieved control of most company assets, the attacker could cause significant damage by deleting data or holding it for ransom. The attack was facilitated by access to a domain registration account, but the same results could be achieved by compromising a DNS service or company-operated DNS servers.

In addition to recognizing the asset value and sensitivity of domain registrations and DNS services, there are several things businesses should do to protect against a worst-case scenario:

  • Choose a reputable domain registrar, preferably one that provides two-factor authentication.
  • Ensure that only trusted individuals have access to the domain registration account and use unique, complex passphrases.
  • Use a whois service to verify that domains are properly registered to the company and contacts are up-to-date.
  • Use the domain lock (registrar lock) feature to make unauthorized domain transfers more difficult.
  • Carefully consider the security of DNS service providers.
  • Use two-factor authentication for all cloud services and social media accounts wherever possible.
  • If backups are held at a cloud provider, use a separate account linked to a different credit card and email address. Ensure that the email account credentials can not be reset from the company domain.
  • Ask providers to require multiple authentications to reset administrator credentials, rather than a single factor such as proof of domain control.

Have a security question you’d like answered in a future column? Email eric.jacksch@iticonline.ca

Related posts