|
Many in the network security field may be familiar with the phrase: “It’s always DNS.” This is a popular meme within the industry, often making reference to the internal domain name system (DNS), the dynamic host configuration protocol (DHCP) part of a company’s online network, that whenever there is a network issue, it’s always an issue with DNS.
However, in the new norm, there is something much larger and more critical than the internal aspects of the DNS that we should all pay attention to. Concentrating on internal networks reflects the predominant focus in cybersecurity of securing networks within firewalls. Under the new norm, such an approach may prove insufficient, as most cyber threats originate outside of the controllable network.
During the pandemic, several governments released different COVID tracking apps. There are those which are praised as secured by design, such as Exposure Notifications by Google® and Apple®, and those that spark various degrees of privacy concerns. In Hong Kong, the local community has called for opening the source code for independent inspection, which the government has claimed would cause security issues with the app. This reply sparked a discussion between two security principles: security by design and security by obscurity.
Security by design is a well-accepted cybersecurity best practice, while its counterpart concept, security by obscurity, has been rejected as far back as 1851. Despite the denunciation of this concept, we all know that obscurity is a very common practice. In the real world, secrecy is preferred because there is hardly any system worthy to be called secured by design.
To illustrate this, blockchain is often mistakenly touted to be secured by design. Blockchain may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance1.
What happened in practice, though? In 2017, someone at Ethereum Classic noticed that almost everyone stopped trading on their platform. The core system itself didn’t seem to be compromised. However, for a period of time on June 30, 2017, everyone who visited the site and logged into their account had exposed their wallet’s private keys. Less than a year later, the team at BlackWallet, a cryptocurrency application for XLM currency, had to publicly announce a warning to everyone via social media to temporarily stop using their service. Hackers had taken over BlackWallet’s DNS and were redirecting funds away from users to the hacker’s account.
A brief look into the history of cryptocurrency hacks reveals more cases where there was NO compromise to the network design, but yet, hackers got in. One may ask how a secured system can be hacked without compromising the system itself. The answer lies in the fact that systems are never independent. While the network itself may have the utmost security, once the network connects to the internet to interact externally—from network to inter-network—even the most secured system will become insecure. This is because the inter-network is insecure by design.
Inter-network communication relies on a few key cornerstones that we call digital assets—assets that define who a company is on the internet and are used in almost all external communication.
One such digital asset is the DNS. When someone is able to take control of a company’s DNS, they can compromise anything that connects to it. Domain names and DNS, as assets, define who a brand is and where people find it online. Once a brand’s site is hijacked, users don’t know they’re connecting to a server controlled by the hackers.
In the internet age, security by design doesn’t always work because the internet is INSECURE by design, and this problem might be intensified in the new norm post-COVID-19. Under a traditional network security practice, security is achieved by preventing and detecting intrusion of the network that is secured by millions of dollars worth of security investment. In the new norm, all employee devices have become the end-point assets connecting to the network, and they now reside outside the network. The problem of network security doesn’t exist within your network anymore, it has increasingly become an inter-network security issue.
A 2018 article in the Harvard Business Review, How to Reframe Your Cybersecurity Strategy, mentions this brutal truth: “It doesn’t matter how much your organization spends on the latest cybersecurity hardware, software, training, and staff ... If your mission-critical systems are digital and connected in some form or fashion to the internet, they can never be made fully safe. Period.”
Some have tried to counter this new trend by moving systems to the cloud and focusing on end-point security. It’s believed that the big boys of cloud infrastructure should have sufficient knowledge and investment to counter the increasing security issues of the internet age. Unfortunately, this may not be the right approach. The purpose of cloud migration is to move your on-premise network to a bigger network operated by someone else. It replaces and improves network security, but it is not designed to tackle the inter-network security issue.
To answer that, we first need to look at how inter-network works. The internet is built to transfer data to the right person. So, to protect the data, companies must:
Under the transmission control protocol/internet protocol (TCP/IP) model, the ultimate definition of whether companies are transferring the data to and from the right place is to obtain the right IP address. An IP address defines a company’s identity online, and if the process goes wrong, everything goes wrong. The modern internet has become so complex that multiple servers, and thus multiple IP addresses, are required to run a successful online service. Therefore, in practice, DNS is the phone book of IP addresses, and has become one of the most critical internet infrastructures.
In 2020, Liquid.com was hacked due to simple domain hijacking. The CEO of Liquid.com admitted that the domain hijack caused a compromise of the infrastructure, leaked private information, and also caused Liquid.com to lose control over their internal email. In research on the perl.com domain hijacking, Bleeping Computer found that the domain was actually pointed to a malicious IP address that was known to be associated with malware, and worse still, the IP address may even be tied to a command and control server. These two examples highlight the critical nature of domain name and DNS and how secured systems can be made insecure through digital assets.
It’s not DNS
There’s no way it’s DNS
It was DNS
Source: Reddit
Even if a domain name is secured and cannot be hijacked, fraudsters can still trick company customers and business partners into transferring critical information by pretending to be the brand. This is one of the most intriguing aspects of inter-network security—that inter-network security compromises are most often a result of social engineering and require no compromise to a network at all.
The world of cybersecurity has come to know this issue as phishing attacks. In one piece of research, it’s shown that phishing or spear phishing is behind 91% of cyber attacks. However, most of the time, phishing is being looked at from a network security perspective and the focus is on how to prevent phishing emails from intruding into the internal network. Such paradigm missed the fact that phishing is essentially an abuse of the organization identity, and of the DNS infrastructure. In 2020, Cisco WebexTM was attacked via phishing, and thousands of Webex credentials were leaked. The attack was done through an email designed to closely resemble the automated secure sockets layer (SSL) certificate error alerts that the company sends out to its customers2. The attack clearly targeted Cisco® to steal its customers’ credentials. There was clearly reputation loss, as news reports called it an issue with Cisco. However, there was absolutely no attack on Cisco’s infrastructure, and the attack did not reach any of Cisco’s firewalls.
A new paradigm is needed to look at phishing attacks, one that looks at it from an inter-network security perspective. From this angle, phishing is also known as a DNS abuse. DNS abuse is defined by the Internet Corporation for Assigned Names and Numbers (ICANN) as “intentionally deceptive, conniving, or unsolicited activities that actively make use of the DNS or the procedures used to register domain names3. This includes issues such as spam, phishing, malware, botnets, and pharming (such as DNS hijacking), and has become one of ICANN’s highest priorities in 2021.
Finally, to adequately address inter-network security, we need to secure the data itself and ensure it’s transmitted without alteration and cannot be read by unintended parties. For the most part, this is achieved by adding encryption or digital certificates to internet communication. However, this is often easier said than done, because SSL management is typically managed on an operations level, and not recognized for its critical role. Almost every year, there’s news that a major corporation had a network outage simply because they forgot to renew an SSL. If major corporations with an abundance of resources are unable to manage SSLs, imagine how many other companies experience the same issue.
To build a mature inter-network security standard, here are four recommended controls.
Implement registry lock and perform third-party risk assessments. Most organizations just leave it up to an entry-level IT administrator to manage the registry with the cheapest provider. While it’s not necessary for a CIO to manage the DNS, if something can bring down your entire infrastructure, the CIO should make it a rule to give it due importance and put in the right controls.
DNS is so critical that many authorities have issued warnings, including:
The Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Homeland Security (DHS), The United Kingdom’s National Cyber Security Centre (NCSC), Japan Registry Services (JPRS), Hong Kong Internet Registration Corporation (HKIRC), ICANN, FireEye, Cisco Talos, CrowdStrike, KrebsOnSecurity, and us at CSC issued a RARE Emergency Directive in Jan 2019 about DNS infrastructure tampering by the Sea Turtle hacking group.
Many organizations spend millions to protect their applications, migrate to the cloud, and implement two-factor authentication—yet only spend a few dollars on domains and DNS—the very assets that these applications run on.
When using an enterprise-level DNS, ensure it is supported by DNSSEC, and implement it. Furthermore, in a mature enterprise DNS setup, I recommend not mixing cloud with the DNS. I often see organizations try to mesh everything into a single provider.
DNS works across virtually everything you do on the internet. Sometimes, companies may only want to connect their content delivery network (CDN) to a few particular services because of cost, and also because other connections are not suitable for CDN. In the past few years, there’s also an increasing trend to adopt a multi-cloud strategy. Most architecture is more complex, and it might be better if the DNS is not bound to a single provider.
Whichever the configuration, avoid free services and only use enterprise-grade ones.
Digital certificate lifespans are getting shorter, and the industry is anticipating them to be reduced further to 90 days maximum. The only way system administrators will be able to manage renewals is to automate.
Mitigate the risks of customers being deceived by redirected traffic or fraud by implementing DNSSEC and anti-phishing technology. To date, much of the internet security innovations we’ve seen revolve around verifying and securing the identities of people and organizations online, wrote Vint Cerf, dubbed the father of the internet. He further added that the web needed spoof-proofing.
DNS is not sexy. There are movies about hacking, corporate espionage, distributing malware to infiltrate a nuclear facility, but never a movie about DNS. Most probably consider the administration of DNS a very low-level task. However, when DNS goes wrong, hackers can direct employees to a malware site, steal critical trade information, and gain access to company servers. When any of these happens, the CEO is going to ask the CIO, and the CIO is going to ask IT colleagues—WHY? The vast majority of DNS and domain issues are not zero-day attacks; no one can say they don’t know about DNS attacks, and there are absolutely no excuses for an incident.
Under the new norm, cybersecurity needs to cover both network and inter-network security. And when it comes to inter-network security, it is always DNS.
Watch the full presentation at the Information Security Summit →
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Not all phishing attacks involve a maliciously registered domain. Most of them, actually, use an existing compromised website. Newly registered domains are marked as suspicious by a number of security systems while compromising old ones require someone to actively flag it as compromised.
DNSSEC, TLSA and DKIM/DMARC can all help with attempts by attackers to hijack or phish your domain. Unfortunately the most common attack seems to be one based on some other domain that looks similar but isn’t yours. I don’t know that there’s any way to deal with that one, because it can be set up so DNSSEC, TLSA and DKIM/DMARC are all valid for it, other than to monitor newly-registered domains for ones that are confusingly similar to yours in some way. There’s already tools to do just that, it’s a matter of convincing the domain owner it’s worth it to take action when the attack isn’t directly affecting them.
NB: the current certificate authority structure makes it difficult to implement TLSA since there’s no issuing certificate unique to your domain or hosts and it’s almost impossible to get the major CAs to give you one. That leaves adding one TLSA record per host. I’d much rather browsers implement TLSA checking fully, so if a TLSA record is present certificate validation is based on the public key listed in the TLSA record and ignores the root CA list.