HackerNews 编译，转载请注明出处： 网络安全研究人员发现五个恶意 Rust 包，它们伪装成时间相关工具，将 .env 文件数据传输给威胁行为者。 这些发布在 crates.io 上的 Rust 包如下： ·     chrono_anchor ·     dnp3times ·     time_calibrator ·     time_calibrators ·     time-sync 据 Socket 公司称，这些包仿冒 timeapi.io 相关功能，于 2026 年 2 月末至 3 月初发布。基于相同的数据窃取方法，以及用于存储被盗数据的相似域名（timeapis [.] io），研究人员判定这些攻击出自同一威胁行为者之手。 “尽管这些包伪装成本地时间工具，但其核心行为是窃取凭据和密钥。” 安全研究员基里尔・博伊琴科（Kirill Boychenko）表示，“它们试图从开发者环境中收集敏感数据（尤其是 .env 文件），并将数据外传到威胁行为者控制的基础设施。” 上述四个包仅具备直接窃取 .env 文件的基础能力，而 “chrono_anchor” 更进一步：通过实现混淆和操作层面的修改来规避检测。这些包对外宣传的功能是 “无需依赖网络时间协议（NTP）校准本地时间”。 “chrono_anchor” 将数据窃取逻辑嵌入名为 “guard.rs” 的文件中，通过一个 “可选同步” 辅助函数调用，以此避免引起开发者怀疑。与其他恶意软件不同，该包的代码并未试图通过服务或计划任务在主机上建立持久化，而是每当持续集成（CI）工作流的开发者调用恶意代码时，就反复尝试窃取 .env 中的密钥。 针对 .env 文件的攻击并非偶然 —— 该文件通常用于存储 API 密钥、令牌等敏感信息，攻击者可借此攻陷下游用户，获得对其环境（包括云服务、数据库、GitHub 及注册表令牌）的深度访问权限。 尽管这些包已从 crates.io 下架，但研究人员建议：不慎下载过的用户需假定数据已被窃取，立即轮换密钥和令牌，审计使用发布 / 部署凭据运行的 CI/CD 任务，并尽可能限制出站网络访问。 Socket 表示：“此次攻击表明，即便低复杂度的供应链恶意软件，只要在开发者工作区和 CI 任务中运行，仍能造成高影响。应优先部署控制措施，在恶意依赖执行前阻止其运行。” 人工智能驱动的机器人利用 GitHub Actions 发起攻击 此前，研究人员还发现一场自动化攻击活动：一款名为 hackerbot-claw 的 AI 驱动机器人扫描公共代码仓库，利用存在漏洞的 GitHub Actions 工作流窃取开发者密钥，攻击目标涵盖主流开源仓库的 CI/CD 流水线。 2026 年 2 月 21 日至 28 日期间，这个自称 “自主安全研究代理” 的 GitHub 账号，攻击了至少七个归属微软、Datadog、Aqua Security 等机构的代码仓库。 攻击流程如下： ·     扫描公共仓库，寻找配置错误的 CI/CD 流水线 ·     复刻（Fork）目标仓库，准备恶意载荷 ·     提交包含微小修改（如拼写错误修复）的拉取请求（PR），同时将核心恶意载荷隐藏在分支名、文件名或 CI 脚本中 ·     利用 “每次 PR 自动触发工作流” 的机制启动 CI 流水线，使恶意代码在构建服务器上执行 ·     窃取密钥和访问令牌 此次攻击中最受关注的目标之一是 Aqua Security 旗下的 “aquasecurity/trivy” 仓库 ——Trivy 是一款主流安全扫描工具，用于检测已知漏洞、配置错误和密钥。 供应链安全公司 StepSecurity 表示：“hackerbot-claw 利用 pull_request_target 工作流窃取了个人访问令牌（PAT），随后用该凭据接管了整个仓库。” Aqua Security 的伊泰・沙库里（Itay Shakury）在上周声明中透露，攻击者借助 GitHub Actions 工作流，将恶意版本的 Trivy Visual Studio Code（VS Code）扩展推送到 Open VSX 注册表，利用本地 AI 编码代理收集并窃取敏感信息。 同样参与该扩展攻击调查的 Socket 公司称，1.8.12 和 1.8.13 版本中注入的恶意逻辑，会以高权限模式运行本地 AI 编码助手（包括 Claude、Codex、Gemini、GitHub Copilot CLI、Kiro CLI），指令这些工具执行全面的系统检查、生成信息报告，并通过受害者已认证的 GitHub CLI 会话，将结果保存到名为 “posture-report-trivy” 的 GitHub 仓库。 Aqua 已从应用市场移除相关恶意制品，并吊销了用于发布的令牌。研究人员建议安装过该扩展的用户立即卸载，检查是否存在异常仓库，并轮换环境密钥；目前恶意制品已下架，未发现其他受影响制品，该事件被分配 CVE 编号 CVE-2026-28353。 需注意的是，系统受该漏洞影响需满足以下前提条件： ·     从 Open VSX 安装了 1.8.12 或 1.8.13 版本扩展 ·     本地安装了至少一款目标 AI 编码 CLI 工具 ·     该 CLI 接受恶意逻辑提供的高权限执行参数 ·     AI 代理能够访问磁盘上的敏感数据 ·     安装并认证了 GitHub CLI（针对 1.8.13 版本） Socket 表示：“从 1.8.12 到 1.8.13 的版本迭代可见攻击者的优化：第一个版本的指令将数据分散到随机渠道，攻击者无法可靠收集输出；第二个版本则利用受害者自身的 GitHub 账号作为稳定的数据窃取渠道，但模糊的指令可能导致 AI 代理将密钥推送到攻击者无法访问的私有仓库。” Pillar Security 评估认为，hackerbot-claw 是人类操作者借助大语言模型（LLM）作为执行层发起的攻击，并将该活动命名为 “Chaos Agent”。 安全研究员埃 ilon・科恩（Eilon Cohen）表示，此次攻击体现了 “AI 增强型攻击者快速利用 CI/CD 配置错误发起攻击”，而 Trivy VS Code 扩展的供应链攻击，标志着 AI 编码代理被滥用于数据窃取。“hackerbot-claw 攻击利用了大多数企业都未察觉的漏洞：对开发者机器上运行的 AI 编码代理完全无可见性，且这些代理被武器化时缺乏运行时控制。” 消息来源：thehackernews.com； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 最新研究发现，包括政府、电信和关键基础设施在内的多个敏感行业组织，存在将密码和凭证粘贴到 JSONFormatter、CodeBeautify 等在线代码格式化与验证工具的行为。 网络安全公司 watchTowr Labs 表示，其在这些网站上捕获了超过 8 万份文件的数据集，从中发现数千组用户名、密码、代码库认证密钥、Active Directory 凭证、数据库凭证、FTP 凭证、云环境密钥、LDAP 配置信息、服务台 API 密钥、会议室 API 密钥、SSH 会话记录以及各类个人信息。 该数据集包含 JSONFormatter 五年的历史内容和 CodeBeautify 一年的历史内容，总计超过 5GB 的增强型带注释 JSON 数据。 泄露影响范围 受此次泄露事件影响的组织遍及国家关键基础设施、政府、金融、保险、银行、科技、零售、航空航天、电信、医疗保健、教育、旅游等行业，具有讽刺意味的是，网络安全行业也在其中。 “这些工具极具 popularity，在‘JSON 美化’‘粘贴机密信息的最佳平台’（推测，未经证实）等搜索词条中常位居前列 —— 企业环境和个人项目中的各类组织、机构、开发人员及管理员均有使用，” 安全研究员杰克・诺特在分享给The Hacker News的报告中表示。 这两款工具均支持保存格式化后的 JSON 结构或代码，并生成半永久性的可共享链接 —— 任何获取该 URL 的用户均可访问其中数据。 更严重的是，这些网站不仅设有便捷的 “近期链接”（Recent Links）页面，列出所有近期保存的链接，其可共享链接还采用可预测的 URL 格式，使得攻击者能够通过简单爬虫轻松获取所有链接： https://jsonformatter.org/{此处为 ID} https://jsonformatter.org/{格式化类型}/{此处为 ID} https://codebeautify.org/{格式化类型}/{此处为 ID} 泄露信息包括 Jenkins 密钥、某网络安全公司泄露的敏感配置文件加密凭证、某银行的客户身份验证（KYC）信息、某大型金融交易所与 Splunk 相关联的 AWS 凭证，以及某银行的 Active Directory 凭证等。 安全风险 更糟糕的是，该公司透露，其在其中一款工具中上传了伪造的 AWS 访问密钥，结果发现该密钥保存 48 小时后便遭到攻击者的滥用尝试。这表明通过此类渠道泄露的敏感信息正被第三方爬取并用于攻击测试，构成严重安全风险。 “主要原因是已经有人在利用这些泄露信息了，而这种（粘贴机密到随机网站的）行为实在是太愚蠢了，” 诺特表示，“我们不需要更多人工智能驱动的智能代理平台；我们需要的是减少关键组织将凭证粘贴到随机网站的行为。” The Hacker New核实发现，JSONFormatter 与 CodeBeautify 目前已暂时禁用保存功能，声称正在 “优化该功能” 并实施 “增强型工作环境不适宜（NSFW）内容防护措施”。 watchTowr 指出，这些网站禁用保存功能很可能是对该研究的回应。“我们推测这一变更于 9 月实施，源于我们通知的多家受影响组织的沟通反馈，” 该公司补充道。   消息来源：thehackernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

