SeerLight的SkyShip Dusk任何服务的构建都必须包括不断进行的安全性工作。 安全性是一个连续的过程，包括对产品安全性的持续分析和改进，有关漏洞的新闻监视等等。 包括-审核。 审计既可以自己进行，也可以由外部专家进行，他们可以极大地提高安全性，因为他们没有沉浸在项目中并且拥有清晰的视野。
这篇文章是关于帮助Mail.ru云解决方案（MCS）团队测试云服务的外部专家的一种非常不受欢迎的观点，以及他们发现了什么。 作为“外部力量”，MCS选择了以其在安全社区中的高度专业知识而闻名的Digital Security。 在本文中，我们将分析一些在外部审核中发现的有趣漏洞-这样，当您使用云服务时，您将获得相同的收益。
产品说明
Mail.ru云解决方案（MCS）是用于在云中构建虚拟基础架构的平台。 它包括IaaS，PaaS，这是针对开发人员的现成应用程序映像市场。 考虑到MCS的体系结构，有必要在以下方面检查产品安全性：
- 虚拟化环境基础架构保护：虚拟机监控程序，路由，防火墙；
- 保护客户的虚拟基础架构：彼此隔离，包括SDN中的网络，专用网络；
- OpenStack及其开放组件；
- S3自己开发；
- IAM：具有角色模型的多租户项目；
- 视觉（机器视觉）：使用图像时的API和漏洞；
- 网络界面和经典网络攻击；
- PaaS组件的漏洞；
- 所有组件的API。
也许，对随后的历史至关重要的一切就是一切。
进行了什么样的工作，为什么需要它们？
安全审核旨在确定可能导致泄漏个人数据，修改敏感信息或破坏服务可用性的漏洞和配置错误。
在平均持续1-2个月的工作期间，审核员重复了潜在攻击者的操作，并在所选服务的客户端和服务器部分中查找漏洞。 在对MCS云平台进行审核的过程中，确定了以下目标：
- 分析服务中的身份验证。 此组件中的漏洞将有助于立即进入他人的帐户。
- 研究不同帐户之间的角色模型和访问控制。 对于攻击者来说，访问其他人的虚拟机的能力是一个受欢迎的目标。
- 客户端漏洞。 XSS / CSRF / CRLF /等 也许可以通过恶意链接攻击其他用户？
- 服务器端漏洞：RCE和各种注入（SQL / XXE / SSRF等）。 服务器漏洞通常更难找到，但是它们会立即导致许多用户的安全受到威胁。
- 用户段的网段隔离分析。 对于攻击者而言，缺乏隔离性会大大增加其他用户的攻击面。
- 业务逻辑分析。 是否可以愚弄企业并免费创建虚拟机？
在该项目中，工作是根据Gray-box模型进行的：审计员以普通用户的特权与服务进行交互，但部分拥有API的源代码，并有机会与开发人员澄清细节。 通常，这是最方便的方法，同时又是非常现实的工作模型：内部信息仍可由攻击者收集，这只是时间问题。
发现漏洞
在审核员开始将各种有效载荷（用于攻击的有效载荷）发送到随机位置之前，您需要了解其工作原理以及提供的功能。 看来这是徒劳的，因为在大多数研究过的地方都不会存在漏洞。 但是，只有了解了应用程序的结构及其操作的逻辑，才有可能找到最复杂的攻击媒介。
找到看似可疑或与众不同的地方很重要。 并以此方式发现了第一个危险漏洞。
IDOR
IDOR漏洞（不安全的直接对象引用，不安全的直接链接到对象）是业务逻辑中最常见的漏洞之一，它允许一种或另一种方式访问实际上不允许访问的对象。 IDOR漏洞创造了获得不同关键程度用户信息的可能性。
IDOR选项之一是通过操纵这些对象的访问标识符来对系统对象（用户，银行帐户，购物篮中的商品）执行操作。 这导致最不可预测的后果。 例如，可以替换发件人的帐户，这样您就可以从其他用户那里窃取它们。
对于MCS，审核员只是发现了与非系统标识符相关的IDOR漏洞。 在用户的个人帐户中，为了访问任何对象，使用了UUID，就像安全人员所说的那样，UUID看起来很粗糙（即受到了蛮力攻击的保护）。 但是对于某些实体，发现使用普通的可预测数字来获取有关应用程序用户的信息。 我认为您意识到可以将用户ID更改一个，再次发送请求，从而绕过ACL（访问控制列表，进程和用户的数据访问规则）获取信息。
服务器端请求伪造（SSRF）
OpenSource产品之所以不错，是因为它们拥有大量的论坛，其中包含对所出现问题的详细技术描述，如果幸运的话，还提供了解决方案的描述。 但是，这种硬币也有另一面：众所周知的漏洞也已详细描述。 例如，OpenStack论坛对
[XSS]和
[SSRF]漏洞进行了精彩的描述，由于某种原因，没有人急着解决它们。
频繁的应用程序功能是用户将链接发送到服务器所单击的服务器的能力（例如，从指定的源下载图像）。 由于没有足够的安全性来过滤从服务器返回给用户的链接或响应本身，因此攻击者很容易使用这种功能。
SSRF漏洞可以极大地促进攻击的发展。 攻击者可以获得：
- 仅在某些网段和某种协议上对受攻击的本地网络的访问受到限制；
- 如果可以从应用程序级别降级到传输级别，则可以完全访问本地网络，因此可以在应用程序级别进行完全负载管理；
- 可以读取服务器上的本地文件（如果支持文件：/// scheme）；
- 还有更多。
长期以来，OpenStack一直以其“盲” SSRF漏洞而闻名：访问服务器时，您不会从中得到响应，但是根据请求的结果，您会得到不同类型的错误/延迟。 基于此，您可以扫描内部网络上主机上的端口，并附带所有随之而来的后果，不要小看。 例如，产品可能具有仅可从公司网络获得的用于后台的API。 拥有文档（不要忘记内部人员），攻击者可以使用内部方法使用SSRF。 例如，如果您设法以某种方式获得了有用URL的近似列表，则可以使用SSRF遍历它们并执行请求-相对而言，从一个帐户到另一个帐户转帐或更改限额。
这不是检测OpenStack中SSRF漏洞的第一种情况。 过去，可以通过直接链接下载VM ISO映像，这也导致了类似的后果。 此功能当前已从OpenStack中删除。 显然，社区认为这是解决问题的最简单，最可靠的方法。
在
此来自HackerOne（h1）服务的公开报告中，利用具有读取实例元数据功能的非盲SSRF导致对整个Shopify基础结构的Root访问。
在MCS中，在两个功能相似的地方发现了SSRF漏洞，但是由于防火墙和其他保护措施，几乎无法利用它们。 无论如何，MCS团队无论如何都可以解决此问题，而无需等待社区。
XSS而不是加载外壳
尽管进行了数百篇研究，但每年XSS（跨站点脚本攻击）仍然是最
常见的 Web漏洞（或
攻击 ？）。
下载文件是任何安全研究人员最喜欢的地方。 通常，您可以使用渗透测试者的术语“加载外壳”来加载任意脚本（asp / jsp / php）并执行OS命令。 但是，此类漏洞的流行有两个方向：记住和开发针对这些漏洞的工具，因此最近“加载外壳”的可能性趋于零。
攻击团队（由Digital Security代表）很幸运。 OK，在MCS中，在服务器端，检查了下载文件的内容，仅允许使用图像。 但是SVG也是一张图片。 SVG图片有什么危险？ 因为您可以在其中嵌入JavaScript片段！
事实证明，下载的文件可用于MCS服务的所有用户-这意味着您可以攻击云的其他用户，即管理员。
使用XSS攻击使用网络钓鱼登录表单的示例利用XSS攻击的示例：
- 如果下载的脚本可以立即访问资源API，为什么还要尝试窃取会话（尤其是自从现在以来，使用JS脚本防止HTTP-only cookie受到盗窃）？ 在这种情况下，有效负载可以通过XHR请求更改服务器配置，例如，添加攻击者的公共SSH密钥并获得对服务器的SSH访问权限。
- 如果CSP策略（内容保护策略）禁止执行JavaScript，则攻击者可能会没有它。 用纯HTML伪造网站的伪造登录表单，并通过这种高级网络钓鱼来窃取管理员的密码：用户的网络钓鱼页面位于相同的URL，用户很难检测到它。
- 最后，攻击者可以安排客户端DoS-设置大于4 KB的cookie。 用户只要打开链接一次就可以访问整个站点，直到您特别怀疑要清理浏览器为止，整个站点都无法访问：在大多数情况下，Web服务器将拒绝接受此类客户端。
让我们看一下另一个揭示的XSS的示例，这次使用更棘手的操作。 MCS服务允许您将防火墙设置组合为组。 在组名中发现了XSS。 它的特点是，引导程序不能立即运行，不是在查看规则列表时，而是在删除组时：
也就是说，场景如下：攻击者创建了一个名称为“ load”的防火墙规则，管理员过了一会儿注意到了该规则，并启动了删除过程。 在这里，恶意JS也可以实现。
对于MCS开发人员，为了防止可下载的SVG映像中的XSS（如果不能放弃它们），数字安全团队建议：
- 用户在单独的域上上传的主机文件，与“ cookie”无关。 该脚本将在另一个域的上下文中执行，并且不会对MCS构成威胁。
- 在服务器的HTTP响应中，提供标题“ Content-disposition：附件”。 然后，文件将由浏览器下载，而不执行。
此外，开发人员现在可以通过多种方法来减轻XSS的风险：
- 使用“仅HTTP”标志，可以使恶意JavaScript无法访问Cookie的会话标头；
- 正确实施的CSP策略将使攻击者XSS的操作大大复杂化；
- 诸如Angular或React之类的现代模板引擎会先自动清除用户数据，然后再将其显示在用户的浏览器中。
两因素身份验证漏洞
为了提高帐户安全性，始终建议用户启用2FA（两因素身份验证）。 确实，这是一种有效的方法，可以防止攻击者在用户凭据受到破坏时获得对服务的访问权限。
但是，使用第二个身份验证因子是否始终可以保证帐户的安全性？ 在2FA实施中，存在以下安全问题：
- 粗略搜索OTP代码（一次性代码）。 尽管操作简单，但大公司也遇到诸如无法防止OTP暴力的错误，例如Slack 案，Facebook案 。
- 弱生成算法，例如，预测以下代码的能力。
- 逻辑错误，例如，与Shopify一样，可以在手机上请求其他人的OTP。
对于MCS，基于Google Authenticator和
Duo实施2FA。 协议本身已经经过时间测试，但是在应用程序端进行代码验证的实现值得检查。
MCS 2FA在多个地方使用：
- 在用户身份验证时。 这里有防止暴力的保护措施：用户只有几次尝试输入一次性密码，然后输入被阻止了一段时间。 这阻止了执行OTP清除的功能。
- 生成脱机备份代码以运行2FA以及将其关闭时。 此处，未实施防止暴力破解的保护措施，如果存在帐户密码和活动会话，则可以重新生成备份代码或完全禁用2FA。
考虑到备用代码与OTP应用程序生成的代码位于相同的行值范围内，因此在短时间内提取代码的机会要高得多。
使用Burp：Intruder工具选择OTP以禁用2FA的过程结果
总的来说，MCS作为一种产品是安全的。 在审核期间，Pentester团队无法访问客户端VM及其数据，并且发现的漏洞已由MCS团队快速修复。
但是这里需要注意的是，安全性是一项持续的工作。 服务不是一成不变的，它们在不断发展。 完全开发没有漏洞的产品是不可能的。 但是您可以及时找到它们，并最大程度地减少重复的机会。
现在，MCS中提到的所有漏洞都已修复。 为了最大程度地减少新产品的数量并缩短其使用寿命，平台团队将继续这样做：