DNS and attacks

It is the application layer, with a lot of interest by attackers because its a service designed without security measures in mind

DNS Domain Hierarchy

The name space is organized in a hierachical tree-like structure where each node is called a domain or subdomain

The root of the domain is call ROOT denoted as '.'

DNS Zone

In DNS, a zone refers to a contiguous portion of the domain tree that is managed by a particular organization or entity. A zone typically includes a domain and its subdomains. For example, if an organization owns the domain example.com and also has subdomains such as blog.example.com and support.example.com, then all these domains and subdomains together form a zone.

Each zone in DNS is assigned management authority to an entity responsible for managing and maintaining the records within that zone. This entity could be an individual or an organization with administrative control over the domain and its subdomains. The management authority has the ability to add, modify, or delete records within their assigned zone.

The hierarchical nature of DNS allows for efficient management of domains and subdomains by delegating authority at different levels. For example, the top-level domain (TLD) authorities are responsible for managing TLDs like .com or .org. Below them, there can be second-level domain authorities responsible for managing specific domains such as example.com.

By organizing DNS according to zones, it becomes easier to manage and control different parts of the overall domain tree. It also allows for delegation of management responsibilities to different entities based on their specific needs and requirements. This helps in distributing the workload and ensuring efficient administration of DNS resources.

Zone vs Domains

Zone is a organizational concept

Authoritative Name Server

It provides the original and definitive answers to DNS queries (publish information about the zone)
Each DNS zone should have at least one authoritative name server
A master server stores the master copies of all zone records whereas a slave server uses an automatic updating mechanism to maintain an identical copy of the master records.

DNS ROOT Servers

The root zone is called ROOT, there are 13 authoritative name server for the root zone

DNS Query Process

Iterative query process

DNS Response

There are 4 types of sections in a DNS response :

• Question section : Describes a question to a nameserver
• Answer section : Records that answer the question
• Authority section : Records that point toward authoritative nameservers
• Additional section : Records that are related to the query.

DNS Cache

We should not query the DNS server many times because it will overload them, we can cache the domain name and IP mapping locally so that if we want to access the domain that we have visited before, we can access directly using the local cache

Problem

As with every caching method, there is a stillness issue, in which if the ip address of the destination change due to DHCP, we will not be able to access that particular domain until the ttl for the domain expires

DNS Attacks

• Denial-of-Service Attacks(DoS): When the local DNS servers and the authoritative nameservers do not respond to the DNS queries, the machines cannot retrieve IP address which essentially cuts down the communication
• DNS Spoofing Attacks
  • primary goal: provide a fraudulent IP address to victims, tricking them to communicate with a machine that is different from their intention

Overview of the Attack Surfaces

1. Local Cache
2. poison the query between the local machine and the local DNS Server
3. poison the Local DNS Server
4. A server in the DNS hierachy

DNS Attacks on compromised machines

• If the attackers have gained the root privileges on the machine
  • modify the /etc/resolve.conf: use malicious DNS server as the machine's local DNS server and can control the entire DNS process
  • Modify /etc/hosts: add new records to the file, providing the IP addresses for some selected domains

Spoofing DNS Replies (from LAN)

Remote DNS Cache Poisoning Attack

1. Targeting the Resolver: Every time a user requests a domain (like "example.com"), their device checks with a DNS resolver to get the corresponding IP address. If the resolver doesn't have this information in its cache, it queries the authoritative name servers for that domain. Once it receives the answer, it caches (stores) this information for a set period, so future queries for the same domain can be answered more quickly.
2. Poisoning the Cache: In a cache poisoning attack, the attacker tricks the resolver into storing incorrect IP information for a domain. This can be accomplished in various ways, one common method being to send fake responses to the resolver, pretending to be from the authoritative name server. If the malicious response reaches the resolver before the legitimate one, the resolver might cache the incorrect information.
3. Redirecting Users: Once the cache is poisoned, any user querying that resolver for the affected domain will receive the false IP address. This can lead them to malicious websites that mimic legitimate ones, potentially stealing user data, distributing malware, or causing other harm.
4. Duration of the Attack: The malicious DNS entry remains in the cache until its Time to Live (TTL) expires or until the cache is manually cleared. This means users could be directed to the malicious site for hours, days, or even longer.

