USENIX Security 安全顶会文献阅读：《ALASTOR : Reconstructing the Provenance of Serverless Intrusions》

USENIX Security 22 年中稿论文 - CCF A - 安全顶会

• 热容器重用策略（Warm Container Reuse Policies）是无服务器计算中的一种性能优化手段，目的是通过缓存最近调用的函数实例在内存中以提高性能。这种优化允许攻击者在发现漏洞时建立准持久性，违反了单个函数调用的隔离性。热容器重用的问题由于安全策略和配置不佳而被放大，使得攻击者能够通过函数工作流横向移动，从而在无服务器应用中就像在传统服务器中一样容易地利用漏洞。
• 因果路径（Causal Paths）：因果路径是指在复杂系统中，特定事件或状态之间的因果关系链。在无服务器计算和安全分析的背景下，因果路径指的是一系列事件的连接，这些事件从一个初始动作或输入开始，通过系统的不同组件传递，最终导致某个特定的输出或状态改变。在追踪安全入侵或故障的来源时，理解这些因果路径是至关重要的，因为它们可以帮助识别攻击者的入侵路线，或是找出系统故障的根本原因。
• 根因分析（Root Cause Analysis, RCA）：根因分析是一种用于诊断问题和识别导致特定事件发生的底层原因的过程。在安全和系统故障调查的背景下，根因分析旨在超越表面问题，深入探究导致安全漏洞被利用或系统出现故障的根本原因。这通常涉及分析因果路径，从而可以采取措施预防未来的问题。根因分析是一种重要的问题解决策略，因为它帮助组织不仅仅修复症状，而是解决导致问题的深层次原因。在无服务器架构的环境中，进行根因分析尤其具有挑战性，因为系统的高度分布式和事件驱动的特性使得追踪因果路径变得复杂。
• **执行分区（execution partitioning）**是将长期运行的进程划分为独立的工作单元的过程。这一做法允许审计者从进程的输出追溯到相关的输入，而不需要关注与当前分析无关的输入（即假溯源）。这是一种通过削减信息的冗余和不相关性来提高审计效率和准确性的策略。

ALASTOR : Reconstructing the Provenance of Serverless Intrusions

代码开源： https://bitbucket.org/sts-lab/alastor/ download

Abstract

ALASTOR 是一个基于溯源的审计框架(provenance-based auditing framework)，用于精确跟踪无服务器应用中的可疑事件。无服务器计算将传统应用分解成短暂的、可重入的函数，使攻击者能够在合法工作流中隐藏其活动，并通过滥用暖容器重用策略破坏因果路径来阻止根因分析。

ALASTOR 记录函数活动，在系统和应用层捕获每个函数实例的行为全貌，然后将来自不同函数的溯源信息在无服务器平台的中央仓库聚合起来，生成复杂函数工作流的全局数据溯源图。ALASTOR 既适用于所有函数也适用于所有编程语言，可以轻松集成到现有无服务器平台中，几乎不需要修改。通过对 OpenFaaS 平台的实现和使用 Nordstrom 的HelloRetail! 应用的评估，研究人员发现 ALASTOR 在提供显著改进的取证能力的同时，只增加了13.74%的可管理开销。

关键亮点： ALASTOR 是第一个专门为满足无服务器平台的操作需求而设计的审计框架。

1 Introduction

无服务安全模型的一个主要疏漏是为了提高性能而普遍实践的缓存最近调用的函数在内存中的做法。这种“热容器重用”优化授予攻击者在发现漏洞时建立准持久性的能力，违反了单个函数调用的隔离性。容器重用问题由于安全策略和配置不佳而被放大，使得攻击者能够在函数工作流中横向移动，因此在无服务器应用中的漏洞可以像在传统服务器中一样容易被利用。

这个问题导致传统的攻击方案在无服务器计算上是可行的，那么传统的防御方案是否也可以使用呢？

传统的防御解决方案（例如Linux Audit）缺乏对平台的可见性，因此对关键的无服务器语义（如函数实例、平台API和容器重用）一无所知。这同样适用于最新的技术。这些方法缺乏对无服务特定语义的理解，因此不能准确追踪这些新型威胁。

