blacklanternsecurity / bbot

A recursive internet scanner for hackers. 🧡
https://www.blacklanternsecurity.com/bbot/
GNU General Public License v3.0
7.09k stars 537 forks source link

Baddns false positives for unresolved DNS names #1551

Closed TheTechromancer closed 1 month ago

TheTechromancer commented 4 months ago

It seems like baddns is raising a Dangling NS Records (NS records without SOA) for certain unresolved dns names:

[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "cm.p.mdg41hoses.com"}    baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "ooops-80.mdg41hoses.com"}        baddns  (baddns-ns, in-scope)                                                                                              [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "arezzo.mdg41hoses.com"}  baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "experience.mdg41hoses.com"}      baddns  (baddns-ns, in-scope)                                                                                              [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "dmp.mdg41hoses.com"}     baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "i2-prod.mdg41hoses.com"} baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "skc.mdg41hoses.com"}     baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "regione.mdg41hoses.com"} baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "s54.mdg41hoses.com"}     baddns  (baddns-ns, in-scope)                                                                                                      [FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "dacia.mdg41hoses.com"}   baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "derecho.mdg41hoses.com"} baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "aplikasi.mdg41hoses.com"}        baddns  (baddns-ns, in-scope)                                                                                              
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "vanzari.mdg41hoses.com"} baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "app.pharma.mdg41hoses.com"}      baddns  (baddns-ns, in-scope)                                                                                              
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "consiglio.regione.mdg41hoses.com"}       baddns  (baddns-ns, in-scope)                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "epicsports.mdg41hoses.com"}      baddns  (baddns-ns, in-scope)                                                                                              
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "pharma.mdg41hoses.com"}  baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "tms.dmp.mdg41hoses.com"} baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "ilp.mdg41hoses.com"}     baddns  (baddns-ns, in-scope)                                                                                                      
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "feeder.mdg41hoses.com"}  baddns  (baddns-ns, in-scope)
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "indiana.mdg41hoses.com"} baddns  (baddns-ns, in-scope)
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "www.consiglio.regione.mdg41hoses.com"}   baddns  (baddns-ns, in-scope)
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au,
 ns2.nameserver.net.au] baddns Module: [NS]", "host": "ada.mdg41hoses.com"}     baddns  (baddns-ns, in-scope)
[FINDING]               {"description": "Dangling NS Records (NS records without SOA) Confidence: [POSSIBLE] Signature: [N/A] Indicator: [DNSWalk Analysis] Trigger: [ns1.nameserver.net.au, ns3.nameserver.net.au, ns2.nameserver.net.au] baddns Module: [NS]", "host": "nike.mdg41hoses.com"}    baddns  (baddns-ns, in-scope)

All of these dns names return SERVFAIL when queried with dig:

$ dig -t ns aplikasi.mdg41hoses.com

; <<>> DiG 9.18.27 <<>> -t ns aplikasi.mdg41hoses.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28983
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation mdg41hoses.com.)
; EDE: 23 (Network Error): (103.252.154.10:53 rcode=REFUSED for aplikasi.mdg41hoses.com NS)
;; QUESTION SECTION:
;aplikasi.mdg41hoses.com.   IN  NS

;; Query time: 2029 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Jul 09 13:14:47 EDT 2024
;; MSG SIZE  rcvd: 155
liquidsec commented 4 months ago

As we discussed, I believe these are true positives which illustrate baddns ability to find dangling records that normal dns resolution fails to find.

If there is any discussion, it might be around whether the only_high_confidence option default should change, either in the module or in some particular presets.

TheTechromancer commented 4 months ago

How is the NS record dangling, though? When I do a DNS lookup on any of these domains, there isn't any authority listed. Even the root domain itself results in a SERVFAIL:

$ dig -t ns mdg41hoses.com

; <<>> DiG 9.18.27 <<>> -t ns mdg41hoses.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7688
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation mdg41hoses.com.)
; EDE: 23 (Network Error): ([2600:3c01::f03c:93ff:fed1:8135]:53 rcode=REFUSED for mdg41hoses.com NS)
;; QUESTION SECTION:
;mdg41hoses.com.            IN  NS

;; Query time: 2376 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Jul 09 21:37:20 EDT 2024
;; MSG SIZE  rcvd: 155

I think I'm just not seeing where the vulnerability is, or how it's specific to the individual subdomain.

liquidsec commented 4 months ago

A lot of services need you to point NS records to them to work properly. Once you set it up, their servers will then (and only then) respond with an SOA for the domain. That’s why when you see NS records without an SOA, it can be a sign a record was left in place after a service was deactivated. Sometimes theres nothing that can be done with, which is why it’s a finding, not a full-blown vulnerability, and why its given a confidence of "POSSIBLE".

The goal is to discover things that could potentially be exploited even without a signature. This way, you might be the first to spot a new service that can be abused.

There are lots of situations where the main domain is what is vulnerable, not the subdomain, like the main domain being unregistered or expired. Why is the specific subdomain relevant? Well, it showed up during the scan for a reason. Discovery of the relevance would require some investigation to figure out why it’s there and what the impact might be.

Bottom line is, it's an anomaly that could be anywhere from worthless (most likely) to full blown base-domain takeover.

liquidsec commented 4 months ago

