【SEED Labs】DNS Rebinding Attack Lab
Lab Overview
实验环境下载：https://seedsecuritylabs.org/Labs_16.04/Networking/DNS_Rebinding/
在这个实验中模拟的物联网设备是一个恒温器，用于控制室内温度。要成功设置温度，客户端需要能够与物联网服务器交互。由于物联网设备在防火墙后面，外部机器不能与物联网设备交互，因此不能控制恒温器。为了击败防火墙保护，攻击代码必须首先进入内部网络。这并不难，当来自内部网络的用户访问攻击者的网站时，攻击者的代码(JavaScript代码)实际上是从用户的浏览器中运行的，因此在受保护的内部网络中运行。然而，由于浏览器实现的沙箱保护，攻击者的代码仍然不能与物联网设备交互，即使它现在在内部网络中。
这个实验的目标是使用DNS重绑定攻击来绕过沙箱保护，这样攻击者的javascript代码就可以成功地从设备获得必要的信息，并使用这些信息来获得温度测量的一个非常高的值。
本实验涵盖以下主题:
• DNS server setup
• DNS rebinding attack
• Attacks on IoT devices
• Same Origin Policy
我们的攻击目标是防火墙后面的一个物联网设备。我们不能从外部直接访问这个物联网设备。我们的目标是让内部用户运行我们的JavaScript代码，这样我们就可以使用DNS重新绑定攻击与物联网设备交互。
许多物联网设备都有一个简单的内置web服务器，因此用户可以通过web api与这些设备交互。通常，这些物联网设备由防火墙保护，它们不能从外部直接访问。由于这种类型的保护，许多物联网设备没有实现强大的身份验证机制。如果攻击者能够找到与它们交互的方法，就很容易危及其安全性。
我们使用一个简单的webserver来模拟这种易受攻击的物联网设备，该服务器提供两个api:密码和温度。物联网设备可以设置室温。为此，我们需要向服务器的温度API发送一个HTTP请求;请求应该包括两部分数据:目标温度值和密码。密码是定期更改的秘密，但可以使用密码API获取。因此，要成功设置温度，用户首先需要获得密码，然后将密码附加到温度API中。密码不是用于身份验证的;它用于抵抗跨站请求伪造(CSRF)攻击。没有这种保护，一个简单的CSRF攻击就足够了;没有必要使用更复杂的DNS重新绑定攻击。为了简单起见，我们硬编码了密码;在实际系统中，密码将定期重新生成。
LabEnvironment
在这个实验室中，我们将使用三台机器，分别称为用户VM、本地DNS服务器和攻击者VM。为了简单起见，我们使用VirtualBox中的NAT网络适配器将这些虚拟机放在同一个网络上。在现实世界中，它们不在同一个网络上。我们还假设运行在用户VM上的设备在防火墙后面，因此攻击者VM不能直接访问物联网设备。这个实验室的设置相当复杂，因为我们需要配置三个VM并在它们上运行多个服务器，包括一个IoT web服务器(在用户VM上)、一个web服务器和一个DNS服务器(在攻击者VM上)以及一个DNS服务器(在本地DNS服务器上)
LabTasks
Task1: Configure the User VM
Step1. 减少Firefox的DNS缓存时间。为了减少DNS服务器的负载并加快响应时间，Firefox浏览器缓存DNS结果。默认情况下，缓存的过期时间为60秒。这意味着我们的DNS重新绑定攻击需要等待至少60秒。为了让我们的实验更轻松，我们把时间减少到10秒或更少。在URL字段中输入about:config。单击警告页面后，我们将看到首选项名称及其值的列表。搜索dnsCache，找到以下条目并将其值更改为10:
更改后，应该退出Firefox浏览器，并重新启动;否则，更改将不会生效。
Step 2. 改变/etc/hosts.我们需要将以下条目添加到/etc/hosts文件中。我们将使用www.seedIoT32.com作为物联网web服务器的名称。此服务器可以运行在不同的VM上，但为了简单起见，我们在用户VM上运行物联网服务器(其IP地址为192.168.43.175):
Step3. Local DNS Server 。我们需要配置用户VM以使用特定的本地DNS服务器。这是通过将本地DNS服务器设置为解析器配置文件(/etc/resolv.conf)中的第一个名称服务器条目来实现的。一个挑战是所提供的VM使用动态主机配置协议(DHCP)来获取网络配置参数，如IP地址、本地DNS服务器等。DHCP客户机将用DHCP服务器提供的信息覆盖/etc/resolv.conf文件。
要将信息导入/etc/resolv.conf而不用担心DHCP，一种方法是将以下条目添加到/etc/resolvconf/resolv.conf.d/head文件(192.168.43.78为本地DNS服务器的IP地址):
头文件的内容将预先写入动态生成的解析器配置文件。通常，这只是一个注释行(/etc/resolv.conf中的注释来自这个头文件)。在进行更改之后，我们需要运行以下命令使更改生效:
Step 4. Testing 。配置用户VM之后，使用dig命令从您选择的主机名获取IP地址。从这个响应中，请提供证据证明这个响应确实来自你们的服务器。如果找不到证据，说明配置不成功。
Task2: Start the IoT server on the User VM
在此任务中，我们将在用户VM上启动物联网服务器。通过web服务器，用户可以与物联网设备通信。
Step 1. 安装 Flask. 我们使用Flask web框架来开发物联网服务器 sudo pip3 install Flask==1.1.1
Step 2. Start the IoT server. 物联网服务器代码包含在user_vm.zip，可以从实验室的网站上下载。解压缩文件后，进入user_vmf文件夹，通过运行准备好的脚本start IoT .sh或直接运行“flask run”启动物联网服务器。需要注意的是，我们使用端口8080作为物联网服务器(该端口号在实验室设置中是硬编码的;将其更改为不同的数字将破坏实验室设置)。
Step 3. Testing the IoT server 。要测试物联网服务器，请将浏览器指向用户VM上的以下URL。如果一切都设置正确，我们应该能够看到一个恒温器。我们也可以通过拖动滑动条来改变温度设置。
Task3: Start the attack web server on the Attacker VM
在本实验室中，只能从防火墙后访问物联网设备，即，仅来自实验设置中的用户VM。将恶意代码发送到用户虚拟机上的一种典型方式是让用户访问我们的网站，这样放置在web页面上的JavaScript代码就可以进入用户虚拟机上。在这个任务中，我们将启动一个web服务器来托管这些web页面。
Step 1. 安装 Flask。 我们的恶意web服务器也是基于Flask web框架开发的。
Step 2. Start the attacker’s web server 。攻击者的服务器代码包含在attacker_vm.zip，可以从实验室的网站上下载。解压缩文件后，进入attacker_vm文件夹，通过运行准备好的脚本start_webserver.sh或直接运行“flask run”来启动web服务器。
Step3. Testing the Attacker’s web server.
Task4: Configure the DNS server on the Attacker VM
攻击者VM也充当了attacker32.com域名的命名服务器。BIND9服务器已经在攻击者VM上运行，我们需要为它准备一个区域文件。一个示例区域文件包含在attackr_vm文件夹中。我们应该相应地更改区域文件，并将其复制到/etc/bind文件夹中。
将以下区域条目添加到/etc/bind/name .因此上面的区域文件将由BIND9服务器使用。
如果一切都设置正确，我们可以尝试以下dig命令，看看我们得到的响应是否与我们放在区域文件中的响应相同
Task5: Configure the Local DNS Server
在本地DNSserver上，我们设置attacker32.com域的转发记录，因此每当本地 DNS 服务器收到此域内主机的 DNS 查询时，它只需将 DNS 查询发送到指定转发记录的 IPaddress，而不是前往 root server 和the .com server，以找出attacker32.com域的名称服务器的位置。
要将此类记录添加到本地 DNS 服务器，我们需要将以下行添加到 /etc/bind/named.conf
在用户机上测试，dig成功：
Task6. Understanding the Same-Origin Policy Protection
同源策略是一种约定，它是浏览器最核心也最基本的安全功能。浏览器的同源策略，限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性。影响“源”的因素有：host（域名或IP地址，如果是IP地址则看做是一个根域名）、子域名、端口、协议。在浏览器中，<script>、<img>、<iframe>、<link>等标签都可以跨域加载资源，而不受同源策略的限制，但是浏览器限制了JavaScript的权限，使其不能读、写返回的内容。
attacker_vm的change界面
单击click之后，user_vm的温度并不会改变
user_vm的change界面
单击click之后，user_vm的温度变为99℃
Task7. Defeat the Same-Origin Policy Protection
击败同源的主要想法保护来自这样一个事实:策略执行基于主机名,而不是IP地址,所以只要我们使用www.attacker32.com的URL,我们遵守SOP的政策,但这并不意味着我们是限制与www.attacker32.com web服务器进行通信。
在用户的浏览器向www.attacker32.com发送请求之前，它首先需要知道www.attacker32.com的IP地址。一个DNS请求将从用户的机器发出。如果IP地址没有缓存在本地DNS服务器上，一个DNS请求最终会被发送到attacker32.com的nameserver，它运行在攻击者的VM上。因此，攻击者可以决定在响应中放入什么。
Step 1: Modify the JavaScript code. 在攻击者虚拟机中，在www.attacker32.com:8080/change中运行的JavaScript代码存储在以下文件中:attacker_vm/rebind_malware/templates/js/change.js。由于该页面来自www.attacker32.com服务器，根据同源策略，只能与同一服务器交互。因此，我们需要将代码的第一行从http://www.seediot32.com:8080更改为以下内容:
Step2: Conduct the DNS rebinding 。我们的JavaScript代码发送请求到www.attacker32.com，请求将返回到攻击者VM。这不是我们想要的，我们希望将请求发送到iot服务器。这可以通过DNS重新绑定技术实现。我们首先映射 www. attacker32.com 为攻击者VM的IP地址，这样用户可以从http: //www.attacker32.com/change获得实际页面。在我们点击网页上的按钮之前，我们重新映射www.attacker32.com主机名到iot服务器的IP地址，按钮触发的请求将到达iot服务器。这正是我们想要的。
修改好相应文件进行刷新：
同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以xyz.com下的js脚本采用ajax读取abc.com里面的文件数据是会被拒绝的。同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。不受同源策略限制的1. 页面中的链接，重定向以及表单提交是不会受到同源策略限制的。2. 跨域资源的引入是可以的。但是js不能读写加载的内容。如嵌入到页面中的<script src="..."></script>，<img>，<link>，<iframe>等
Task8. Launch the Attack
使用用户机访问下列url：
每当10秒倒计时为0，温度将会被设定为88度：