考虑以下问题来解决这些挑战：

(1) 无服务器溯源：为了准确重建无服务器应用的溯源，必须监控哪些特定的代理、实体和活动？
(1)Serverless provenance: What are the specific agents, entities, and activities that must be monitored to accurately reconstruct the provenance of serverless applications?

(2) 无服务器的通用审计：如何整合无服务器堆栈各个层级的取证证据以便有效地进行威胁调查？
(2) Universal auditing for serverless: How can forensic evidence at various levels of the serverless stack be integrated to facilitate effective threat investigation?

为了解决以上问题，提出了 ALASTOR ，一个以更细粒度的方式在平台堆栈的不同级别收集信息的溯源框架。函数实例（i.e. 容器）同时在系统级别和应用级别（e.g. HTTP请求）进行监控，然后汇总给全局溯源图构建器。ALASTOR 的实现与函数无关，可以最小修改集成现有系统。

作者声称的本文贡献：
1.提出了 ALASTOR，一个在无服务器计算环境中用于攻击调查的函数无关的溯源框架。与传统溯源工具的区别是，同时跟踪环境中的 dead 和 active 实体；
2.性能测试，增加的开销小；
3.工具对比，和商用工具对比，效果更好；

2 Background and Motivation

介绍了一个案例：serverless 项目的攻击策略

• Exploiting Container Reuse: 攻击者发现，通过将恶意软件或工具包写入内存分区(例如/tmp)，可以利用热容器重用来实现持久性，然后迫使受损的函数实例保留在缓存中[58]。图1中的步骤4利用了容器重用。

• **Exfiltration through Function Workflows:**攻击者已经开发出了通过下游授权函数和合法的平台API偷窃数据以便传输到公开互联网的方法。他们可以利用合法的函数转换在应用中横向移动。此外，无服务器访问控制策略的复杂性增加了错误配置的机会[41,74]，从而为攻击者创造了更大的机会。图1中的第5步展示了通过授权的工作流泄露数据。

现有方法的局限性：

• 大多数系统级溯源技术仅限于发生在单个机器内的事件，而无服务器平台上的攻击性质需要分布式跟踪和审计机制。
• 云厂商现有的一些工具，提供分布式跟踪，但只提供不透明的函数执行视图，无法解释系统级交互，过于粗粒度，无法用于攻击诊断和调查。同时这些工具没有考虑容器内交互(intra-container interactions)（eg. 容器重用），这对防止交叉调用攻击(cross-invocation attacks)是必要的。

3 Threat Model & Assumptions

这项工作考虑了对运行在第三方公共计算云平台(如Amazon Lambda)中的无服务器应用程序的攻击。我们假设云提供商和平台基础设施是可信的，这意味着提供者将正确地部署功能，并且不会尝试与攻击者勾结。基于亚马逊Lambda和其他类似FaaS平台的流行，我们假设提供者提供基于容器的无服务器环境，而不是基于语言的环境。

基于容器的 FaaS 可以不限制语言，但缺点是因为函数不一定是类型/内存安全的语言编写的，并且函数还可以与底层主机交互。此外，用户关于函数的访问控制策略可能被错误配置或者过于宽松，导致攻击者可以遍历函数工作流来推进目标。

在此环境下，论文考虑了针对无服务器云应用程序的攻击，主要目标为数据窃取。攻击者可以利用各种传统技术和手段来实现目的，包括二进制利用、命令注入、下载和执行渗透测试工具等。此外，他们还可能采用特定于无服务器的攻击技术来实现持久性和数据泄露。尽管攻击者可以在受损的函数实例内自由活动，但假设他们没有获取受害者客户账户的管理访问权限，从而限制了他们的攻击范围。

此外，论文假设云平台中存在API网关来处理来自公共互联网的外部请求，所有无服务器功能都通过REST API调用或其他远程过程调用方式被触发。该假设基于web和API服务是无服务器范式中最常见的用例。论文还假设事件追踪机制和事件日志在使用时是准确的，并假定由于云平台是可信的，且攻击者没有管理访问权限，因此可以合理地假设这些日志存在安全存储。最后，论文没有考虑云平台的侧信道攻击，如跨租户侧信道等。

4 Overview

在无服务器领域部署基于溯源的审计技术面临几个显著挑战：

1.审计短暂活动：由于无服务器函数是短暂的，传统的取证分析并不适合审计那些已经不存在或不再影响系统当前状态的实体。这意味着，应用于无服务器环境的传统审计技术可能会丢失关键的攻击活动证据。

2.脆弱程序的复制：在无服务器环境中，一个函数中的漏洞可能影响到许多不同物理机器上的函数实例和容器的安全。这使得追踪漏洞来源及评估其对整个应用潜在影响的任务变得复杂。

3.繁重的审计成本：尽管无服务器计算模型允许客户仅为实际使用的资源付费，但由于函数基础架构不断地启动和销毁，与单个函数调用相关的事件实际上可能远多于典型Web请求预期的数量。因此，与传统服务器基础设施相比，无服务器审计的开销可能更大。

执行分区(execution partitioning)方面的优化可用来缓解这些挑战。在执行分区中，长期存活的进程被细分为自主工作单元，允许研究人员从进程输出跟踪到相关进程输入而不用考虑不相关输入（即虚假来源）。由于无服务器的事件驱动性质，低级系统事件可以可靠地绑定到事件触发器。无服务器函数的短暂性意味着一个函数实例很少会触发大量其他进程或函数（即高扇出过程）。这减少了在审计过程中需要考虑的相关事件和输入的数量，简化了审计工作。

无服务器架构中进程活动的天然短暂和事件驱动特性，大多数函数的执行已经是独立的、自包含的工作单元。这意味着，与传统长期运行的系统不同，无服务器平台上的执行活动自然而然地被分割成小块，与很少的假溯源相关联。因此，在无服务器审计中通常不需要执行额外的执行分区步骤。

5 ALASTOR Design

5.1 Provenance collector

系统调用跟踪 System Call Tracing：利用strace工具追踪进程、文件和网络相关的系统调用，生成系统级事件跟踪。这对于收集溯源信息至关重要，因为攻击者的恶意活动会通过他们调用的系统调用记录下来。

网络分析 Network Profiling: 系统调用跟踪提供了对低级网络活动的可视化，但由于应用组件经常被复制和迁移，IP级信息不足以描述。ALASTOR通过在每个容器中部署透明网络代理来观察API使用和HTTP请求，从而解决这个问题。对于加密流量，ALASTOR的溯源收集器包含了一个HTTPS代理（mitmproxy），这是一种在企业环境中常用的监控敏感网络流量的技术。

进程到网络请求关联 Process to Network Request Association: 网络代理提供了对函数更高级别网络活动的洞察，但无法将网络请求与发起请求的特定系统进程关联起来。ALASTOR使用ss工具将进程映射到它们使用的TCP套接字的端口号，并通过mitmproxy计算起始网络请求的源端口。这些信息被结合起来，计算每个容器中每个进程发送的请求集。

**本地溯源图创建 Local Provenance Graph Creation:**在此阶段，溯源收集器将收集的溯源信息编码成一个溯源图。这个图的顶点是在函数实例中观察到的系统主体（进程）和对象（文件、网络连接），边表示因果依赖事件。

1-4行，算法使用单个容器顶点来初始化图，容器 ID 可以从容器内的 proc 目录读取。

5-9行，解析请求处理程序的日志以识别与函数调用请求相关的进程，并将这些进程节点添加到图中。

10-14行，网络分析结果将IP地址和进程节点关联。

15-20行，图中存在的每个进程节点都会调用 GetSystemCall§ 协程。

21-24行，解析进程 p 的 strace 的输出。22 行检查并去掉失败的 syscall（失败的syscall返回值为负）。23-28行，通过跟踪 fork、execve、clone 等系统调用并在其子进程上递归调用 GetSystemCall 来计算 p 的后代。将进程 p 及其后代都纳入图中，并且设置从父节点 p 指向子节点的边。
29-42 行，解析系统调用参数，以计算成功的系统调用影响的系统对象（如 files, sockets），然后将这些对象加入到图中，设置一条进程节点到系统对象的边，并标记为 system call，边的方向取决于数据流的方向。

5.2 Global Provenance Builder Service

global provenance builder service 实现了无服务器溯源技术的独特特征，dead-provenance。Dead-provenance 处理跟踪环境中不存在的对象(即死容器)，并计算死对象过去诱导的事件如何影响活对象。与传统的单机系统相比，dead-provenance 对检测第二节中提到的攻击至关重要。全局溯源构建服务分为两个阶段：

从平台和实例收集信息 Information collection from the platform and the instances: 全局溯源构建服务查询平台服务，了解部署的函数、运行的容器及其状态（例如，容器是初始化、运行还是已终止）。通常情况下，平台会为生态系统中的每个对象分配唯一的标识符。每个函数和每个容器的唯一标识符使得该服务能够追踪跨越可能在相同时间内活动或可能已终止的函数实例的流动。

全局溯源图创建 Global provenance graph creation： 全局溯源图算法（算法2）以算法1生成的一组本地溯源图和无服务器平台日志（网关日志、DNS服务器日志等）为输入。该算法以对应于各种平台服务的顶点初始化全局图（第1-4行）。然后，所有来自本地图的边和顶点都被添加到全局图中（第6-9行）。平台日志记录了分配给不同容器的IP地址。从这些日志中创建了一个容器ID到IP地址的映射（第10行）。平台网关路由并记录每一个对函数的请求，无论请求是平台内部的还是外部发起的。最终，通过网关日志和第10行构建的映射，计算容器之间的请求流动，并将带有请求ID和时间戳的相应边添加到全局溯源图中（第11-14行）。

当来自正在终止的容器的预终止溯源信息到达时，相应容器的子图会用新信息进行追加，并且相应的容器顶点会被标记为已终止。通过这种方式，ALASTOR在全局溯源图中保留了已死亡的溯源信息。如图2所描述，一个完整的多函数攻击路径在全局溯源图中是可见的，这在单独检查本地图时是无法发现的。

6 Implementation

ALASTOR 选择在 OpenFaaS 上实现，这是因为 OpenFaaS 是一个流行的、与多种容器编排平台兼容的开源无服务器框架，包括Kubernetes 和 Docker Swarm。OpenFaaS 提供灵活性，允许开发者轻松部署和管理无服务器函数。

实现过程中主要修改了OpenFaaS的两个组件：watchdog和of-watchdog。这些组件作为函数容器中的请求处理器，负责接收和处理对函数的入站请求。修改的目的是让这些组件能够执行ALASTOR的溯源收集任务，包括网络请求代理和系统调用跟踪，而不干扰它们原有的功能。

使用strace工具来实现系统调用跟踪，这是ALASTOR收集系统级活动信息的关键方法。通过监视函数执行过程中的系统调用，ALASTOR能够捕获底层操作系统级别的事件，为审计提供重要数据。

通过Mitmproxy Python库代理函数生成的网络请求，这包括指向Kubernetes集群外部地址的HTTP和HTTPS请求。此外，ALASTOR也监控内部集群流量，使用来自Kubernetes apiserver、OpenFaaS网关和被改造的函数容器发出的系统日志。

ALASTOR的全局溯源构建服务作为一个独立的定时任务在Kubernetes控制平面上运行，负责从函数实例中获取本地溯源数据，并将这些数据汇总成一个全局溯源图。这一服务的实现确保了ALASTOR对现有无服务器平台的影响最小化，同时能够提供详细的审计信息。

通过这些实现细节，ALASTOR为无服务器应用提供了一种高效的审计框架，使得审计者能够追踪到每个函数实例中发生的事件，从而有效地支持无服务器攻击的调查和根因分析。

