深入考察无服务器架构的安全威胁，SLS-1：事件注入
|
最终，攻击者可以通过注入代码来修改原始机器人的行为。在下面的示例中，我们可以看到攻击者是如何通过恶意payload修改机器人的化身，并打印原始的ICON_URL (很明显，窃取BOT_TOKEN本身可能会导致部分接管Slack帐户) 的:
当然，攻击者也可以注入使用提供程序API的代码，例如AWS-SDK。这样的话，将允许攻击者与该帐户下的其他资源进行交互。例如，由于易受攻击的函数会从某个DynamoDB表读取数据，因此，攻击者可以使用DynamoDB.DocumentClient.scan()函数以及代码中已有的表数据，从同一个表中读取信息，并利用Slack通道发送窃取的数据：
但是，通过Slack攻击无服务器函数，只是针对应用程序生命周期的新型攻击途径之一。此外，攻击者还可以通过电子邮件（主题、附件或标题）、MQTT发布/订阅消息、云存储事件（文件上传/下载等）、队列、日志、代码提交或任何可以触发我们代码的其他事件来发动这种攻击。 当然，这种攻击的影响还是有所不同的。由于没有服务器，因此，也就无法接管服务器了。但是，尽管在我们的示例中，攻击者能够读取代码、模拟函数、从数据库中窃取数据并入侵该slack账户，但根据易受攻击函数的权限的不同，在某些情况下，可能会导致云账户被完全接管(我们将在后续文章中加以介绍，敬请关注！)。如果该函数能够访问其他资源，那么，只需注入相应的代码即可。
那么，我们应该如何防范这种攻击呢？不是所有的事情都需要改变。大多数传统的最佳实践也适用于无服务器架构环境。永远不要信任输入或对输入的合法性做出任何假设，使用安全的API，并尝试以执行任务所需的最低权限运行代码，以减少攻击面。此外，开发人员还必须接受编写安全代码所需的相关培训——现实告诉我们，这是不可能的。 然而，作为人类，我们非常容易出错的。因此，我们必须找到一种自动化的方法，来进行预防。但是，如果没有一个布防的边界，我们该如何是好呢？ 我们认为，无服务器架构环境的防御控制机制，也应该是基于无服务器架构的。否则，我们会失去转移到无服务器环境中的一切。一位智者曾经说过，就像我们不能用剑来保护我们的宇宙飞船一样，我们也不能用旧技术来保护新技术。无服务器架构的防御机制应该是短暂的，它将与其保护的代码一起生死存亡。 此外，还有其他方面的一些因素，使得无服务器架构下的注入攻击不同于传统的注入攻击。我们已经讨论过一些，比如不同类型的输入源、大多数动态语言以及环境中的相关(和无关)文件。同时，还有其他方面的区别。例如，无服务器函数的生存时间通常只有几秒到几分钟。在这样的环境中，攻击该如何实现持续化呢？正常的攻击肯定会持续到函数失效，攻击者可能不得不重复发动攻击，这会导致被发现的概率增大。然而，该攻击还有其他实现持久化的方式。一种方法是直接维持容器的“体温”，这意味着攻击者每隔几分钟就会触发一次事件，以确保容器继续运行。另一种方法是注入payload来修改函数的源代码，这些将在后面的文章中详解介绍。这种方法将导致所有新容器都将与恶意代码一起运行，从而导致环境被攻击者长期占据。 【编辑推荐】
点赞 0 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
