HackerNews 编译，转载请注明出处： 网络安全公司Koi警告称，JavaScript生态系统主流包管理器（包括NPM、PNPM、VLT和Bun）存在的六项安全漏洞可能被利用来绕过供应链攻击防护机制。这些被统称为”PackageGate”的安全缺陷，可能导致攻击者隐藏在依赖包中的恶意代码被执行。 继Shai-Hulud和PhantomRaven等重大NPM供应链攻击事件后，各组织和开发者普遍采用两大防护机制：一是设置标志位阻止安装包时自动执行预装/安装/后装脚本；二是记录依赖树中每个包的版本及完整性哈希值，后续安装时进行哈希校验。 Koi指出，影响四大包管理器的六项PackageGate漏洞可绕过这些防护措施，实现完全远程代码执行（RCE），但各管理器的攻击手法存在差异： • NPM中可通过包含恶意.npmrc文件的Git依赖实现RCE • PNPM默认禁用的脚本防护仅适用于构建阶段，不适用于Git依赖处理 • VLT的压缩包解压操作存在路径遍历漏洞，可导致系统任意文件写入 • Bun的脚本执行白名单仅验证包名而非来源，攻击者可伪装合法包实现RCE 此外，Koi发现PNPM和VLT仅存储压缩包依赖的URL而缺乏完整性哈希验证，导致初始安装通过安全检查的压缩包可能在后续安装中被篡改注入恶意代码。”攻击者一旦将恶意包植入依赖树（即使嵌套多层），即可根据时间、IP地址等信号定向投递恶意负载，”Koi强调。 安全公司已向四家包管理器提交漏洞报告。PNPM、VLT和Bun均在数周内修复漏洞，其中PNPM漏洞编号为CVE-2025-69263和CVE-2025-69264。但NPM方面将该报告标记为”信息性说明”，认为相关功能按设计运行。Koi指出该安全风险真实存在，已观测到威胁行为体讨论利用恶意.npmrc文件的概念验证代码。 针对安全媒体询问，NPM母公司GitHub回应称，通过Git安装依赖包时信任整个代码库是预期设计。”我们正积极处理新报告的问题，NPM持续扫描注册表中的恶意软件。保障NPM生态系统安全需要集体努力，我们强烈建议项目采用可信发布、精细化访问令牌及强制双因素认证来加固软件供应链。GitHub持续投入加强NPM安全，近期已实施认证和令牌管理改进措施。” 消息来源: securityweek.com： 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 新研究发现，超100款Visual Studio Code（VS Code）扩展的发布者泄露了访问令牌，这些令牌可能被恶意行为者利用来更新扩展，从而构成严重软件供应链风险。 “泄露的VS Code Marketplace或Open VSX个人访问令牌（PAT）允许攻击者直接向整个安装基础分发恶意扩展更新。”Wiz安全研究员拉米·麦卡锡在与《黑客新闻》分享的报告中说，“发现此问题的攻击者本可以直接向总计15万的安装基础分发恶意软件。” 这家云安全公司指出，在许多情况下，发布者未能考虑到VS Code扩展虽然作为.vsix文件分发，但可以解压并检查，从而暴露嵌入其中的硬编码机密。 Wiz表示，它总共发现了超550个经过验证的机密，分布在来自数百个不同发布者的超500款扩展中。这550个机密被发现属于67种不同类型的机密，包括： – 人工智能供应商机密，如与OpenAI、Gemini、Anthropic、XAI、DeepSeek、Hugging Face和Perplexity等相关的机密 – 云服务供应商机密，如与亚马逊网络服务（AWS）、谷歌云、GitHub、Stripe和Auth0等相关的机密 – 数据库机密，如与MongoDB、PostgreSQL和Supabase等相关的机密 Wiz还在其报告中指出，超100款扩展泄露了VS Code Marketplace PATs，涉及超8.5万次安装。另有30款扩展的累计安装量不少于10万，被发现泄露了Open VSX访问令牌。其中相当一部分被标记的扩展是主题。 随着Open VSX还被集成到像Cursor和Windsurf这样的人工智能（AI）驱动的VS Code分支中，泄露访问令牌的扩展可能会显著扩大攻击面。 在一次事件中，该公司表示，它发现了一个VS Code Marketplace PAT，本可以用来向一家市值300亿美元的中国大型企业的员工推送针对性恶意软件，表明这个问题还延伸到了组织内部或供应商特定的扩展。 在2025年3月和4月向微软负责任地披露后，这家Windows制造商已撤销了泄露的PATs，并宣布将增加机密扫描功能，以阻止带有经过验证的机密的扩展，并在检测到机密时通知开发者。 建议VS Code用户限制安装的扩展数量，在下载扩展前仔细审查，并权衡启用自动更新的利弊。建议组织制定扩展清单，以便更好地应对恶意扩展的报告，并考虑为扩展制定集中的允许列表。 “这个问题凸显了扩展和插件以及供应链安全的持续风险，”Wiz说，“它继续证实了任何软件包仓库都存在大量机密泄露的高风险。” TigerJack针对VS Code市场发布恶意扩展 与此同时，Koi安全公司披露了一名被命名为TigerJack的威胁行为者的细节，该行为者自2025年初以来被认定使用各种发布者账户发布了至少11款看似合法的恶意VS Code扩展，作为一场“协调的、系统的”活动的一部分。 “以ab-498、498和498-00的身份运营，TigerJack部署了一套复杂的武器库：能够窃取源代码、挖掘加密货币并建立远程后门以实现对系统完全控制的扩展。”安全研究员图瓦尔·阿德蒙尼说。 两款恶意扩展——C++游乐场和HTTP格式化——在被下架前吸引了超1.7万次下载。然而，它们仍在Open VSX上可用，威胁行为者还在2025年9月17日，即被移除后，以新名称在VS Code市场重新发布了相同的恶意代码。 值得注意的是，这些扩展提供了承诺的功能，这为它们的恶意活动提供了完美的掩护，使不知情的开发者在安装它们后无法察觉。 具体来说，C++游乐场扩展被发现可以通过一个在500毫秒延迟后触发的监听器几乎实时地捕获按键。最终目标是窃取C++源代码文件。另一方面，HTTP格式化扩展包含了运行CoinIMP矿工的恶意代码，并通过滥用系统资源秘密挖掘加密货币。 TigerJack以“498”为别名发布的另外三款扩展，即cppplayground、httpformat和pythonformat，通过每20分钟从外部服务器（“ab498.pythonanywhere[.]com”）下载并运行任意JavaScript的能力，进一步增加了风险，从而能够充当后门。 “通过每20分钟检查新指令一次，并对远程获取的代码使用eval()，TigerJack可以动态推送任何恶意载荷，而无需更新扩展——窃取凭证和API密钥、部署勒索软件、利用被入侵的开发人员机器作为进入企业网络的切入点、将后门注入你的项目，或者实时监控你的活动。”阿德蒙尼指出。 Koi安全公司还指出，这些扩展大多最初是完全无害的工具，直到引入恶意修改，这是典型的特洛伊木马手段。这有几个优势，因为它允许威胁行为者建立合法性并在用户中获得影响力。 更重要的是，它还可以欺骗一个在安装前审查过扩展的开发者，因为威胁行为者可以在稍后推送更新来入侵他们的环境。 2025年6月，微软表示，它有一个多步骤流程，以确保VS Code市场免受恶意软件的侵害。这包括对所有传入软件包进行初步扫描，以在沙箱环境中检测恶意运行时行为，以及重新扫描和定期进行市场范围的扫描，以“确保一切安全”。 尽管如此，这些安全保护措施仅适用于VS Code市场，而不适用于其他市场，如Open VSX注册表，这意味着即使恶意扩展从微软的平台被移除，威胁行为者也可以轻松迁移到安全性较低的替代平台。 “所有市场碎片化的安全格局造成了危险的盲点，复杂的威胁行为者已经在利用这些盲点，”该公司说，“当安全在孤岛中运行时，威胁就会在平台间迁移，而开发者仍然在不知情的情况下暴露。”       消息来源：thehackernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

