微软38TB内部数据惨遭泄露！私人密钥、3w+工作对话流出，背后原因震惊了

昨天，微软在GitHub上发布开源训练数据时，无意中泄露了38 TB的内部数据。好在，百亿独角兽Wiz及时发现了漏洞，现在微软已经连夜修补上了。

出大事了！

几个月前，微软的人工智能研究团队在GitHub上发布大量开源训练数据时，曾发生了大规模泄露。

高达38 TB的数据流出，包括员工电脑的的个人备份、私人密钥和三万多条内部的Teams消息。

原来，是微软的AI研究团队在发布开源训练数据集时，不小心打开了「小金库」的门。

而泄露之所以会发生，是因为一个SAS token配置错误了。

微软的工作人员，都是使用Azure来共享文件的。但现在，它的便利性也成了一把双刃剑——容易共享，却也容易泄露。

就在昨天，微软和Wiz同时发博，梳理了一下这件事的来龙去脉，因此广大群众们才了解到，原来三个月前发生过这么一场严重的泄漏事件。

01

Microsoft调查结果

在得知了捅出这么大一个篓子之后，微软也马上修复了这个问题，并对可能产生影响的文件进行了全面的排查，还发了一个官方博客对泄露事件进行了总结。

官方博客最主要的目的是安抚客户，微软一开头就表示了「没有客户数据泄露，也没有其他内部服务因为这个问题而处于危险之中。对于此问题，不需要客户采取任何行动。」

但是如此大规模的数据泄漏，别说微软的客户了，就是路过的吃瓜群众看了消息也不是很放心啊。

我们就来看看这次数据泄漏的前因后果。

最早发现泄漏的是一个云安全公司Wiz，他们在发现了这个问题之后，在将问题告知微软的同时，把自己的发现和分析写了一篇长文博客，为自己的业务能力打了一波广告。

按照Wiz的说法，微软的人工智能研究团队在GitHub上发布大量开源训练数据时，意外暴露了38 TB的额外私人数据，其中包括2名员工工作站的硬盘备份。

其中包括：机密文件、私钥、密码和超过 30,000 条内部 Microsoft Teams 消息。

但是因为发现这个漏洞的公司本来就是网络安全公司，而且第一时间联系了微软，所以大概率这些数据没有被真正泄露出去。

而数据意外暴露的过程，是源于Wiz的研究团队在网上扫描意外暴露云托管数据时的发现。

Github上Microsoft的组织下找到了一个名为robust-models-transfer的Repo。浏览者可以通过Azure的存储URL来下载模型：

但是，用户通过这个URL能够访问的不仅仅是这个开源模型。它被配置为授予用户访问整个存储帐户的权限，从而公开了其他私人敏感数据。

扫描显示，此帐户包含38 TB的额外数据，包括两个微软员工的电脑硬盘备份。

图：「robustnessws4285631339」存储帐户下泄漏出来的文件夹

图：在文件备份中发现的一小部分敏感文件

两名微软员工的Teams聊天记录

而且除了错误的访问权限之外，这个SAS token还被错误地配置为「完全控制」权限。这意味着，其他用户不仅可以查看存储帐户中的所有文件，还可以删除和篡改这些文件。

因为Repo原本的目的是提供一个用于训练代码的AI模型。Repo会引导用户从SAS链接下载格式为ckpt的模型数据文件。

它是使用Python的 pickle 格式化器格式化的，很容易引发任意代码执行攻击。

攻击者可以将恶意代码注入到这个存储帐户中的所有AI模型中，每个信任这个微软GitHub Repo的用户都会受到威胁。

不过还好，因为这个账户是在Wiz研究团队主动扫描时找到的，并并没有公开给所有的访问用户。

微软Azure使用了一种被称为「SAS token」的机制。用户通过这个机制来创建链接分享自己的存储账户的访问权限，而经过他们检查，这个账户还是完全私有的。

微软也表示，由于Wiz的研究发现，他们已经扩展了GitHub的一项特殊监控服务，会监视所有公开开源代码的更改，以防止可能的代码篡改和敏感文件泄露。

02

SAS token简介

SAS即共享访问签名。

在Azure中，SAS token是一个经过认证的URL，它能够授予对Azure存储数据的访问权限。

SAS的访问权限可由用户自定义。

访问的内容可以是单个文件、容器或整个存储帐户，权限介于只读和完全控制之间。

过期时间也可以自定义，并允许用户创建无限期的访问 token。

这种精细的操作划分为用户带来了极大灵活性和机动性，但也可能会导致授权过多带来的一系列风险。

这次微软内部数据的泄露印证了这一点。

在权限最大的情况下，token可以永久开放对整个帐户的所有权限，基本上与账户密钥的访问权限相同。

SAS token有3种类型：账户SAS、服务SAS和用户授权SAS。

其中，最常用的是账户SAS token，微软的Repo中使用的也是这种token。

生成账户SAS的过程很简单，如下图所示：

用户配置token的范围、权限和有效期，然后生成token。随后在后台中，浏览器会从Azure下载帐户密钥，并用密钥签署生成的token。

整个过程都将在浏览器上完成，与Azure云中的资源或事件无关。

因此，当用户创建了一个具有高权限且无限期的token时，管理员根本无法得知这个token的地点以及流通范围。

这使得想要吊销token变得十分困难。

管理员需要轮换签署token的帐户密钥，从而使所有由相同密钥签署的其他令牌也变得无效。

这个缺陷让这项服务很容易成为寻找暴露数据的攻击目标。

除了意外暴露的风险，该服务的缺陷还使其成为攻击者在入侵账户中进行持久攻击的有效工具。

微软最近的一份报告表明，攻击者正在利用该服务缺乏监控功能的特点，生成特权SAS token作为后门。

但由于token的发放在任何地方都没有记录，所以管理员无法对其采取相应的行动。

SAS安全建议

Wiz在回顾分析了微软数据泄露的整个流程后，贴心地针对这次的始作俑者SAS，为用户提出了一些提高SAS安全性的建议。

03

SAS管理

首先是管理方面，由于账户SAS token缺乏安全性和管理，因此应将其视为与账户密钥本身，给予同样的重视

要避免将账户 SAS用于外部共享，token创建的错误很容易被忽视并暴露敏感数据。

如果要进行外部共享，可考虑将服务 SAS与存储访问策略一起使用。

该功能可以将 SAS token与服务器端策略相连，从而能过以集中方式管理策略和撤销策略。

如果需要以有时间期限的方式共享内容，可以考虑用户授权SAS，它仅提供上限为7天的访问权。

并且，它还能将 SAS token与 Azure Active Directory的身份管理连接起来，提供对令牌创建者及其用户身份的控制和可见性。

此外，Wiz建议为外部共享创建专用的存储帐户，以确保过度授权的token其潜在影响仅限于外部数据。

为了禁用SAS token，企业必须分别禁用每个存储账户的 SAS访问权限。云安全策略管理 可以作为一项策略来进行跟踪和执行。

另一种禁用SAS token创建的解决方案是阻止Azure中的“列出存储帐户密钥”操作，然后轮换当前的帐户密钥，以使现有的SAS令牌无效。

这种方法仍然允许创建用户授权SAS，因为它依赖于用户密钥而不是账户密钥。

SAS监管

其次是监管方面，如果要跟踪活动SAS token的使用情况，需要为每个存储账户启用Storage Analytics日志。

生成的日志将包含SAS token访问的详细信息，包括签名密钥和分配的权限。

但需要注意的是，只有主动使用的token才会出现在日志中，并且启用日志会产生额外费用，这对于活动频繁的账户来说可能会很昂贵。

此外，Azure Metrics也可用于监控存储账户中 SAS token的使用情况。

在默认情况下，Azure会记录和汇总长达 93 天的存储帐户事件。利用Azure Metrics，用户可以通过查找 SAS 验证请求，找到使用 SAS token的存储账户。

SAS秘密扫描

最后是使用秘密扫描工具来检测工件和公开暴露资产中泄漏或过度授权的 SAS token，这在微软的案例中可以看到。

对于Wiz的用户，Wiz提供了秘密扫描功能来识别内部和外部资产中的SAS token，并探索其权限。此外，还可以使用Wiz CSPM跟踪支持SAS的存储账户。

04

Wiz介绍

帮助微软发现这次数据泄漏，防止了可能出现的更严重的后果的Wiz，是一家位于美国纽约，创立于2020年的网络云安全初创公司。

根据公司自己的介绍，他们的业务主要是帮助企业发现公共云基础设施中的安全问题，为企业安全团队设计云原生可视性解决方案，可分析整个云环境，提供跨云、容器和工作负载的安全风险 360° 视图。

在8月底，他们刚刚完成了接近3亿美元的D轮融资，估值接近100亿美元，是云安全领域的一只巨型独角兽。

客户包括了各行各业对于云服务和安全有需求的公司。

4位创始人：Ami Luttwak、Assaf Rappaport、Yinon Costiva 和 Roy Reznik都来自以色列，他们相识于在以色列军队服役期间。

后来4人开发了一个名为Adallom的云访问代理产品，2015年被微软收购。4人因此加入了微软。而他们开发的云安全产品被微软整合了进自己的服务之中，为微软创造了每年接近10亿的云安全业务收入。

当他们发现自己做的业务和产品，在微软Azure之外，也有非常好的市场前景时，他们4人决定离开，共同创立第二家企业——Wiz。

因为他们发现与本地网络安全不同，安全团队无法在「单一管理平台」中查看所有云服务器，而Wiz正是瞄准了这个市场发力，提供了一个支持多个公有云服务的安全管理平台。