介绍
在 Forcepoint,我们不断寻求改善我们产品所提供的防护。为此,我们经常研究不寻常或潜在新颖的攻击技术。最近的一个研究课题是从公网发起的针对 localhost 和内网的攻击。
虽然不是新的攻击,但在安全研究社区之外,恶意 JavaScript 可以攻击内网并不广为人知。在关于该主题的有限文档中,大多数资源是从 inter-protol(协议间)漏洞来描述 [1] [2],而我们的重点是 intra-protol(协议内部)的漏洞。我们发现没有一站式资源从协议内部攻击的角度去描述这种攻击,并且在白皮书中收集这些技术是为了填补关于这些攻击文档的空白,以及让被低估的攻击面受到关注。
由于浏览器默认可以访问 localhost 以及本地局域网,因此这些攻击可以绕过潜在的本地基于主机的防火墙以及企业/消费者外围防火墙。
恶意攻击者了解这些攻击,但防守者也需要被告知。除了描述攻击的技术细节之外,我们还将讨论检测和防范攻击的方法。
可疑行为:公网到局域网的连接
从恶意站点加载的 JavaScript 可以在许多情况下能够连接用户本地计算机(localhost)或其他内部主机上运行的服务。现代 Web 浏览器不能完全阻止使用受害者浏览器作为代理攻击内网。事实上,我们不仅可以让受害者浏览器在内部发送请求,而且我们还可以发现内部主机,进行有限端口扫描,进行服务指纹识别,最后我们甚至可以通过恶意 JavaScript 来攻击易受攻击的服务。
如果从公网获取的网页尝试访问未路由的 IP 地址(例如 localhost 或内部网络),则应将其视为可疑行为。通过我们的遥测技术,我们还没有发现过存在于公网上的良性网页需要连接到私有 IP 地址,我们也没有发现任何有效和合理的业务用例来做这样的事情。是否有必要允许公网上的网页连接到私有 IP 地址,而不是在某些边缘情况下,这是值得怀疑的。一个边缘情况可能是在内部网络上使用公共 IP 地址的不常见设置。(但必须允许相反的方向的情况,因为许多内部页面可能出于完全正当的原因而获取外部资源。)
这种可疑行为与攻击链的各个部分一起具有某些特征,可以用于检测目的建模。我们稍后将回到更详细的关于检测的讨论,因为如果我们先了解攻击链的技术细节,检测就更有意义了。
在进行威胁建模时,开发者通常认为本地服务永远不会接收外部输入,因此通常缺乏对这些服务的安全审核。可能通过远程托管的恶意 JavaScript 攻击易受攻击的本地服务的最新示例是 Logitech Options 应用开启易受攻击的 WebSocket 服务器 [3]。通过远程跨域 JavaScript 进行的本地攻击代表了一种被低估的攻击面。
同源策略不会阻止本地攻击吗?
实际上,同源策略(SOP)[4]在很多情况下确实可以防范这种攻击,但正如我们看到的,仍然存在攻击可能成功的情况。尽管有相关文档,通常被忽略的事实是同源策略并不会阻止浏览器发出跨域请求,它只能阻止 JavaScript 读取响应。(同源策略允许嵌入跨域资源,如图像和 JavaScript,但这是另外一方面的内容。)对于攻击某些易受攻击的服务,它可能足以能够盲目地发送恶意请求以达到攻击者的目的。
Mozilla 的文档很好地描述了同源策略的功能:允许跨域嵌入和写入,但不允许读取。允许跨域写入的事实使得可能执行以下攻击:
受害者在互联网上浏览恶意页面。页面上的 JavaScript 根据同源策略向不应与之通信的内部服务器发出异步请求(XMLHttpRequest)。
然而,浏览器将发送请求(此时服务器被利用)。
浏览器收到响应但不会将其传递给 JavaScript。
那跨域资源共享呢?
我们要展示的攻击与跨域资源共享(CORS) [5] 无关,只与同源策略相关。在本白皮书中,我们可以假设不允许跨域资源共享请求,这意味着我们拥有最严格的设置,其中同源策略“阻止”所有内容。即使面对同源策略,我们也可以进行攻击。
攻击概述
我们将看一下使用受害者的浏览器作为代理,外部站点上的 JavaScript 如何攻击运行在 localhost 或内网中的易受攻击的服务的示例。作为概述,我们将看看以下步骤:
侦察绕过同源策略的方法:查找受害者的私有 IP 地址,查找内部主机,查找开放端口,查找在开放端口上运行的服务。
从外部浏览内部网络的实际边缘情况是使用受害者的浏览器作为代理,同时同源策略生效。
对在 localhost 上运行的识别的服务进行攻击,使攻击者能够持久访问受害者的计算机。
近年来,已经设计出不同的攻击来对抗同源策略,例如 DNS 重新绑定 [6]。然而,在本文中,我们的重点将是在进行侦察时以及通过跨站点请求伪造(CSRF)利用时从 JavaScript 错误中推断信息。(本白皮书并不打算解释 CSRF 攻击的基础知识,我们将推荐其它资源给读者,例如 OWASP [7]。)
攻击内部服务存在一些先决条件:
服务需要驻留在 localhost 或内部网络上,并且可由受害者(例如本地局域网或企业网络通过 VPN)访问。
需要知道端口以及服务的 IP 地址或主机名,或者可以弄清楚。
该服务需要易受 CSRF(可预测的交易参数)的攻击。
如果服务需要身份验证,则受害者当前必须已经登录。
虽然侦察部分采用了相当普遍的技术,但通过 CSRF 的攻击将针对特定的应用程序或设备。因此,对于没有特定目标的攻击,攻击者的最佳选择是攻击一些常用的应用程序,或者家庭路由器。许多家用路由器都有 CSRF 漏洞,很少及时更新补丁,而且它们通常使用已知的静态 IP 地址 - 这些属性使它们易于定位。易受攻击的家庭路由器的例子可以在网上找到 [8]。
潜在的类似攻击
为简洁起见,我们仅阐述上述攻击,但我们还有许多其他攻击机会,例如:
通过 CSRF 更改受害者路由器的管理员密码,或更改路由器配置。
通过具有协议间漏洞的内部 SMTP 邮件服务器发送电子邮件。(需要额外的步骤来安装恶意浏览器扩展以禁用 SMTP 端口的黑名单。)
攻击组织内的易受攻击的设备(例如打印机)。
使用定时侧通道攻击(泄漏页面加载时间)进行盲跨域 SQL 注入。
如果 TOR 浏览器配置不安全,则允许与本地局域网通信,这可能会用于对用户进行去匿名化。可以对 TOR 用户的路由器进行 CSRF 攻击,使其对某些外部主机执行 ping 操作,从而显示公共 IP 地址。
协议间的漏洞
值得注意的是,由于协议间漏洞 [9] [10] [11],攻击机会不一定限于 HTTP/HTTPS 服务。由于不同的供应商有时会以不同的方式解释 RFC,因此协议通常会忽略错误。将 HTTP 的 POST 请求发送到不同的协议可能会导致其他服务忽略它不理解的 HTTP 头,并且只对有效负载起作用。
除了在讲述不同协议的服务上运行完全合法的命令之外,如果存在合适的漏洞,则可以利用该服务来获得任意代码执行(例如,通过缓存溢出)。虽然现代浏览器比旧版浏览器更不容易受到协议间漏洞的影响,但由于现代浏览器默认将其他协议的许多常见端口 [12] 列入黑名单,但仍允许使用很多端口。此外,通过恶意浏览器扩展,攻击者可以禁用任何端口的黑名单。可能受到协议间漏洞攻击的设备的一个例子是 WIFICAM 网络摄像机 [13],它具有易受攻击的 telnet 服务以及弱静态密码(通过浏览器绕过黑名单端口绕过来利用)。
侦察
为了利用某些东西,我们首先需要进行侦察来找出目标上易受攻击的目标。让我们看看如何解决同源策略相关问题。
找到受害者的内部 IP 地址
受害者的机器将始终回复 IP 地址 127.0.0.1,这对我们很有用。除此之外,了解受害者的机器在内网进行通信时使用的 IP 地址是有益的。原因是知道内部 IP 地址将允许我们对附近的其他主机进行更有针对性的搜索。
JavaScript 可以使用 WebRTC API 找出受害者的内部 IP 地址。 可以在 Ipcalf [14] 找到对此的概念证明。它不适用于浏览器和平台的所有组合,但这是在 Linux上 中运行 Chrome 时的样子:
图例 1: 使用 JavaScript 显示内部 IP 地址
通过恶意 JavaScript 实现的这种技术可能会将有关内部 IP 地址的信息发送给攻击者。
基于内网实现对其他主机的探测
在找到开放端口和可能易受攻击的服务之前,我们需要找出内网中存活的主机。为此,我们接下来将对内部 IP 地址和主机名进行探测。这对于即使非特定目标的攻击也非常有效。 请注意,在这个阶段我们只是猜测这些 IP 地址和主机名;稍后我们将通过技术验证我们的猜测是否正确。
消费者和低端企业网络设备(如 ADSL 调制解调器和路由器)的一些常见默认地址范围是 192.168.0.0/24,192.168.1.0/24 和 192.168.8.0/24。无论是在家庭还是在小型企业网络上,用户很可能位于其中一个子网中。
此外,许多低端 DHCP 服务器默认分配从八位字节开始的 IP 地址,因此有一个有根据的猜测是,我们可能会在地址 192.168.0.100-105 找到其他内部主机,对于上面列出的子网也是类似的。
较大的公司通常使用 172.16.0.0/24 或 10.0.0.0/24 作为子网网段,它们都有如此大的 IP 地址空间,只是猜测正确的 C 段地址可能不会有效果。对于攻击者来说幸运的是,上面提到的使用 JavaScript 公开受害者内部 IP 地址的方式将揭示正确的 C段地址。无论地址的最后八位字节可能在公司环境中,查看附近的八位字节对于攻击者来说可能是一个不错的选择。
默认情况下,路由器通常使用子网中最低的IP地址。例如,在 192.168.1.0/24 子网