“共存的邪恶：云中Lambda的秘密通信”

36 浏览量更新于2025-01-16 收藏 900KB PDF 举报

1005

Co R e si d e n t Evil：与Lambdas在云中的秘密通信

Anil Yelam

UC San Diego

斯特凡

萨维奇

UC San Diego

Shibani Subbareddy

UC San

Diego

阿丽亚娜

米利

安

UC San Diego

吉尔塔纳

甘尼桑

UC San

Diego

摘要

“Serverless”

这些服务很受欢迎，部分原因是它们的轻量级特性

以

及调度和成本方面的灵活性，但是

与无服务器计算相关的安全问题

尚未得到很好的理解。在这项工作中，我们探讨了构建一个实用

的隐通道从

Paddas

的可行性我们建立了一个快速的共同居住的检

测为

bridas是关键，使这样一个隐蔽的通道，并着手

开发一个

可靠的和可扩展的共同居住的检测器的基础上的内存总线硬件。

我们的技术可以动态发现共同驻留的数据库，并且非常快，在几

秒钟内执行我们评估我们的方法的正确性和可扩展性，并使用它

来建立隐蔽通道，并在

AWS

数据库上执行数据我们表明，我们可

以建立数百个独立的隐蔽通道，每

1000

个部署的数据包，

这些通

道

中的每一个

可以

发送数据的

速率为

千比特每秒

，从而

证明通过数

据包的隐蔽通信是完全

可行的。

CCS

概念

•

安全和隐私→

虚拟化和安全

。

关键词

云，制图，无服务器，共存，隐蔽通道

ACM参考格式：

阿尼尔

耶拉姆，希巴尼

苏巴雷迪，克尔塔纳

甘尼桑，斯特凡

萨维奇和阿尔

亚娜

米里安

. 2021

年

CoResident Evil

：

Covert Communication In The

Cloud

With Lambdas.

在

网络会议

2021

（

WWW '21

）的会议记录

，

2021

年

月

日至

日，斯洛文尼亚卢布尔雅那。

ACM

，纽约州纽约市，美国，

页。

https://doi.org/10.1145/3442381.3450100

1 介绍

在过去十年中，组织越来越多地将

其数据处理和存储需求转移到第

三方

“

云

”

平台。然而，云平台的经济性是基于

高水平的统计复

用，因此

共同租用

-在同一物理硬件上同时

执行来自不同客户的

计算

-是常态。的风险

本文在知识共享署名4.0国际

（CC-BY 4.0）许可下发布。作者保留在其个人和公

司网站上以适当的署名传播作品的权利

WWW

2021 IW 3C 2

（国际万维网大会委员会），

在知识共享

CC-BY 4.0

许可下发布。

ACM ISBN 978-1-4503-8312-7/21/04。

https://doi.org/10.1145/3442381.3450100

与这种布置相关联的数据泄漏和干扰都得到了很好的理解，并且

已经产生了大量的研究文献（从

Ristenpart

等人开始，

[19]

）以及

云平台提供商采用的各种技术隔离对策

。这项工作的大部分都集

中在用于虚拟化专用网络连接服务器的传统概念的

长寿命、重

型虚拟机（亚马逊术语中的

“

实例

”

）

的信息通道的风险

然而，在过去的六年中，大多数最大的云

提供商已经引入了

一种

新的

“

无服务器

”

服务模式，该模式按需执行短暂的轻量级计

算（例如

，

Amazon

的 Lambda [ 14 ] 、 Google 的 Cloud

Functions [ 10 ]和Microsoft的Azure Functions [ 5 ]）。这些

服务在设计上使用

较轻的租户隔离机制（所谓的

“微VM”或容

器）以及固定的系统环境，以提供低延迟启动和减少的内存

占用

。反过来，

无服务器系统可以支持更高级别的统计复用，

从而可以为客户节省大量成本

，客户的需求能够匹配此模型（例

如，具有嵌入状态的事件驱动

计算）。然而，与无服务器计算相关

的安全问题远

不如它们的重量级兄弟那么好理解。虽然无服务

