home.social

#nsec3 — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #nsec3, aggregated by home.social.

  1. Marcin Cieślak @[email protected] ·

    @rmbolger @bortzmeyer maybe, but setting things up is horribly complicated. It takes way too many steps to set up a decent domain name zone. (Only email is worse and that includes DNS tricks, too). Today as I bought a fresh name, I was scratching my head about adding DS record in an over complicated web interface only to figure out I should stop using salting, reduce the number of hashing rounds and while am I here replace the algorithm. #nsec3 #dnssec

    #nsec3 #dnssec
  2. Pen Test Partners @[email protected] ·

    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: pentestpartners.com/security-b

    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

    #dnssec #cybersecurity #infosec #dns #nsec #nsec3
  3. Pen Test Partners @[email protected] ·

    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: pentestpartners.com/security-b

    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

    #dnssec #cybersecurity #infosec #dns #nsec #nsec3
  4. Pen Test Partners @[email protected] ·

    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: pentestpartners.com/security-b

    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

    #threatintel #zonewalking #nsec3 #nsec #dns #infosec
  5. Royce Williams @[email protected] ·

    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!)

    infosec.exchange/@jpmens@masto

    Via @jpmens

    #DNS #NSEC3 #hashcat

    #dns #nsec3 #hashcat
  6. Royce Williams @[email protected] ·

    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:

    github.com/knqyf263/CVE-2023-5

    Added to my roll-up post.

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

    #keytrap #nsec3 #cve202350387 #cve_2023_50387 #dns #dnssec
  7. Royce Williams @[email protected] ·

    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:

    github.com/knqyf263/CVE-2023-5

    Added to my roll-up post.

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

    #nsec3 #cve202350387 #cve_2023_50387 #dns #dnssec #keytrap
  8. Royce Williams @[email protected] ·

    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:

    github.com/knqyf263/CVE-2023-5

    Added to my roll-up post.

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

    #nsec3 #cve202350387 #cve_2023_50387 #dns #dnssec #keytrap
  9. Royce Williams @[email protected] ·

    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:

    github.com/knqyf263/CVE-2023-5

    Added to my roll-up post.

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

    #dnssec #dns #cve_2023_50387 #cve202350387 #nsec3 #keytrap
  10. Royce Williams @[email protected] ·

    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:

    github.com/knqyf263/CVE-2023-5

    Added to my roll-up post.

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

    #keytrap #nsec3 #cve202350387 #cve_2023_50387 #dns #dnssec
  11. Royce Williams @[email protected] ·

    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):

    infosec.exchange/@tychotithonu

    • 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

    #keytrap #nsec3 #cve202350387 #cve202350868 #cve_2023_50387 #cve_2023_50868
  12. Royce Williams @[email protected] ·
    CW: New multi-implementation DNSSEC validation DoS vulnerabilities - CVE-2023-50387 ("KeyTrap"), CVE-2023-50868 (NSEC3 vuln)

    (living doc, updated regularly - if you prefer a low-edit post to boost, use infosec.exchange/@tychotithonu)

    Looks like DNS-OARC coordinated fixes in advance, but no centralized analysis at first other than the announcement from the team who discovered KeyTrap:

    Details may be still partially embargoed until patching ramps up.

    Analysis:

    DoS of all major DNSSEC-validating DNS resolvers (servers, but also maybe local resolvers like systemd's?) at the implementation level. Exploitation described as 'trivial'. Both are CVSS 7.5. DNS is a rich ransom target - but some resolver setups don't even validate DNSSEC.

    "In 2012 the vulnerability made its way into the implementation requirements for DNSSEC validation, standards RFC 6781 and RFC 6840" (per ATHENE)

    Per the Unbound writeup, both vulns require query to a malicious zone (which is probably not hard to trigger, for any DNSSEC-enabled client or server).

    Resolution: patch (recommended); disable DNSSEC validation (discouraged, but can buy you time / mitigate active DoS)

    Fixes mitigate the exhaustion by putting caps on validation activities. These caps appear to have been missing from most implementations.

    Details:

    Two DNSSEC DoS CVEs:

    CVE-2023-50387 ("KeyTrap"): "DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers" (CVSS 7.5)
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
    seclists.org/oss-sec/2024/q1/1

    (KeyTrap was discovered by ATHENE - their press release here has very important detail:
    athene-center.de/en/news/press)

    CVE-2023-50868: "NSEC3 closest encloser proof can exhaust CPU" (CVSS 7.5)
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

    MITRE links (now populated):
    cve.mitre.org/cgi-bin/cvename.
    cve.mitre.org/cgi-bin/cvename.

    Vulmon queries:
    vulmon.com/searchpage?q=CVE-20
    vulmon.com/searchpage?q=CVE-20

    VulDB:
    vuldb.com/?id.253829

    Resolver status:

    BIND (patched - vuln since 2000?):
    fosstodon.org/@iscdotorg/11192
    kb.isc.org/docs/cve-2023-50387
    kb.isc.org/docs/cve-2023-50868
    seclists.org/oss-sec/2024/q1/1
    isc.org/blogs/2024-bind-securi
    (note: posts say "Versions prior to 9.11.37 were not assessed." but also have a range of affected versions starting at 9.0.0 - typo?)

    BIND tools:
    dig: no validation
    kdig: no validation
    delv: affected, patched

    dnsmasq (patched - 2.90 has fix):
    thekelleys.org.uk/dnsmasq/CHAN
    lists.thekelleys.org.uk/piperm

    Knot (patched in 5.7.1):
    knot-resolver.cz/2024-02-13-kn
    (kzonecheck also affected, patched?)

    ldns-verify-zone:
    affected per ATHENE paper

    OPNsense (patched):
    forum.opnsense.org/index.php?t

    pfSense:
    (Bundled Unbound: plan appears to be to make a separate package available for manual update?; BIND: optional package)
    forum.netgate.com/topic/186145
    redmine.pfsense.org/issues/152

    Pi-Hole (uses dnsmasq - patch available)
    patreon.com/posts/dnssec-fix-9
    pi-hole.net/blog/2024/02/13/fi

    PowerDNS (patched - all versions affected):
    blog.powerdns.com/2024/02/13/p
    github.com/PowerDNS/pdns/pull/
    github.com/PowerDNS/pdns/pull/
    seclists.org/oss-sec/2024/q1/1

    Stubby:
    [?]
    github.com/getdnsapi/stubby

    systemd.resolved:
    [?]

    Ubiquiti
    [?]

    Unbound (patched - vuln since Aug 2007):
    nlnetlabs.nl/news/2024/Feb/13/
    nlnetlabs.nl/downloads/unbound
    seclists.org/oss-sec/2024/q1/1

    Library status:*
    dnspython (GitHub patched):
    affected per ATHENE paper
    github.com/rthalley/dnspython/

    getdns (used by stubby - no patched release?):
    affected per ATHENE paper
    getdnsapi.net/releases/

    ldns (not yet patched?):
    affected per ATHENE paper
    github.com/NLnetLabs/ldns

    libunbound (used by Unbound):
    affected per ATHENE paper
    no recent patches?
    github.com/NLnetLabs/unbound/t

    Cloud status:

    Akamai:
    akamai.com/blog/security/dns-e

    Cloudflare:
    blog.cloudflare.com/remediatin

    Google DNS:
    (stated as patched in Register and SecurityWeek articles)
    [?]

    NextDNS (patched per forum reply):
    help.nextdns.io/t/h7yxwc5/does

    OS status:

    Debian:
    BIND:
    lists.debian.org/debian-securi
    pdns-recursor:
    lists.debian.org/debian-securi
    Unbound:
    lists.debian.org/debian-securi

    Fedora:
    bodhi.fedoraproject.org/update

    FreeBSD:
    cgit.freebsd.org/ports/commit/

    Gentoo:
    bugs.gentoo.org/show_bug.cgi?i

    Mageia:
    bugs.mageia.org/show_bug.cgi?i

    OpenBSD (unwind):

    Red Hat:
    bugzilla.redhat.com/show_bug.c
    access.redhat.com/security/cve
    access.redhat.com/security/cve

    SUSE:
    suse.com/security/cve/CVE-2023
    bugzilla.suse.com/show_bug.cgi

    Ubuntu:
    ubuntu.com/security/CVE-2023-5
    ubuntu.com/security/CVE-2023-5
    ubuntu.com/security/notices/US

    Windows (Server, DNS Role):
    msrc.microsoft.com/update-guid

    Package status:

    BIND:
    repology.org/project/bind/vers

    dnsmasq:
    repology.org/project/dnsmasq/v

    Unbound:
    repology.org/project/unbound/v

    GitHub:
    github.com/advisories/GHSA-845

    Go (Knot module?)
    github.com/golang/vulndb/issue

    Non-coverage: (no mentions known yet)

    AWS :
    [?]

    Azure (Microsoft Server DNS?):
    [?]

    Cisco Umbrella:
    umbrella.cisco.com/blog [?]

    CoreDNS:
    coredns.io/blog/ [?]

    Infoblox:
    blogs.infoblox.com/ [?]

    Quad9 DNS:
    quad9.net/news/blog/ [?]

    News/Press/Forums

    pducklin.com/2024/02/18/the-sc

    theregister.com/2024/02/13/dns

    securityweek.com/keytrap-dns-a

    bleepingcomputer.com/news/secu

    news.ycombinator.com/item?id=3

    darkreading.com/cloud-security

    Detection/Validation:

    Check to see if a server is doing DNSSEC validation (if not an open recursive resolver, you may need to query a zone the server is authoritative for):

    # zone signed, server DNSSEC-enabled:
    $ delv example.net @8.8.8.8
    ; fully validated
    example.net.            4437    IN      A       93.184.216.34
    example.net.            4437    IN      RRSIG   A 13 2 86400 20240225232039 20240204162038 18113 example.net. 94G2PRXins1G9ntfklvCq2mvcgqjB0z9FqQXp77lD/wXR4J3D67ceih1 yNgsYYqlIAOoWKXUekux6Zq9aIwszQ==

    # zone unsigned, server DNSSEC-enabled:
    $ delv google.com @8.8.8.8
    ; unsigned answer
    google.com.             100     IN      A       142.250.69.206

    Tenable:
    tenable.com/plugins/pipeline/i

    Snyk:
    security.snyk.io/vuln/SNYK-UNM

    Exploits:

    (multiple sources describe as "trivial")

    github.com/knqyf263/CVE-2023-5 (not tested)

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

    #keytrap #nsec3 #cve202350387 #cve202350868 #cve_2023_50387 #cve_2023_50868
  13. John Shaft @[email protected] ·

    #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

    dnspython.readthedocs.io/en/st

    #dnspython #nsec3 #dns #python #dnssec
  14. John Shaft @[email protected] ·

    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

    #dns #dnssec #nsec3
  15. Damien Goutte-Gattat @[email protected] ·

    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.

    #dnssec #nsec #nsec3 #axfr
  16. Damien Goutte-Gattat @[email protected] ·

    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.

    #dnssec #nsec #nsec3 #axfr
  17. Damien Goutte-Gattat @[email protected] ·

    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.

    #dnssec #nsec #nsec3 #axfr
  18. John Shaft @[email protected] ·

    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? 😏

    #nsec3