DNSJava DNSSEC Bypass
Date: 2024-07
Affected: maven/dnsjava:dnsjava
Attack vector: info-disclosure
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2024-25638
CWE: CWE-345
CWE-349
CVSS: 8.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L)

### Summary Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. ### Details DNS Messages are not authenticated. They do not guarantee that - received RRs are authentic - not received RRs do not exist - all or any received records in a response relate to the request Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) 1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases 2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) 3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. 4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. dnsjava does not implement a comparable algorithm, and the provided APIs instead return eit


Mitigations:

Architectural layers (MAESTRO):