关注我们

黑客技术?没你想象的那么难!——dns劫持篇

LzersLzers 黑帽艺术 2018-05-11 200845 0

目录

一、什么是DNS
二、DNS原理
三、什么是DNS劫持及危害
四、DNS劫持方法
五、如何防止DNS劫持(网络层面)
六、如何防止DNS劫持(应用层面)
七、历史著名劫持案例

黑客技术?没你想象的那么难!——dns劫持篇

从 www.toutiao.com 到 202.108.250.213 的转换工作称为域名解析,域名解析需要由专门的域名解析服务器来完成,DNS就是进行域名解析的服务器(Domain Name System 或Domain Name Service)。

:直接使用 202.108.250.213是无法访问今日头条官网的,这是因为今日头条的服务器做了设置,限制IP访问。
一般的网站会选择放在虚拟主机,且在主机上放置了很多个网站,而每个网站绑定1个或以上域名、虚拟主机上。例如Apache主机的配置会将对应的ip解析到对应的网站目录的,实现一台服务器上配置多个站点;一般用户在访问的时候,会产生一个http请求报文,上面的host信息可以提供给服务器,告诉服务器要访问的域名,从而实现一台主机绑
定一个IP,即使有多个网站,也不会相互干扰。但使用IP访问,主机不知道用户访问的具体目录,请求便会出现错误。)

 

 

二、DNS原理

DNS 查询时,会先在本地缓存中尝试查找,如果不存在或是记录过期,就继续向 DNS 服务器发起递归查询,这里的 DNS 服务器一般就是运营商的 DNS 服务器。

1、DNS工作原理

黑客技术?没你想象的那么难!——dns劫持篇

第一段是查询参数和统计。

黑客技术?没你想象的那么难!——dns劫持篇

上面结果表示,查询域名 math.stackexchange.com A记录,
Aaddress的缩写。
第三段是DNS服务器的答复。

黑客技术?没你想象的那么难!——dns劫持篇

上面结果显示stackexchange.com共有四条NS记录,即四个域名服务器,向其中任一台查询就能知道stackexchange.com的IP地址是什么。
第五段是上面四个域名服务器的IP地址,这是随着前一段一起返回的。

黑客技术?没你想象的那么难!——dns劫持篇

上面结果显示,本机的DNS服务器是192.168.1.253,查询端口是53(DNS服务器的默认端口),以及回应长度是305字节。
如果不想看到这么多内容,可以使用+short 参数。

$ dig +short math.stackexchange.com
#返回:

151.101.129.69
151.101.65.69
151.101.193.69
151.101.1.69

上面命令只返回math.stackexchange.com对应的4个IP地址(即A记录)。

3、DNS服务器
下面我们根据前面这个例子,一步步还原,本机到底怎么得到域名math.stackexchange.com的IP地址。
首先,本机一定要知道DNS服务器的IP地址,否则上不了网。通过DNS服务器,才能知道某个域名的IP地址到底是什么。

黑客技术?没你想象的那么难!——dns劫持篇

比如,域名math.stackexchange.com显示为math.stackexchange.com. 这不是疏忽,而是所有域名的尾部,实际上都有一个根域名。
举例来说,
www.example.com
真正的域名是
www.example.com.root
简写为www.example.com.。
因为,根域名.root对于所有域名都是一样的,所以平时是省略的。
根域名的下一级,叫做"顶级域名"(top-level domain,缩写为TLD),比如.com、.net;
再下一级叫做"次级域名"(second-level domain,缩写为SLD),比如www.example.com里面的.example,这一级域名是用户可以注册的;
再下一级是主机名(host),比如www.example.com里面的www,又称为"三级域名",这是用户在自己的域里面为服务器分配的名称,是用户可以任意分配的。
总结一下,域名的层级结构如下。

主机名.次级域名.顶级域名.根域名
# 即host.sld.tld.root

 

5、根域名服务器
DNS服务器根据域名的层级,进行分级查询。
需要明确的是,每一级域名都有自己的NS记录,NS记录指向该级域名的域名服务器。
这些服务器知道下一级域名的各种记录。
所谓"分级查询",就是从根域名开始,依次查询每一级域名的NS记录,直到查到最终的IP地址,过程大致如下。

  • 从"根域名服务器"查到"顶级域名服务器"的NS记录和A记录(IP地址)

  • 从"顶级域名服务器"查到"次级域名服务器"的NS记录和A记录(IP地址)

  • 从"次级域名服务器"查出"主机名"的IP地址

仔细看上面的过程,你可能发现了,没有提到DNS服务器怎么知道"根域名服务器"的IP地址。
回答是"根域名服务器"的NS记录和IP地址一般是不会变化的,所以内置在DNS服务器里面。
下面是内置的根域名服务器IP地址的一个例子。

黑客技术?没你想象的那么难!——dns劫持篇

根据内置的根域名服务器IP地址,DNS服务器向所有这些IP地址发出查询请求,询问math.stackexchange.com的顶级域名服务器com的NS记录。
最先回复的根域名服务器将被缓存,以后只向这台服务器发请求。
接着是第二段。

黑客技术?没你想象的那么难!——dns劫持篇

上面结果显示 stackexchange.com 有四条NS记录,同时返回的还有每一条NS记录对应的IP地址。
然后,DNS服务器向上面这四台NS服务器查询 match.stackexchange.com的主机名。

黑客技术?没你想象的那么难!——dns劫持篇

上面结果显示,facebook.github.io的CNAME记录指向github.map.fastly.net。
也就是说,用户查询facebook.github.io的时候,实际上返回的是github.map.fastly.net的IP地址。
这样的好处是,变更服务器IP地址的时候,只要修改github.map.fastly.net这个域名就可以了,用户的facebook.github.io域名不用修改。
由于CNAME记录就是一个替换,所以域名一旦设置CNAME记录以后,就不能再设置其他记录了
(比如A记录和MX记录),这是为了防止产生冲突。
举例来说
foo.com

指向bar.com,而两个域名各有自己的MX记录,如果两者不一致,就会产生问题。由于顶级域名通常要设置MX记录,所以一般不允许用户对顶级域名设置CNAME记录。

PTR
记录用于从IP地址反查域名。dig 命令的-x参数用于查询PTR记录。

黑客技术?没你想象的那么难!——dns劫持篇

1、利用DNS服务器进行DDOS攻击
正常的DNS服务器递归查询过程可能被利用成DDOS攻击。假设攻击者已知被攻击机器的IP地址,然后攻击者使用该地址作为发送解析命令的源地址。这样当使用DNS服务器递归查询后,DNS服务器响应给最初用户,而这个用户正是被攻击者。那么如果攻击者控制了足够多的肉鸡,反复的进行如上操作,那么被攻击者就会受到来自于DNS服务器的响应信息DDOS攻击。
如果攻击者拥有着足够多的肉鸡群,那么就可以使被攻击者的网络被拖垮至发生中断。利用DNS服务器攻击的重要挑战是,攻击者由于没有直接与被攻击主机进行通讯,隐匿了自己行踪,让受害者难以追查原始的攻击来。

2、DNS缓存感染
攻击者使用DNS请求,将数据放入一个具有漏洞的的DNS服务器的缓存当中。这些缓存信息会在客户进行DNS访问时返回给用户,从而把用户客户对正常域名的访问引导到入侵者所设置挂马、钓鱼等页面上,或者通过伪造的邮件和其他的server服务获取用户口令信息,导致客户遭遇进一步的侵害。

3、DNS信息劫持
TCP/IP体系通过序列号等多种方式避免仿冒数据的插入,但入侵者如果通过监听客户端和DNS服务器的对话,就可以猜测服务器响应给客户端的DNS查询ID。每个DNS报文包括一个相关联的16位ID号,DNS服务器根据这个ID号获取请求源位置。攻击者在DNS服务器之前将虚假的响应交给用户,从而欺骗客户端去访问恶意的网站。假设当提交给某个域名服务器的域名解析请求的DNS报文包数据被截获,然后按截获者的意图将一个虚假的IP地址作为应答信息返回给请求者。原始请求者就会把这个虚假的IP地址作为它所要请求的域名而进行访问,这样他就被欺骗到了别处而无法连接想要访问的那个域名。

4、DNS重定向
攻击者将DNS名称查询重定向到恶意DNS服务器上,被劫持域名的解析就完全在攻击者的控制之下。

演示DNS重定向:

首先,我们要用一个无线网卡来伪造ap。
启动伪ap前的准备
Ifconfig –a 查看当前网卡情况
Ifconfig wlan0 up 激活无线网卡
Airmon-ng start wlan0 将你的无线网卡开启“Monitor”模式
如果这里有其他进程干扰的话就先把干扰进程kill掉再进行。在设置监听模式前先输入airmon-ng check kill结束进程。

黑客技术?没你想象的那么难!——dns劫持篇

黑客技术?没你想象的那么难!——dns劫持篇

黑客技术?没你想象的那么难!——dns劫持篇黑客技术?没你想象的那么难!——dns劫持篇

黑客技术?没你想象的那么难!——dns劫持篇

黑客技术?没你想象的那么难!——dns劫持篇

探测目标ap,为伪ap的假设做准备,airodump-ng wlan0mon.

在上面探测ap中,我们可以了解到WiFi名称(ssid)、加密方式以及信道等信息。
接下来我们就可以启动伪ap了。airbase-ng wlan0mon -e "xiaoqin00" -c 6 (这里环境不同,启动方式也不一样,我这里是kali2.0的环境所以这样,以前版本启动方式为airbase-ng mon0 -e "xiaoqin00" -c 6)

这个时候我们就可收到我们伪造的ap了,但是这个ap无法行使正常的功能,你连接的话它会一直保持获取ip中的状态。

 

接下来就需要我们配置和这个伪ap配套的dhcp了。
apt-get install udhcpd
修改/etc/udhcpd.conf配置文件,自定义IP池、网关、DNS、interface等等。
推荐用gedit工具来编辑文件:
gedit /etc/udhcpd.conf
修改IP池
192.168.x.y
192.168.x.z

修改执行dhcp功能的接口
可以用过ifconfig -a或者iwconfig命令来查看接口

修改DNS、网关、netmask等

修改/etc/default/udhcpd,修改dhcpd功能为yes。
DHCPD_ENABLE="yes"

开启dhcp服务,service udhcpd start。
配置好dhcp后,我们还需要解决流量问题,这里192.168.2.0/24中的流量需要通过主机网卡eth0与外界进行交互。我们用iptables来解决这个。

再接着就是配置dns服务了。这里我们使用msf中的fakedns来提供dns服务。

 

我们将http://xiaoqin00.com的域名劫持到192.168.2.1上。

当这都配置好后,我们来连接这个伪ap。现在,只要被攻击者一进入www.xiaoqin00.com,他就会被劫持到错误的站点,这算是钓鱼的一种方法吧。

当你完成这些之前,如果目标主机已经连接上WiFi,可以对它的WiFi用mdk3等工具进行ddos攻击强制目标断开连接。
*在智能手机中,如果两个WiFi一样,那么手机会保持当前连接并对新出现的WiFi自动进行屏蔽。
*构造伪dhcp服务器有很多种方法。

 

5、ARP欺骗
ARP攻击就是通过伪造IP地址和MAC地址实现ARP欺骗,能够在网络中产生大量的ARP通信量使网络阻塞,攻击者只要持续不断的发出伪造的ARP响应包就能更改目标主机ARP缓存中的IP-MAC条目,造成网络中断或中间人攻击。ARP攻击主要是存在于局域网网络中,局域网中若有一台计算机感染ARP病毒,则感染该ARP病毒的系统将会试图通过”ARP欺骗”手段截获所在网络内其它计算机的通信信息,并因此造成网内其它计算机的通信故障。
ARP欺骗通常是在用户局域网中,造成用户访问域名的错误指向。如果IDC机房也被ARP病毒入侵后,则也可能出现攻击者采用ARP包压制正常主机、或者压制DNS服务器,以使访问导向错误指向的情况。
我们可以使用ettercap或者arpspoof来实现dns劫持。

黑客技术?没你想象的那么难!——dns劫持篇

黑客技术?没你想象的那么难!——dns劫持篇

 

五、如何防止DNS劫持(网络层面)

1、互联网公司准备两个以上的域名,一旦黑客进行DNS攻击,用户还可以访问另一个域名。
2、手动修改DNS:

 

  • 在地址栏中输入:http://192.168.1.1 (如果页面不能显示可尝试输入:http://192.168.0.1)。

  • 填写您路由器的用户名和密码,点击“确定”。

  • 在“DHCP服务器—DHCP”服务中,填写主DNS服务器为更可靠的114.114.114.114地址,备用DNS服务器为8.8.8.8,点击保存即可。

