DNS

6 Ways to avoid a Punycode attack

Photo by Arsyad Basyarudin on Unsplash

Research shows a new phishing site is created every 20 seconds and they are usually only live for four hours before hackers take them down and move on to create another deceiving domain. A clever way to cover their tracks and evade detection.

  1. Be cautious if the site presses you to do something quickly. This is a classic strategy by hackers to rush their potential victims so that they are less likely to notice anything suspicious. Often they will offer a “limited time only” deal, and make it difficult to exit the page with ‘are you sure you want to exit’ pop-ups: these are all tactics to make you stay on their site longer and give them your details.
  2. If you are being offered a deal, go to the original company site and check if it’s available there as well, if not it’s most likely a scam doing its best to mimic the established brand and trick visitors into handing over their details.
  3. If some of the letters in the address bar look weird, or the website design looks different, rewrite it or visit the original company URL in a new tab to compare. The letters in the address bar looking strange is a key indicator that punycode is being used to trick you into thinking you are visiting a well-established brand site when in fact you are being taken to a malicious site.
  4. Use a password manager; this reduces the risk of pasting passwords into dodgy sites.
  5. Force your browser to display Punycode names, this option is available in Firefox.
  6. Click on the padlock to view and inspect the HTTPS certificate.

What is Punycode?

Photo by Mika Baumeister on Unsplash

Punycode
noun
Unicode that converts words that cannot be written in ASCII, like the Greek word for thank you ‘ευχαριστώ’ into an ASCII encoding, like ‘xn--mxahn5algcq2e’ for use as domain names.
What does this actually mean?!

Writing with numbers

As with all things computers, it all boils down to numbers. Every letter, character, or emoji we type has a unique binary number associated with it so that our computers can process them. ASCII, a character encoding standard, uses 7 bits to code up to 127 characters, enough to code the Alphabet in upper and lower case, numbers 0-9 and some additional special characters. Where ASCII falls down is that it does not support languages such as Greek, Hebrew, and Arabic for example, this is where Unicode comes in; it uses 32 bits to code up to 2,147,483,647 characters! Unicode gives us enough options to support any language and even our ever-growing collection of emojis.

So where does Punycode come in?

Punycode is a way of converting words that cannot be written in ASCII, into a Unicode ASCII encoding. Why would you want to do this? The global Domain Name System (DNS), the naming system for any resource connected to the internet, is limited to ASCII characters. With punycode, you can include non-ASCII characters within a domain name by creating “bootstring” encoding of Unicode as part of a complicated encoding process.

What is DNS Spoofing?

Photo by Lars Kienle on Unsplash

DNS spoofing, or DNS cache poisoning, is a phishing and cyber attack where false Domain Name System (DNS) information is introduced into a DNS resolver’s cache. This causes DNS queries to return an incorrect response, which commonly redirects users from a legitimate website to a malicious website designed to steal sensitive information or install malware.

There are several reasons why DNS spoofing is possible, but the principal problem is DNS was built in the 1980s when the Internet was much smaller, and security was not a primary concern. There is no in-built way for DNS resolvers to verify the validity of the data they store, and incorrect DNS information can remain until the time to live (TTL) expires or is manually updated.

How Do Attackers Poison DNS Caches?

DNS poisoning or DNS spoofing attacks work by impersonating DNS nameservers, making a request to a DNS resolver, and then forging the reply when the DNS resolver queries a nameserver. This is possible because DNS uses UDP, an unencrypted protocol, which makes it easy to intercept traffic with spoofing. DNS servers do not validate the IP addresses they are directing traffic to.

There are two common methods for poisoning DNS caches:

Man in the middle attack: The interception of communication between users and a DNS server to route users to a different or malicious IP address. In this situation, the attacker sits between the computer’s stub resolver and the recursive resolver, sending back a fake DNS result.

DNS server compromise: This type of attack occurs when an attacker gains direct access to the DNS server of a domain, generally through spear phishing or whaling, and updates the DNS entries to point to a malicious website. This type of attack is also known as DNS hijacking.

This works because, unlike TCP, which relies on both communicating parties performing a ‘handshake’ to initiate communication and verify the identity of devices, DNS requests and responses rely on UDP or User Datagram Protocol. With UDP, there is no guarantee that a connection is open, that the recipient is ready to receive, or that the sender is who they say they are. This leaves UDP communications vulnerable to MITM attacks; an attacker can send a message via UDP, pretending that it is a legitimate nameserver by forging header data. If the receiving DNS resolver accepts the fake response and caches, which can happen as there is no way to verify if the information is accurate and comes from a legitimate source. With that said, DNS spoofing attacks are not easy to pull off as the DNS resolver queries the authoritative nameserver giving attackers only a few milliseconds to fake the response before the real response arrives.

