通过西尔莱特
构建任何服务都必然包括持续的安全工作。安全是一个持续的过程，包括不断分析和改进产品安全、监控有关漏洞的新闻等等。包括审计。审计由内部和外部专家进行，他们可以从根本上帮助安全，因为他们没有沉浸在项目中并且有开放的心态。
本文介绍了帮助 Mail.ru 云解决方案 (MCS) 团队测试云服务的外部专家的最直接观点以及他们的发现。作为“外部力量”，MCS选择了在信息安全领域拥有深厚专业知识的Digital Security公司。在本文中，我们将分析作为外部审计的一部分发现的一些有趣的漏洞 - 以便您在创建自己的云服务时避免相同的佣金。
Описаниепродукта
是一个在云中构建虚拟基础设施的平台。它包括 IaaS、PaaS 以及为开发人员提供的现成应用程序映像市场。考虑到MCS架构，有必要在以下几个方面检查产品的安全性：
- 保护虚拟化环境的基础设施：管理程序、路由、防火墙；
- 保护客户的虚拟基础设施：相互隔离，包括SDN中的网络、专用网络；
- OpenStack 及其开放组件；
- 我们自己设计的S3；
- IAM：具有角色模型的多租户项目；
- 视觉（计算机视觉）：处理图像时的 API 和漏洞；
- Web 界面和经典的 Web 攻击；
- PaaS组件的漏洞；
- 所有组件的API。
也许这就是进一步历史所必需的一切。
开展了哪些工作以及为什么需要开展这项工作？
安全审核旨在识别可能导致个人数据泄露、敏感信息修改或服务可用性中断的漏洞和配置错误。
在平均持续 1-2 个月的工作中，审核员重复潜在攻击者的操作，并查找所选服务的客户端和服务器部分中的漏洞。在 MCS 云平台审核的背景下，确定了以下目标：
- 服务中的身份验证分析。该组件中的漏洞将有助于立即进入其他人的帐户。
- 研究角色模型和不同帐户之间的访问控制。对于攻击者来说，能够访问其他人的虚拟机是一个理想的目标。
- 客户端漏洞。 XSS/CSRF/CRLF/等。是否有可能通过恶意链接攻击其他用户？
- 服务器端漏洞：RCE和各类注入（SQL/XXE/SSRF等）。服务器漏洞通常更难发现，但它们会导致许多用户同时受到危害。
- 网络层面的用户段隔离分析。对于攻击者来说，缺乏隔离会大大增加针对其他用户的攻击面。
- 业务逻辑分析。难道可以欺骗商家，免费创建虚拟机吗？
在这个项目中，工作是按照“灰盒”模型进行的：审计人员以普通用户的权限与服务进行交互，但拥有部分API的源代码，并有机会与开发人员澄清细节。这通常是最方便的，同时也是相当现实的工作模型：攻击者仍然可以收集内部信息，这只是时间问题。
发现漏洞
在审计员开始向随机位置发送各种有效负载（用于执行攻击的有效负载）之前，有必要了解事物的工作原理以及提供的功能。这似乎是一个无用的练习，因为在大多数研究的地方都不存在漏洞。但只有了解应用程序的结构及其运行逻辑，才有可能找到最复杂的攻击向量。
找到看起来可疑或在某些方面与其他地方非常不同的地方很重要。第一个危险漏洞就这样被发现了。
多尔
IDOR（不安全直接对象引用）漏洞是业务逻辑中最常见的漏洞之一，它允许一个或另一个访问实际上不允许访问的对象。 IDOR 漏洞使得获取有关不同重要程度的用户的信息成为可能。
IDOR 选项之一是通过操纵系统对象（用户、银行帐户、购物车中的物品）的访问标识符来执行这些对象的操作。这会导致最不可预测的后果。例如，可以替换资金发送者的帐户，通过它您可以从其他用户那里窃取资金。
就 MCS 而言，审计人员刚刚发现了与非安全标识符相关的 IDOR 漏洞。在用户的个人帐户中，UUID 标识符用于访问任何对象，正如安全专家所说，这似乎非常不安全（即免受暴力攻击）。但对于某些实体，人们发现常规的可预测数字用于获取有关应用程序用户的信息。我想你可以猜到，有可能将用户ID更改1，再次发送请求，从而绕过ACL（访问控制列表，进程和用户的数据访问规则）获取信息。
服务器端请求伪造 (SSRF)
开源产品的好处是它们有大量的论坛，其中有对出现的问题的详细技术描述，如果幸运的话，还有解决方案的描述。但这枚硬币也有另一面：已知的漏洞也有详细描述。比如OpenStack论坛上有精彩的漏洞描述 и ，由于某种原因没有人急于修复。
应用程序的一个常见功能是用户能够向服务器发送链接，服务器单击该链接（例如，从指定源下载图像）。如果安全工具不过滤链接本身或从服务器返回给用户的响应，则此类功能很容易被攻击者利用。
SSRF 漏洞可以极大地促进攻击的发展。攻击者可以获得：
- 对受攻击本地网络的访问受到限制，例如只能通过某些网段并使用某种协议；
- 如果可以从应用层降级到传输层，则可以完全访问本地网络，从而实现应用层的满负载管理；
- 访问读取服务器上的本地文件（如果支持 file:/// 方案）；
- 等等。
OpenStack 中的 SSRF 漏洞早已为人所知，其本质上是“盲目”的：当您联系服务器时，您没有收到服务器的响应，但您会收到不同类型的错误/延迟，具体取决于请求的结果。基于此，您可以对内部网络的主机进行端口扫描，随之而来的一切后果不容小觑。例如，产品可能具有只能从公司网络访问的后台 API。通过文档（不要忘记内部人员），攻击者可以使用 SSRF 访问内部方法。例如，如果您能够以某种方式获得有用 URL 的大致列表，那么使用 SSRF 您可以浏览它们并执行请求 - 相对而言，从一个帐户转移到另一个帐户或更改限额。
这并不是 OpenStack 第一次发现 SSRF 漏洞。过去，可以从直接链接下载VM ISO映像，这也导致了类似的后果。该功能现已从 OpenStack 中删除。显然，社区认为这是解决该问题最简单、最可靠的方法。
而在 来自 HackerOne 服务 (h1) 的公开报告显示，利用不再盲目的 SSRF 并能够读取实例元数据，可以实现对整个 Shopify 基础设施的 Root 访问。
在MCS中，在两个具有类似功能的地方发现了SSRF漏洞，但由于防火墙和其他保护措施，它们几乎不可能被利用。不管怎样，MCS 团队还是解决了这个问题，没有等待社区。
XSS而不是加载shell
尽管撰写了数百份研究报告，但年复一年的 XSS（跨站脚本）攻击仍然是最严重的 网络漏洞（或 ？）。
文件上传是任何安全研究人员最喜欢的地方。事实证明，您通常可以加载任意脚本（asp/jsp/php）并执行操作系统命令，用渗透测试人员的术语来说就是“加载 shell”。但此类漏洞的流行是双向的：它们被记住，并且针对它们制定了补救措施，因此最近“加载 shell”的概率趋于零。
攻击团队（以 Digital Security 为代表）很幸运。好的，在服务器端的 MCS 中检查了下载文件的内容，只允许使用图像。但SVG也是一张图片。 SVG 图像有什么危险？因为您可以将 JavaScript 片段嵌入其中！
事实证明，下载的文件可供MCS服务的所有用户使用，这意味着有可能攻击其他云用户，即管理员。
针对网络钓鱼登录表单的 XSS 攻击示例
XSS 攻击利用示例：
- 如果加载的脚本可以立即访问资源 API，为什么要尝试窃取会话（尤其是现在 HTTP-Only cookie 无处不在，可以使用 js 脚本防止盗窃）？在这种情况下，有效负载可以使用 XHR 请求来更改服务器配置，例如，添加攻击者的公共 SSH 密钥并获得对服务器的 SSH 访问权限。
- 如果 CSP 策略（内容保护策略）禁止 JavaScript 注入，那么攻击者无需注入 JavaScript 也能成功。使用纯 HTML，为网站创建一个虚假的登录表单，并通过这种高级网络钓鱼窃取管理员密码：用户的网络钓鱼页面最终位于相同的 URL，并且用户更难以检测到它。
- 最后，攻击者可以安排 — 设置大于 4 KB 的 Cookie。用户只需要打开一次链接，整个网站就变得无法访问，直到用户想到专门清理浏览器：在绝大多数情况下，Web 服务器会拒绝接受这样的客户端。
让我们看一下另一个检测到的 XSS 示例，这次有一个更巧妙的利用。 MCS 服务允许您将防火墙设置组合成组。组名是检测到 XSS 的位置。它的奇特之处在于，向量不会立即触发，不是在查看规则列表时触发，而是在删除组时触发：
也就是说，场景如下：攻击者创建了一条名称中带有“load”的防火墙规则，管理员在一段时间后注意到它并启动了删除过程。这就是恶意 JS 的作用所在。
对于 MCS 开发人员，为了防止下载的 SVG 图像中的 XSS（如果无法放弃），数字安全团队建议：
- 将用户上传的文件放置在与“cookie”无关的单独域中。该脚本将在不同域的上下文中执行，不会对 MCS 构成威胁。
- 在服务器的 HTTP 响应中，发送“Content-disposition：附件”标头。然后文件将被浏览器下载并且不会被执行。
此外，现在开发人员可以通过多种方法来降低 XSS 攻击的风险：
- 使用“HTTP Only”标志，您可以使恶意 JavaScript 无法访问会话“Cookies”标头；
- 将使攻击者更难利用 XSS；
- 现代模板引擎（例如 Angular 或 React）会在将用户数据输出到用户浏览器之前自动对其进行清理。
双因素身份验证漏洞
为了提高账户安全性，建议用户启用2FA（双因素身份验证）。事实上，如果用户的凭据已被泄露，这是防止攻击者获得服务访问权限的有效方法。
但是使用第二个身份验证因素是否总能保证帐户安全？ 2FA的实施存在以下安全问题：
- 暴力搜索 OTP 代码（一次性代码）。尽管操作简单，但大公司也会遇到诸如缺乏OTP暴力破解防护等错误： , .
- 弱生成算法，例如预测下一个代码的能力。
- 逻辑错误，例如能够在您的手机上请求他人的 OTP，如下所示 来自 Shopify。
对于 MCS，2FA 是基于 Google Authenticator 实现的， 。协议本身已经经过了时间的考验，但应用端代码验证的实现值得检验。
MCS 2FA 用于多个地方：
- 验证用户身份时。有针对暴力破解的保护：用户只能尝试几次输入一次性密码，然后输入会被阻止一段时间。这阻止了暴力选择 OTP 的可能性。
- 当生成离线备份代码以执行 2FA 时，以及禁用它。在这里，没有实施暴力保护，如果您有帐户密码和活动会话，则可以重新生成备份代码或完全禁用 2FA。
考虑到备份代码与 OTP 应用程序生成的字符串值位于相同范围内，因此在短时间内找到代码的机会要高得多。
使用“Burp: Intruder”工具选择 OTP 来禁用 2FA 的过程
导致
总体而言，MCS 作为一种产品似乎是安全的。在审计过程中，渗透测试团队无法访问客户端虚拟机及其数据，MCS 团队很快纠正了发现的漏洞。
但这里需要注意的是，安全是一项持续的工作。服务不是静态的，而是不断发展的。并且不可能开发出完全没有漏洞的产品。但你可以及时发现它们并最大限度地减少它们复发的机会。
目前MCS中提到的所有漏洞均已得到修复。为了将新的数量保持在最低限度并缩短其生命周期，平台团队继续这样做：
- 定期由外部公司进行审计；
- 支持和发展参与;
- 从事安全工作。 🙂
来源： habr.com