欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

深入考察无服务器架构的安全威胁,SLS-1:事件注入

来源:本站整理 作者:佚名 时间:2019-01-09 TAG: 我要投稿

通过观察代码,发现它好像是用来查看Slack请求的:

即使无法从代码中读取环境变量值,攻击者也可以直接使用它们,因为它们是环境的组成部分。
最终,攻击者可以通过注入代码来修改原始机器人的行为。在下面的示例中,我们可以看到攻击者是如何通过恶意payload修改机器人的化身,并打印原始的ICON_URL (很明显,窃取BOT_TOKEN本身可能会导致部分接管Slack帐户) 的:

当然,攻击者也可以注入使用提供程序API的代码,例如AWS-SDK。这样的话,将允许攻击者与该帐户下的其他资源进行交互。例如,由于易受攻击的函数会从某个DynamoDB表读取数据,因此,攻击者可以使用DynamoDB.DocumentClient.scan()函数以及代码中已有的表数据,从同一个表中读取信息,并利用Slack通道发送窃取的数据:

但是,通过Slack攻击无服务器函数,只是针对应用程序生命周期的新型攻击途径之一。此外,攻击者还可以通过电子邮件(主题、附件或标题)、MQTT发布/订阅消息、云存储事件(文件上传/下载等)、队列、日志、代码提交或任何可以触发我们代码的其他事件来发动这种攻击。
当然,这种攻击的影响还是有所不同的。由于没有服务器,因此,也就无法接管服务器了。但是,尽管在我们的示例中,攻击者能够读取代码、模拟函数、从数据库中窃取数据并入侵该slack账户,但根据易受攻击函数的权限的不同,在某些情况下,可能会导致云账户被完全接管(我们将在后续文章中加以介绍,敬请关注!)。如果该函数能够访问其他资源,那么,只需注入相应的代码即可。

那么,我们应该如何防范这种攻击呢?不是所有的事情都需要改变。大多数传统的最佳实践也适用于无服务器架构环境。永远不要信任输入或对输入的合法性做出任何假设,使用安全的API,并尝试以执行任务所需的最低权限运行代码,以减少攻击面。此外,开发人员还必须接受编写安全代码所需的相关培训——现实告诉我们,这是不可能的。
然而,作为人类,我们非常容易出错的。因此,我们必须找到一种自动化的方法,来进行预防。但是,如果没有一个布防的边界,我们该如何是好呢?
我们认为,无服务器架构环境的防御控制机制,也应该是基于无服务器架构的。否则,我们会失去转移到无服务器环境中的一切。一位智者曾经说过,就像我们不能用剑来保护我们的宇宙飞船一样,我们也不能用旧技术来保护新技术。无服务器架构的防御机制应该是短暂的,它将与其保护的代码一起生死存亡。
此外,还有其他方面的一些因素,使得无服务器架构下的注入攻击不同于传统的注入攻击。我们已经讨论过一些,比如不同类型的输入源、大多数动态语言以及环境中的相关(和无关)文件。同时,还有其他方面的区别。例如,无服务器函数的生存时间通常只有几秒到几分钟。在这样的环境中,攻击该如何实现持续化呢?正常的攻击肯定会持续到函数失效,攻击者可能不得不重复发动攻击,这会导致被发现的概率增大。然而,该攻击还有其他实现持久化的方式。一种方法是直接维持容器的“体温”,这意味着攻击者每隔几分钟就会触发一次事件,以确保容器继续运行。另一种方法是注入payload来修改函数的源代码,这些将在后面的文章中详解介绍。这种方法将导致所有新容器都将与恶意代码一起运行,从而导致环境被攻击者长期占据。
 

上一页  [1] [2] 

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载