微软的签名密钥泄露为云安全乃至“纵深防御”敲响了警钟，因为黑客在获取微软签名密钥的过程中，微软纵深防御的每一层似乎都出现了（不应该出现的）错误。 微软今年7月份发布的安全公告声称，一名中国黑客（Storm-0558）早在2021年就获取了微软帐户(MSA)加密密钥，用来伪造身份验证令牌，监视美国国务院、商务部以及其他美国政府机构的电子邮件账户。但微软在该公告中并未透露加密密钥泄露的原因和过程。 本周三，微软研究中心在官方博客发布取证调查报告，披露了黑客如何获取微软加密密钥并成功入侵了微软工程师的企业账号。 微软在博客中指出，中国黑客（微软代号为Storm-0558）获得了对25个美国政府机构的Exchange Online和Azure Active Directory（现称为Microsoft Entra ID）帐户的“合法”访问权限。 一连串错误导致签名密钥泄露 根据微软本周三发布的博客，2021年4月，微软消费者签名系统崩溃产生了崩溃进程快照（故障转储），通常来说，故障转储会去除敏感信息，不应包含签名密钥，但是由于微软设定了一个竞争条件（race condition）允许密钥在某些情况下出现在故障转储中（该问题已经得到纠正），而微软的系统未检测到故障转储中存在机密信息（此问题已纠正），导致MSA密钥无意中泄漏到微软保护区之外的（实施严格访问控制的）生产环境。 这个当时被微软认为不包含敏感信息的故障转储随后从隔离的生产网络转移到微软与互联网连接的企业网络的调试环境中。 屋漏偏逢连夜雨，在崩溃转储被转移到调试环境之前和之后，本应在故障转储中检测此类敏感数据的凭证扫描系统也未能检测到签名密钥。（此问题已纠正） 在9月6日发布的取证分析中，微软透露，遭入侵的微软工程师帐户可能有权访问存储MSA密钥的调试环境（从而提取了密钥）。但令人遗憾的是，这最关键的取证分析结论仅仅是微软的“猜测”。 微软表示：“由于日志保留政策，我们没有包含（保留）该攻击者进行窃取密钥的具体证据的日志，但这是攻击者获取密钥的最可能的机制。” 微软的“万能钥匙” 获取合法加密密钥后，黑客Storm-0558利用Get Access Token For Resource API中的零日漏洞，伪造签名的访问令牌并冒充25个组织的目标帐户。 该API由Microsoft于2018年提供，旨在帮助使用消费者和企业应用程序的客户系统都能以加密方式验证签名。微软在7月份的公告中确认，该缺陷“已被修复，目前仅接受分别从Azure AD或MSA发行的令牌”。 虽然被盗的加密密钥是针对消费者帐户的，但“微软代码中的验证错误”使黑客还可以为政府机构和其他组织的微软托管帐户创建虚假令牌，从而访问这些帐户。 俄勒冈州的民主党参议员罗恩·怀登(Ron Wyden)在7月27日的一封公开信中表示，微软应该“为其疏忽的网络安全做法负责”。 他认为，微软不应该拥有“单一万能钥匙”，一旦被盗，攻击者就可以访问客户的私人通信。怀登还提出了有关加密密钥如何存储的问题。 此外，还有安全专家对微软报告的事件影响范围和严重性提出质疑。 微软声称，此次攻击活动中，黑客Storm-0558“仅能”访问Exchange Online和Out look。 然而，Wiz研究主管Shir Tamari在7月21日的帖子中指出，黑客或许能够访问各种Microsoft服务，包括“Outlook、SharePoint、OneDrive和Teams，以及客户的应用程序支持微软账户认证。” 给纵深防御敲响警钟 作为缓解措施的一部分，微软已经撤销了所有有效的MSA签名密钥，以防止黑客访问其他受损密钥，并确保没有其他证据表明有其他攻击者使用相同的令牌伪造技术未经授权访问客户帐户。 微软还将云日志记录的访问权限扩展至所有用户，该功能以前是为其高级客户保留的。这可以帮助网络防御者检测未来类似的攻击尝试。 很多网络安全业界人士认为，微软签名密钥泄露事件为云安全乃至“纵深防御”敲响了警钟，因为黑客在获取微软签名密钥的过程中，微软纵深防御的每一层似乎都出现了（不应该出现的）错误。     转自GoUpSec，原文链接:https://mp.weixin.qq.com/s/ZtMei3fz3BlrcyEJmrAJgg 封面来源于网络，如有侵权请联系删除

