Did you know your DNS security could accidentally leak your entire subdomain structure? Enter DNSSEC with NSEC/NSEC3 records, which is great for ensuring integrity and authentication but can also be a sneaky way for attackers to ‘zone walk’ and enumerate your domains...

Darrell Hall breaks it down in our latest blog post: https://www.pentestpartners.com/security-blog/dnssec-nsec-the-accidental-treasure-map-to-your-subdomains/

What's covered:
• How NSEC/NSEC3 can inadvertently expose DNS data
• The difference between zone transfers and zone walking
• How to crack NSEC3 records (and why you should care)
• Real-world examples and mitigation strategies

#DNSSEC #CyberSecurity #Infosec #DNS #NSEC #NSEC3 #ZoneWalking #ThreatIntel

Great coverage by Jan Doskočil of NSEC3 hash enumeration, and cracking with hashcat. Also good info about the limits of making that harder (some resolvers cap the work factor they will resolve!)

https://infosec.exchange/@jpmens@mastodon.social/114019491327504188

Via @jpmens

#DNS #NSEC3 #hashcat

Looks like @sans_isc picked up on an exploit for KeyTrap - I haven't tested it yet, and it is explicitly documented as being defanged, but looks legit on the surface:

https://github.com/knqyf263/CVE-2023-50387

Added to my roll-up post.

#keytrap #nsec3 #CVE202350387 #CVE_2023_50387
#dns #dnssec

I have two posts about the new multi-implementation DNSSEC validation DoS vulnerabilities CVE-2023-50387 ("KeyTrap") and CVE-2023-50868 (the NSEC3 vuln):

• The big summary post (more editing - your client may notify you about each edit, which may be a feature):

https://infosec.exchange/@tychotithonus/111924626712765292

• The post you're reading (low editing, minimal noise, but you might want to check the big post occasionally for updates).

#keytrap #nsec3 #CVE202350387 #CVE202350868 #CVE_2023_50387 #CVE_2023_50868
#dns #dnssec

#dnspython 2.5 released

Among the changes, still no options to generate #NSEC3 signatures when using the zone signing function, but it seems it's coming : "[t]he NSEC3 class now has a next_name() method for retrieving the next name as a dns.name.Name"

#DNS #Python #DNSSEC

https://dnspython.readthedocs.io/en/stable/whatsnew.html#id1

Your random #DNS and #DNSSEC facts of the day.

As of today (2023-09-24):
- 1465 TLDs in the root zone
- 1354 are signed. That's 92.4% of all TLDs
- 1311 are using NSEC3. That's 89.5% of all TLDs and 96.8% of all signed TLDs
- 644 are following RFC 9276's recommended #NSEC3 parameters. That's 43.9% of all TLDs, 47.5% of all signed TLDs and 49.1% of all signed TLDs using NSEC3

I’ve received on my postmaster@ address a message from some security researchers warning me of the “insecure” #DNSSEC configuration of my domain, so for the record:

My domain (incenp.org) is configured to use #NSEC, and not #NSEC3, on purpose. This is not a misconfiguration. I weighed the pros and cons of NSEC3, and decided it was just not worth it.

Yes, people could use NSEC records to enumerate all the DNS records of my zone. So what?

Usually I am not a fan (and that’s an euphemism) of the “if you have nothing to hide, you have nothing to fear” argument, but in this case, there is really nothing to hide in my DNS zone. I would happily give a list of all the records (or even the original master zone file) to anyone who asks for it.

Actually last time I checked, one of the slave DNS servers I use was even configured to allow #AXFR requests from anywhere, and I never bothered to contact the admin of that server to ask him to do anything about it. So if you want the entirety of my zone’s records, don’t waste your time mounting a NSEC enumeration attack, just ask the right server.

His plan was perfect... And then he realized he forgot about #NSEC3 🤦‍♂️

Ok, NSEC3 hash is predictable.

How about, taking a signed zone file, changing one NSEC3 record and recreate the corresponding RRSIG? 😏