Apifox高危漏洞分析：SSH密钥与Git凭证泄露自查及安全修复指南

近期，一款主流的国产 API 协作平台 Apifox 被曝出存在高危安全漏洞。攻击者通过供应链攻击，篡改了其桌面客户端动态加载的外部 JavaScript 文件，可能导致用户的本地敏感信息被窃取。该事件主要影响在特定时间段内使用 Apifox 公网 SaaS 版桌面客户端的开发者。

根据官方公告，被植入的恶意脚本具备读取用户本地设备上高敏感文件的能力，例如 ~/.ssh/ 目录下的私钥、Shell 历史记录文件（.zsh_history， .bash_history）以及 Git 凭证文件（.git-credentials）等，并可能将数据外传到恶意域名 apifox.it.com。

对于依赖 SSH 密钥登录服务器、使用 Git 进行代码版本控制、通过跳板机或 VPN 访问内网环境的开发者与运维工程师而言，此漏洞威胁极大。一旦中招，可能直接导致服务器被非法登录、企业源代码仓库遭窃，甚至危及生产环境的安全。在 云栈社区 的安全板块中，我们经常讨论此类供应链攻击的防范措施。

本文将基于该漏洞的原理，提供一套可直接执行的自查命令，并针对不同风险场景给出详尽的安全整改方案，适用于 macOS 与 Windows 系统用户。

漏洞原理简述

该漏洞的本质是一次针对软件供应链的攻击。攻击者成功劫持了 Apifox 客户端从公网 CDN 加载的一个 JavaScript 文件，并注入了恶意代码。当用户运行受影响版本的客户端时，恶意代码会在后台静默执行，扫描并窃取本地存储的多种敏感凭证文件。

本地自查命令

如果你的 Apifox 版本在风险时间范围内，可以通过以下命令快速检查本地环境是否已受到感染。

1. 检查本地缓存中是否存在恶意代码特征

此命令用于在 Apifox 的本地缓存数据库中搜索恶意脚本留下的特定字符串。

macOS 终端命令：

grep -arlE "rl_mc|rl_headers" ~/Library/Application\ Support/Apifox/Local\ Storage/leveldb

Windows PowerShell 命令：

Select-String -Path "$env:APPDATA\apifox\Local Storage\leveldb\*" -Pattern "rl_mc","rl_headers" -List

结果解读：如果命令执行后没有任何输出，通常表示未检测到感染迹象。如果输出了具体的文件路径，则表明你的本地缓存可能已被污染，需要立即执行后续的整改步骤。

2. 检查系统日志中是否存在与恶意域名的连接记录

即使缓存被清理，也可以通过系统日志判断 Apifox 进程是否曾尝试连接恶意服务器。

macOS 终端命令：

sudo log show --predicate 'process == "Apifox" AND eventMessage contains "apifox.it.com"' --last 30d

Windows PowerShell 命令：

Get-WinEvent | Where-Object Message -match "apifox.it.com"

结果解读：查询结果为 0 条记录，意味着大概率没有发生数据外传。如果存在相关日志记录，则你的敏感文件很可能已经泄露。

3. 检查 Apifox 进程是否读取过敏感文件

此命令用于检查 Apifox 是否在后台访问过如 .ssh 或 git 相关的敏感路径。

macOS 终端命令：

sudo log show --predicate 'process == "Apifox" AND (eventMessage contains ".ssh" OR eventMessage contains "git")' --last 30d --info --debug

注意：部分开启了 SIP（系统完整性保护）的 macOS 系统可能无法捕获此类文件访问事件，这属于正常现象，不代表绝对安全。

安全整改与修复方案

根据你的具体使用场景，安全整改的紧急程度和范围有所不同。你可以参考以下流程进行操作。

场景 A：低风险场景
如果你的团队通过 L2TP/VPN + 跳板机登录服务器，本地不保存服务器私钥，且 Git 使用账号密码而非 SSH 密钥认证，那么漏洞直接获取服务器权限和内网渗透的风险较低。整改侧重客户端本身：

1. 立即升级：将 Apifox 客户端升级至官方修复版本 v2.8.19 或更高。
2. 清理缓存：完全退出 Apifox 后，删除其本地缓存目录。
   • macOS:

     rm -rf ~/Library/Application\ Support/Apifox/
     rm -rf ~/Library/Caches/Apifox/

3. 屏蔽恶意域名：在 hosts 文件中将恶意域名指向本地，防止任何可能的后续连接。

   echo "127.0.0.1 apifox.it.com" | sudo tee -a /etc/hosts

场景 B：高风险场景（必须严格执行）
如果你的开发环境是本地保存 .ssh 密钥直连服务器，且 Git 使用 SSH 或 Token 认证，或者 Shell 历史记录中包含过明文密码，那么你正处于高危状态。除了执行上述1-3步，还必须进行以下关键操作：

4. 强制轮换 SSH 密钥：这是防止服务器被入侵的核心步骤。

   cd ~/.ssh
   mkdir backup # 可选：备份旧密钥
   mv id_rsa* backup/
   ssh-keygen -t ed25519 # 生成更安全的新密钥对

   重要：生成新密钥后，需要将新的公钥（如 id_ed25519.pub）更新到所有相关平台：GitHub、GitLab、Gitee 等代码仓库，以及所有需要通过 SSH 密钥登录的跳板机、云服务器。

5. 撤销并更新所有 Git 凭证：

   • 登录你使用的所有 Git 平台（GitHub, GitLab, Gitee 等）。
   • 在账号的 Settings -> SSH and GPG keys 中，删除旧的 SSH 公钥，添加新生成的公钥。
   • 在 Settings -> Developer settings -> Personal access tokens 中，撤销（Revoke） 所有旧的 Token，并重新生成（Generate new token） 新的 Token。这直接关系到 运维 & 测试 流程中的代码安全。

6. 清理命令历史记录：清除可能包含敏感信息的 Shell 历史。

   > ~/.zsh_history
   > ~/.bash_history

7. 企业级额外审计（针对团队管理员）：

   • 审计 Git 平台近 30 天的账号登录与仓库克隆记录，排查异常。
   • 检查跳板机或服务器的登录日志，查看有无异常 IP 或时间点登录。
   • 为代码仓库强制启用双因素认证（2FA），提升账户安全等级。

总结与反思

本次 Apifox 漏洞事件再次为开发者工具的安全性问题敲响了警钟。其核心风险在于，被篡改的客户端能够无感读取并外传用户本机的核心隐私数据。对于企业团队或对数据安全有严格要求的环境，选择 支持私有化部署的 API 管理工具 是更稳妥的方案，确保所有数据（包括客户端加载的资源）都保留在内网环境中，从根本上杜绝因公网 CDN 被劫持而导致的供应链攻击。

作为开发者，我们除了及时应用补丁，更应建立起持续的安全意识，定期审计和更新本地存储的各类密钥与凭证。对于此次事件中涉及的 安全/渗透/逆向 技术细节与防范思路，也值得深入探讨。在 云栈社区 的技术论坛中，大家可以找到更多关于安全开发和漏洞防范的实践经验分享。