3、修改路由器密码:

 

  • 在地址栏中输入:http://192.168.1.1 (如果页面不能显示可尝试输入:http://192.168.0.1)

  • 填写您路由器的用户名和密码,路由器初始用户名为admin,密码也是admin,如果您修改过,则填写修改后的用户名和密码,点击“确定”

  • 填写正确后,会进入路由器密码修改页面,在系统工具——修改登录口令页面即可完成修改(原用户名和口令和2中填写的一致)

 

 

六、如何防止DNS劫持(应用层面)

本小节内容来自美图在HTTPS环境的DNS优化实践,通过该优化方案,使美图App请求耗时节约近半。
真实案例,提供给大家参考。
美图的移动端产品在实际用户环境下会面临 DNS 劫持、耗时波动等问题,这些 DNS 环节的不稳定因素,导致后续网络请求被劫持或是直接失败, 对产品的用户体验产生不好的影响。
为此,对移动端产品的 DNS 解析进行了优化探索,产生了相应的 SDK。在这过程中,参考借鉴了业内的主流方案,也进行了一些实践上的思考。
下面的内容会主要以 Android 平台来进行说明。

LocalDNS VS HTTP DNS
在长期的实践中,互联网公司发现 LocalDNS 会存在如下几个问题:

 

  • 域名缓存: 运营商 DNS 缓存域名解析结果,将用户导向网内缓存服务器;

  • 解析转发 & 出口 NAT: 运营商 DNS 转发查询请求或是出口 NAT 导致流量调度策略失效;

为了解决 LocalDNS 的这些问题,业内也催生了 HTTP DNS 的概念。
它的基本原理如下:
原本用户进行 DNS 解析是向运营商的 DNS 服务器发起 UDP 报文进行查询,而在 HTTP DNS 下,我们修改为用户带上待查询的域名和本机 IP 地址直接向 HTTP WEB 服务器发起 HTTP 请求,这个 HTTP WEB 将返回域名解析后的 IP 地址。
比如 DNSPod 的实现原理如下:

黑客技术?没你想象的那么难!——dns劫持篇

HTTP 协议相对比较容易,只需要处理 HOST,那么 HTTPS 呢?
发起HTTPS请求首先需要进行 SSL/TLS 握手,其流程如下:

  • 客户端发送 Client Hello,携带随机数、支持的加密算法等信息; 

  • 服务端收到请求后,选择合适的加密算法,连同公钥证书、随机数等信息返回给客户端;

  • 客户端检验服务端证书的合法性,计算产生随机数并用证书公钥加密发送给服务端; 

  • 服务端通过私钥获取随机数信息,基于之前的交互信息计算得到协商密钥并通知给客户端;

  • 客户端验证服务端发送的数据和密钥,通过后双方握手完成,开始进行加密通信;

在我们采用 IP 直连的形式后,上述 HTTPS 的第三步会发生问题, 客户端检验服务端下发的证书这动作包含两个步骤:

  • 客户端用本地保存的根证书解开证书链,确认服务端的证书是由可信任的机构颁发的。

  • 客户端需要检查证书的 Domain 域和扩展域是否包含本次请求的 HOST。

证书的验证需要这两个步骤都检验通过才能够进行后续流程,否则 SSL/TLS 握手将在这里失败结束。
由于在 IP 直连下,我们给网络请求库的 URL 中 host 部分已经被替换成了 IP 地址,
因此证书验证的第二步中,默认配置下 “本次请求的 HOST” 会是一个 IP 地址,这将导致 domain 检查不匹配,最终 SSL/TLS 握手失败。
那么该如何解决这个问题?
解决 SSL/TLS 握手中域名校验问题的方法在于我们重新配置 HostnameVerifier, 让请求库用实际的域名去做域名校验,
代码示例如下:

黑客技术?没你想象的那么难!——dns劫持篇

