整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

恶意JavaScript注入活动感染了51000个网

恶意JavaScript注入活动感染了51000个网站

语:Unit 42的研究人员一直在跟踪一起大范围的恶意JavaScript(JS)注入活动,该活动将受害者重定向到广告软件和欺骗页面等恶意内容。这一威胁在2022年全年都很活跃,并在2023年继续感染众多网站。

Unit 42的研究人员一直在跟踪一起大范围的恶意JavaScript(JS)注入活动,该活动将受害者重定向到广告软件和欺骗页面等恶意内容。这一威胁在2022年全年都很活跃,并在2023年继续感染众多网站。

我们在51000多个网站上检测到了注入的JS代码,包括跻身Tranco前100万个网站排行榜的数百个网站。受影响的网站出现在Tranco中表明,这起活动可能影响了大量的人。

我们还发现,这起活动是多方面的,因为它在重定向到恶意网页之前执行多步注入,并使用混淆和良性附加攻击来绕过检测机制。恶意软件编写者利用这些技术将恶意JS代码样本的多种变体注入到网站中。

我们新颖的对抗性深度学习技术无罪推定(IUPG)检测到了注入的JS代码的多种变体。该模型是我们下一代防火墙产品的高级URL过滤(AUF)订阅服务的一部分。它可以检测恶意JS样本,并可以对来自内联保护和我们离线爬虫的内容进行分类,内联保护可对防火墙上的流量进行实时分析。

具体活动和用户影响

我们已经检测到攻击者将恶意JS代码注入到网站的活动的多种形式。这种注入的代码将受害者重定向到各种恶意内容,比如广告软件和骗局。

研究人员去年报道了一起类似的活动。我们在2020年观察到了该活动的第一例。然而,我们将侧重介绍在2022年1月至2023年期间跟踪的这起活动的最新变体。

自2022年初以来,我们在来自51000个主机名的大约170000个URL上检测到了这起活动。如图1所示,该活动在过去一年保持活跃状态,并在2023年继续影响网站。这起活动在2022年5月至8月期间达到了顶峰,当时我们看到平均每天有4000个URL中招。

图1. 该图显示了整个2022年和2023年初的活动,在2022年5月至8月之间达到顶峰

我们怀疑这起活动影响了大量的人,因为在撰写本文时,数百个受感染的网站跻身Tranco的前100万网站排行榜。在2023年1月期间,我们在14773个设备上拦截了来自这些网站的约240000次会话。

JS注入的例子

这起恶意JS注入活动使用各种技术来绕过检测机制,比如混淆、向大型良性文件附加代码和多步注入。我们将介绍恶意JS代码的几个例子,活动背后的不法分子对这些代码进行混淆处理,并隐藏在更庞大的JS文件中。我们还将介绍一个例子,其中恶意软件在最终加载恶意载荷之前执行一系列的JS注入。

混淆

图2a、b和c显示了活动中经常检测到的JS片段例子。在所有这些例子中,注入的JS代码都经过混淆处理,以隐藏恶意载荷从而绕过检测。具体来说,这种经过混淆处理的代码隐藏了用于加载恶意JS的外部URL。代码还包括向文档对象模型(DOM)动态添加恶意JS的行为。

比如说,下面的前两个JS代码片段(图2a和图b)使用String.fromCharCode隐藏了指向恶意JS的链接,这是一种常见的混淆技术。图2c显示了混淆的另一个例子。经过混淆处理的代码显示在左边,经过去混淆处理的代码显示在右边。通过使用variable _0xfcc4中的十六进制表示来混淆函数调用的名称(比如fromCharCode)。

图2 a. 使用String.fromCharCode隐藏恶意JS链接的例子

图2 b. 使用String.fromCharCode隐藏恶意JS链接的例子

图2 c. 隐藏函数调用名称的例子。图像的左侧显示了如何使用variable _0xfcc4中的十六进制表示来混淆函数调用。图像的右侧显示了去混淆后的函数调用fromCharCode

将JS代码附加到大文件中

我们在一些网站上发现了这些经过混淆处理的JS片段被注入到常见实用程序JS文件(比如jQuery)中的例子。恶意软件编写者经常使用这一招将恶意代码附加到大块的良性代码中,这又叫良性附加攻击。这种技术可以帮助恶意软件编写者逃避安全爬虫的检测机制。

多步JS注入

在所有JS代码片段中注入的JS代码(如图2a、b和c所示)通过操纵DOM附加外部恶意JS代码。这使攻击者能够改变恶意载荷。