器计算的瞬态和动态特性

给攻击者

带来了固有的挑战，但其低

成本和轻量级隔离也可能带来新的购买点

在我们的工作中，我们通过一个单一的问题来探索这些问题：

一个实际的隐蔽通道可以完全

从现有的

隐蔽通道提供了一种绕过传统监视或审计的数据传输方式

在

虚拟化环境中，隐蔽通道通常涉及一些共享资源（例如，高速缓

存），竞争为该高速缓存提供了信令手段在无服务器环境中，威

胁模型是攻击者能够从目标组织内部启动或注入代码到恶意软件

中，并希望将信息传达给组织外部的各方（即，他们的行为，没

有任何

明显的迹象。打开网络连接等）

然而，无服务器上下文为实现隐蔽通道提出了许多独特的挑

战。首先，

lambda

的物理位置是未知的，因为

lambda

的调度和

放置由云服务提供商管理因此，

没有办法安排发送

lambda

和接收

lambda

将

在相同的物理硬件上执行，

更不用说同时执行了

。

我们将使用术语“服务”来代表未来的所有此类服务

1006

WWW

其次，考虑到这一现实，任何无服务器的隐蔽通信协议都必须反

复启动

AMDA

，希望至少有

两个发送和接收AMDA同时驻留在

同一

硬件上。这

在成本合理的现有云平台上的可行性尚不清楚。第

三，

仅仅

实现

共同居住是不够的，但任何

幸运的共同居住者必

须能够迅速确定

这一事实，然后利用他们有限的生命来

实现沟

通。最后，由于无服务器系统中的会合本质上是统计性的，因此

任何这样的协议都必须预测干扰的可能性（即，当多个发送

AAA

碰巧与一个或多个接收AAA共存时）。

在本文中，我们依次解决了这些问题，并完全在亚马逊的

无服务器云平台的背景下

展示了隐蔽通信的可行性。具体而言，

我们做出了三项关键的技术贡献：

快速共居检测。

利用

Wu et.在[26]中，我们开发并实现

了

一种

共存检测器，其是通用的、可靠的、可扩展的，

并且最重要的是，快速的，

对于数千个并发的λ共存检测

器在几秒钟

动态邻居发现。我们提出了一种新的协议，其中共同居

住的多个代理

使用基于硬件的隐蔽通道来通信他们的

，以

便识别

彼此。该协议还允许发送方或接收方

枚举其

所有

共同驻留的邻居，这是在

执行隐蔽通信时避免不必要的

通信干扰的要求。

隐蔽通道演示我们使用我们的共存检测器在AWS上建

立lambda隐蔽通道。然后，我们进行了一项研究的可

行性隐蔽通信1）估计每个通道的容量

和

）测量共同居

住的密度

也就是说，对于一个给定数量的

ERADA

在同一

时间点发射，有多少会成为共同居住？我们在一系列亚马

逊数据中心

进行这些测量，以确定有足够的lambda共

存，并且隐蔽通信是可行的。

我们的实现可以在

https://github.com/

anilkyelam/columbus

上公

开获得

。

2 背景

我们首先简要介绍相关主题的

2.1

Lambdas/

无服务器函数

我们在本文中重点关注无服务器功能，因为它们是

增长最快的

云服务之一，并且从安全角度来看研究较少。这些功能在

AWS [14]

上作为云函数提供，并在

GCP [10]

和

Azure [5]

上作为云函数提

供，因为它们不需要开发人员提供，维护

或管理服务器。除了这

种低维护之外，

由于它们允许更有效地将功能打包到服务器上，

因此它比虚拟机（

）更具成本效益。此外，

Apache

执行的单

元要小得多，而且更短暂

虚拟机。例如，在AWS上，Rendas的内存

上限为

3 GB

，最大

执行时间限制为

分钟。与其他云服务一样，用户无法控制服务

器

的物理位置，他们的服务器在其上产生。

虽然

Apache

在它们可以执行的计算方面受到限制

（通常是用

Python，C#等高级语言编写的），但它们相反是非常轻量级

的，可以在很短的时间内启动和删除。云提供商

