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