Difficulties

For remote attackers who are not on the same network as the local DNS server, spoofing replies is much more difficult, because they need to guess two random numbers used by the query packet

• Source port number (16 bit random number)
• Transaction ID (16 bit random number)

Cache effect: If one attempt fails, the actual reply will be cached by local DNS server; attacker need to wait for the cache to timeout for the next attempt

Kaminsky Attack

How can we keep forging replies without worrying about the cache effect?

1. Flooding the Resolver: While the resolver waits for a response from the authoritative server, the attacker floods it with fake responses for the non-existent subdomain query, each trying a different transaction ID. Alongside the fake address for "fake.example.com", these responses also provide malicious data for the parent domain "example.com".
2. Leveraging the Shortcomings: Once one of these fake responses is accepted (because the attacker guessed the correct transaction ID), the malicious data for "example.com" is also cached. This means users could then be redirected to a malicious version of "example.com", even though the original query was for a non-existent subdomain.
   

Attacks from Malicious DNS Server

When a user visits a website, such as attacker32.com, a DNS query will eventually come to the authoritative nameserver of the attacker32.com domain. In addition to providing an IP address in the answer section of the response, DNS server can also provide information in the authority and additional sections. Attackers can use these sections to provide fraudulent information.

Those records that are out of zone will be discarded

When a user visits a website, such as attacker32.com, a DNS query will eventually come to the authoritative nameserver of the attacker32.com domain. In addition to providing an IP address in the answer section of the response, DNS server can also provide information in the authority and additional sections. Attackers can use these sections to provide fraudulent information.

Reply forgery in reverse DNS Lookup

• In the reverse lookup, a DNS query tries to find out the hostname for a given IP address.
• Question: Can we use the hostname obtained from reverse DNS lookup as the basis for access control?
  • Example: Packets from syr.edu are allowed to access certain services.

Reverse DNS Look up

1. Ask a root server, we get the nameservers for the in-addr.arpa.zone
2. Ask a nameserver of the in-addr.arpa zone we get nameservers for the 128.in-addr.arpa zone
3. Ask a naeserver of the 128.in-arpa zone. We get the nameservers for the 203.128 in-addr.arpa zone
4. Ask a nameserver of the 230.128.in0appr.arpa zone. we get the final result

Protection against DNS Attacks

Using chain of trust

Protection agains DNS Cache Poisoning Attacks

DNSSEC

• DNSSEC is a set of extension to DNS, aiming to provide authentication and integrity checking on DNS data.
• DNS cache poisoning will be defeated by this mechanism as any fake data will be detected because they will fail the signature checking.

1. Digital Signatures: At the heart of DNSSEC are cryptographic digital signatures created using public-key cryptography. These signatures cover DNS records, ensuring their integrity.
2. Zone Signing Key (ZSK) & Key Signing Key (KSK):
   • Each DNS zone has two key pairs: a ZSK and a KSK.
   • The ZSK is used to sign DNS records in a zone.
   • The KSK is used to sign the ZSK, effectively acting as a safeguard for the signing key.
3. RRSIG Records: When a zone is signed with DNSSEC, for each DNS record, a new record called an RRSIG (Resource Record Signature) is created. This RRSIG is a cryptographic signature of the original record. When a DNS resolver receives a DNS response, it also receives the RRSIG for validation purposes.
4. DS Records: When a child zone is signed, a DS (Delegation Signer) record, which is a hash of the child zone's KSK, is placed in the parent zone. This creates a chain of trust. For example, the DS record for "example.com" is in the ".com" TLD zone.
5. Validation: When a DNS resolver receives a query response, it:
   • Uses the public ZSK to verify the RRSIG of the DNS record.
   • Uses the public KSK to verify the RRSIG of the ZSK.
   • Checks the DS record in the parent zone (and its RRSIG), following the chain of trust up to the root.