这起活动最近的一种变体是将恶意JS代码注入到网站。然后它执行一系列中间JS注入,之后加载将受害者重定向到恶意网页的恶意载荷。

在图3显示的例子中,每个注入的JS代码在投放恶意载荷之前依次执行来自另一个网站的JS代码。包含来自不同网站的JS注入的一个原因可能是,攻击者想要不断改变加载最终载荷的URL,以防加载JS的URL被安全爬虫列入黑名单。

图3. 这个例子表明网站上的脚本注入在最终加载重定向到恶意网页的恶意载荷之前执行一系列中间脚本注入

重定向到恶意内容

最终的恶意载荷将用户重定向到不同的网站,然后登录到最终的网页,这通常是广告软件或欺骗页面。比如说,访客可能被重定向到一个虚假的通知欺骗页面,如图4a所示。在这个页面上,人们会看到欺骗性内容,引诱他们允许由攻击者控制的网站发送浏览器通知。

图4. 显示虚假的验证码图像,是为了引诱人们允许网站发送通知

在另一个例子中,如图4b所示,最终的恶意网页显示了来自知名视频共享平台的模仿页面的虚假警告这种形式的欺骗性内容。这些欺骗性内容会诱使人们下载虚假浏览器。

图4 b. 显示了知名视频共享平台的模仿页面以及虚假警告,诱使人们下载虚假浏览器

JS如何被注入到网站上?