7 Performance Evaluation

测试环境：64-core Intel® Xeon® CPU E5-2683v4 @2.10GHz and 132 GB memory running CentOS Linux 7 (Core) 64 bit OS.

Docker version 20.10.3 as the container runtime, Kubernetes version 1.18.8 for orchestration, and OpenFaaS with of-watchdog version 0.8.1

性能评估在配置为单节点的Kubernetes集群上进行，该集群运行在server-class机器上。这种设置旨在模拟典型的无服务器应用部署环境，以确保评估结果的实用性和相关性。

测试工作负载：使用了HelloRetail等实际应用作为测试工作负载。HelloRetail是一个典型的无服务器应用示例，涵盖了多个无服务器函数的调用和互动，适合作为性能评估的基准。

性能指标：评估集中在几个关键性能指标上，包括：

• CPU和内存使用率：评估ALASTOR对系统资源使用的影响，以确定是否会显著增加资源消耗。
• 延迟：测量ALASTOR引入的额外处理时间，以评估其对函数响应时间的影响。
• 吞吐量：评估系统在启用ALASTOR后能够处理的请求量，以确定其对系统处理能力的影响。
• 性能比较：将启用ALASTOR的OpenFaaS与未修改的OpenFaaS（即Vanilla OpenFaaS）进行比较，以直观展示ALASTOR对性能的影响。这种比较方式有助于理解ALASTOR增加的审计功能对无服务器应用性能的具体影响。

• 构建和编排性能（Build and Orchestration Performance）
  构建和编排性能评估了ALASTOR对无服务器平台的部署和管理过程的影响。结果表明ALASTOR引入的延迟和开销相对较小，对平台的构建和编排流程影响有限，保持了无服务器平台的灵活和快速部署能力。

• 运行时性能（Runtime Performance）
  运行时性能部分关注于ALASTOR在函数执行期间的表现。评估显示，虽然ALASTOR引入了额外的溯源收集和处理步骤，但这些操作对函数响应时间和处理能力的影响很小，保持了无服务器函数的高效执行。

• CPU和内存利用率（CPU and Memory Utilization）
  对于CPU和内存利用率，评估发现ALASTOR对资源的额外需求相对较低。尽管执行溯源信息收集和处理会消耗一定的CPU和内存资源，但优化后的实现确保了这种消耗不会对系统的整体性能造成重大影响。

• 磁盘和网络利用率（Disk and Network Utilization）
  在磁盘和网络利用率方面，ALASTOR通过有效的数据管理和传输策略，最小化了对磁盘空间和网络带宽的需求。评估指出，尽管全局溯源图的构建和维护需要存储和交换大量数据，通过压缩、去重等技术可以有效控制数据量，减少对资源的消耗。

• 操作总成本（Total Cost of Operation）
  操作总成本评估考虑了ALASTOR带来的额外开销，包括资源使用成本和管理维护成本。评估结果表明，尽管ALASTOR增加了一定的运行和维护成本，但考虑到其在安全性和可审计性方面带来的好处，这些成本是合理的，并且可以通过优化资源使用和自动化管理流程进一步降低。

结果和分析
性能评估结果表明，ALASTOR对CPU和内存使用率的增加是有限的，即使在高达每秒500个请求的测试负载下也能保持系统的响应性。此外，磁盘和网络利用率的评估显示，通过日志过滤和数据压缩技术，可以有效减轻ALASTOR产生的大量数据对系统资源的压力。延迟方面，ALASTOR引入的额外处理时间在可接受范围内，对用户体验的影响较小。性能评估的结果证明了ALASTOR在提供强大审计能力的同时，对无服务器平台性能的影响是可管理和可接受的。这表明ALASTOR是一个实用的无服务器安全和审计解决方案，能够在不牺牲系统性能的前提下，增强无服务器应用的安全性和透明度。

8 Security Analysis

略，具体说明了几个具体的攻击，采用 ALASTOR 可以检出，但传统的不行。

9 Related work

略。

10 Discussion & Conclusion

略。