深入研究攻击Serverless环境下的应用 SLS-2: 权限绕过

Posted 2021-04-30 安全客

 

前言

感谢您阅读此系列的第二篇文章。上一篇文章我们讨论了注入攻击。在视频中，可以看到使用它攻击传统应用程序到Serverless应用攻击面的变化。对于Serverless应用来说，注入攻击是基于不同源的各种事件。

在这篇文章中，我将研究Serverless应用安全性方面面临的另一个问题。在Serverless架构中，有很多隐秘的入口点，服务，事件和触发规则且没有连续的flow，事情可能会变得更加复杂。与传统应用程序架构不同，Servless应用在Stateless容器中运行。数百个不同的功能，分别运行在不同的Server，这意味着单个的Server没有很大的flow。不同的Server有不同的功能，由不同的事件触发，没有团队协作的概念。

攻击者试图寻找容易被遗忘的资源，像公共云储存仓库和公共API，这意味着作为开发者的我们必须给每个Server和资源加上密钥。然而，面向外部的资源不是唯一需要考虑的。让我们继续深入研究。

外部资源的认证方式通常很脆弱，用暴力破解的方式，攻击者可以使用自动化工具猜测用户的凭据。如果某个网站的认证方式很脆弱，那么攻击者就可以接触到它的敏感内容或功能。弱密码和不安全的密码恢复流程也是属于脆弱的认证方式。好消息，现在现代的网络中，服务器提供商能防御大多数的攻击。我们再也不用担心密码管理，暴力破解和密码恢复流程等安全问题。经验丰富，装备精良的服务提供商将完美防御任何这类攻击。

如果面向外部的资源没有合适的身份认证方式，那么Serverless应用会出现重大安全漏洞。现在，我们唯一要做的就是确保我们的资源配置正确，如恰当的访问权限控制和合适的认证方式。这可以由云服务商提供的身份管理服务轻松完成，如AWS Cognito，Azure AD，Google Firebase或Auth0等服务。

那么，我们可以去睡一觉，等待下一篇文章？NO！当应用的内部功能不是由用户端发出请求（或某些的事件）触发时，事情会变得更加复杂。在应用的整个flow中，存在一些特殊方式可以绕过我们的身份认证架构，接触到一些资源。这种漏洞通常是身份验证和访问控制设计存在缺陷的结果。

 

案例研究

一个非常简单的Serverless应用：

一. 正常的用户通过了身份验证，发送一个API请求，触发一堆内部flows（图中蓝色区域）

二. 用户也可以上传文件（例如图像），其存储在云存储中

三. 典型的Serverless flow：当文件上传到云存储时，触发另一个处理该上传文件的功能。

四. 从下图可以看到，云存储是开放的，不需要任何身份验证。

五. 恶意用户直接上传文件到云存储，触发内部功能，可以绕过身份验证。

所以？只是一个文件上传。这里的安全问题是什么？我们首先要了解我们绕过的flow(s)，让我尝试着全面解读。

在这个例子中，用户通过指定的移动应用提交图片，应用程序打印图片。流程：

可以发现，云存储仓库没有正确的身份认证，可供任何用户直接上传图片文件。

这里可以造成一些攻击。首先，最明显的漏洞，攻击者可以不用付款，使应用跳转到下一个flow（绕过C阶段），即处理上传图片文件（阶段D）。如何实现？ 如果云储存开放写入访问权限，攻击者使用aws cli（AWS命令行界面）就可以进行攻击。

但这里还有另一个漏洞，应用程序会验证上传的文件类型和文件名，以确保没有上传恶意文件。可能有些人已经发现了，D阶段也可以绕过，攻击者可以直接上传恶意文件到云存储仓库。

保护云存储其实很容易，只需简单点击几下就可以阻止公共访问。问题是，我们如何确保内部资源中没有其他脆弱的身份验证方法？没有十全十美的办法。我们可以根据Serverless应用的资源类型和flow设计独特的认证方式，我们选择可以使用知名的服务，例如Federated Identity(e.g. SAML, OAuth2, Security Tokens)，并确保使用经得起实践的产物(e.g. encrypted channels, password and key management, client certificate, OTA/2FA)。

 

演示视频

如果你想观看演示视频，请点击阅读原文。