6. Chain of Trust: For DNSSEC to work, there needs to be a continuous chain of trust from the root zone down to the queried DNS record. The root zone's public keys are typically pre-configured in DNS resolvers, ensuring that the resolver can trust them. From there, the resolver can validate the DS record at each level of the DNS hierarchy until it reaches the final DNS record being queried.
   

Protection using TLS/SSL

Transport Layer Security (TLS/SSL) protocol provides a solution against the cache poisoning attacks

• After getting the IP address for a domain name using DNS protocol, a computer will ask the owner (server) of the IP address to proof that it is indeed the owner
• The server has to present a public-key certificate signed by a trusted entity and demonstrates that it knows the corresponding private key associated with domain
• HTTPS is built on top of of TLS/SSL. It defeats DNS cache poisoning attacks

See More -> 6. Public Key Infrastructure

Comparison

DNS Rebinding Attack

base on the fact that they are smart IOT devices at home
goal: interact with the target server from outside

prevent using same origin policy

the attacker can lie that all the packets come the attacker's machine is the in the same origin when doing the same origin policy check

1. Victim Visits Malicious Website: The victim unknowingly visits a malicious website controlled by the attacker. This website serves a malicious script to the victim's browser.

2. Initial DNS Resolution: The victim's browser resolves the domain of the malicious website. The DNS response contains an IP address that points to the attacker's server, and the browser fetches the malicious script from there.

3. Execution of Malicious Script: The malicious script runs on the victim's browser and begins making periodic requests to the same domain. However, the script is designed to run for a long time, longer than the DNS record's Time-To-Live (TTL).

4. DNS Rebinding: After the DNS record's TTL expires, the next time the malicious script makes a request to the domain, the browser will re-resolve the domain. This time, the attacker's DNS server returns a different IP address in its response, typically an internal IP address pointing to a private network resource, like a home router's web interface or a local server. This new IP address "rebinds" the domain to the local target.

5. Bypassing Same-Origin Policy: Web browsers use the same-origin policy to isolate websites from each other. This policy ensures that scripts from one site cannot access data from another site. However, in a DNS rebinding attack, since both the attacker's server and the victim's local resource share the same domain (from the browser's perspective), the malicious script can bypass this policy.

6. Unauthorized Access: Now, with the domain rebinding to a local IP, the malicious script can communicate with and potentially exploit vulnerabilities in the local target. For instance, if the target is a home router with a known vulnerability or default login credentials, the script might reconfigure it, establish a persistent backdoor, or conduct other malicious activities.

To protect against DNS rebinding attacks, several countermeasures can be applied:

• Browser-level Protections: Some modern browsers have implemented defenses against rapid DNS rebinding attacks.
• Network-level Protections: DNS resolvers can be configured to block DNS responses that contain RFC1918 (private IP) addresses.
• Application-level Protections: Services and applications can be configured to validate Host headers or utilize authentication methods that can't be easily bypassed by external attackers.

Denial of services attacks on DNS

DoS attacks on Root Servers

Root nameservers: If the attackers can bring down the servers of the root zone, they can bring down the entire Internet. However, attack root servers is difficult:

• The root nameservers are highly distributed. There are 13 (A,B....M) root nameservers (server farm) consisting of a large number of redundant computers to provide reliable services.
• As the nameservers for the TLDs are usually cached in the local DNS servers, the root servers need not be queried till the cache expires (48 hrs). Attacks on the root servers must last long to see a significant effect.

DoS on TLD Servers

Nameservers for the TLDs are easier to attack. TLDs such as gov, com, net etc have quite resilient infrastructure against DOS attacks. But certain obscure TLDs like country-code TLDs do not have sufficient infrastructure. Due to this, the attackers can bring down the Internet of a targeted country.

Attacks on Nameservers of a Particular Domain

UltraDNS: DNS provider for many major e-commerce companies such as Amazon, Walmart, Expedia.
These big companies want to focus on their services and hence outsource the DNS protection to third party
In 2004, DOS against this provider was launched which suffered an outage for an hour.