Unit 42的研究人员怀疑,由于一个或多个易受攻击的内容管理系统(CMS)插件,大量网站可能会遭到攻击。Sucuri公司的研究人员曾报告了一起类似的活动利用CMS插件(详见https://blog.sucuri.net/2022/05/massive-wordpress-javascript-injection-campaign-redirects-to-ads.html)。我们还发现,检测到的网站(共51000个)中估计四分之三使用流行的CMS。

在一半以上被检测到的网站的主页上都包含注入的恶意JS代码。活动攻击者采用的一种常见策略是向经常使用的JS文件名(比如jQuery)注入恶意JS代码,它们可能被包含在中招网站的主页上。这可能帮助攻击者锁定网站的合法用户,因为他们更有可能访问网站的主页。

利用深度学习检测恶意JS注入

恶意软件编写者为这起活动设计了恶意JS代码的不同变体,将其注入到网站中。众所周知,深度学习技术在检测同一攻击的不同变体方面功能很强大。因此,深度学习技术可以提高恶意JS注入的检出率。

深度学习技术还可以抵抗来自恶意软件的对抗性逃避活动。这些类型的对抗性逃避的一个具体例子是普遍存在的黑盒对抗性威胁,即良性附加攻击。

结论

在2022年至2023年初期间,在51000多个网站上检测到了一起广泛的恶意JavaScript注入活动。我们发现恶意软件编写者对恶意JS进行混淆处理以绕过检测机制,并在重定向到恶意网页之前执行多步注入。

注入的JS代码可能影响了大量互联网用户,因为数百个受感染的网站跻身Tranco前100万网站排行榜。我们建议网站所有者和客户及时更新第三方插件和软件,以保护他们的网站免受这类注入。

这起活动中注入的恶意JS代码是我们在外头看到的附加攻击的一个常见例子。正如我们在IEEE安全和隐私研讨会(SPW)上发表的IUPG模型研究工作中所解释的那样,IUPG模型的训练过程专门旨在识别和隔离良性内容背景中的恶意子模式。

我们的深度学习模型无罪推定(IUPG)检测到了注入恶意JS代码的多种变体。该模型是高级URL过滤云提供的安全服务(可检测恶意JS样本)的检测功能之一。它还可以对来自离线爬虫以及防火墙上流量的内联实时分析的内容进行分类。

使用高级URL过滤和DNS安全订阅的下一代防火墙让客户可以免受本文描述的恶意JS注入活动的已知URL和主机名。我们还提供了已知攻陷指链接(https://github.com/pan-unit42/iocs/blob/master/IOCs_MaliciousJS.txt),帮助对付本文中讨论的威胁。


翻译自:https://unit42.paloaltonetworks.com/malicious-javascript-injection/

from https://www.4hou.com/index.php/posts/GKy0

景说明

假设需要劫持http响应并在html页面中注入一段js代码后再传回浏览器,实现在浏览器出现一个弹框消息提醒。

由于原始html页面编码格式存在UTF-8、GBK等多种编码格式,如果注入的js包含中文消息的话,那么在UTF-8或GBK编码的页面就会有一个出现乱码。有没有办法做到不管是针对GBK、UTF-8编码的页面都能做到正常显示而不会出现乱码哪?

产生乱码的原因

首先来分析一下产生乱码的原因,我们在浏览器看到的信息都是通过图形学手段在显示器上呈现出来的,而实际保存在计算机硬件上的都是0和1(因为计算机实现是基于二进制),那么计算机要显示、传递信息就需要依靠一套规则把一串串的0和1识别为正确的字符,这就是编码。

例如01000001在ASCII编码规则下对应字母A。相同的0/1串,不同的编码解析出的字符一般是不同的,因此如果html页面按照UTF-8的编码解析正常,那么按照GBK的编码解析就会是乱码了。根据上面的示意图,假设注入的js代码为utf-8编码格式,而原始html编码格式也为UTF-8编码格式,那么最终注入这部分中的中文就能正常显示,但是如果原始html为GBK编码,那注入的这部分js代码的中文就会显示乱码。

解决办法

有一种unicode统一编码字符集,目标是把所有文字、字符统一编码,也就是一串0/1组合在unicode字符集下对应的字符是唯一的,不会存在歧义。而js是支持解析unicode字符的,那么就可以在注入js中把要显示的消息统一转换为unicode编码,浏览器端去解析这个unicode编码,这样不管原始html是UTF-8还是GBK,都能正常显示中文。

原始注入js代码关于中文字符的部分

// utf-8编码格式
let message="中文";

解决乱码的注入js代码关于中文字符的部分

// utf-8编码格式
let message="\\u4e2d\\u6587";  // 这个编码对应上面的message"中文"

注意:

  1. 注入的js代码仍然是utf-8编码格式,只是消息内容转换为unicode编码的形式;
  2. unicode中0x4e2d表示的0/1串对应汉字"中",0x6587对应的0/1串对应汉字"文";
  3. message其实也不是真正的unicode编码,它只是普通的字符串,只是使用了unicode对应的码点(也就是二进制对应的数值),因为可以利用这个码点在浏览器中恢复出正确的字符,事实上unicode字符集并没有规定具体的编码格式。

  • 最终产品代码中对错误的处理方式要比“垃圾进,垃圾出”复杂的多。
  • 防御式编程技术可以让错误更容易发现、更容易修改,并减少错误对产品代码的破坏。
  • 断言可以帮助人尽早发现错误,尤其是在大型系统和高可靠性的系统中,以及快速变化的代码中。
  • 关于如何处理错误输入的决策是一项关键的错误处理决策,也是一项关键的高层设计决策。
  • 异常提供了一种与代码正常流程角度不同错误处理手段。如果留心使用异常,它可以称为程序员们知识工具箱中的一项有益补充,同时也应该在异常和其他错误处理手段之间进行权衡比较。
  • 针对产品代码的限制并不适用于开发中的软件。你可以利用这一优势在开发中添加有助于更快地排查错误的代码。

核对表 (防御式编程)

一般事宜

  • 子程序是否保护自己免遭有害输入数据的破坏?
  • 你用断言来说明编程假定吗?其中包括了前条件和后条件吗?
  • 断言是否只是用来说明从不应该发生的情况?
  • 你是否在架构或高层设计中规定了一组特定的错误处理技术?
  • 你是否在架构或高层设计中规定了是让错误处理更倾向于健壮性还是正确性?
  • 你是否建立了隔栏来遏制错误可能造成的破坏?是否减少了其他需要关注错误处理的代码的数量?
  • 代码中用到的辅助调试的代码了吗?
  • 如果需要启用或禁用添加的辅助助手的话,是否无须大动干戈
  • 在防御式编程时引入的代码量是否适宜——既不过多,也不过少?
  • 你在开发阶段是否采用了进攻式编程来使错误难以被忽视?

异常

  • 你在项目中定义了一套标准化的异常处理方案吗
  • 是否考虑过异常之外的其他替代方案?
  • 如果可能的话,是否在局部处理了错误而不是把它当成一个异常抛到外部?
  • 代码中是否避免了在构造函数和析构函数中抛出异常?
  • 所有的异常是否都与抛出它们的子程序处于同一个抽象层次上?
  • 每个异常是否都包含了关于异常发生的所有背景信息?
  • 代码中是否没有使用空的catch语句?(或者如果使用空的catch语句确实很合适,那么明确说明了吗?)

安全事宜

  • 检查有害输入数据的代码是否也检查了故意的缓冲区溢出,SQL注入、HTML注入、整数溢出以及其他恶意输入数据?
  • 是否检查了所有的错误返回码?
  • 是否捕获了所有异常?
  • 出错消息中是否避免出现有助于攻击者攻入系统所需的信息

安全、断言、异常