Isolated and Exhausted: Attacking Operating Systems via Site Isolation in the Browser

0x00 摘要

（1）使用Site Isolation来创建fork bomb，来对计算机资源进行占用（以此可以进行OS资源耗尽攻击）。

（2） 使用WebRTC占用UDP端口。

​ 最终效果：借助（1）（2），来进行DNS缓存中毒攻击。

0x01 相关知识

• 什么是Site Isolation？

​ Site Isolation将不同的网站隔离到不同的进程中，即使其中一个网站的渲染进程受到攻击，攻击者也无法访问其他网站的信息，因为它们被隔离在不同的进程中。

• 什么是fork bomb？

​ Fork bomb通过不断复制自身来占用操作系统的资源，从而使系统停止响应。

• webrtc是什么？

​ Webrtc是一种浏览器技术，可以实现实时音频、视频与数据通信。

• 什么是DNS缓存攻击？

​ DNS缓存通常用于存储先前查询的DNS记录，以便加快未来相同查询的响应时间。攻击者利用DNS服务器未经身份验证的响应请求，将虚假信息存储在DNS缓存中。当用户请求该信息时，DNS服务器会返回已被篡改的信息，导致用户被重定向到恶意网站。

0x02 Site Isolation进行OS资源耗尽攻击的细节

​ Site Isolation使每个不同的网页都会有不同的进程。理论上，web浏览器能够任意分配许多资源，只需要打开好多好多页面即可。但实际上，可以自动打开的窗口的数量是有限制的，需要一个可信事件（例如，单击鼠标）才能获得打开更多资源的权限。

​ 那么，如何解决这个问题？我们引入了iframe的概念。

​ 如上图所示，a.com/1网页包含三个资源，分别为a.com/1，c.net和b.org，这是通过HTML的iframe标签完成的，iframe标签用于在网页中嵌入其他网页或文档。

1

<iframe src="URL" width="width" height="height"></iframe>

​ 因此，以上5个资源分配到5个进程中，其中a.com/1中的b.org与a.com/2中的b.org共用一个进程。

​ 那如何用Site Isolation来创建fork bomb呢？

1. 攻击者有N个IP地址。
2. 生成一个网页，本身包含一个iframe，其指向IP_1，在iframe标签里面是正常的html，里面又会有2个iframe，分别指向IP_2和IP_3，以此递归。

​ 最终，就会产生N个进程，从而耗尽CPU资源。

0x03 如何利用webRTC来占用UDP端口

​ 利用webrtc进行视频通信时，发送方要在本机分配一些端口，以发送视频信息以及建立连接所需要的数据。

​ WebRTC协议使用的端口数量可以是不固定的，因为它可以根据需要进行动态分配，这些端口包括传送音频视频数据的端口，以及建立连接时传送连接数据的端口。

​ 一个WebRTC对象指的是是通信双方的一个WebRTC连接，里面可以包含一个或多个数据通道。经研究发现，经研究发现，单个数据通道分配两个UDP端口。一个用于建立交互式连接，另一个用于进行数据传输。因此，WebRTC对象只能成对分配端口。

​ 注意：webrtc分配端口时，发送方与接收方并未连接，我们只是分配了端口，然后就停止了对webrtc的操作。

​ Chrome为每个WebRTC对象分配一个线程，如果对象很多，负载就很大。因此，为了减少负载，同时想要分配更多的UDP端口，我们就打算在一个WebRTC对象中分配多个数据通道。

0x04 如何有限的负载内占用尽可能多的端口

1. 利用Site Isolation，生成好多iframe，这些iframe对应N个IP，迭代的分配在www.evil.org中。
2. 对于每个iframe，建立好多WebRTC对象，直到系统说此页面的webrtc对象数量超出限制。
3. 对于每个webrtc对象，使用多个数据通道，这样就可以占用足够多的UDP端口。

​ 上述流程对于Chrome与Edge都可正常完成，但是FireFox不行，因为它无法做到：一个webRTC连接内包含多个数据通道，也就是第3步。

​ 注意，上述流程，只能占用偶数个端口。

0x05 进行DNS缓存攻击（大概流程）

​ 我们假设，UDP端口并不是随机分配的，而是顺序分配的。

​ 首先，要搞明白DNS请求与回复的具体流程？

1. 有一个域名bank.com，主机先查看自己的DNS缓存中有没有，如果有，直接访问对应IP，流程结束。
2. 如果没有，主机生成TXID（随机16比特），并生成TXID+(IP_dest,Port_dest,IP_src,Port_src)+'bank.com'，给DNS服务器，让DNS服务器查询bank.com对应的IP地址。
3. DNS服务器查询到对应地址后，生成TXID+(IP_dest,Port_dest,IP_src,Port_src)+ip地址，并返回给主机。
4. 主机验证TXID是不是之前发送的TXID，如果是，则保存bank.com:ip地址到DNS缓存中。否则，则进行重传（5次）。

​ 可以看到，我们要想进行DNS缓存攻击，即我们想要污染主机的DNS缓存，重点是：

1. 我们要知道主机的IP与请求端口，即IP_src,Port_src。
2. 我们要知道正确的TXID。

​ 假设我们已知主机的IP（IP_src），下面我们想要知道请求端口Port_src与TXID。

​ 如何知道Port_src？我们已知如何在有限的负载内占用尽可能多的端口，那么我们把端口全占了，只剩下几个空余的UDP端口（且我们已知这些空余端口），然后再进行DNS请求。

​ 如何知道TXID？一共16位，遍历不就得了。

0x06 进行DNS缓存（缓存中毒）攻击（细节）

​ 细节流程如下图所示：

​ 其中，Victim是受害者主机，DEMONS是我们的攻击程序，我们的目的是污染Victim的DNS缓存。

​ 攻击分为两个阶段：

阶段1：setup

1. 端口消耗。根据0x04流程，将主机端口几乎占用完，只剩下1个或者0个端口。
2. 释放。攻击者释放一个webRTC对象（这个对象占用两个UDP端口），将两个端口放回操作系统池，使这些端口空闲。

​ 具体而言，受害者访问www.evil.org，www.evil.org上有恶意的js脚本，受害者访问后会执行恶意的js代码，此代码的大概流程为：

（1）建立与Poisoner双向通信的WebSocket，这用于在setup阶段结束时向Poisoner发送DNS查询端口。

（2）使用大量WebRTC对象，通过端口消耗和释放流程分配几乎所有临时UDP端口，其中空闲的端口至多为3个。

（3）通过WebSocket将端口发给Poisoner。

阶段2：Poisoning

（1）Poisoner发送一系列DNS响应TXID+(IP_dest,Port_dest,IP_src,Port_src)+恶意ip地址，其中遍历TXID，持续一段时间。

（2）主机运行js恶意代码到XMLHttpRequest，来访问bank.com，从而触发主机对bank.com的DNS请求。

（3）主机收到正常DNS服务器与Poisoner发来的DNS响应。注意：当主机收到不正确TXID的响应时，会发生重传（不超过5次）。

（4）如果主机访问了恶意Ip地址，说明污染成功。

​ 为了获得提高中毒可能性，重复（1）（2）（3）（4），最终成功率36%。