As for the specifics on this domain, here is the debug output from baddns (i had chatgpt make it more concise):

Starting NS module with target aaaaaplikasi.mdg41hoses.com Attempting to resolve aaaaaplikasi.mdg41hoses.com Dispatching DNS with nameserver 10.1.1.1 All nameservers failed: SERVFAIL for IN NS Retrying resolve for aaaaaplikasi.mdg41hoses.com Dispatching DNS with nameserver 10.1.1.1 All nameservers failed: SERVFAIL for IN NS Attempting to find NS records for aaaaaplikasi.mdg41hoses.com Recursive instance: querying nameserver 199.7.83.42 Querying nameserver 199.7.83.42 for NS records Received authority section with TLD NS records Received NS record for a.gtld-servers.net, resolved to 192.5.6.30 Received NS record for b.gtld-servers.net, resolved to 192.33.14.30 Received NS record for c.gtld-servers.net, resolved to 192.26.92.30 Received NS record for d.gtld-servers.net, resolved to 192.31.80.30 Received NS record for e.gtld-servers.net, resolved to 192.12.94.30 Received NS record for f.gtld-servers.net, resolved to 192.35.51.30 Received NS record for g.gtld-servers.net, resolved to 192.42.93.30 Received NS record for h.gtld-servers.net, resolved to 192.54.112.30 Received NS record for i.gtld-servers.net, resolved to 192.43.172.30 Received NS record for j.gtld-servers.net, resolved to 192.48.79.30 Received NS record for k.gtld-servers.net, resolved to 192.52.178.30 Received NS record for l.gtld-servers.net, resolved to 192.41.162.30 Received NS record for m.gtld-servers.net, resolved to 192.55.83.30 Recursing deeper with nameserver 192.43.172.30 Querying nameserver 192.43.172.30 for NS records Response: NOERROR, authority section with mdg41hoses.com NS records Received NS record for ns1.nameserver.net.au, resolved to 112.140.176.177 Received NS record for ns2.nameserver.net.au, resolved to 103.252.154.10 Received NS record for ns3.nameserver.net.au, resolved to 45.79.92.84 Recursing deeper with nameserver 45.79.92.84 Querying nameserver 45.79.92.84 for NS records: REFUSED Querying nameserver 112.140.176.177 for NS records: REFUSED Querying nameserver 103.252.154.10 for NS records: REFUSED No further results found Submitting final NS records: ns3.nameserver.net.au, ns1.nameserver.net.au, ns2.nameserver.net.au No SOA record found with nameservers present Reported generic dangling NS record issue

TheTechromancer commented 4 months ago

Where did 199.7.83.42 come from?

liquidsec commented 4 months ago

hardcoded root server

TheTechromancer commented 4 months ago

Ohhhhh okay. That makes sense. But the vulnerability is on the domain, not the subdomain, right? I'm just thinking how we can avoid having hundreds of these findings.

liquidsec commented 4 months ago

The fact that this specific one is happening on the base domain, and that for some reason we emitted a ton of subdomains and none resolved is relatively unusual. There are things we could do, but i feel like this is probably a weird edge case.

It may not be exploitable in any way but something super weird happened here.

Sh4d0wHunt3rX commented 4 months ago

Maybe this is relevant. In this scan, I have 1305 hostnames and 1214 reporting of Dangling NS Records

https://drive.proton.me/urls/F0SXJ3ZQ0W#FsznOUtqOa0M

Out of these, 12 have been labeled as Vulnerability, however, when I check them, they don't have any NS. I still don't know how to exploit these 😔Doesn't "Dangling NS Records" mean these hostnames have NS, but their NS lead to nowhere because of expiration?

vulnerable.json

liquidsec commented 4 months ago

The ns1 signature didnt originate with me. If I get a chance I will do some digging and see if there is still an exploitation path.

The one thing I am confident in, is that these really are dangling NS records. That's why I said if anything, the discussion might be collapsing multiple alerts from the same base domain. Don't believe your other tools, this is actually some of the sauce of baddns - i discovered that without an SOA, your downstream dns servers (95 percent of them) just lie and say nothing is there.

I talk about this in the baddns blog post.

As far as what to do with them, well theoretically if there is a signature, there is a path somewhere. The one that used to be the most reliable was aws route53. But there is a lot of debate as to whether that is still exploitable, my own testing was inconclusive. The point is, it would be different for every service. Some of those signatures may need to be removed.

If you have zero interest in dangling NS with no explicit chance of exploiting, the module allows for turning off low confidence findings.

liquidsec commented 4 months ago

@TheTechromancer

Do you think we need to change the default setting? It's hard for me to be objective on that question since i spent 3 months steeped in this stuff. But if the average BBOT user is just going to be confused by those, maybe it's not worth it.

TheTechromancer commented 4 months ago

I think it's fine as is (assuming it's a legitimate vulnerability), except we should be raising the finding only for the domain that has the ns record, instead of the individual subdomain.

liquidsec commented 4 months ago

But then there's a loss of data. It's only relevant because of the subdomain - the subdomain is what links the event to our scan. It had to have been found somewhere - maybe it was excavated, came from an API, etc.

liquidsec commented 1 month ago

I am going to close this as an issue since it morphed into more of a (good) discussion, but there doesn't seem to be any actual issue other than potentially some baddns signatures need to be updated.