在本周末，很多企业的网络安全人员正忙得不可开交。Log4j漏洞出现了另外一种攻击载体，它通过使用底层的Javascript WebSocket连接，通过驱动式的破坏，在本地服务器上触发远程代码执行(RCE)漏洞进行攻击。
换句话说，攻击者可以利用漏洞攻击那些并不暴露于任何网络内部系统中的以localhost运行的服务。
Blumira公司的研究人员指出，这一发现推翻了Log4Shell攻击仅限于暴露的有漏洞的网络服务器的说法。
研究人员在周五的评论中说："这个最新攻击载体的出现意味着任何使用有漏洞的Log4j版本的用户都可以通过他们机器上的监听服务器的路径，或通过浏览本地网络从而触发该漏洞。”
这意味着还有更多新的恶意攻击方式的存在，而不仅仅是通过使用一行代码来获得一个shell，从而在面向互联网的服务器上投放恶意软件进行攻击。
利用WebSockets进行攻击
WebSockets实现了网络浏览器和网络应用之间的通信，如网站上的聊天和各种警报。它们通常会允许浏览器向这些类型的应用程序发送数据，但它们也常被用于主机指纹识别和端口扫描。
研究人员在帖子中解释说，WebSockets同样也充满了各种安全风险。WebSockets不像普通的跨域HTTP请求那样受到同源策略的限制。他解释说："它们期望服务器本身能够验证请求的来源。虽然它们有时候很有用，但它们也引入了相当多的风险，因为没有任何安全控制来限制它们的使用。"
在Log4j的案例中，攻击者将通过WebSockets向可能含有漏洞的localhost或本地网络服务器发出恶意请求。但这些目标不一定是要暴露在互联网上。
BreachQuest的联合创始人兼首席技术官在电子邮件中说：" WebSockets以前曾被用来对内部系统进行端口扫描。企业应该及时对应用程序进行打补丁，并防止潜在的易受攻击的服务向外进行连接。"
Log4Shell的本地攻击场景
研究人员在帖子中对他的攻击概念证明(PoC)进行了详细的分解;下面是研究人员的解释。
第一步：在安装了含有Log4j2漏洞的服务器上，攻击者会通过WebSocket连接从浏览器触发一个文件路径的URL。Blumira在PoC中使用了一个基本的Javascript WebSocket连接，但研究人员指出，这不一定必须是localhost;WebSockets则允许连接到任何IP，这很容易在私有IP空间内进行利用。
第二步：当页面加载时，它将会启动一个本地WebSocket连接，连接到易受攻击的监听服务器上，并通过基于Java命名和目录接口(JNDI)连接字符串来连接出去。这种技术类似于WebSockets的本地主机端口扫描，用于主机的指纹识别。
第三步：一旦受害者的主机连接到本地服务或主机本身可访问的服务的开放端口，攻击者就可以在文件路径或参数中放置一个漏洞字符串。当这种情况发生时，含有漏洞的主机会和漏洞服务器进行连接，加载攻击者的类，并以java.exe为父进程来执行它。
漏洞的检测和处理
但是坏消息是，根据分析，这是一种很隐蔽的攻击方法。主机内的WebSocket连接可能很难进行深入的扫描，这也增加了这种攻击检测的复杂性。这是因为WebSocket在网页加载时会悄悄进行连接，客户端则没有方法进行直接控制。然而，安全研究人员指出，还是有一些方法来绕过这一点的。
为了检测可能存在的攻击，研究人员建议寻找".*/java.exe "被用作 "cmd.exe/powershell.exe "父进程的实例。
研究人员说："这样检查出来的可能是非常杂乱的"。最后，企业还应该确保他们设置了检测Cobalt Strike、TrickBot和相关常见攻击工具的设备。
研究人员指出，为了及时检测出本地环境中使用Log4j的地方，现在有公开可用的扫描脚本，
为了完全避免这些风险，企业应该尽快将所有的本地开发工作、内部应用程序和面向互联网的网络环境更新到Log4j 2.16，其中包括了任何自定义应用程序。
同时，用户也可以采用流量出口过滤的措施，这也可以限制在实际漏洞利用过程中所需的回调，还可以在不受信任的外部网站上使用NoScript Java拦截器等工具，避免Javascript触发WebSocket连接。
Netenrich公司的安全专家通过电子邮件说："这一消息确实意味着，依靠网络应用程序防火墙或其他网络防御系统不再是有效的攻击缓解措施。打补丁仍然是一个组织可以采取的唯一的步骤"。
本文翻译自：https://threatpost.com/new-log4shell-attack-vector-local-hosts/177128/如若转载，请注明原文地址。