德国亚琛工业大学的研究人员发表的一项研究表明，Docker Hub 上托管的数以万计的容器镜像包含机密信息，使软件、在线平台和用户面临巨大的攻击面。 Docker Hub 是一个基于云的存储库，供 Docker 社区存储、共享和分发 Docker 镜像，这些容器创建模板包括所有必要的软件代码、运行时刻、库、环境变量和配置文件，以便在Docker中轻松部署应用程序。 研究人员分析了来自 Docker Hub 和数千私人注册表的 337171 个镜像，发现大约 8.5% 包含私钥和 API 密钥等敏感数据，并且许多暴露的密钥都被积极利用，破坏了依赖它们的元素的安全性。 该研究从 337171 个 Docker 镜像中收集了包含 1647300 个层面的海量数据集，并尽可能从每个存储库中获取最新的镜像版本。使用正则表达式搜索特定数据分析显示，28621 个 Docker 镜像中暴露了 52107 个有效私钥和 3158 个不同的 API密钥。经过研究人员验证，这些不包括测试密钥、API密钥示例和无效匹配。大多数暴露的数据（95% 为私钥，90% 为 API密钥）都驻留在单用户映像中，这表明它们很可能是无意泄露的。 调查结果 影响最大的是 Docker Hub，其暴露比例为 9.0%，而来自私有注册表的镜像暴露比例为 6.3%。这种差异可能表明 Docker Hub 用户通常比设置私有存储库的用户对容器安全性的了解较差。 使用暴露的密钥 接下来，研究人员确定了所暴露秘密的实际用途，以了解攻击面的大小。令人震惊的是，研究人员发现了 22082 个依赖于暴露私钥的受损证书，其中包括 7546 个私有 CA 签名证书和 1060 个公共 CA 签名证书。 这上千个 CA 签名证书尤其值得关注，因为这些证书通常被大量用户使用。在研究时，141 个 CA 签名的证书仍然有效，这在一定程度上降低了风险。 为了进一步确定暴露的秘密在野外的用途，研究人员使用了 Censys 数据库提供的全互联网测量结果，发现275269 台主机与泄露的密钥存在关联，其中包括了8674 个 MQTT和19 个 AMQP 主机可能传输隐私敏感的物联网 (IoT) 数据。 这种程度的暴露凸显了容器安全方面的巨大问题，以及在创建镜像时未首先清除镜像中的机密信息这类过失性错误。 关于API暴露，分析发现大多数容器（2920个）属于亚马逊AWS等云提供商，但也有一些涉及Stripe等金融服务。目前，研究人员还不清楚这些API在野外的具体利用情况。     转自Freebuf，原文链接:https://www.freebuf.com/news/372226.html 封面来源于网络，如有侵权请联系删除