Clash-verge-rev service提权漏洞浅浅复现一下

作用：可以让任意程序提权到system(Windows)、root(*nix系)
版本影响：截止本消息发布前的拥有 clash-verge-service的所有版本
建议：临时禁用clash-verge-service服务，直到项目组修复

某些还在坚持Clash for Windows(简称CFW)的守旧派不要沾沾自喜哦😋

替换旧版内核为新版mihomo内核可以继续使用，但是这仅限于不开启服务模式。

CFW的服务进程(clash-core-service)在某一次更新中对内核文件进行了签名校验。意味着一旦通过改名更换内核文件，将无法使用服务模式，因为更换之后的校验无法通过。

当然如果替换旧版的服务进程，自然是没有签名校验的，但是这个情况下也就和clash-verge-rev差不多了，依旧存在本地提权漏洞。

所以还是要及时更新科学上网的工具滴😷

晚点更新CFW的"漏洞"演示

随手录的

利用Clash for Windows(CFW)服务模式进程进行提权的概念验证演示

前提条件：

1. CFW服务进程不是最新版或较新版本，较新版本加入了对内核文件的签名校验

本演示在用的CFW版本为停更的最后一版(0.20.39)，此版本加入了签名校验，所以我找了一个未加入签名校验的版本进行替换，来演示早期CFW版本存在本地提权漏洞。cfw的作者在较新版本填补这个漏洞，所以用户无需担心

仅供娱乐，请勿较真


另外，如果大家想看绕过CFW针对内核文件进行签名校验的话，我可以单独出一期视频

Clash for Windows 的clash-core-service是服务模式的实现程序

其签名校验的验证逻辑如下：

1. 内核文件为clash-win64.exe，对应的签名文件为clash-win64.exe.sign

2. CFW服务进程通过开放HTTP API进行内核文件的启动管理

3. 开放的HTTP端口为53000
提供的接口有：
http://127.0.0.1:53000/start POST 启动内核进程
/stop GET 停止内核进程
/ping GET 确认接口是否存活，响应内容为“pong”
/command POST 可用来执行任意程序

4. 对/start和/command传进来的二进制路径中，对该路径所指向的文件进行sha256 hash

5. 将该 hash 用512位RSA私钥进行签名，然后进行 base64编码，得到签名字符串
6. 将该签名字符串与 对应文件名.sign 文件进行比对（比如文件名为clash.exe,那么就去找clash.exe.sign），如果正确才继续执行。
7. 自此验证逻辑结束

如果以上逻辑有不足之处，还望海涵

相关代码参考

今天稍微研究了下另一个Clash GUI —— clash-nyanpasu

项目地址：https://github.com/libnyanpasu/clash-nyanpasu

发现它的的服务模式也存在本地提权漏洞（目前仅测试Win），但是好在作者在源码作了TODO计划，说明发现了问题。另外，clash-nyanpasu默认不开启服务模式，普通用户无需担忧

漏洞产生原因：

nyanpasu-service 在 Windows 下使用了不安全的 SecurityDenoscriptor 配置 D:(A;;GA;;;WD)
这个配置允许所有用户（WD=Everyone）完全访问（GA=Generic All）
脚本可以利用这一点，以普通用户权限通过 Named Pipe 直接调用特权级 API

不过这个提权会比rev要麻烦一些，但依旧可以利用

subconverter目前有任意文件读取漏洞，想用的话先把它丢在docker里运行

提示: 这个利用非常简单

https://github.com/tindy2013/subconverter/issues/845

知名项目 Alist 疑似被收购

官网404且文档持续两周大改引社区质疑:

https://github.com/AlistGo/alist/issues/8649

后续回应:

https://news.1rj.ru/str/alist_news/85

🔔Koipy v1.12.0 发布包
⬆️更新日志:

1. 对Clash配置文件中的节点名称长度进行限制，过长的节点名称将被截断。这一限制是为了避免绘图内存占用过多。
2. 现在bot.strictMode 严格模式有了新的行为。当设置为true时，解析的Clash配置文件中的协议将启动白名单模式，只有实际支持的协议才会读取。
3. 更新geoip脚本，解决部分显示错误问题
4. 新增miaospeed:// URI scheme，用于快速对接一个临时本地后端，直接给bot发送前缀为 miaospeed:// 的URI，它会自动解析并临时创建一个临时后端，临时后端仅在bot运行期间有效。
5. 修复inivte按钮中的一些错误
6. 现在 /checkslaves 的结果支持显示后端版本

- 往期更新内容 -

v1.12.0-dev (2025-09-23)

1. 现在选择后端显示的是真延迟
2. 修复了一些指令参数的bug
3. 现在/test 里可以选择上行测试了
4. 为了保持向后兼容，现在支持上行测试必须在后端里指定 option.apiVersion=3 ，明确版本。

对应的miaospeed后端更新内容:
miaospeed v4.6.1
1. 🎉首次迎来了对上行速度测试的支持，
2. 上行速度测试对应的 MacroType 为: uspeed ，对应的 MatrixType有：

| MatrixType | 描述 | Macro |
|-|||
| USPEED_MAX | 最大上行速度 | uspeed |
| USPEED_AVERAGE | 平均上行速度 | uspeed |
| USPEED_PER_SECOND | 每秒上行速度 | uspeed |


3. 新的命令行启动参数： -upload ，可用于在此后端服务器上启用上行速度测试
4. 上行速度测试默认是禁用的，需要在启动时加入 -upload 参数启用
5. 将mihomo升级到 v1.19.13
6. 支持vless的 encryption 特性
7. 支持 AmneziaWG v1.5 特性
8. 旧版客户端兼容性优化
9. 现在Miaospeed项目主页有了新的样式：https://github.com/AirportR/miaospeed/blob/master/README.md

v1.12.0-dev(2025-09-10) - 更新内容

⚠️ 大版本更新，含有破坏兼容性的改动
1. 实验性地开始支持上行速度测试，使用 /uspeed 指令进行体验
2. 新的后端配置，前往配置文件示例 查阅 slave.option 相关配置
3. 现在绘图结果中的页脚里，上下行线程将分开显示

转眼间做这个的测速机器人项目已经超过3年了，从最初的毛胚迭代开发到现在已经进入标准生产环境，不禁感慨颇多。下面是一些开发的杂谈：

回过头来看，其中实现最难受的是“绘图模块”，如何把测试数据汇总成一张近乎完美的图，让我花费了不少时间，直到现在，绘图模块仍是维护的一大技术债。

其次就是任务调度，以及测试配置的构造。不同的人有不同的测试需求，比如有人只想测流媒体，有些人又要单线程，或者全都要。还要改测速链接，测延迟链接等等。如何把这些自然地摆在操作界面还是不少功夫的，好在做的是Telegram bot，如果选择做桌面端，估计又要头大。

其实我还有一些想法还没来得及实现，不过我现在也没有当初刚开发时的热情了，只能闲暇之余写写了😂

⚠️提示：这个项目一般不会停更，除非TG倒闭或者个人迫不得已的原因。
🔔预告：未来可能会做一个感谢墙，感谢各位朋友的赞助以及TG测速频道的大力支持

即将支持Sudoku 协议，不要在意速度（

现在类型一栏支持显示协议相关Logo了哦。

这些Logo大部分我都用代码重绘了

什么意思呢，就是没有任何的图片资源，用代码在内存里实时生成的