Binance的63亿美元安全事件：发生了什么，如何降低风险

Binance的初步调查描述了6月和9月发生的员工设备入侵，以及10月20日借助内部AI工具进一步扩大的入侵。攻击者进入两名同事的计算机，找到了用于部署容器的令牌。10月29日，他们利用该令牌部署恶意代码，进入钱包签名系统并发起未经授权的转账。

攻击者还利用签名服务创建了EIP-7702委托，允许其控制的代码代表一个Ethereum钱包执行操作。这项权限存在于区块链上，独立于Binance的提现系统。停止提现无法移除该权限，Binance必须单独在链上撤销委托。

关键区别在于停止某项活动与移除支撑该活动的权限。更换设备、撤销部署凭据、取消另一个系统内的权限，分别针对入侵的不同部分。

笔记本电脑、部署系统和敏感服务承担着不同职责。当对其中一个的访问自动打开通向下一个的入口时，风险就会增加。被盗令牌可能让攻击者替换软件，而该软件随后可能使用员工本人从未直接拥有的权限运行。

以下四个问题有助于确定应在哪里打断这一过程。

1. 凭据暴露。 攻击者能从一名员工的设备上获得哪些生产环境访问权限？
2. 部署权限。 谁能修改使用这些权限运行的代码？
3. 服务授权。 敏感服务会接受该代码发起的哪些操作？
4. 持久访问。 原账户被停用后，哪些新权限仍可能保留？

目标是限制权限在系统之间传递的范围，并识别和撤销入侵期间创建的额外访问权限。下面将讨论支持这一目标的四项控制措施。

控制措施1. 减少笔记本电脑可能暴露的凭据

凭据对攻击者有用，是因为其他系统将其视为权限证明。减少员工设备上的生产环境凭据，可以降低工具、代码仓库或浏览器会话遭入侵时可被窃取的信息量。

对于日常工作，员工通常需要的是请求执行某项操作的权限，例如重启服务。执行该操作的凭据可以由独立的执行身份持有。因此，减少暴露既要移除不必要的副本，也要管理仍然保留的凭据。

• 在可行的情况下，用范围明确的操作替代日常直接访问。
• 不同职责使用不同身份，并限制各自的权限范围和有效期。
• 维护凭据清单，记录其所有者和撤销方式。

这体现了OWASP机密管理指南中的原则：减少人员直接处理机密的机会，仅授予每个身份所需的访问权限。这样，工作站被盗或遭入侵时，暴露的可复用凭据更少，响应人员也知道仍需撤销的凭据由谁负责。

控制措施2. 将部署权限视为生产环境特权

某个机密可能对一个人不可见，却能被他部署的代码使用。能够修改该代码的人可能读取机密、调用内部API，或以应用程序服务账户的身份执行操作。因此，必须根据最终工作负载的权限来评估部署访问权限。

OWASP的CI/CD安全指南将仓库变更、流水线配置和执行主机视为同一安全问题的不同组成部分。防护应同时覆盖部署前的代码和部署后的权限。

• 要求生产代码经过审核，并保护自动化所执行的仓库分支。
• 不仅要控制主脚本，还要控制任务定义、依赖项和启动时输入的变更。
• 仅向工作负载提供其功能所需的凭据和网络访问权限。

这两组控制必须协同工作。仓库和部署权限决定谁能修改代码。独立的身份、主机和网络策略限制代码运行后能做什么。集中存储机密可以减少暴露，而这些策略则约束使用机密的程序。

控制措施3. 授权具体操作，而不只是识别调用方

签名服务可以隐藏私钥，却仍然接受有害的签名请求。数据库和云API也存在同样的区别：对工作负载进行身份验证是确定调用方是谁，授权则决定其可以执行什么操作。

OWASP建议对每个请求进行授权检查，并拒绝未被明确允许的访问。对于接收请求的服务，这意味着同时检查操作及其目标，例如允许的支付目的地与金额、数据库操作或基础设施变更。

即使调用方已经受信任，服务也应评估其请求的操作。自动化管理如何提出工作请求，接收请求的服务则决定接受哪些操作。

控制措施4. 撤销入侵期间创建的访问权限

