<\/p>\n\n\n\n
What are the risks and impacts of DNS KeyTrap vulnerability?<\/h2>\n\n\n\n
For an enterprise or an ISP operating a validating DNSSEC recursive resolver, the impact of the vulnerability will be catastrophic.<\/p>\n\n\n\n
Since the exploit would result in a spike and exhaustion of CPU, the recursive resolver will be non-functional, resulting in operational and business downtime.<\/p>\n\n\n\n
An attacker can craft and send a single packet(DNS query) to a DNSSEC validating recursive resolver, resulting in all systems using only that recursive resolver offline. <\/p>\n\n\n\n
The impact of the DNS KeyTrap vulnerability on the Internet<\/h2>\n\n\n\n![\"DNS](\"https:\/\/shreshtait.com\/blog\/wp-content\/uploads\/2024\/02\/Untitled-design2-683x1024.png\")
<\/figure>\n\n\n\nThe impact of DNS KeyTrap vulnerability to the Internet could have been fatal. With approximately 60% of the Internet users in India<\/a> and 30% of the Internet users in the world<\/a> relying on DNSSEC validating recursive resolvers, the magnitude of the vulnerability would have been severe were it not for coordinated efforts and responsible disclosure.<\/p>\n\n\n\nCredit to the folks at the German National Research Center for Applied Cybersecurity ATHENE<\/a> for the responsible disclosure and working with the stakeholders in the DNS ecosystem – resolver operators, resolver software vendors and others. <\/p>\n\n\n\nCVE-2023-50387<\/strong><\/h2>\n\n\n\nCertain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the \"KeyTrap\" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records. <\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
CVE-2023-50868<\/strong><\/h2>\n\n\n\nThe Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the \"NSEC3\" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Shreshta engineering team have swiftly patched all customer DNS Shield<\/a> (DNS Firewall\/Protective DNS<\/a>) cloud and on-premise instances. <\/p>\n\n\n\nSafety Recommendations<\/strong><\/h2>\n\n\n\nIf you operate a DNSSEC validating recursive resolver, please find our safety recommendations below,<\/p>\n\n\n\n
\n- The ideal option is to update the recursive resolver software<\/li>\n\n\n\n
- If that’s not an option, major recursive resolver software vendors have made a patch available<\/li>\n\n\n\n
- We strongly recommend against disabling DNSSEC to eliminate the risk of exposure to the vulnerability<\/li>\n<\/ul>\n\n\n\n
The link to the full report is available here<\/a><\/p>\n\n\n\nRecommended reading<\/strong><\/h2>\n\n\n\n
<\/figure>\n\n\n\nThe impact of DNS KeyTrap vulnerability to the Internet could have been fatal. With approximately 60% of the Internet users in India<\/a> and 30% of the Internet users in the world<\/a> relying on DNSSEC validating recursive resolvers, the magnitude of the vulnerability would have been severe were it not for coordinated efforts and responsible disclosure.<\/p>\n\n\n\n Credit to the folks at the German National Research Center for Applied Cybersecurity ATHENE<\/a> for the responsible disclosure and working with the stakeholders in the DNS ecosystem – resolver operators, resolver software vendors and others. <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Shreshta engineering team have swiftly patched all customer DNS Shield<\/a> (DNS Firewall\/Protective DNS<\/a>) cloud and on-premise instances. <\/p>\n\n\n\n If you operate a DNSSEC validating recursive resolver, please find our safety recommendations below,<\/p>\n\n\n\n The link to the full report is available here<\/a><\/p>\n\n\n\nCVE-2023-50387<\/strong><\/h2>\n\n\n\n
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the \"KeyTrap\" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records. <\/code><\/pre>\n\n\n\nCVE-2023-50868<\/strong><\/h2>\n\n\n\n
The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the \"NSEC3\" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.<\/code><\/pre>\n\n\n\nSafety Recommendations<\/strong><\/h2>\n\n\n\n
\n
Recommended reading<\/strong><\/h2>\n\n\n\n