Re: How do subdomains get discovered by adversaries?
On Thu, 22 Dec 2022 05:19:46 +
Michael De Roover wrote:
> I have been running BIND 9 on my external and internal networks for a
> few years now -- as such I have a basic understanding of the most
> common RR types and activities such as zone transfers. However, I have
> been seeing something that's been baffling me for quite a while now.
> Somehow there are services like c99.nl [1] and Criminal IP [2], which
> can enumerate various subdomains on a given target domain. I am
> confused as to how they can enumerate this information.
In addition to techniques others have mentioned, here are some
possibilities:
- TLS certificate issuance. When a CA issues a certificate, some data
about the cert and the associated hostname(s) is posted to public
certificate transparency logs. Based on the output of the c99 site, I
have a hunch this is where it gets much of its information.
- Passive DNS logs. A variety of orgs with access to enormous amounts of
network traffic are actively sniffing port 53 DNS traffic and logging
everything they see.
- Dictionary style enumeration. Some attackers (or "researchers") will
attempt to resolve many thousands of commonly-used hostnames in your
zone, recording which ones return RRs. If you have an authoritative BIND
server configured with the rate-limit {} option, these attacks will show
up in the corresponding rate-limit logging channel.
Shaun
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How do subdomains get discovered by adversaries?
On Thu, Dec 22, 2022 at 07:16:55AM +, Michael De Roover wrote: > So PTR records don't seem to be very useful in getting this information > either. As such, I am still stranded. Unless you scan for all (IPv4) PTR records into a database ready for searches. Here's a link to a page that lists several tools for finding subdomains. At least one of them maintains a large database of domain names. But there are probably various ways. There seems to be a lot of different tools for this. You could check out each tool and see what they say they do. https://geekflare.com/find-subdomains/ > Thanks again for your attention, > Michael cheers, raf -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Providing AD flag for authoritative domains
> On 23 Dec 2022, at 01:13, Emmanuel Fusté wrote: > > Le 22/12/2022 à 14:30, Jesus Cea a écrit : >> I have a validating DNSSEC bind server. I get AD (Authenticated Data) flag >> when requesting details from a DNSSEC protected domain. Good. >> >> The point is that when the requested DNS name belongs to a domain with this >> server is authoritative and that domain is DNSSEC enabled, no AD flag is >> provided in the answer. I guess this is because bind is replying with DNSSEC >> data but it doesn't follow that DNSSEC delegation tree in order to verify >> that everything is OK and so it doesn't signal safety with the AD flag. >> >> Is there any way to configure bind to verify DNSSEC integrity and signal the >> AD flag for authoritative domains?. Views (it would lose the AA flag, then)? >> >> What would be the best practice for dnssec verification? To use a fully >> validating local resolver? Any other choice? I am currently using a local >> "bind" as a resolver and it works fine for DNSSEC verification, except for >> my authoritative domains. >> > If you trust your server for the AD bit, you could trust it for AA bit > without AD bit. > Otherwise you should go for a local validating server. It is a policy > decision. Or you should do what was originally intended to happen and have your applications validate the data using DNSSEC. Without a tamper proof channel between the validating recursive resolver and the client you should not trust AD. > Emmanuel. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: key dir massive
> On Dec 22, 2022, at 09:32, Matthijs Mekking wrote: > > > I hope you have read our KB article on dnssec-policy before migrating: > > https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy > > It should list the main pitfalls to save you a lot of hassle (I suspect you > started algorithm rollover immediately when changing to dnssec-policy > default). > > If there are any things we should add, I am happy to receive your suggestions. Are there any examples from ISC on how to handle multiple algorithms in the dnssec-policy stanza? I’m running 8 and 13 both as an experiment Eric -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: key dir massive
Hi Edwardo, On 12/22/22 05:01, Edwardo Garcia wrote: Hi, I recently upgraded from 9.16 to latest version and changed a zone, ran verisign test and it said all good, so changed my zones from auto maintain dnssec to dnssec policy default, what a nightmare, most our zones vanished few hours later for a day, and it create new keys for everything, this bug i saw was fixed many versions ago, should it not see my have keys and re-use them (keys were made a year ago on current at the time v9.11, we upgrade to 9.16 in July and no issue till these option name change rubbish. I was warned by colleagues not to do this as they too say migration nightmares, but I am my own person and now I regret not listening their advise. I hope you have read our KB article on dnssec-policy before migrating: https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy It should list the main pitfalls to save you a lot of hassle (I suspect you started algorithm rollover immediately when changing to dnssec-policy default). If there are any things we should add, I am happy to receive your suggestions. Now I think is under control, once identifying the current key set, is it safe to manually delete all the others keys privates and states, except the current one, and will any of that DS change again? Probably, without knowing your current state of things it is hard to give a more confident answer. Setting 'purge-keys' inside your 'dnssec-policy' is probably your best bet for the future. By default, no longer used keys are deleted from disk after 90 days. Best regards, Matthijs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Providing AD flag for authoritative domains
Le 22/12/2022 à 14:30, Jesus Cea a écrit : I have a validating DNSSEC bind server. I get AD (Authenticated Data) flag when requesting details from a DNSSEC protected domain. Good. The point is that when the requested DNS name belongs to a domain with this server is authoritative and that domain is DNSSEC enabled, no AD flag is provided in the answer. I guess this is because bind is replying with DNSSEC data but it doesn't follow that DNSSEC delegation tree in order to verify that everything is OK and so it doesn't signal safety with the AD flag. Is there any way to configure bind to verify DNSSEC integrity and signal the AD flag for authoritative domains?. Views (it would lose the AA flag, then)? What would be the best practice for dnssec verification? To use a fully validating local resolver? Any other choice? I am currently using a local "bind" as a resolver and it works fine for DNSSEC verification, except for my authoritative domains. If you trust your server for the AD bit, you could trust it for AA bit without AD bit. Otherwise you should go for a local validating server. It is a policy decision. Emmanuel. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Providing AD flag for authoritative domains
On 22/12/2022 13:30, Jesus Cea wrote: I have a validating DNSSEC bind server. I get AD (Authenticated Data) flag when requesting details from a DNSSEC protected domain. Good. The point is that when the requested DNS name belongs to a domain with this server is authoritative and that domain is DNSSEC enabled, no AD flag is provided in the answer. I guess this is because bind is replying with DNSSEC data but it doesn't follow that DNSSEC delegation tree in order to verify that everything is OK and so it doesn't signal safety with the AD flag. Is there any way to configure bind to verify DNSSEC integrity and signal the AD flag for authoritative domains?. Views (it would lose the AA flag, then)? What would be the best practice for dnssec verification? To use a fully validating local resolver? Any other choice? I am currently using a local "bind" as a resolver and it works fine for DNSSEC verification, except for my authoritative domains. You can achieve this by using a hidden-primary and then using "mirror zones" on the secondaries. They will return +AD, but not AA. FWIW, adding your own auth data to a recursive server is this manner is IMHO completely fine - it's what we do at ISC for our own internal recursors. On the other hand, having recursive lookups happen on a server that is a designated authoritative server (in the NS set) is regarded as bad practise. cheers, Ray -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Providing AD flag for authoritative domains
I have a validating DNSSEC bind server. I get AD (Authenticated Data) flag when requesting details from a DNSSEC protected domain. Good. The point is that when the requested DNS name belongs to a domain with this server is authoritative and that domain is DNSSEC enabled, no AD flag is provided in the answer. I guess this is because bind is replying with DNSSEC data but it doesn't follow that DNSSEC delegation tree in order to verify that everything is OK and so it doesn't signal safety with the AD flag. Is there any way to configure bind to verify DNSSEC integrity and signal the AD flag for authoritative domains?. Views (it would lose the AA flag, then)? What would be the best practice for dnssec verification? To use a fully validating local resolver? Any other choice? I am currently using a local "bind" as a resolver and it works fine for DNSSEC verification, except for my authoritative domains. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How do subdomains get discovered by adversaries?
I was just reading yesterday about one way this can be done. If you are using DNSSEC, the server, in order to sign a negative result, will use an NSEC record type which will contain some similar record to the missing record since it can’t sign an empty record. see below where I dig for MacBook.mylocal which doesn’t exist on my home domain and it returns a couple of NSEC records with appletv-livingroom.mylocall, jj-soundbar.mylocal., and macbookpro-20.mylocal. The solution to this is NSEC3 where the host names are hashed (https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#nsec3). Not sure if that answers how others are doing it, but was something I read about yesterday that has been exploited in the past to learn details about a zone. $ dig macbook.mylocal IN A @192.168.40.42 +dnssec ; <<>> DiG 9.16.33-Debian <<>> macbook.mylocal IN A @192.168.40.42 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18808 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 498ba75e90a524ad010063a44d72b4b9adb0b61ef5de (good) ;; QUESTION SECTION: ;macbook.mylocal. IN A ;; AUTHORITY SECTION: mylocal.7200IN SOA ns1.mylocal. hostmaster.mylocal. 64133 43200 900 1814400 7200 mylocal.7200IN RRSIG SOA 13 1 86399 20230105095806 20221222085806 2295 mylocal. 0AaPYQf2zVZuTshZ/yaVoQfgtQdwp2WigXypDEXp/NVdz6jH8pQKDB8j 3NDB7Xw1lr/o2OeJeK9NjuVIr3dZiA== mylocal.7200IN RRSIG NSEC 13 1 7200 20221228002743 20221213235040 2295 mylocal. SLA3LiYg8s80GlEFIgK0thf83k7z927lJJvGGUTF6mBzbrpC2kkDFfvw hx3cwjHU+zMlKoy1MdyDUJajBfn7hg== mylocal.7200IN NSECappletv-livingroom.mylocal. NS SOA RRSIG NSEC DNSKEY CDS CDNSKEY TYPE65534 jj-soundbar.mylocal. 7200 IN RRSIG NSEC 13 2 7200 20221228203849 20221221200203 2295 mylocal. bczZ0RfYzVaoLoJC6qV8RJHaXJhyxVtkExQ/S1NB0iPQeb26jZghZfMK umFNNcsMlGo4o5eiryxJGeC+yMfReA== jj-soundbar.mylocal. 7200 IN NSECmacbookpro-20.mylocal. A RRSIG NSEC DHCID ;; Query time: 0 msec ;; SERVER: 192.168.40.42#53(192.168.40.42) ;; WHEN: Thu Dec 22 07:28:34 EST 2022 ;; MSG SIZE rcvd: 576 > On Dec 22, 2022, at 12:19 AM, Michael De Roover wrote: > > Hello, > > I have been running BIND 9 on my external and internal networks for a > few years now -- as such I have a basic understanding of the most > common RR types and activities such as zone transfers. However, I have > been seeing something that's been baffling me for quite a while now. > Somehow there are services like c99.nl [1] and Criminal IP [2], which > can enumerate various subdomains on a given target domain. I am > confused as to how they can enumerate this information. > > As far as I know, a NS record returns the name servers authoritative > for a domain. Alright, now you've got authoritative information when > querying these domains. No useful information about the zone data they > are responsible for though. > > Then there is an A record, which returns an IPv4 address of a server > responsible for a domain. Alright, now you can talk to a server. Maybe > that would be a webserver, and now you may perform a HTTP exchange to > that server (GET /whatever, with a given Host header). You still have > to guess what the Host: header would have to be. > > Maybe it would be an MX record. Brilliant, now you could talk to a mail > server. Its EHLO message (sometimes called a "banner" in security > circles) would contain a domain, alright. It would also only be one of > them -- AFAICT only one domain that the organization wants to actually > primarily send from. > > Another interesting record would be the CNAME record. As far as I know, > this is used to redirect to another domain from within the DNS, with > its own bespoke entries (bringing us back to A records). Getting from a > CNAME to an A record seems easy enough, but what about getting these > CNAME records in the first place? > > This is what I am thinking of so far, but it may well be that I've been > talking crap in all of the above and know nothing about the DNS. That's > fine, and in that case please correct me where necessary. Either way, > I'm very confused on how these services can actually enumerate these > subdomains, and find most -- if not all -- reliably. This seems a bit > concerning to me with regards to unwanted information disclosure, hence > my curiosity. If it is at all possible to mitigate, I would of course > also appreciate discourse on this matter. Thank you! > > [1] https://subdomainfinder.c99.nl > [2] https://criminalip.io/domain > > Best regards, > Michael > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at