When are DNS Spoofing Attacks Successful?

For a DNS spoofing attack to be successful, attackers either need to know or guess:

Which DNS queries are not cached by the targeted DNS resolver so that the resolver will query the authoritative name server what port the DNS resolver uses, which was easy in the past but has since become much more difficult as DNS resolvers rotate their open ports to mitigate DNS spoofing The request ID number which authoritative nameserver the DNS resolver will query.

Furthermore, these malicious websites are often used to install computer worms, ransomware, and spyware on the user’s computer, giving the perpetrator long-term access.

How to Mitigate DNS Spoofing

The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications designed to secure certain kinds of information the DNS provides. DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence, and data integrity but not availability or confidentiality.

Like TLS/SSL, DNSSEC uses public-key cryptography to verify and authenticate DNS data.

When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record and the requested record type. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.

The delegation signer (DS) is used to authenticate DNSKEYs by using a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.

The chain of trust starts with a set of verified public keys for the DNS root zone, the trusted third party. Domain owners generate their own public key/private key pair and upload them using their domain-name registrar’s DNS control panel, which pushes the keys via secDNS to the zone operator (for example, Verisign for the com zone), who signs and publishes them in the DNS.

This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.

In short, DNSSEC provides two security features to DNS:

Data origin authentication: This allows a resolver to cryptographically verify data from the zone requested.Data integrity protection: This allows a resolver to know that the data hasn’t been modified in transit and was originally signed by the zone owner’s private key.

These two security features all any recursive resolver to look up data in the zone and retrieve the zone’s public key, which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end-user. If the signature is not valid, the resolver assumes a cyber attack, discards the data, and returns an error.

While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS, such as Certificate records, SSH fingerprints, IPSec public keys, and TLS Trust Anchors.

That said, DNSSEC, unlike SSL certificates, does not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).

DNSSEC also has several potential downsides, including:

Lack of data confidentiality: While DNSSEC authenticates, it does. not encode DNS responses. This means that perpetrators can still listen in on traffic and use this data for more sophisticated attacks; this is why SSL certificates are such an important part of Internet security. Deployment complexity: DNSSEC is easily misconfigured, which can cause servers to lose their security benefits or even deny access to the website altogether. No widespread adoption: While DNSSEC was published in 2005, it has not yet become mainstream, leaving any DNS records vulnerable to attacks.

Beyond DNSSEC, there are other ways you can prevent DNS spoofing:

Active monitoring: DNS data should be continuously monitored for changes, such as the appearance of a new external host, that could indicate compromise.

Patching: Like anything, DNS servers and software can be vulnerable to exploits and zero-day vulnerabilities. Ensure whoever is hosting your DNS records is meticulous about vulnerability management and attack surface management.

DNS updates Newer versions of DNS use port randomization and cryptographically secure transaction IDs to prevent DNS attackers and ensure your servers are up-to-date.

Password policies: Ensure you use strong passwords and, ideally, two-factor authentication for the account that manages your DNS records. And don’t forget about changing default passwords on network equipment, such as routers, which can put every device and user in danger if compromised. Read our guides on password security and network security for more information.

Invest in cybersecurity awareness training: Remember that many DNS spoofing attacks are either the result of or aim to initiate some phishing attack. Educate your staff about what to look for in phishing campaigns.

What Is a Man-in-the-Middle Attack

Photo by Stephen Phillips – Hostreviews.co.uk on Unsplash

A man-in-the-middle attack, often abbreviated as an MITM attack, is a type of cyber assault in which an unauthorized individual interposes themselves in the communication flow between two parties who assume they are engaging in direct communication. In this scenario, the attacker gains the ability to intercept, eavesdrop on, and potentially manipulate the content of the communication taking place. Man-in-the-middle attacks pose a significant threat as they allow for clandestine surveillance and potential tampering with communications across various contexts, such as interactions between individuals, clients, and servers, and even secure connections like HTTPS and other SSL/TLS protocols, as well as Wi-Fi network connections, among others.

Here is how a Man-in-the-middle attack works.

Picture a scenario where you and a colleague are engaged in a conversation through a secure messaging platform. In this situation, an adversary with malicious intent aims to intercept your exchange, clandestinely monitor it, and insert fabricated messages into the conversation, making it appear that these false messages are coming from you to your colleague. This form of cyber attack illustrates the peril of a man-in-the-middle assault, where the attacker attempts to undermine the integrity and confidentiality of your communication.