Android 平台上常用的 Okhttp、HttpUrlConnection 等网络请求库都会依赖这个形式的 DNS 解析。
我们深入分析 InetAddress 的运行流程,其大致如下:
在上述流程中我们可以知道,InetAddress 会有到 AddressCache 尝试获取已缓存记录的动作,而这里 AddessCache 是一个 static 的 map 结构变量。
因此,在这里我们来对它做点小手脚 :

  • 模仿系统的 AddressCache 构造一个我们自己的 AddressCahce 结构,不过它的 get 方法被替换为从我们 SDK 获取解析记录。

  • 通过反射的形式用我们修改后的 AddressCache 替换掉系统的 AddressCache 变量。

这个偷天换日的操作之后,HttpsUrlConnection 等 Java 层网络请求在进行 DNS 解析时就会是这样一个流程:

黑客技术?没你想象的那么难!——dns劫持篇

那么在这里,我们是否可以手动修改这个映射表内容,把 getaddrinfo 的内存地址替换成我们的 my_getaddrinfo 地址呢?
这样,a.so 在实际运行时会被拐到我们的 my_getaddrinfo 中?
实际上,确实是可行的。 我们尝试在 SDK 启动后,对 a.so 的 .rel.plt 表进行修改,达到接管 a.so DNS 的目的,
修改后的 a.so 运行流程如下:

黑客技术?没你想象的那么难!——dns劫持篇

通过 HTTP DNS 的引入和 LocalDNS 优化升级策略,我们的网络请求成功率有提升,在未知主机等具体错误率表现出下降的趋势。
由于 SDK 层面本身做好了灵活的策略配置,我们通过线上监控和配置也让各产品在效益和成本之间取得一个最佳的平衡点。

 

 

七、历史著名DNS劫持案例

  • 2009年巴西最大银行遭遇DNS攻击,1%用户被钓鱼。
    2009年巴西一家最大银行Bandesco巴西银行,曾遭受DNS缓存病毒攻击,成为震惊全球的““银行劫持案”。受到影响的用户会被重定向至一个假冒的银行网站,该假冒网站试图窃取用户密码并安装恶意软件。DNS缓存病毒攻击是利用互联网域名系统中的漏洞进行的,没有及时打补丁的ISP很容易受到攻击。合法的IP会被某个网站给取代,即使终端用户输入正确的网址也会被重定向至那些恶意网站。有近1%的银行客户受到了攻击,如果这些客户注意到了银行SSL证书在被重定向时出现的错误提示,就不会上当受骗。

  • 2010年1月12日 上午7时40分 “百度域名被劫持”事件。
    当时有网民发现百度首页登陆发生异常情况。上午8时后,在中国内地大部分地区和美国、欧洲等地都无法以任何方式正常登陆百度网站,而百度域名的WHOIS传输协议被无故更改,网站的域名被更换至雅虎属下的两个域名服务器,部分网民更发现网站页面被篡改成黑色背景以及伊朗国旗,同时显示“This site has been hacked by Iranian Cyber Army”(该网站已被伊朗网军入侵)字样以及一段阿拉伯文字,然后跳转至英文雅虎主页,这就是“百度域名被劫持”事件。

  • 2012年10月25日 日本邮储银行、三井住友银行和三菱东京日联银行各自提供的网上银行服务都被钓鱼网站劫持。
    据日本《日经电脑》报道,日本邮储银行、三井住友银行和三菱东京日联银行于2012年10月25日和10月26日分别发布公告提醒用户,三家银行各自提供的网上银行服务都被钓鱼网站劫持,出现要求用户输入信息的虚假页面,在登录官方网站后,会弹出要求用户输入密码等的窗口画面,本次虚假弹出式窗口页面的目的在于盗取用户网上银行服务的密码。这种弹出式窗口页面上还显示有银行的标志等,乍看上去像真的一样。

  • 2013年5月6日 史上最大规模DNS钓鱼攻击预估已致800万用户感染。

  • 2014年1月21日 北京2014年1月21日,全国大范围出现DNS故障,下午15时20分左右,中国顶级域名根服务器出现故障,大部分网站受影响,此次故障未对国家顶级域名.CN造成影响,所有运行服务正常。


版权声明

本文仅代表作者观点,不代表黑白网立场。
如文章侵犯了您的权利,请通过邮箱联系我们删除
E-Mail:server@heibai.org
黑白网官群:238921584

喜欢0评论已闭