利用DNS重绑定攻击专用网路
利用DNS重绑定攻击专用网路
来自专栏看雪论坛
6 人赞了文章
家庭WiFi网路是一个神圣的地方，是属于你自己的网路空间。 在那里，我们将手机，笔记本电脑和智能设备相互连接并联通到互联网，从而改善我们的生活，或者至少我们是这样想的 。 到了二十世纪末，我们的本地网路已经被越来越多的设备所占据。 从智能电视和媒体播放器到家庭助理，安全摄像头，冰箱，门锁和恒温器，我们的家庭网路是可信赖的个人和家庭设备的天堂。摘要：点击错误的链接可能会导致远程攻击者控制你的WiFi路由器，Google Home，智能电视盒子Roku，Sonos扬声器，家用恒温器等。
许多这些设备提供有限或不存在的身份验证来访问和控制其服务。 它们默认信任网路上的其他设备，就像你信任被允许进入你家的人一样。 它们使用通用即插即用（UPnP）和HTTP等协议在彼此之间自由通信，同时通过路由器的防火墙，本质上可以防止来自Internet外部的连接请求 。 它们相当于在一个有围墙的花园中运行，不受外部威胁。至少这是开发人员所认为的。
几个月前，我开始研究一项有10年历史的名为DNS重绑定的网路攻击研究。 简而言之，DNS重绑定允许远程攻击者绕过受害者的网路防火墙，并使用其Web浏览器作为代理，直接与其私有家庭网路上的设备进行通信。 通过打开错误的链接或点开恶意横幅广告，你可能会无意中让攻击者能够访问控制家中温度的恒温器。
注意：本研究同时也经由Lily Hay Newman在Wired网站上发表。
什么是DNS重绑定？
为了更好地理解DNS重绑定的工作方式，首先要了解它所避开的安全机制是有帮助的; Web浏览器的同源策略。 许多月前，浏览器供应商认为，如果没有来自第二个域的明确许可，从一个域提供的网页能够向另一个域发出任意请求可能不是一个好主意。
如果你在网路上打开恶意链接，你到达的网页将无法向你的银行网站发出HTTP请求，并利用你在此处登录的会话来清空你的帐户。 浏览器通过限制来自一个域的HTTP请求仅能访问位于同一域的其他资源（或明确使用跨源资源共享的另一个域）来禁止这种行为。
可以滥用DNS来诱骗Web浏览器与他们不想要的伺服器进行通信。
因为malicious.website和http://bank.com属于不同的域，http://malicious.website上的代码无法向http://bank.com/transfer-fund发送标准的XMLHttpRequest请求，因此浏览器将它们视为单独的来源。 浏览器通过要求请求的URL的协议，域名和埠号与请求它的页面的URL相同来强制执行此操作。 听起来不错吧？
但是不然。 每个域名后面都有一个IP地址。 malicious.website可能位于34.192.228.43，http://bank.com可能位于171.159.228.150。 域名系统（DNS）提供了一种有用的机制，可以将易于记忆的域名转换为我们的计算机实际用来相互通信的IP地址。
问题在于现代浏览器使用URL来评估同源策略限制，而不是IP地址。 如果malicious.website的IP地址从34.192.228.43快速更改为IP地址171.159.228.150，会发生什么？ 从浏览器上看，没有任何改变。
但现在，你的浏览器实际上正在与http://bank.com交谈，而不是与最初托管恶意网站文件的伺服器进行通信。 问题出现了，我们可以通过滥用DNS来诱骗Web浏览器与他们不想要的伺服器进行通信。
在过去的一年中，DNS重绑定因为一些流行软体的漏洞，已经收到了一些短暂的关注。 最值得注意的是，暴雪的视频游戏，传输Torrent客户端和几个以太坊加密货币钱包直到最近才不再容易受到DNS重绑定攻击。 糟糕的情况下，以太坊Geth漏洞可能让远程攻击者完全控制受害者的以太坊账户，并使用它完全控制所有硬币。
DNS重新绑定允许远程攻击者绕过受害者的网路防火墙，并使用其Web浏览器作为代理，直接与其私有家庭网路上的设备进行通信。
DNS重绑定是如何工作的？
攻击者控制恶意DNS伺服器来回复域的查询，比如rebind.network。
攻击者欺骗用户在浏览器中载入http://rebind.network。 他们可以通过多种方式，从网路钓鱼到持久性XSS，或购买HTML横幅广告，来实现这一目标。
一旦用户打开链接，他们的Web浏览器就会发出DNS请求，查找rebind.network的IP地址。 当它收到受害者的DNS请求时，攻击者控制的DNS伺服器会使用rebind.network的真实IP地址34.192.228.43进行响应。 它还将响应的TTL值设置为1秒，以便受害者的机器不会长时间缓存它。受害者从http://rebind.network载入网页，其中包含恶意JavaScript代码，该代码开始在受害者的Web浏览器上执行。 该页面开始反复向http://rebind.network/thermostat发送一些奇怪的POST请求，其中包含JSON有效负载，如{「tmode」: 1,」a_heat」: 95}。首先，这些请求被发送到34.192.228.43上运行的攻击者的Web伺服器，但过了一段时间（因为浏览器DNS缓存的奇怪运作），浏览器的解析器观察到rebind.network的DNS条目是陈旧的，因此它进行另一次DNS查找。攻击者的恶意DNS伺服器接收受害者的第二个DNS请求，但这次它以IP地址192.168.1.77响应，该地址恰好是受害者本地网路上智能恒温器的IP地址。受害者的计算机收到此恶意DNS响应，并开始将指向http://rebind.network的HTTP请求指向192.168.1.77。 就浏览器而言，没有任何改变，因此它将另一个POST发送到http://rebind.network/thermostat。这一次，POST请求被发送到在受害者WiFi连接的恒温器上运行的小型不受保护的Web伺服器。 恒温器处理请求，受害者家中的温度设置为95度。
这个场景是我发现并使用的无线电温控器CT50智能恒温器的实际漏洞利用（CVE-2018-11315）。 这样的攻击可能对专用网路上运行的设备或服务产生深远的破坏性影响。 通过将受害者的Web浏览器用作一种HTTP代理，DNS重绑定攻击可以绕过网路防火墙，并使受保护的内网上的每个设备都可供外网上的远程攻击者使用。
什么设备会被攻击？
在我第一次尝试发现并利用此漏洞后，我担心可能还有很多其他物联网设备也可以作为目标。 我开始收集和借用当今市场上一些比较流行的智能家居设备。 在接下来的几周内，我手上的每一台设备都以某种方式成为DNS重新绑定的受害者，导致信息被泄露，或者在某些情况下，导致设备完全控制。
Google Home，Chromecast，Roku，Sonos WiFi扬声器和某些智能恒温器都可以通过未经授权的远程攻击者以某种方式与其进行连接。 好像是个大问题吧？
当地网路是一个避风港的想法是一种谬论。 如果我们继续相信这个谬论，人们会受到伤害。
我一直与这些产品的供应商保持联系，所有这些产品都正在开发或已经发布了安全补丁（本论文中包含此披露的更多信息）。 这些只是我业余时间亲自测试过的设备的公司。 如果具有如此高级配置的公司未能防止DNS重绑定攻击，那么必须有无数其他供应商同样不能防止这一攻击。
演示于此：http://rebind.network
Google Home
快进五年，谷歌似乎已将同样神秘的API集成到其所有Google Home产品中，而且你可以想像，此时无数业余爱好者已经很好地记录了这种未记录的API。 事实上，今年早些时候，Rithvik Vibhu向公众发布了详细的API文档。
此API提供广泛的设备控制，无需任何形式的身份验证。 一些最有趣的功能包括启动娱乐应用和播放内容，扫描和加入附近的WiFi网路，重启，甚至恢复出厂设置的能力。
想像一下，你正在浏览网页，突然你的Google Home开始恢复出厂设置。 或者比如你的室友在他们的笔记本电脑上打开网路浏览器，并且在你尝试观看电影时通过一个HTML广告将你的Chromecast发送到重启循环。 我最喜欢的针对此API的攻击方案之一是滥用WiFi扫描功能。
攻击者可以将此信息与可公开访问的驾乘式攻击数据配对，并仅使用附近的WiFi网路列表获得准确的地理位置。 即使你已禁用Web浏览器的地理位置API并使用VPN来隧道通过其他国家/地区的流量，此攻击也会成功。
这是我从自己的Chromecast中删除的部分数据示例。 你能弄明白我在什么地方写这篇文章吗？
更新(06/19/2018): Craig Young昨天在此帖之前公布了对此漏洞的同步和独立研究。他实际上为我上面描述的地理定位攻击场景创建了一个PoC，但还没有对此加以实现。 他的作品和Brian Kreb对它的评论都非常出色。
我在3月份发现此漏洞时通知了Google，并在无响应后于4月再次通知了Google。根据Kreb的帖子，Young在5月向谷歌报告了这个漏洞并且他的请求以「状态：不会修复（预期行为）」为由被关闭了。 直到Krebs自己联系谷歌，他们才同意修补漏洞。 预计谷歌将于2018年7月中旬发布补丁。
Sonos Wifi 扬声器
与Google Home一样，Sonos WiFi扬声器也可以由远程攻击者（CVE-2018-11316）控制。 通过打开错误的链接，你会发现令人愉快的夜晚爵士乐播放列表，会突然被非常不同的内容所打断。 对于简单的恶作剧来说这很有趣，但最终还是无害的，对吗？
经过一番挖掘后，我在Sonos UPnP网路伺服器上发现了一些其他有趣的链接，这些链接可能并不那么无辜。 看来设备上可以访问几个隐藏的网页以进行调试。
http://192.168.1.76:1400/support/review提供的XML文件似乎包含在Sonos设备上运行的几个Unix命令的输出（它本身似乎运行在一个Linux发行版系统上）。
http://192.168.1.76:1400/tools提供了一个简单的HTML表单，让你自己在Sonos设备上运行一些这些Unix命令！ Sonos HTTP API允许远程攻击者使用traceroute命令映射内部和外部网路，并使用简单的POST请求通过ping使用ICMP请求探测主机。 攻击者可以使用Sonos设备作为枢轴点来收集有用的网路拓扑和连接信息，以用于后续攻击。
更新（06/19/2018）：Sonos已发布声明并公开表示; 「在了解DNS重绑定攻击后，我们立即开始研究并将在7月软体更新中推出修复程序。」
Roku
有趣的是，它还允许直接控制按钮和按键，如虚拟遥控器，以及多个感测器的输入，包括加速度计，方向感测器，陀螺仪甚至磁力计（为什么？）正如你可能已经猜到的，这个本地API 不需要身份验证，可以通过DNS重新绑定（CVE-2018-11314）进行攻击。
我向Roku安全团队报告了这些调查结果，他们最初回复说：「使用此API对我们客户的帐户或Roku平台没有安全风险...我们知道可以载入到浏览器中并用于与Roku交互的http://remoku.tv等网路应用程序位于同一个本地网路。「
在描述了一个详细的攻击场景之后，公司的一名安全副总裁澄清说他们的团队确实「认为这是一个有效的威胁，而且至少不是平凡的。」为了团队的信誉，他们立即停止了Roku OS 8.1的发布。 并开始开发一个补丁，如果他们找不到及时发布的解决方案，他们预计可能仍需要3-4个月。
经过一番考虑后，我告诉团队我正在和WIRED的记者一起工作，我们很可能会快速发布研究报告。 第二天早上，我收到了团队的一封电子邮件，说明已经开发了一个补丁，并且已经通过固件更新推送到超过2000万台设备！
更新（06/19/2018）：Roku已发布声明以及此公示; 「在最近意识到DNS重新绑定问题之后，我们创建了一个软体补丁，现在正在向客户推出。 请注意，对此漏洞的任何潜在利用都不会对我们客户的帐户，渠道合作伙伴的内容安全或Roku平台造成安全风险。」
Radio恒温器
Trustwave SpiderLabs的Daniel Crowley试图多次联系该供应商，然后在听不到该公司的回应后最终发布该漏洞。 不幸的是，这种缺乏响应是多年来漏洞披露的反复出现的主题，特别是对于较小的制造商而言。 我预计这个漏洞未修补五年的可能性实际上很高，所以我购买了一台全新的CT50。
这个假设被证明是正确的，并且恒温器的控制API为DNS重新绑定恶作剧留下了大门。 如果你的建筑物的恒温器可以由远程攻击者控制，那么可能会发生的损害非常明显。
http://rebind.network上的PoC在将目标温度设置为95°F之前从恒温器中泄漏了一些基本信息。
在夏季，对于老年人或残疾人来说，这个温度可能是危险的，甚至是致命的。 更不用说如果你的设备在你度假时成为攻击目标，你可以回到家里去付一大笔公用事业账单。
这个漏洞的严重性，以及美国Radio恒温器公司多年来一直无视此漏洞，是我们为什么需要对物联网设备进行安全监管的完美例子。
无线路由器
如果你还一直在阅读这篇文章，你可能已经开始考虑家庭网路上可能会被攻击的其他设备。 你是否会惊讶地发现，从历史上看，网路路由器本身是DNS重绑定攻击的最常见目标之一？ 可能不会。
那是因为网路路由器拥有王国的钥匙。 拥有路由器，你就拥有网路。 我通过DNS重绑定看到了两种常见的攻击媒介：
将默认登陆账户通过POST发送到登录页面，如http://192.168.1.1/login作为自己的路由器管理员页面。 一旦攻击者通过身份验证，他们就可以完全控制设备，并可以随意配置网路。
通过UPnP使用路由器的Internet网关设备（IGD）介面来配置永久埠转发连接，并将网路上的任意UDP和TCP埠暴露给公共Internet。
第一种攻击方式是非常基础的。 许多路由器都附带默认登录账户，消费者从不更改它们。 当然，也许他们会启用WPA2并设置WiFi密码，但我敢打赌他们中的许多人都没有意识到他们的路由器的配置面板仍然可以使用「admin：admin」被网路上任何人访问。
第二种攻击更糟糕，是彻头彻尾的讽刺。 不知何故，在这个时代，大多数品牌主打的新家用路由器仍配备默认启用的UPnP伺服器。 这些UPnP伺服器通过HTTP为网路上任何未经身份验证的计算机提供类似管理员的路由器配置控制。
网路上的任何机器或通过DNS重绑定的公共Internet都可以使用IGD / UPnP配置路由器的DNS伺服器，添加和删除NAT和WAN埠映射，查看网路上发送/接收的位元组数，以及访问 路由器的公共IP地址（有关更多信息，请访问http://upnp-hacks.org）。
针对路由器的UPnP伺服器的DNS重新绑定攻击可以在受害者的防火墙中打一个洞，留下永久入口点，对网路上的设备执行原始TCP和UDP攻击，而不受DNS重新绑定攻击的正常HTTP限制的约束。
他们甚至可以配置埠转发规则，将流量转发到Internet上的外部IP地址，允许攻击者将受害者的路由器添加为受感染路由器的大型网路中的节点，可用于避开当局的审计（请参阅Akamai最近的 UPnProxy研究）。
IGD还提供了一个通过简单的未经身份验证的HTTP请求来发现路由器的公共IP地址的介面。 此功能与DNS重绑定相结合，可用于对试图通过VPN或使用TOR屏蔽其公共IP地址的用户进行去匿名化。
根据我的经验，路由器对DNS重绑定的漏洞是一个混合包。 我已经看到有路由器可以实现完全阻止DNS重绑定攻击，随机化其UPnP伺服器埠以使发现和攻击更加困难，但同时也有对攻击完全开放的路由器。 我应该提一下，到目前为止，我基本上没有将DNS重绑定研究应用到路由器......主要是因为我几乎不敢看。
内网是避风港的想法是一个谎言
今天如此多的设备如何容易受到十年前的攻击？ 这可能有比我能解释的更多的理由，但我愿意在其中两个上赌钱。
你必须在云中启动恶意DNS伺服器，编写针对特定服务的一些自定义JavaScript有效载荷，将其提供给目标网路上的受害者，然后找出如何使用其Web浏览器转移到运行的目标计算机 那个服务，你可能不知道的IP地址。 有开销，而且容易出错。 （我已经写了一些工具来缓解一些痛苦。以后会提出更多信息......）
我们需要开发人员在开发软体时，将本地专用网路视为恶意公共网路。
即使DNS重绑定在网路安全社区中变得越来越流行，这并不能保证我们会看到易受攻击的设备数量大幅下降。那是因为安全人员不是那些实现这些API的人，而是Web开发人员。当然，Web开发人员应该知道面向外部的API端点需要某种授权，但人们普遍认为私有网路本身可用于保护面向内部网的API。
本地API始终将信任和安全性托付到专用网路本身。如果你的路由器拥有它，为什么你的本地REST API需要授权？像UPnP这样的整个协议都围绕著同一网路上的设备可以相互信任的想法而构建。这是问题的根源。
我们需要开发人员在开发软体时，将本地专用网路视为恶意公共网路。本地网路是一个避风港的想法是一种谬论。如果我们继续相信它，人们会受到伤害。
防止DNS重绑定攻击消费者
作为产品或服务的用户，你经常受制于构建它的人的摆布。幸运的是，在DNS重新绑定的情况下，只要你可以更改路由器的配置，就可以控制保护网路。 OpenDNS Home是一种免费的DNS服务，可配置为过滤DNS响应中的私有IP范围等可疑IP地址。你应该能够将路由器使用的DNS伺服器从默认ISP的DNS伺服器更改为路由器设置中的OpenDNS Home DNS伺服器之一。
如果你希望在路由器本身上控制此过滤而不是信任像OpenDNS这样的公共DNS伺服器来执行此操作，则可以使用Dnsmasq或选择在路由器本身上安装libre路由器固件（如DD-RT）。如果你可以控制路由器，这些解决方案中的任何一个都是足够的，但请注意，因为无论何时你处于未明确配置以防止它们的网路上，你仍可能成为DNS重新绑定攻击的目标。
开发者
如果你是开发人员，或者参与创建具有HTTP API的产品，则可以采取一些措施来保护其免受DNS重绑定攻击。有三种简单的解决方案可供选择。
第一个，也是最简单的实现，对于你现有的系统也没有副作用，是向你的HTTP伺服器添加「主机」标头验证。此标头包含在从现代浏览器发送的所有HTTP请求中，它包含期望与之通信的伺服器的主机（主机名：埠）。此值可以是域名或IP地址，但无论哪种方式，接收请求的伺服器都应验证其自己的主机是否与所请求的主机匹配。
由于DNS重新绑定依赖于与域名关联的基础IP地址的更改，重绑定到目标服务的恶意HTTP请求中的Host头会保持原始的域名。对路由器登录页面的恶意POST请求将具有与你在路由器上的主机名或IP地址不匹配的主机标头值。它看起来像Host：malicious.website。
Web伺服器应验证所请求的Host标头是否与其预期值完全匹配，如果不满足，则使用403 Forbidden HTTP状态代码进行响应。我已经为Express.js Web伺服器编写了一个NPM模块，但在任何Web伺服器或语言中都应该很容易实现。
破坏DNS重绑定攻击的另一种有效方法是使用HTTPS而不是HTTP，即使对于本地网路连接也是如此。发生重新绑定时，目标服务将具有对malicious.website无效的SSL证书，因此安全警告将阻止请求到达你的API端点。
此解决方案还为你的用户提供额外的隐私和安全性，以及TLS / SSL带来的常见好处。供应商历来回避使用自己的TLS / SSL证书来加固物联网设备的安全性，但Plex媒体伺服器软体通过实际使用DNS重绑定来颁发证书并保护其客户，以有趣的方式解决了这个问题！
可能最好的解决方案是在你的API中添加某种形式的用户身份验证，尽管这种解决方案可能会对你现有的服务造成最大的破坏。如果你的API控制真实世界的功能或提供对敏感信息的访问，则只有选择方才能访问它。
它不应该是整个专用网路，因此也不应该通过DNS重新绑定访问公共Internet。绝对没有理由认为WiFi网路上的任何设备应该能够任意控制建筑物中的温度。人们忘记破解WPA2 WiFi是多么容易。
工具和细节
为了帮助传播DNS重绑定攻击的意识，我构建了其他人可以用来创建自己的DNS重绑定攻击的工具和库。 除了针对特定设备或服务编写的JavaScript有效负载之外，交付该有效负载，与恶意DNS伺服器交互以及枚举受害者专用网路上的主机的过程在不同的攻击目标之间几乎相同。 为了降低进入门槛以了解和执行DNS重绑定攻击，我已经开源了：
一个名为whonow的「恶意」DNS伺服器
一个名为DNS rebind toolkit的前端JavaScript库
Whonow DNS伺服器
Whonow是一个自定义DNS伺服器，允许你使用域请求本身动态指定DNS响应和重新绑定规则。 这是一个如何工作的例子：
如果你愿意，可以立即尝试，只需使用dig查询公共whonow实例。 它响应对* rebind.network域名的请求。
DNS Rebind Toolkit是一个实用程序库，可自动执行DNS重绑定攻击的过程。 一旦你编写了一个JavaScript有效载荷来定位特定服务，DNS Rebind Toolkit就可以帮助你在受害者的网路上部署该攻击。
使用WebRTC IP地址泄漏来发现受害者的本地IP地址。
可以自动执行网路子网枚举，这样即使你不知道专用网路上的IP地址，也可以定位设备。
自动化攻击的DNS重新绑定部分。 你得到一个Promise，一旦重新绑定完成就会解决。
在幕后使用whonow，因此你不必担心DNS重新绑定攻击的DNS伺服器组件。
带有几个用于攻击常见物联网设备的有效负载和记录良好的示例，以便你学会编写自己的漏洞。
在192.168.1.1/24子网上启动对Google Home设备的攻击就像在index.html页面中嵌入代码段一样简单。
每个iframe都使用以下JavaScript代码段嵌入有效内容/ google-home.html：
链接和感谢
感谢Lily Hay Newman与我进行了三个月的对话，及她在WIRED中对这项研究进行了报道。 非常感谢William Robertson对这项工作的帮助，特别是让我攻击他的家庭网路 和Sonos设备。 我还要感谢Roku和Sonos的安全团队在开发和部署固件更新方面的迅速反应，以保护他们的用户免受DNS重绑定攻击。
以下是我在研究中发现有用的DNS重绑定资源的集合。 你可能也会从中得到帮助！
斯坦福大学的原始DNS重绑定研究（2007年）
https://crypto.stanford.edu/dns/
与Robert RSnake Hansen进行DNS重绑定（精彩视频）https://www.youtube.com/watch?v=FIQGKIE3Fv0
·
CORS, the Frontendian
https://frontendian.co/cors
Luke Young的DEFCON 25「实现可靠的DNS重新绑定」讲座
https://www.youtube.com/watch?v=Q0JG_eKLcws
·
Ricky Lawshae的DEFCON 19 SOAP和UPnP讲座
https://www.youtube.com/watch?v=dT0b5DWq9b8
UPnP Hacks网站
http://www.upnp-hacks.org/upnp.html
亲爱的开发人员，谨防DNS重绑定
https://www.twistlock.com/2018/02/28/dear-developers-beware-dns-rebinding/
DNS重绑定的实际攻击
https://www.tripwire.com/state-of-security/vert/practical-attacks-dns-rebinding/
由Tavis Ormandy撰写的原始暴雪游戏的DNS重绑定错误报告
https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=2
翻译链接：https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
编译：看雪翻译小组 一壶葱茜
校对：看雪翻译小组
原文作者：一壶葱茜
原文链接：https://bbs.pediy.com/thread-230047.htm
编译：看雪翻译小组 一壶葱茜
校对：看雪翻译小组 SpearMint
更多阅读：
1、[原创]关于android 微信 frida 使用技巧
2、[原创]Hook原理
3、[翻译]一次红队之旅
4、[原创]逆向及修复最新iOS版少数派客户端的闪退 bug
5、[原创]逆向分析及修复稀土掘金iOS版客户端闪退 bug
推荐阅读：
