Serverless安全研究—Serverless安全风险( 二 ) 一．专题信息专题：Serverless安

下述示例是AWS Lambda函数的代码片段【2】
文章插图
上述Serverless函数接收数据并使用DynamoDB的put_item()方法将数据存入数据库，函数看起来没有问题，但从如下部署函数的serverless.yml文件看出，开发人员犯了一个严重的错误：
文章插图
可以看出开发人员授予了dynamodb的所有访问权限（*），这么做是十分危险的，针对以上Serverless函数正确的做法是只赋予该函数对数据库的PutItem权限，如下述所示：
文章插图
Gartner预测，到2020年， 95%的云安全问题将由用户错误的使用配置引起。 Serverless中，应用可能会由许多函数组成，函数间的访问权限，函数与资源的权限映射非常多，高效率管理权限和角色成为了一项繁琐的问题，许多开发者简单粗暴地为所有函数配置单一权限和角色，这样做会导致单一漏洞扩展至整个应用的风险。
4.4 针对应用程序数据泄露的攻击
在应用程序中，敏感数据信息泄漏、应用程序日志泄漏、应用程序访问密钥泄漏、应用程序未采用HTTPS协议进行加密等是一些常见的数据安全风险，通过调研我们发现，这些事件的产生原因多是由于开发者的不规范操作引起，比较著名事件有2017年Uber公司由于开发人员误将AWS S3存储的密钥硬编码在应用程序中并公开在Github上，进而导致5700万用户数据遭到泄漏【9】， Uber公司也最终通过支付1.48亿美金作为违约和解，付出了惨重的代价；2019年5月，国外著名社交网站Instagram ，一个在AWS上的数据库因为开发人员的误配置导致可无口令访问，从而引发4900万用户的个人信息遭到泄漏【10】，其中包括图片、粉丝数、地理位置、电话、邮件等敏感数据。需要注意的是，在Serverless中以上这些风险同样存在，但与传统的应用程序不同的是：
1. 针对攻击数据源的不同，传统应用只是从单一服务器上获取敏感数据，而Serverless架构中攻击者可针对各种数据源进行攻击，例如云存储（AWS S3）或DynamoDB等，因此攻击面更广一些；[PM5]
2. Serverless应用由许多函数组成，无法像传统应用程序使用单个集中式配置文件存储的方式，因此开发人员多使用环境变量替代。虽然存储更为简单，但使用环境变量本是一个不安全的行为；
3. 传统的应用开发人员并不具备丰富的Serverless的密钥管理经验，不规范的操作易造成敏感数据泄露的风险；
2018年6月，著名开源Serverless平台Apache OpenWhisk曝出CVE-2018-11756漏洞【11】，该漏洞由Puresec公司的YuriShapira安全研究员发现，其指出在应用程序含有漏洞的情形下，攻击者可能会利用漏洞覆盖被执行的Serverless函数源代码，并持续影响函数后续的每次执行，如果攻击者对函数代码进行精心伪造，可进一步造成数据泄露、RCE（远程代码执行）等风险，为了更清晰的说明此CVE漏洞的风险，以下是一个完整的示例【5】：
在OpenWhisk中，每个Serverless函数都在一个Docker容器中运行， OpenWhisk通过RestfulAPI与容器内部的Serverless函数进行交互，该API可通过本地8080端口进行访问，此API提供两个操作：
/init: 接收容器内被执行函数的源代码
/run: 接收该函数的参数并运行代码
由于OpenWhisk并没有对/init调用进行有效限制，所以攻击者可以利用应用程序漏洞强制Serverless函数发送一个HTTP POST请求到http://localhost:8080/init ，从而覆盖之前接收到的函数源代码，换而言之，攻击者构造的危险函数体将被执行，下述是简易的攻击流程图【6】：
文章插图
图4. CVE-2018-11756攻击简易图
以下是一个简单部署在OpenWhisk上的Serverless函数：
文章插图
该函数接收一个PDF文件并通过pdftotext命令行工具将其转换为文本，不难看出如果该应用程序中存在输入参数校验漏洞，攻击者可通过控制文件名的输入进行恶意攻击。
以下是攻击者构造的恶意函数输入，主要有包含以下三部分内容：
1. 安装curl命令
2. 提交相关请求至http://localhost:8080/init
3. 在当前容器中重写函数源码
以下是攻击者构造的恶意Payload:
文章插图