在具有有限资

源的专用容器（例如，

fixtacker [1]

），这些文件通常会被缓存并

重新用于将来的数据库，以减轻冷启动延迟

[2]

。无

服务器函数的

短暂性及其有限的灵活性增加了检测共存的难度，我们将在后

面讨论。

虽然以前的研究主要关注

性能方面，如冷启动延迟，

函数实例

生命周期和各种云的

CPU

使用率，但安全方面

仍然相

对不足。

2.2 云计算中的隐蔽通道

在我们试图阐明的安全方面的

Bundas

，我们特别关注的可行

性，建立一个可靠的隐蔽

通道在云中使用Bundas。隐蔽通道

是一

种绕过传统监控或审计的实体之间传输信息的方法。通常，

这是通过

在非预期信道上传输数据来实现的，例如

通过引起服务

器上共享硬件介质上的争用来传输信令比特

[16

，

25-

27 ]

。过去的工作已经证明

了虚拟化环境中的隐蔽通道，如云使用

各种硬件

，如缓存[19，27]，内存总线[26]，甚至处理器温度

[16]。

特别感兴趣的这项工作是隐通道基于内存总线硬件介绍吴等。

[26]

第

段。在

x86

系统中，

只要操作数保持在高速缓存行内

（通常

是语言编译器确保操作数对齐的情况），高速缓存一致性

协议就支持被设计为促进多处理器同步的原子存储器指令。然

而，如果操作数分布在两个高速缓存行上（

称为

“

外来

”

内存操

作），

x86

硬件

通过锁定内存总线来防止任何其他内存访问操

作，直到当前操作完成为止，从而实现原子性。与传统的存

储器访问

相比

，这导致因此，几个连续的

锁定操作可能会导致内

存总线上的争用，这可能会被利用来进行隐蔽通信。

等人在

理

想的实验室设置中，在存储器总线通道上实现了每秒700比特

（bps）的数据速率。

然而，在云环境中实现这样的理想性能通常是不可能的云平台采

用虚拟化

来实现统计多路复用，因此，隐蔽信道上的通信可能受

到以下因素的影响：

）调度器中断，

因为发送方或接收方可能

仅获得对通信的间歇性访问。

使用

Lambdas

WWW

1007

信道和

）来自其他非参与工作负载的干扰这可能会导致传输数

据中的错误，并需要额外的机制，如纠错

[26]

，以确保可靠

的通

信。

2.3

共居检测

在云环境中，通过传统的隐蔽通道进行通信带来了将发送者

和接收者放置在同一台机器上的额外挑战然而，这种共同

驻留

信息是隐藏的，即使实体属于同一租户。过去的研究已经使用了

各种策略来实现

共同驻留，以展示云中的各种隐蔽通道攻击

。通

常，攻击者会启动大量

云实例（

、

Lambda

等），遵循特定

的启动模式，并采用共存检测机制来检测

那些实例中的任何一

对是否在同一机器上运行

。传统上，这种检测是基于在同一服务

器上运行的两个实例

可能共享的软件运行时信息，如公共/内部

IP地址[19]，procfs中的文件或其他环境变量[24，26]，以及其

他此类逻辑侧通道[21，29]。

随着虚拟化平台

向实例之间更强的隔离（例如， AWS

的

FirecrackerVM [ 1 ]

），这些逻辑隐蔽通道已经变得不那么有效或不可

行。此外

，这些通道中的一些通道仅在共享底层OS映像的基于

容器的平台上有效，

因此不太适合基于管理程序的平台。这促使人

们转向使用基于硬件的隐蔽通道，例如第

2.2

节中讨论的那些，它们

可以绕过软件隔离

，因此通常更难修复。例如，Varadarajan et

al. [22]

使用内存总线隐蔽通道来检测

EC2

实例的共存然而，他们

的方法并不能很好地扩展

到Paddas，因为它既不快速也不可扩

展。

3 动机

在本节中，我们将讨论我们的隐蔽通道攻击场景，在启用这种攻

击时，

Biddas

将带来的挑战，以及

Biddas对共存检测器的需求

威胁模型

隐蔽通道攻击通常需要一个

“

内部人员

”

通过隐蔽介质

发送数据进行渗透。我们

假设攻击者使用社会工程技术或其他一些

手段（超出本工作的范围），在受害者系统中引入这样的内部人

员。在

lambda

的情况下，这个内部代码

可能在lambda本身中，或

者在控制组织的lambda

部署的系统中，并且已经拥有

需要被泄

露的敏感数据。我们进一步假设

攻击者知道受害者正在

操作的

云区域，并且可以在自己的帐户下部署恶意软件

在典型的攻击中，攻击者在云区域中启动一组接收器，其中

受害者接收器（receiver）

被期望操作。然后，攻击者和（受损

的）受害者可以一起工作

，通过隐蔽

通道交换数据，如前面讨论的

内存总线硬件。然而，在这方面，

我们不明确区分攻击者和受害者，因为它们都被

认为是在攻击者的控制之下。

如前所述，在我们

可以在云中使用传统的隐蔽通道之前，存在一

些独特的挑战。我们需要：

）将发送者和接收者共同定位在同一

服务器上（通过共同居住检测），

）处理此类信道上的中断，例

如

嘈杂的邻居邻居或调度。

虽然这些挑战已经被其他云平台

（如VM）处理过[21，26]，

但云服务器本质上是不同的，因为

它们的生命周期非常短。两个

共同居住的居民之间的秘密渠道不会持续很长时间。然而，虽然

Biddas

不是持久的，但一次性大量启动

Biddas

并建立多个共同居住

点以允许

更隐蔽的通信是微不足道和廉价的。此外，集群也比虚

拟机更密集，加剧了嘈杂的邻居

问题。

短暂的，众多的，和密集的性质，需要

一个快速，可扩展的，

和可靠的共存检测器。这个检测器还应该允许攻击者识别所有具

有两个或更多个共同驻留的代理的服务器，并在每个这样的服务

器上建立一个隐蔽通道此外，检测器应该精确地识别出有多少个

和哪些是共同驻留的，允许攻击者

在给定的机器上选择任何两个

共同驻留的，并在这两个共同驻留的之间建立一个隐蔽的

通道，

而不受其他机器

的干扰。

在本节中，我们将描述基于

lambda

的共存探测器的必要要

求，以及这些要求如何推动

我们的设计选择，我们用来克服在这种情况下的独特挑战的详细

实施，以及

对其有效性的评估。

4.1 规范

给定部署到公共云的一组云实例（VM、容器、函数等）

，共

存检测机制应该为该组中的每对实例识别该对实例是否在某个点运行

在同一物理服务器上。

Varadarajan et al. [22]

，任何这种机制要

在

广泛的发射战略中发挥作用，就应具有下列特性：

通用

技术应该适用于广泛的服务器架构和软件运行时。在

实践

中，该技术将在大多数第三方云平台上工作，甚至在云中

的不同平台之间工作。

可靠

该技术应该具有合理的检测成功

率，具有最小的假阴性（未检测到共同驻留的实例）和甚

至更少的假阳性（被

归类为共同驻留的非共同驻留的实

例

可扩展

启动策略可能需要部署数百甚至数千个实例，并且

必须扩展，

使得该技术将以合理的成本检测所有共存对

我们在这个列表中添加了另一个属性，它与

Biddas

“共存的邪恶：云中Lambda的秘密通信”

Java：解锁Lambda表达式的魔法-从零开始的函数式编程之旅

awslambda:AWS Lambda的示例代码

drools-lambda:Drools Lambda

js-lambda:用于Lambda演算的DSL

alexaHomeboy:Alexa Lambda函数，用于与IFTTT制造商渠道进行通信

lambda-monitoring：AWS Lambda的日志和指标库

amazonlambdatest:AWS Lambda Java测试功能

aws-lambda-events:AWS Lambda的Rust事件类型

aws-lambda-cheatsheet：AWS Lambda速查表

LambdaSchoolReview：重做Lambda学校课程和挑战复习

最新资源