Open TheTechromancer opened 2 weeks ago
liquidsec
commented
2 weeks 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
2 weeks 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: 155I think I'm just not seeing where the vulnerability is, or how it's specific to the individual subdomain.
liquidsec
commented
2 weeks 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
2 weeks 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
2 weeks ago Where did 199.7.83.42 come from?
liquidsec
commented
2 weeks ago hardcoded root server
TheTechromancer
commented
2 weeks 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
2 weeks 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.
amiremami
commented
2 weeks 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?
liquidsec
commented
2 weeks 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
2 weeks 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
2 weeks 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
2 weeks 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.
It seems like baddns is raising a
Dangling NS Records (NS records without SOA)for certain unresolved dns names:All of these dns names return
SERVFAILwhen queried withdig: