[dns-operations] Stunning security discovery: AXFR may leak information

[Warren Kumari]

On Tue, Apr 14, 2015 at 2:47 PM, Marjorie <marjorie at id3.net> wrote:
> This is an interesting discussion actually.
> It's all about a rather benign but widespread misconfiguration.

It's only a misconfiguration if the operator didn't choose to do that
intentionally...
>
> Not long ago, I ran a survey against a small ccTLD and tested each
> domain name for AXFR.
> The ccTLD zone file itself having been obtained - you guessed it - by
> way of zone transfer...

A number of ccTLD operators intentionally allow AXFR of the zone. They
take the view that what is registered is:
A: public and or
B: will become public anyway. By allowing AXFR they cut down on
dictionally attacks and similar...

>
> Surprisingly, AXFR requests were honored by one server out of seven or
> something.
> So the prevalence of AXFR-enabled DNS servers is still quite high. I
> would guess this is the result of using default configuration settings
> from older Bind versions, but I didn't fingerprint the DNS software
> versions.
>
> Still many seem to consider that zone transfer is a moot point anyway,
> because the zone file can be reconstructed by scanning known IP ranges,
> then resolving hostnames.
> I disagree with this.  There is no valid reason for exposing your
> network topology to the outside world. You are only making the job
> easier for potential attackers.

If your security is somehow predicated on attackers not knowing the
names of machines you are going to have a bad day...

>
> I think the biggest issue with zone transfers, is that they may leak
> information that cannot be easily guessed otherwise.
> Specifically: hostnames declared outside the IP ranges that are known to
> the attacker.
>
> For example, company acme.com may have a zone file like this (IP
> addresses are of course made up):
>
> IN  SOA ns1.acme.com. hostmaster.acme.com. (
>             2015041001 ; serial
>             3H ; refresh
>             15 ; retry
>             1w ; expire
>             3h ; minimum
>             )
> ...
> sqlserver    A    204.63.177.1
> mailserver    A    204.63.177.21
> mailserver2    A    204.63.177.22
> sharepoint    A    204.63.177.40
> archive    A    204.63.177.55
> backupserver    A    89.52.67.31
> ...
>
>
> By looking at the zone file, you now know they have a backup server
> (89.52.67.31) hosted with a third party provider, thus you have one
> additional target to try.
> Thank you AXFR for helping hackers.

Again, if you were hoping that a "hacker" wouldn't have thought to
query for backupserver.acme.com and that this was providing you
protection you will become sad.
Also, let me introduce you to Farsight Security's DNSDB
(https://www.dnsdb.info/#Home) (many similar, but inferior services do
similar things)...

>
> Occasionally I have found sensitive comments in TXT records (HINFO
> records are telling too, sometimes).
>
> The bottom line is that unrestricted AXFR is generally evil, except for
> researchers of course.

... and those who want to cut down on dictionary attacks... and those
who run "public" zones, like the root and .arpa, and...


AXFR is also nice when you operate a search engine
> and want to find as many hosts as possible.
>

This is usually not "open" AXFR, but rather an agreement between the
search engine and TLD operators, with the TLD operator allowing AXFR
from a specific source block....

> DNS is like webhosting: the majority of the users do not have in-depth
> understanding of the mechanisms at work. They just have enough knowledge
> to make things run more or less smoothly.
>
> Marj
>
>
>
> On 14-04-2015 17:52, Samson Oduor wrote:
>> On 4/14/2015 6:38 PM, Jelte Jansen wrote:
>>> some DNS geeks even enable open AXFR on purpose, btw. Open AXFR is not
>>> necessarily a security hole or data leak.
>>>
>> open AXFR =  good for conducting reconnaissance
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-jobs mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf