逆天！Wiz发现微软AI研究人员意外泄露38TB数据
Wiz 在的AI 存储库上发现了一起数据泄露事件，其中包括30,000多条 Teams内部消息，所有这些都是由一个错误配置的SAS令牌造成的。
核心要点
关于微软的发现
作为Wiz研究团队在云托管数据意外暴露方面持续工作的一部分，该团队扫描了互联网以查找错误配置的存储容器。在这个过程中，我们发现了一个名为"--"的存储库，该存储库属于微软的AI研究部门，其目的是提供用于图像识别的开源代码和AI模型。该存储库的读者被指示从Azure存储的URL下载这些模型：
The URL, taken from ’s
然而，这个URL不仅允许访问开源模型。它被配置为授予整个存储帐户的权限，因此错误地暴露了额外的私人数据。
我们的扫描显示，这个帐户包含了38TB的额外数据token 权限管理·(中国)官方网站，其中包括微软员工的个人计算机备份。这些备份包含了敏感的个人数据，包括用于访问微软服务的密码、秘密密钥，以及来自359名微软员工的超过30,000条内部 Teams消息。
under the '39'
A small of files found on the
Teams two
除了过于宽松的访问范围外，该令牌还配置错误，允许“完全控制”权限而不是只读权限。这意味着攻击者不仅可以查看存储帐户中的所有文件，还可以删除和覆盖现有文件。
这尤其有趣，考虑到该存储库的原始用途：提供用于训练代码的AI模型。该存储库指示用户从SAS链接下载模型数据文件，并将其输入到脚本中。文件的格式是ckpt，这是由库生成的格式。它使用的格式化程序进行格式化，这在设计上容易受到任意代码执行的影响。这意味着攻击者本可以将恶意代码注入到该存储帐户中的所有AI模型中，而信任微软的存储库的每个用户都会受到感染。
然而，重要的是要注意，这个存储帐户并没有直接对公众暴露；事实上，它是一个私有存储帐户。微软的开发人员使用了一种名为“SAS令牌”的Azure机制，该机制允许您创建一个可共享的链接，授予对Azure存储帐户数据的访问权限，而在检查时，存储帐户仍然看起来完全私有。
关于SAS令牌的介绍
在Azure中，共享访问签名（SAS， ）令牌是一种已签名的URL，用于授予对Azure存储数据的访问权限。用户可以自定义访问级别，权限范围从只读到完全控制，而范围可以是单个文件、容器或整个存储帐户。过期时间也是完全可定制的，允许用户创建永不过期的访问令牌。这种细粒度提供了用户极大的灵活性，但也存在授予过多访问权限的风险；在最宽松的情况下（正如我们在上文中看到的微软的令牌），该令牌可以在整个帐户上永久授予完全控制权限，本质上提供了与帐户密钥本身相同的访问级别。
有三种类型的SAS令牌：帐户SAS、服务SAS和用户委托SAS。在本博客中，我们将重点关注最常见的类型——帐户SAS令牌，这种类型也在微软的存储库中使用。
生成帐户SAS是一个简单的过程。如下图所示，用户配置令牌的范围、权限和到期日期，然后生成令牌。在幕后，浏览器从Azure下载帐户密钥，并用密钥对生成的令牌进行签名。整个过程在客户端完成；这不是Azure事件，生成的令牌也不是Azure对象。
a high non- SAS token
因此，当用户创建了一个高度宽松且永不过期的令牌时，管理员无法知道该令牌的存在以及它在哪里传播。撤销令牌也不是一项容易的任务——它需要轮换签署令牌的帐户密钥，使由同一密钥签署的所有其他令牌也变得无效。这些独特的陷阱使得这项服务成为寻找暴露数据的攻击者的容易目标。
除了意外暴露的风险外，该服务的缺陷使其成为攻击者寻求在受损的存储帐户上维护持久性的有效工具。微软最近的一份报告显示，攻击者正在利用该服务缺乏监控功能的情况，以发放特权的SAS令牌作为后门。由于令牌的发放在任何地方都没有记录，因此无法知道它已发放并采取行动。
SAS的安全风险
SAS令牌存在安全风险，因为它们允许与外部未识别的身份共享信息。这个风险可以从多个角度来考虑：权限、卫生、管理和监控。
权限
SAS令牌可以授予对存储帐户非常高的访问级别，无论是通过过多的权限（如读取、列出、写入或删除），还是通过广泛的访问范围，允许用户访问相邻的存储容器。
卫生
SAS令牌存在到期问题——我们的扫描和监控显示，组织通常使用具有非常长（有时是永久）寿命的令牌，因为令牌的到期没有上限。微软的令牌就是这种情况，它有效期直到2051年。
管理和监控
帐户SAS令牌极其难以管理和撤销。在Azure内部没有官方方法来跟踪这些令牌，也没有监控它们的发放，这使得很难知道已经发放了多少令牌并且正在活跃使用。甚至连发放都无法追踪的原因是SAS令牌是在客户端创建的，因此它不是Azure跟踪的活动，生成的令牌也不是Azure对象。因此，即使看似是私有的存储帐户，也可能在很大程度上暴露。
至于撤销，没有办法撤销单个帐户SAS；唯一的解决方案是撤销整个帐户密钥，这也会使得所有使用相同密钥发放的其他令牌失效。
监控SAS令牌的使用是另一个挑战，因为它需要分别在每个存储帐户上启用日志记录。此外，这可能会成本高昂，因为价格取决于每个存储帐户的请求量。
SAS安全建议
SAS安全性可以通过以下建议显著提高。
管理
由于对帐户SAS令牌缺乏安全性和管理，它们应被视为与帐户密钥本身一样敏感。因此，强烈建议避免使用帐户SAS进行外部共享。令牌创建错误很容易被忽视，从而暴露敏感数据。
对于外部共享，考虑使用带有存储访问策略的服务SAS。这个功能将SAS令牌连接到服务器端策略，提供了集中管理策略和撤销策略的能力。
如果需要在有限的时间内共享内容imToken钱包下载，请考虑使用用户委托SAS，因为它们的到期时间被限制在7天。这个功能将SAS令牌连接到Azure 的身份管理，提供了对令牌创建者及其用户的身份的控制和可见性。
此外，我们建议为外部共享创建专用的存储帐户，以确保过度授权的令牌的潜在影响仅限于外部数据。
要完全避免SAS令牌，组织必须分别禁用每个存储帐户的SAS访问。我们建议使用云安全和合规性管理（CSPM）工具来跟踪和强制执行此策略。
另一种禁用SAS令牌创建的解决方案是阻止Azure中的“列出存储帐户密钥”操作的访问（因为没有密钥，无法创建新的SAS令牌），然后轮换当前的帐户密钥，以使现有的SAS令牌失效。这种方法仍然允许创建用户委托SAS，因为它依赖于用户的密钥而不是帐户密钥。
监控
要跟踪活跃的SAS令牌使用情况，您需要为每个存储帐户启用存储分析日志。生成的日志将包含SAS令牌访问的详细信息，包括签名密钥和分配的权限。然而，需要注意的是，只有活跃使用的令牌才会出现在日志中，并且启用日志记录会带来额外的费用，对于活动频繁的帐户来说可能会成本高昂。
Azure度量标准可用于监控存储帐户中的SAS令牌使用情况。默认情况下，Azure记录和汇总存储帐户事件，最长保留93天。利用Azure度量标准，用户可以查找通过SAS认证的请求，突出显示使用SAS令牌的存储帐户。
秘密扫描
此外，我们建议使用秘密扫描工具来检测泄露或过度授权的SAS令牌，这些令牌可能存在于构件和公开暴露的资产中，例如移动应用、网站和存储库，就像在微软的案例中看到的那样。
在AI流程中的安全风险
随着公司更广泛地采用AI技术，安全团队需要理解AI开发过程中每个阶段固有的安全风险。
本博客中详细介绍的事件就是其中两个风险的例子。
首先是数据的过度共享。研究人员收集并分享大量的外部和内部数据，以构建他们AI模型所需的培训信息。这会带来与高规模数据共享相关的固有安全风险。安全团队需要为AI数据集的外部共享制定明确的准则，就像我们在这个案例中看到的，将公开AI数据集分离到专用存储帐户可能会限制曝光。
第二个是供应链攻击的风险。由于不恰当的权限设置，公共令牌授予了对包含AI模型的存储帐户的写访问权限。如上所述，将恶意代码注入模型文件可能会导致对使用存储库模型的其他研究人员的供应链攻击。安全团队应该检查和清理来自外部来源的AI模型，因为它们可以用作远程代码执行的向量。
结论要点
简单地共享AI数据集导致了一个重大的数据泄露，其中包含超过38TB的私人数据。根本原因是使用帐户SAS令牌作为共享机制。由于缺乏监控和治理，SAS令牌存在安全风险，它们的使用应尽量限制。这些令牌很难跟踪，因为微软没有提供在Azure门户内集中管理它们的方式。此外，这些令牌可以配置为有效期永久，没有到期时间的上限。因此，不安全的是将帐户SAS令牌用于外部共享，应该避免使用。
在更广泛的范围内，通过让安全团队更多地了解AI研究和开发团队的流程，可以预防类似的事件发生。随着公司内部对AI模型的广泛采用，重要的是要在AI开发过程的每一步中提高与相关安全风险的意识，并确保安全团队与数据科学和研究团队密切合作，确保定义了适当的安全措施。
微软关于此问题的报告可以在MSRC博客上找到。
时间线
原文链接：
--of---in-a---due-to---sas-token/
往期回顾
网安商业观察
关注「安全喵喵站」，后台回复关键词【报告】，即可获取网安行业研究报告精彩内容合集：
《网安供应链厂商成分分析及国产化替代指南》，《网安新兴赛道厂商速查指南》，《2023中国威胁情报订阅市场分析报告》，《网安初创天使投资态势报告》，《全球网络安全创业加速器调研报告》，《网安创业生态图》，《網安新興賽道廠商速查指南·港澳版》，《台湾资安市场地图》，《全球网络安全全景图》，《全球独角兽俱乐部行业全景图》，《全球网络安全创业生态图》
话题讨论，内容投稿，报告沟通，商务合作等，请联系喵喵 。