攻击者可能使用合法身份添加另一组凭据或授予更多权限。MITRE ATT&CK将账户操纵列为维持或扩大访问权限的手段，包括添加云凭据和SSH密钥。停用原始会话并不一定会移除这些变更。

Binance的链上委托说明，响应人员必须检查受影响系统本身的权限。遏制入侵既要覆盖最初的立足点，也要覆盖由此创建的权限。

• 限制哪些自动化身份可以创建更多凭据或授予权限。
• 将新创建的账户、会话和委托纳入响应计划。
• 在实际执行权限控制的系统中验证撤销结果，不要将任务停止视为已完成遏制的证明。

执行这些步骤后，响应人员就有了一组明确需要调查和撤销的身份与权限。这也让遏制效果可以验证：团队能够检查通向受影响服务的每条已知路径是否真正关闭。

这些控制作用于不同层面：员工设备、部署系统、接收请求的服务和响应流程。每个层面都需要明确负责人，并提供验证方法，确认其他层面遭入侵时，其限制仍然有效。

自动化管理平台处理的是员工请求到生产环境执行之间的这部分问题。在Semaphore UI中，团队可以准备定义明确的任务，控制谁能运行或修改它，并使用独立身份执行。目标服务内部的授权，以及对其他系统中新建权限的撤销，仍由相应系统和响应团队负责。

以需要重启API服务的值班工程师为例。维护人员准备一个playbook和Task Template，固定目标主机和重启方式。工程师无需建立到生产环境的SSH会话，只需启动任务并查看结果。下面两条路径执行相同的重启操作，但执行凭据由不同主体持有。

构建重启工作流需要四个相互衔接的步骤：创建受限的执行身份，定义用户能运行或修改什么，选择执行环境，以及让结果可见。完成这些步骤后，同样的方法还可以扩展到部署。

被盗操作人员会话仍可请求执行该账户获准运行的操作。即使是允许的重启，反复触发也可能干扰服务。应在预发布环境中使用接近真实情况的操作人员账户，测试已配置的工作流，同时覆盖其可执行的行为以及团队对滥用的响应。

• 任务与输入权限。 测试实际角色和启动时选项，包括其他分支、inventory和参数。
• 超出预期操作范围的访问。 检查对其他模板、凭据和生产系统的访问，包括runner进程能够触达的范围。
• 检测与运行影响。 确认谁接收结果、谁调查意外活动，以及重复执行是否会造成无法接受的中断。
• 撤销。 测试会话和令牌的撤销，并确定执行身份可能在其他系统中创建哪些权限。

记录测试账户仍保留的访问权限，并关闭超出操作目的的所有路径。演练结束后，团队应清楚被盗会话能做什么，以及如何检测和遏制相应滥用。

访问控制需要与终端防护，以及了解如何响应的团队共同发挥作用。应让准备好的工作流足够方便，使人员无需退回到共享密钥和未记录的捷径。还应以一些日常实践作为支持。

• 在一次性的隔离环境中运行不熟悉的安装程序和面试作业，环境中不应有企业凭据、主机挂载或内部网络访问。
• 让人员能够尽早、方便地报告可疑活动，而不必担心受到责备。提供明确的联系渠道和事件响应路径。
• 职责变化时重新审核访问权限，维护受控的紧急访问程序，并在事件发生前演练撤销流程。

这些实践将预防、检测和恢复融入日常工作。它们有助于在职责变化时保持访问模型的准确性，并让团队在出现可疑事件时按熟悉的流程响应。

核心教训是限制一个遭入侵的身份能够积累多少权限。减少笔记本电脑上的凭据、审核自动化代码、限制执行主机，以及在生产服务内部实施授权，分别减少了攻击者可利用的路径。

Semaphore将其中若干控制融入可重复的工作流：准备好的任务、分离的运行与编辑权限、集中提供的凭据，以及可查看的执行记录。操作人员获得工作所需的操作权限，维护人员则保留对背后代码和凭据的控制。

从一项经常使用的生产操作开始：准备其任务模板，分配必要的操作人员权限，并在停用被替代的直接连接前测试最终访问范围。有效的进展衡量标准是：攻击者在下一次攻破某个账户后，能做的事情有多少被减少了。