10月31日，美国国家安全局（NSA）、网络安全及基础设施安全局（CISA）、国家情报总监办公室（ODNI）携手发布了保护软件供应链的实操指南。该指南内容总共有40页，主要提及了软件供应商在供应链中所需要承担的责任和改进方法。指南中提及的供应商主要责任包括： 第一，努力识别可能危及组织、软件开发、软件本身和软件交付（即内部部署或SaaS）环境的威胁，并实施相关的缓解措施；第二，作为客户和软件开发团队之间的联络人，需要确保软件在安全环境下开发，并通过安全渠道交付；第三，供应商通过合同协议、软件发布和更新、通知和漏洞缓解机制来提供所交付的软件额外的安全功能。 对于软件供应链的安全实践，NSA、CISA与ODNI有着一系列的规划，相关规划落实在由NSA及CISA所主导的政企工作小组所开发的“长期安全框架”（Enduring Security Framework，ESF）之中。这一框架将产出指导美国重大网络基础设施的安全指南，针对软件供应链总计有3部分：首先是今年9月发布、锁定软件开发者的《Securing the Software Supply Chain for Developers》，10月31日发布的指南适用于软件供应商，下一步则会发布针对软件供应链客户使用者的版本。 该指南针对软件供应商的供应链安全提出了非常多的建议，现将主要要点如下概述： 第一，该指南敦促软件供应商在软件收发供货过程中保证供应链安全。供应商有义务做到确认发货的软件与客户收到的软件是一样的；需要创建一个安全的哈希值来验证文件是否传送正确；需要确保软件传输通信渠道是安全的。需要通过利用国际公认的标准（如NIST SSDF）对软件进行最终检查，这有助于确保在软件发布前满足软件功能和安全要求。 第二，该指南认为供应商应提供一种机制，通过在整个软件生命周期内对代码进行数字签名，来验证软件发布的完整性。经过数字签名的代码，使代码接收者以及客户能够积极地验证和信任代码的来源和完整性。 第三，该指南要求供应商必须确保本地开发的软件和由第三方供应商提供的任何组件都需要符合安全要求。由于第三方提供的软件和模块通常会包含在供应商发布的软件产品中，为此，供应商可以通过召集专家评估第三方提供的软件是否符合适用的安全要求、与第三方软件提供者签订合同协议来解决潜在的第三方软件问题。 第四，该指南认为供应商应尽一切努力，确保提供给客户的任何软件中不存在公开的或容易识别的漏洞。在向客户提供软件之前，需要测试、了解和消除软件中的漏洞，以防止提供容易被破坏的代码。需要建立一个由架构师、开发、测试人员、密码学家和人为因素工程师组成的漏洞评估小组，其任务是识别软件中可利用的弱点。需实时检查与第三方软件和与软件相关的开放源码组件相关的软件物料清单（SBOM）。在相关问题公布后，建立并遵循企业对嵌入式组件升级的指导。 该指南下载地址： https://media.defense.gov/2022/Oct/31/2003105368/-1/-1/0/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_SUPPLIERS.PDF    转自 Freebuf，原文链接：https://www.freebuf.com/news/349435.html 封面来源于网络，如有侵权请联系删除