TL博士
一组 PyPI 软件包借用了以下名称 uv使用快速且极其流行的基于 Rust 的 Python 包管理器伪装成 uv 助手。它们几乎没有任何实际功能。它们携带的只是一个 Windows 有效载荷,该载荷会启动一个 JupyterLab 服务器(已关闭身份验证) 在后续版本中,它会通过反向隧道将其发布到公共互联网上。
这就是全部故事,一句话概括: 以值得信赖的工具名称作为诱饵,以 JupyterLab 作为远程代码执行引擎。 Jupyter 服务器会运行你在 Jupyter 中输入的任何代码。ebook 一个使用空令牌启动并绑定到每个网络接口的单元是一个开放解释器,任何能够访问该端口的人都可以驱动它。
我们跟踪集群 仿紫外线所检查的两个软件包是: moon-uv (0.0.1-0.0.16)和 my-magic-uv-helper (0.0.1),由同一运营商发布,在分析时可在 PyPI 上运行。
| 生态系统 | 的PyPI |
moon-uv (0.0.1-0.0.16), my-magic-uv-helper (0.0.1) | |
| 平台目标 | Windows |
| 核心行为 | 未经身份验证的 JupyterLab 服务器,通过反向隧道发布到互联网。 |
| 合法工具被滥用 | uv、JupyterLab、Cloudflare、Pingly |
诱饵:一个你已经信任的名字
uv 是过去两年安装量最高的 Python 工具之一,因此,“一个辅助工具” uv“ ”是一个开发者会毫不犹豫地安装的软件包。FauxUV 的信誉完全建立在这个名字之上。这些软件包封装了 真正 uv Astral 的安装程序——有效载荷中的 URL 指向真实可靠的主机——因此只需快速浏览一下,就能看到所有可信的引用。实际上,这些软件包都不会添加任何内容。 uv 功能性;名称本身就是全部的伪装。
JupyterLab 作为 RCE 引擎
该有效载荷的核心是一个启动器,它会在启动 JupyterLab 时移除所有限制条件:
jupyter server --with jupyterlab --ip=0.0.0.0 # listen on every interface --ServerApp.token="" # no password, no token --allow_origin='*' # accept cross-origin connections --disable_check_xsrf # allow a remote browser/WebSocket to drive it 每个标记都会移除一层保护,而且附带的脚本甚至还对其进行了注释(原文为中文):空标记 “关闭密码和令牌检查——任何人都可以连接。” Jupyter实验室 是一个合法的数据科学集成开发环境,但并非ebook 单元格按设计执行任意代码。已按此方式配置并绑定到 0.0.0.0它不再是 IDE,而是变成了主机上未经身份验证的远程 shell——不需要自定义恶意软件二进制文件,只是一个指向错误方向的主流工具。
两个支撑因素使得这一切成为可能且可重复实现:
- 静默安装触发器。 早期版本运行 PowerShell -ExecutionPolicy Bypass 直接从 设置文件 on 点安装在后台运行,错误已被抑制。 点子 看起来很正常。后续版本将相同的基本元素移至 pip-uv 使用命令行工具——并完全取消安装时自动运行。
- 一条公共反向隧道。 服务器上 0.0.0.0 仍然只有能够路由到该机器的主机才能访问它。捆绑的模块打开一个 [Pinggy](https://pinggy.io/SSH反向隧道会将本地Jupyter端口转发到公共地址,从而解除端口限制。提供的脚本还包含一个备用路径(已注释掉),使用Cloudflare的服务。 Cloudflare 配备 的netsh 通过端口代理将端口转发到 Linode IP,通过不同的基础设施实现相同的目标。
综上所述:安装该软件包后,Windows 主机最终会运行一个无需密码的 JupyterLab 并将其发布到开放的互联网上。
FauxUV是如何演变的
FauxUV 的版本接连快速发布,有效载荷的触发点也随之移动——这提醒我们,一个标记的版本很少能完整地反映出一个软件包系列的情况。
| 阶段 | 选项 | 触发端口 | 它增加了什么 |
|---|---|---|---|
| 安装钩子 | moon-uv 0.0.1-0.0.3, my-magic-uv-helper 0.0.1 | setup.py 在 pip 安装中 | uv 安装 + PATH 前缀 |
| CLI运行时 | moon-uv 0.0.5-0.0.13 | pip-uv 命令 | 无需密码的 JupyterLab 启动器 |
| 隧道 | moon-uv 0.0.14-0.0.16 | pip-uv 命令 | 活跃的Pingy反向隧道 |
值得注意的是,安装时自动运行是 去除 在后来的、功能更强大的版本中——因此,扫描仪仅以生命周期为关键信息 hooks 会给新发行的版本打分 减 冒险,恰恰相反。
妥协指标
已通过阅读软件包源代码确认;端点已标记 评论 这些指标存在于文件中,但不会被分析版本执行。网络指标已被禁用。
| 类型 | 指示符 |
|---|---|
| 安装命令 | powershell -ExecutionPolicy Bypass 在 pip 安装时获取真正的 UV 安装程序 |
| JupyterLab 标志 | --ip=0.0.0.0 --ServerApp.token="" --allow_origin='*' --disable_check_xsrf |
| 反向隧道(已激活) | free[.]pinggy[.]io:443 本地转发 127.0.0.1:8888 |
| 隧道主机(已注释) | cloudflared tunnel --url hxxp://127[.]0[.]0[.]1:2718 |
| IP(已注释) | 45[.]79[.]134[.]161 (Linode)通过 netsh port-proxy |
| 坚持 | 准备 %USERPROFILE%\.local\bin 添加到用户路径 |
值得关注的行为信号,与这些具体字符串无关: 点安装 生成的 powershell -ExecutionPolicy Bypass; 任何 朱庇特 发射组合 token=”” - –ip=0.0.0.0;以及出站 SSH 到 *.pinggy.io 来自开发人员或 CI 服务器。
观察到的行为和来源
这两个软件包的作者和方法相同:它们都使用了一个可信工具的名称,仅限 Windows 系统,在后台执行并抑制错误,并且依赖于信誉良好的工具,因此只需快速查看即可发现所有 URL 都是可信的。源代码中包含中文注释,清晰地描述了与安全相关的标志;我们将其作为文件中可观察到的语句进行报告,而不是作为关于动机的断言。 允许来源 值和一个 colab.bat 文件名呼应了在 Google Colab 中流传的非正式“共享本地运行时”工作流程。无论其来源如何,打包后的结果都是一样的。
对防守者的影响和指导
谁会接触到 FauxUV? Windows 开发人员和 CI 运行人员 点安装 这些软件包之一。无需密码即可在 JupyterLab 上运行。 0.0.0.0 远程代码执行允许任何能够访问该端口的人执行;隧道则消除了“谁可以访问”的限制。服务器以安装用户的身份运行,并继承该用户的文件、令牌和云凭证。
为什么很容易错过它。 每个网络字符串都指向一个信誉良好的主机——Astral、JupyterLab、 CloudflarePinggy、Colab 等工具都无法做到这一点。这里既没有恶意软件二进制文件需要哈希处理,也没有混淆的数据块需要解码。基于信誉和基于特征码的扫描都低估了这一点,这就是为什么需要关注行为问题的原因—— 安装此软件包后,机器会做什么? ——就是那个抓住它的人。
指导:
- 处理任何安装时间 powershell -ExecutionPolicy Bypass 无论它获取的是哪个 URL,都会发出破坏构建的信号。
- 提醒 朱庇特 使用空令牌启动 –ip=0.0.0.0;这种组合绝对不应该出现在工作站或运行器上。
- 监控到隧道提供商的出站 SSH 连接(*.pinggy.io, *.trycloudflare.com来自开发人员和 CI 环境。
- 安装 uv 来自[其官方来源](https://docs.astral.sh/uv/)并且对那些包装了原本安装起来就很简单的工具的第三方“辅助”软件包持怀疑态度。
- 升级时锁定并重新审查依赖项——软件包系列可能会随着版本更新而增加新功能。



