DNS侦察对抗通配符域名

我最近对一家公司进行了测试，在汇报中他们询问我是如何枚举出如此多的子域名的，因为他们使用了通配符DNS设置，而之前的测试人员曾评论说这阻止了DNS枚举。当我向他们解释通配符只是掩盖了有效域名时，他们对之前的测试人员说了几句选择性的词语，我认为这可以成为一篇不错的博客文章。

场景设定

通配符DNS记录是一种在没有明确定义记录的情况下匹配请求的记录。通常定义为*.domain.com，以下是一个使用示例：

1
2
3
4
5

www.domain.com      A   1.2.3.4
hidden.domain.com   A   1.2.3.4
test.domain.com     A   1.2.3.5
staging.domain.com  A   1.2.3.6
*.domain.com        A   1.2.3.4

在这里，如果我请求www.domain.com的IP，我将得到IP 1.2.3.4；如果我请求test.domain.com，我将得到1.2.3.5；但如果我请求mail.domain.com，由于没有明确定义的记录，我将得到通配符响应1.2.3.4。

为什么这会阻止枚举？

大多数枚举的起点之一是对名称服务器进行暴力查找，寻找常见名称列表。有很多工具可以做到这一点，我偏好Carlos Perez的dnsrecon，但也有Jabra的Fierce和dnssenum。当对使用通配符记录的域名执行此类暴力查找时，每个请求都会返回成功，要么是真实结果，要么是默认记录。生成的数据量可能让之前的测试人员不堪重负，这就是为什么他认为通配符增加了安全性。

那么为什么这不是问题？

首先，通过请求一个永远不会存在的记录，例如fkrusfk9374Fs.domain.com，我可以确定是否正在使用通配符。如果我得到一个结果，那么就是，并且我知道通配符返回的默认IP。接下来，我只需过滤掉具有该IP的任何结果。如果我得到以下结果：

1
2
3
4
5
6
7
8
9

www.domain.com      A   1.2.3.4
hidden.domain.com   A   1.2.3.4
test.domain.com     A   1.2.3.5
test1.domain.com    A   1.2.3.4
test2.domain.com    A   1.2.3.4
staging.domain.com  A   1.2.3.6
lab.domain.com      A   1.2.3.4
mail.domain.com     A   1.2.3.4
owa.domain.com      A   1.2.3.4

我可以将它们过滤到这个列表：

1
2

test.domain.com     A   1.2.3.5
staging.domain.com  A   1.2.3.6

由于这些记录与通配符IP不匹配，它们必须是名称服务器上明确定义的记录。你会注意到我丢失了两个有效结果，www和hidden。由于大多数域名都会有www记录，我通常会假设它存在。至于hidden，好吧，这是一个漏网之鱼，但我宁愿丢失一个记录，留下两个进行测试，而不是一看到使用通配符就完全放弃。

下一步

如果你想知道如何找到在上述过滤中丢失的两个条目，DNS枚举的下一步是查看Google对你的目标了解什么。我不会尝试记录这一点，而是指向你Tim Tomes（lanmaster53）在今年Hack3rcon上的演讲和工具，“下一代Web侦察”。

祝你好运，希望下次你看到通配符记录时，能够透过干扰找出它只是掩盖的美味部分。