作者：腾讯安全平台部研发安全团队 Martin

众多名流被黑，推特面临严重安全事件

16日凌晨，众多推特“大V”突然集体转发诈骗信息 —— “只要给特定账号汇入等值1000美元的比特币，就能获得双倍返还”，受影响账户包括：前总统奥巴马、比尔盖茨、巴菲特、马斯克和苹果公司等。

推特官方很快介入调查，并于三小时后给出初步调查结果：“员工受钓鱼攻击，内部系统和工具被攻击者滥用”。

事件很快攻占各大媒体头条，对平台安全的质疑声四起。

并由此引发蝴蝶效应，推特面临公关危机，股价受累。当今万物互联，作为重要媒介，越来越多政商名流、企业等通过推特等社交媒体宣布重大政策决定，此类攻击甚至有可能掀起现实世界的乱局。

居安思危，相关风险应该如何防范？

从公开信息分析，本次安全事件与“认证鉴权、访问控制”相关。历史上，通过内部安全测试、TSRC等渠道，腾讯安全团队曾提前发现并处置过多起类似安全风险。

2013年，腾讯微博也曾差点经历类似的“惊魂时刻”。因存在一个CGI鉴权漏洞，若被攻击者利用，能以任何人的账号发微博。当时漏洞由国内著名白帽子、知道创宇CSO SuperHei发现并提交给腾讯安全应急响应中心（TSRC），接到报告后TSRC很快就联合业务修复了漏洞。同时内部展开排查，又修复了数个类似问题。

该次事件的TSRC应急响应过程

为保护用户隐私数据，近年来，腾讯各团队积极开展安全内建。透过本次事件，结合内部实践经验，从系统研发及运营视角，我们简单梳理了风险及建议。

1. “零信任”，精细化访问控制

管理系统在内网一定“高枕无忧”吗？本次推特的安全事件，无疑敲响警钟 ——风险也有可能来自内部。甚至有时内部“作恶”并非是有意的，员工可能成为攻击者的“提线木偶”。从披露的推特管理后台看，此次事件暴露出许多系统设计可吸取的教训。

安全，再怎么严谨都不为过。当前，业界推行的“零信任”安全理念，或许是更好的安全防御思路。即：每个用户、设备、服务或应用程序都是不可信任的，必须经历身份和访问管理过程才能获得最低级别的信任和关联访问特权。这意味着，不应将内外网作为是否可信的“边界”，访问控制应精细到个体级别，尤其是特权接口、敏感数据。

从应用视角看，原则上，只有用户能接触、操作自身的数据。如因业务需要，员工或运营系统访问、操作敏感接口和数据，均应审批并留存日志，方便定期审计、回溯。

在业界，相关理念已有实践。如，针对云原生服务架构，Google提出的BeyondProd (https://cloud.google.com/security/beyondprod) 模型。相关要点可概括为：

不信任网络边界。

Google不依赖内部网络分段或防火墙作为主要安全机制；

服务模块间访问控制。

在Google基础架构上运行的每项服务都具有关联的服务帐号身份标识。服务具有加密凭据，可在向其他服务发送或从其他服务处接收远程过程调用 (RPC) 时用于证明自己的身份。客户端利用这些身份标识来确保其与正确的目标服务器通信，而服务器则利用这些身份标识将方法与数据的访问权限授权给特定的客户端；

精确到单用户角色的访问控制。

Google的中央身份识别服务会对最终用户的登录信息进行验证，然后向该用户的客户端设备签发用户凭据，例如 Cookie 或 OAuth 令牌。从该客户端设备向 Google 发出的任何后续请求都需要提交此用户凭据。当一项服务收到最终用户凭据时，就会将该凭据传递给中央身份识别服务进行验证。如果最终用户凭据经验证正确无误，中央身份识别服务就会返回短期有效的“最终用户权限工单”，该工单可用于与请求相关的远程过程调用 (RPC)；

异曲同工，类似理念在腾讯业务也已有落地实践，如：微信 —— 全程票据系统。是由微信团队设计的一套数据保护机制，其方案核心是：用户登录后，后台会下发一个票据给客户端，客户端每次请求带上票据，请求在后台服务的整个处理链条中，所有对核心数据服务的访问，都会被校验票据是否合法，非法请求会被拒绝，从而保障用户隐私数据只能用户通过自己的客户端发起操作来访问。

2. 同级别“地雷”，权限控制类逻辑漏洞

一如前文所述的“腾讯微博”案例，业务中的权限控制类逻辑漏洞，也能产生类似此次事件的效果。从TSRC历史报告来看，由于此类问题与业务逻辑高度相关，无法设计通用的自动化检测手段，正逐年成为各类业务面临的首要风险。

漏洞主要分三类：

未鉴权，业务未校验登录态，外部可任意拉取业务敏感数据。例如：SNS社交动态任何人可删除、网站管理接口可直接操作。

水平越权，具有同等权限的A、B能相互进行敏感操作。例如：以QQ号A的身份，能在B的QQ空间中发布动态。

垂直越权，即普通用户能执行需要更高级别身份的操作。

我们建议，业务开发阶段遵循以下原则：

1) “零信任”，系统/接口开启默认鉴权。除非敏感功能外，所有接口/功能校验权限；

2) 禁止将参数值作为判断用户身份或权限的依据。应从登录态判断用户并根据用户角色、权限等级进行鉴权；

3) 健全访问控制相关的人工及自动化测试用例。开发过程中，按功能设计需求，编写单元测试用例进行自测。对于核心的业务逻辑，采用自动化测试用例的方式覆盖，避免持续的变更过程中因疏忽导致漏洞产生；

在此背景下，结合Google BeyondProd和微信全程票据方案，安全团队也正与公司系统框架中台协同预研 —— RPC票据。我们认为它可能会是一种更为彻底、有效的数据保护和逻辑漏洞收敛手段。相关技术细节与实践经验，敬请期待后续TSRC分享。方案可简述为：

  • 用户鉴权登录后，衍生成RPC票据，供内部服务间流转

  • RPC票据采用非对称加密保护完整性，只有指定颁/验票节点才有权创建、修改

  • 授权信息通过RPC票据承载、层层透传，且会随扩展颁票，不断填充入增强信息（如：关系链等）

  • 基于“零信任”思路，数据操作（DAO）时，没有或持非法RPC票据则拒绝操作

总结

“应对一场被3亿人关注的安全事件，一点也不好笑”。曾负责推特安全团队的Charlie Miller如是说。

作为从事安全防御方向的同行，深知其中不易。有时攻击只要击破一个点，而防御往往需要考虑千百种情况，往往面临更大挑战和不确定因素。正如Google安全总监Heather对此次事件评论的那样“这就是为什么我看到同行面临困境时，一点也笑不出来的原因。”

居安思危，在访问控制方向的安全防御建设，仍任重道远。欢迎与我们携手，一同探索零信任、数据保护、逻辑漏洞收敛方面的方案与经验。

参考资料

[1]《从无到有：微信后台系统的演进之路》

https://www.infoq.cn/article/the-road-of-the-growth-weixin-background/

[2] Google BeyondProd

https://cloud.google.com/security/beyondprod

声明：本文来自腾讯安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。