Initially, you request your colleague’s public key to establish secure communication. If your colleague sends her public key, but an attacker manages to intercept it, a man-in-the-middle attack becomes possible. The attacker sends you a fabricated message skillfully designed to mimic your colleague’s communication. However, this message contains the attacker’s public key instead of your colleague’s legitimate one. Thinking you are using your colleague’s public key, you encrypt your message and unknowingly employ the attacker’s key to secure it. Subsequently, you send this encrypted message back to what you believe is your “colleague.”The attacker, once again, intercepts the message, decrypts it using their private key, manipulates the content, and then re-encrypts it using the public key they initially intercepted from your colleague, who had intended to send it to you. As your colleague receives and examines the encrypted message, she is under the impression that it originated from you, unaware of the attacker’s meddling.

What is Cache Poisoning?

Photo by DeepMind on Unsplash

What is a Cache?

A cache is a temporary storage location that allows faster retrieval of frequently used data and files. Several types of caches are found across several devices and applications, such as laptops, desktops, smartphones, tablets, web applications, and web browsers. The purpose is to make everything run faster and more efficiently. 

When a user opens an app or visits a website for the first time, pertinent data and files are stored in the web cache. When the user revisits the website or app, the associated data and files can be accessed locally from the cache, allowing the site or app to load more quickly. This is why after users initially input their credentials into a website or app, such as Amazon or Gmail, they typically do not have to do so again with each subsequent visit.

Benefits of Caches

The most recognized benefit of caches by users and IT professionals is that they allow apps and websites to run much faster, improving the system’s performance. The DNS (Domain Name Server) resolver can respond to queries without communicating with multiple servers. There are also additional benefits to caches, including:

  • Offline access: As mentioned above, caches save data. In some situations, this allows apps to work without an internet connection. The reason some apps can do so is that the cached data can be used to enable the app to function correctly.

  • Optimize resources: Since caches only need to download files once, the app or website doesn’t have to waste battery power and time downloading data on each subsequent visit. Caches significantly increase efficiency.
It is pertinent to note two things. First, the data from a site or an
app will be redownloaded if changes have been made to the data or files. Second, the DNS information is stored in the designated cache for a specific time frame known as TTL (Time-to-Live). This is why users must re-login into applications such as their email every so often (e.g., 30 days).

How Cache Poisoning Works

In DNS poisoning, the perpetrator enters fake information into the DNS cache. The purpose is to redirect users from the intended server to a different server. The new destination is dangerous and has malicious intentions. There are three different forms of attack:

  1. Once the user is on the malicious website, some program, such as a hijacking program, spyware, malware, a worm, a trojan, etc., is downloaded onto the user’s device without their knowledge.
  2. Sensitive information such as login credentials or bank information may be stolen because the user believes they are on a legitimate website or app, so they willingly input their information. Instead, they are on a phishing website. A common tactic to use is the man-in-the-middle attack approach. A man-in-the-middle attack may occur where the perpetrator alters the communication between two parties. For example, users may think they are talking with a bank representative about their accounts. When the truth is that the attacker has intercepted and hijacked the conversation so that the user is now actually talking with a cyber attacker. The users believing they are communicating with a trustworthy party, may give out sensitive information.
  3. The attacker compromises security updates on the device, which leaves the device vulnerable to hacking.

It is essential to understand that the attacker disguises the dangerous destination, so the user has no idea they’ve been a victim of a cyber attack and were diverted to a different server other than the intended one. One way attackers accomplish DNS spoofing attacks is to enter a website address into the DNS that has been altered. The destination is a fake website disguised as a real one. Cache poisoning can occur on Apple (Mac), Android, and Microsoft operating systems.

Preventing Cache Poisoning

Effectively preventing cache poisoning is the combined responsibility of website owners, DNS service providers, and users. Here are the best ways to protect your business from DNS poisoning.

Utilize DNS Security Extensions

DNS Security Extensions (Domain Name System Security Extensions) or DNSSEC is a protocol in which authentication is required at every communication step between servers. It creates a digital hierarchy designed to prevent cache poisoning. While this is better than nothing, DNS Security Extensions still have vulnerabilities because IP addresses and URLs can still be falsified. Name servers cannot tell the difference during translation.

Utilize End-to-End Encryption 

End-to-End Encryption (E2EE) sends encrypted DNS requests that only the intended server can decrypt. This is a useful method because cyber attackers should be unable to decrypt and exploit the request. However, as with all things internet-based, some attackers can decrypt or foil these encrypted requests. 

Educate users

Educate end-users on how to safely use apps and websites and implement internet protocols that significantly reduce their chances of introducing an attack into the system. Here’s what users should do whenever possible:

  • Never click on unknown URLs
  • Never disable firewalls
  • Routinely scan devices for suspicious activity
  • Routinely clear the cache (if a cache has been poisoned unknowingly, this will help get rid of it faster than waiting for the TTL to expire)
  • Use a VPN (a virtual private network) when possible.