Berd's Playground

_(:з」∠)_

11/2
23:25
技术

Chrome 恶意拓展 ModHeader 分析笔记

0x00 前言

一些废话就不说了, 见 Chrome 恶意拓展 User-Agent Switcher 分析笔记

拓展ID: idgpnmonknjnojddfkpgkljpfnnfcklj

这次也是例行流量审查抓到的,拓展更新时间为 2020/10/31,还好没造成什么大危害

真是万圣节惊喜

0x01 恶意行为

代码提取就不赘述了,参见上一篇分析文章,这里直接分析拓展的恶意行为

首先我观察了一下拓展的行为,禁用拓展并重启 Chrome 后首次启用拓展会观察到网络连接,此时没有打开任何标签页,于是可以判定恶意代码位于背景视图中

一样的从 manifest.json 直接追进 Background Script,搜索恶意域名,发现拓展在一定条件下会尝试连接三个服务器,我们先不管条件来看看连接部分

连上服务器后,拓展发送了一个看似人畜无害的数据请求,只发了一些简单的拓展信息,很像在检查更新

但是我们追到下面的 r.onmessage 中就能看出一些不正常的行为了

首先拓展会从服务器接收指令,然后收到下发的指令后似乎可以发起请求以及停止这些请求,这看起来就已经很吓人了

让我们追进具体的逻辑看一下。在服务端的控制下,拓展可以向指定的 URL 带上指定的 Payload 发送一个 HTTP 请求,然后返回头会被第二个红框的部分进行处理,带上 (可能重定向过的) 最终 URL 信息

随后,Body 数据被传到下一个 Handler 里进行处理,在此处将所有信息发回给服务端

不过还好,由于带上了 mode: "cors",这整一套逻辑似乎只能进行不带本地凭据的 HTTP 请求,因此暂时没有严重的数据泄露风险

表面上看,这套逻辑带来的危害就是拓展用户会被当成一个代理服务器来利用,可能会给攻击者带来出售代理的收益。怎么说呢,比偷数据好很多吧…

但还需注意: 这个 mode: "cors" 是可以被服务端下发的 userParams 参数给覆盖的,所以仍然不能保证没有数据泄露。如果你也中招了,请尽快检查自己的各个账户是否有异常

此外,在特定条件下,攻击者可能通过这个代理入侵你的内网乃至部分企业的内网。这个拓展的用户应该绝大多数都是开发者,而不少开发者应该是有企业内网的访问权限的,仔细思考一下,说是 Malware 一点都不过分。

0x02 启用条件

分析完恶意行为,我们再回头看看启用条件

这段其实很简单,往上追引用可以看到读取了一个 proxyIsWork 的本地值,只要这个值不为 true 就会启用代理,这个应该是开发者自己留的禁用后门的开关。

0x03 继续深挖

深挖了一下,拓展的更新日志其实是有写这事的,并且隐私策略也有提示。使用拓展即同意加入 https://infatica.io/ 的 P2P 网络

众所周知,Chrome 拓展自动更新并不会给你弹什么更新日志更不会告诉你 Privacy Policy 有变动,甚至不会主动告知你更新过拓展。开发者不可能不清楚这一点,相反可能就在利用这一点。总之,先 Report Abuse 吧

V2EX 有人把 出问题的 Commit 找出来了(没想到还有 GitHub 仓库),感谢 @lp10

续集

作者马上更新了一段五分钟后初始化代理逃避检测的代码,你以为这样别人就抓不到了么

0x04 碎碎念

没想到我能在 10 天内从 Chrome 里抓出两个恶意拓展… 已经搞的我不敢再信任任何自动更新了

接下来要干的事大概就是把所有拓展都审一遍然后手动加载吧,绝对不会再用自动更新了

放假后希望能在 Chromium-EyeProtect 里加上拓展权限控制,或者禁用背景视图联网之类的。如果不行,大概只能把所有拓展都拆开手动加载了

另外我必须说一句: Google is Evil

Chrome 恶意拓展 ModHeader 分析笔记