看我如何通使用Lambda函数对AWS帐户进行攻击测试

  • A+
所属分类:未分类

严正声明:本文涉及到的内容和技术仅用于教育和讨论目的,严禁用于非法用途。

前言

2018年8月3号,我收到了一条神秘的LinkedIn消息,这条消息来自Caleb Sima,内容如下:

LinkedIn消息

我不得不承认,我一开始都没反应过来Caleb想跟我说啥,不过看了一下URL之后(其中包含了Lambda和Shell),我感觉他应该是想告诉我他开发出了一种通过Lambda函数来执行Shell命令的技术。我之前也见过类似的东西,比如说Lambdash。几秒钟之后,我打算点进去看一看这个Web页面,然后发现了:

LinkedIn消息

看到这段话之后,我首先得弄清楚Caleb的动机,所以我给他发了一条信息:

LinkedIn消息

好吧,Caleb是打算让别人通过Lambda函数来攻击他的AWS账号,并最终实现Shell命令的运行。听起来确实值得一试,毕竟现在很难有人愿意把自己的账号给别人去免费“蹂躏”了,这让我非常兴奋!

第一步:收集情报

首先,我在当前目录(/var/task)下运行“ ls -IF”命令来提取函数处理器的文件名:

提取函数处理器的文件名

拿到文件名(index.js)之后,我通过运行“cat index.js”命令来获取函数的源代码:

获取函数的源代码

实际上,最初的源代码并没有让我感到惊讶,因为它就是普通的利用Lambda函数执行Shell命令的一段代码,我之前也已经见过很多类似的了。

我跟我自己说:“好吧,我现在能运行Shell命令了,可是那然后呢?我怎么才能给这个账号带来一点实际的威胁呢?”

于是,我打算收集更多信息,然后我列出了所有的环境变量,我想看看Caleb有没有留下一些有用的东西,这里可以使用‘env’命令:

使用‘env’命令

第二步:冒充Lambda函数

在对环境变量进行渗入分析之后,我发现当一个AWS Lambda函数执行时,它会使用一个由开发者(IAM角色)提供的临时安全证书。此时需要从AWS STS(安全令牌服务)接收以下三个参数:

AWS_SECRET_ACCESS_KEY

AWS_ACCESS_KEY_ID

AWS_SESSION_TOKEN

这是三个非常敏感的令牌,但是却直接在我的屏幕上作为环境变量打印了出来…

如果你不熟悉AWS IAM安全模型的话,我可以告诉你,这是一个非常强大且细粒度非常高的安全权限模型,模型的具体介绍可参考AWS提供的IAM角色文档:【传送门】。

既然我们已经拿到了AWS STS给函数生成的令牌了,那接下来就好办了。这里我可以直接使用令牌来在本地设备上调用AWS的命令行接口。此时我需要通过调用下列命令来在本地设置这些环境变量:

/>export AWS_SECRET_ACCESS_KEY = …..

/>export AWS_ACCESS_KEY_ID = ….

/>export AWS_SESSION_TOKEN = ....

为了测试这些令牌,我打算调用AWS STS命令行实用工具来获取当前的调用者身份:

/>aws sts get-caller-identity

几秒钟之后,命令行工具会给我返回下列信息:

{

"UserId":"AROA********GL4SXW:exec",

"Account":"1232*****446",

"Arn":"arn:aws:sts::1232*****446:assumed-role/lambda_basic_execution/exec"

}

非常好,现在我就可以在本地运行AWS命令行工具了,而且我还可以伪装成IAM角色。

当你查看AWS Lambda Web终端时,你将会看到:

AWS Lambda Web终端

大家可以看到,Caleb其实并没有用环境变量存储任何的应用程序隐私数据,这让我很“生气”。但是这里不得不提醒大家一下,很多开发人员确确实实会犯这样的错误,这是值得警惕的一点。

* 参考来源:darkreading,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: