一、前言

大概是25号传出chrome在野漏洞利用的恶意样本,当即收到任务让分析一下,看看能不能复现到利用链,尽管我不太会这玩意,但没办法,只能硬着头皮逝一世了。

二、样本还原

样本拖回来看一眼先

可以看到对<script>部分进行了加密处理,粗略扫了一眼,先把这部分拖出来url解码一下,处理完后大概长这样:

嗯,看得出不够美观,拖过去格式化一下( https://tool.chinaz.com/tools/jsformat.aspx

映入眼帘的一大片16进制,两千多行代码粗略过了一遍,第一遍没怎么看得懂,大概就是在疯狂的各种自定义和混淆,然后看到一个EXP字符串,兴奋了起来,编码不多,手动挨着16进制解一下贴回去,处理完后:


然后跟一下这些字符串,看看是怎么定义的

等我照着全部捋完的时候,传来噩耗(我属实是个s*,为啥不先去百度下字符串)

没关系,再来,直接撸个脚本批量正则匹配hex内容并解码替换
(在这儿贴一份代码,如果有需要的师傅自取(代码写的丑,勿喷))

import re
import binascii

def unhex(s):
    str = s.replace('\\x','').replace(' ','').replace('\n','').replace('  ','')
    str_1 = binascii.unhexlify(str)
    return str_1.decode('utf-8')

f = open(r'F:\1.txt','r+')
ff = open(r'F:\2.txt','w+')
lines = f.readlines()
for line in lines:
    hex = re.findall(r"'(.*?)'",line)
    for i in range(len(hex)):
        line = line.replace(hex[i],unhex(hex[i]))
    ff.write(line)

进制全部处理完后发现还是有很多莫名其妙的字符串:
(其实这样做可能会误处理一些东西,但管不了这么多了,只想大概看看情况先)

说实话,很眼熟,看样子是某种混淆,一时间想不起来,后来经过多方查证发现是obfuscator混淆,好,跑github去处理一下(https://github.com/jscck/crack.js)

三、样本分析与结论

现在大部分代码已经比较清晰了,让我们看看到底在干嘛,还是先粗略扫一遍,发现两处有意思的地方。

最关心的当然是RCE,先跟一下这个字符串

在全文中就出现了两次,跟到这个位置看一下在干嘛,734行定义生成样式,rce字符串就在这里传入,然后在737行看到一个fetch请求(混淆的参数我在后面注释标注了)

跟进到_0x1fdaef,好家伙,就是这个url
(这行下面那个_0x51b全文就在这里出现了这一次,所以未作讨论,咱也不清楚为啥莫名其妙重新定义一次。。。)

再回过头去看,没有什么发现,下面又是一些混淆,到这里有点疑惑,感觉是在根据请求url来进行什么操作,而且名字叫about.asp,访问一下

emmm,这是没了吗。。。不急,再多看一下,

发现从180行开始,定义了一些信息,chrome version、target os,看起来是在收集目标信息,再联想到之前那个about.asp,大部分代码都是在请求此网站响应,于是通篇定位关键词、全局查找被混淆参数,最后分别定位到如下几处:

  1. 操作indexedDB数据库(1908-2081)

2.收集浏览器信息(2226-2381)

3.收集主机信息 (2385-2622)

(其实不仅是这些地方,这中间会跳各种混淆函数,但主体大致是集中在这些片段里)

然后结合这些代码再跟进到各个片段的混淆参数进行分析替换,尝试捋出代码逻辑。经过这些操作之后,其实到此我已经感觉这个样本应该是没有包含chrome rce的完整利用链,仅仅是在根据目标的各类信息来判断是否满足利用规则,如果匹配成功则通过漏洞利用的服务器再进行攻击。恶意载荷或许托管在请求的url中(举例):

后来在网上发现一位国外的师傅也与我的观点大致相同:

结语

当然,也可能是我自身学艺不精导致,本身确实对js不熟(加上混淆真的太严重了,一个混淆参数要跳好几个函数),或许确实存在利用链,只是我没有捋得出来,只能在此给各位师傅分享一下大致过程,含泪下播,溜了溜了。

点击收藏 | 5 关注 | 3
  • 动动手指,沙发就是你的了!
登录 后跟帖