May 1, 2017
Preventing DNS Hijacking through Multifactor Authentication
In late October 2016 a Brazilian bank began to see anomalies across their 36 internet web properties. Fewer customers than anticipated were accessing their online banking and help center, and strangely enough, inbound email reduced to a crawl. What initially began as an unexpectedly slow day was actually the beginnings of the type of cyberattack that wakes up security professionals in a deep sweat in the middle of the night: A circumvention of every network and web-based defense money can buy.
Over the next five hours bank-owned web domains, corresponding email and FTP services, and even ATM and point-of-sale networks were reportedly replaced by a sophisticated hacker and redirected to completely different, yet indistinguishable hosted infrastructure. To complete the ruse, the fake websites even had valid TLS/SSL certificates circumventing the certificate authority chain of trust. For five hours, customers had no discernible way of knowing they had been redirected to malicious websites, potentially providing sensitive information to the hackers that could be used for financial gain or worse.
The Threat
The type of attack endured by the Brazilian bank and its customers is known as DNS hijacking (or DNS redirection) and is the act of changing domain name registration information without the permission of the registrant and then redirecting the domain to unassociated infrastructure.
In this case, the DNS hijack was perpetrated through an ICANN accredited registrar, a third-party vendor of the bank, and appears to have been a compromise of the bank’s username and password to their registrar account. Internet registries such as fTLD Registry Services, the registry operating .BANK and .INSURANCE, are not permitted to sell domains directly to end-users; registrars must provide this service. Registrars possess the authority for modifying or deleting information about domain names in the registry database and the power to redirect domains to different authoritative DNS servers.
Financial services veterans know that regulators have long emphasized the importance of evaluating the potential risks of third-party vendors. In recent years, vendor relationships with cyber components have come under increased scrutiny with the FFIEC, including the OCC and CFPB, as well as state authorities such as NYDFS all issuing relevant guidance.
Registrars are vital to the internet ecosystem, which means they must be judiciously evaluated for the services they provide. However, the account compromise example facing this Brazilian bank raises the question—how can registrar relationships be better managed to reduce cybersecurity risk?
Fortunately, there are solutions to help mitigate the risk of domain hijacking.
Mitigating the Risk
Using static credentials, even those designed to resist dictionary and brute-force attacks, is the traditional method to prevent cyber intrusion; however, for the Brazilian bank this lone control was somehow overcome.
More recently, multifactor authentication (MFA) has gained traction as a method to reduce the risk of account takeover. MFA works by combining static credentials (something you know) with a dynamic credential (something you have) such as a hard or soft token. The theory is that even if the static credential is captured by a nefarious party, they would not easily possess the dynamic credential and would not be able to gain unauthorized access to the system.
To mitigate the risk of account takeovers, fTLD requires its registrars to provide secure multifactor authentication solutions to .BANK and .INSURANCE registrants when accessing their registration systems. This requirement is detailed in fTLD’s Security Requirement #22.
A second and compatible methodology that prevents unauthorized changes to domain name registration data, is to use a “registry lock” solution at the registry and/or registrar levels. If registry lock is employed, changes to the registry database must be approved by an “out-of-band” step, such a phone call, to protect against automation errors or system compromise. While offering increased protection, this method slows the speed in which domain registration changes can be made.
Approved .BANK and .INSURANCE registrars are permitted to offer Registry Lock services. fTLD anticipates offering a Registry Lock service at the registry level in the coming months.
If you are a .BANK or .INSURANCE registrant, the good news is you can rest easy knowing you are protected from a domain hijack attack based on the Security Requirements. However, for those with web properties hosted by other Top-Level Domain extensions, you may not be so lucky. If you are looking for a good night’s rest knowing your web domain is more secure, contact an fTLD registrar[1] and register a .BANK or .INSURANCE domain name.
By the way, the Brazilian bank was able to reclaim its domains, but is still working to resolve the issues related to the hijacking including the long-term impact to its customers.
By Andrew Kennedy, Financial Services Roundtable/BITS Cybersecurity Advisor to fTLD