DNS Cache Poisoning

The goals of this assignment are to:

  1. Learn about DNS cache poisoning
  2. Implement a Kaminsky-style attack against a vulnerable cache server

The Domain Name System

The Domain Name System (DNS) is a critical component of Internet infrastructure. In its most basic form, it maps hostnames to IP-layer addresses. Since hostnames are a principal in multiple security models (i.e., notion of identity), a secure and reliable DNS is fundamental to a secure Internet. Conversely, if an attacker is able to subvert the DNS, then any security framework that relies on trust in domain names can be broken (unless other security mechanisms are composed with the DNS). Breaking the DNS thus violates authenticity, and serves as a stepping stone for other serious attacks.

In 2008, Dan Kaminsky published a new attack against DNS cache servers; this became known as the Kaminsky attack. As discussed in class, this attack allows an adversary to assume control of entire sub-trees of the DNS hierarchy. In addition, it was possible for this attack to be performed by an off-path attacker.1 Mitigations were later implemented to greatly reduce the attacker’s chances for success, and DNSSEC renders this attack infeasible.

In this assignment, you will learn about cache poisoning by carrying out an off-path Kaminsky-style attack against a vulnerable cache server.

Vulnerable Service

Fig. 1: Vulnerable service and attack overview.

Fig. 1 displays an overview of the vulnerable service and intended attack. The client first contacts its caching DNS recursor to resolve the A record for the remote service (1). The recursor will initiate a recursive walk of the DNS hierarchy starting from a root server (2-4). Finally, the client will engage in the service protocol (5).

Your goal is to assume the role of the attacker by

  • Poisoning the recursor’s cache to become the authoritative name server for the service domain
  • Redirecting the service hostname to a malicious service

Canvas contains two container images named netsec_dns_hijack_client.img.xz and netsec_dns_hijack_cache.img.xz that contains the client and caching recursor, respectively. The client simply loops forever, while the recursor services any DNS requests it receives. You should first run the recursor. Then, run the client, instructing it to use your recursor for DNS resolution.

# Run the cache
docker run -it --rm --name=cache netsec_dns_hijack_cache

# Run the client
docker run -it --rm --name=client               \
    netsec_dns_hijack_client                    \
    -f ${cache_address}                             # Address of the recursor (e.g., 8.8.8.8:53)

By default, the client will attempt to contact example.com.

The cache is vulnerable to a Kaminsky-style attack because it does not deploy sufficient mitigations. Carefully analyze its traffic using tcpdump or wireshark!

Attack Container

Your attack should be implemented in a separate container that will be invoked with the following arguments.

docker run -it --rm --name=attacker             \
    --cap-add=net_raw                           \   # Add raw socket capability
    netsec_dns_hijack_attacker                  \
    ${interface}                                \   # Injection interface
    ${source_mac_address}                       \   # Source MAC address
    ${dest_mac_address}                         \   # Destination MAC address
    ${recursor_ipv4_address}                    \   # Recursor IPv4 address (e.g., 10.0.0.1:53)
    ${malicious_ipv4_address}                       # Malicious server IPv4 address

As a suggestion, you probably want to get your attack working in an on-path configuration first before attempting off-path poisoning.

Submission Instructions

Package your solution as a gzipped TAR archive. Your solution should expand to the following directory structure.

$ tree -F dns_cache_poisoning
dns_cache_poisoning
├── Dockerfile
└── src/

The source code to your solution should be contained in src/. Your Dockerfile should, when processed using docker, create a container image that runs your solution using the aforementioned command-line interface.

Submit the solution archive to Canvas.

  1. This write-up provides a long-form walkthrough of the steps of the attack.↩︎

© 2023 wkr