Category: DNS / Network Security

Difficulty: Medium

1. Challenge Overview

The challenge provided a DNS server at 52.59.124.14:5053. The hint stated that “latest and greatest DNS features” now allow internal networks to resolve names without VPNs or Firewalls. This was a clear pointer toward EDNS Client Subnet (ECS) or DNS over QUIC (DoQ).

2. Vulnerability Analysis

Step 1: Protocol Reconnaissance

I first checked the standard TXT record for the domain.

dig @52.59.124.14 -p 5053 TXT flag.ctf.nullcon.net

Result: ENO{Zzzzt_Zzzzt_FAKEFLAG_Zzzzt}

The server responded, but with a “troll” flag. The “Zzzzt” sound (a bug) confirmed I was hitting the right service but lacked the “internal” authorization.

Step 2: Protocol Identification (The QUIC Rabbit Hole)

The challenge title DragoNflieS (DNS over QUIC/Dragonfly) and the “latest and greatest” hint led me to test modern transports:

• DNS over TLS (DoT): Failed with Connection refused.
• DNS over HTTPS (DoH): Failed with Connection refused.
• DNS over QUIC (DoQ): Using doggo, the connection timed out (deadline exceeded), suggesting the server was either not using standard QUIC ALPNs or was strictly validating client metadata.

Step 3: Probing “Internal” logic with ECS

The hint about “internal networks” is the classic use case for EDNS Client Subnet (ECS). I attempted to spoof the client’s origin IP to bypass the “internal only” restriction.

• Attempt 1 (Localhost): +subnet=127.0.0.1 -> Result: FAKEFLAG.
• Attempt 2 (Private Range): +subnet=10.0.0.1 -> Result: FAKEFLAG.

3. Developing the Exploit

Reflecting on the previous challenge in the same CTF infrastructure, I noticed a specific “Leet” IP address (10.13.37.1) had appeared in the zone serial history. I hypothesized that the “internal network” for this CTF environment was defined by this specific 10.13.37.x subnet.

4. The Solution

I crafted a DNS query that explicitly defined the client’s subnet as the “Leet” internal IP.

dig @52.59.124.14 -p 5053 TXT flag.ctf.nullcon.net +subnet=10.13.37.1

5. The Winning Payload

The server accepted the spoofed subnet as a trusted internal requester and returned the actual flag:

;; ANSWER SECTION:
flag.ctf.nullcon.net. 300 IN TXT "ENO{Whirr_do_not_send_private_data_for_wrong_IP_Whirr}"

6. Result

• Flag: ENO{Whirr_do_not_send_private_data_for_wrong_IP_Whirr}
• Lessons Learned: 1. ECS Spoofing: DNS servers that rely on ECS for “security” or “internal views” are vulnerable to IP spoofing because the client (or a malicious resolver) can claim any origin IP. 1. Context Matters: In a CTF, hints from one challenge (like the 10.13.37.1 IP from the previous DNS task) often provide the keys to the next. 2. Whirr vs Zzzzt: The change in the “bug sound” from the fake flag (Zzzzt) to the real flag (Whirr) was a clever thematic indicator of success.