白泽带你读论文｜ALASTOR

无服务器计算减轻了开发人员管理平台和基础架构的负担，使得他们能够快速地设计原型和部署应用程序。然而，无服务器计算也带来了一些令人担忧的安全问题，其中之一是带来入侵调查方面的困难。在无服务器计算中，攻击者能够将传统应用程序分解为临时可重入函数，使恶意活动隐藏在合法的工作流程中，甚至能通过滥用容器重用策略来破坏因果路径，阻止根本原因分析。不幸的是，传统的系统审计方法和商业无服务器安全产品都无法提供所需的透明度，以准确跟踪这些新型威胁。

本文提出了ALASTOR，一个基于溯源的审计框架，可以精确跟踪无服务器应用程序中的可疑事件。ALASTOR记录系统和应用程序层的函数活动，以捕获每个函数实例行为的整体情况。然后，在无服务器平台内部的中央存储库中汇集不同函数的来源，将它们拼接在一起，形成复杂函数工作流的全局数据溯源图。ALASTOR既可以适用于不同类型的函数和语言，也可以很容易地集成到现有的无服务器平台中。本文还对ALASTOR进行了性能评估，证明了其性能开销相对较小（13.74％）的同时，相比于商业可用的监控工具取证能力显著提高。

本文考虑了针对运行在第三方公共计算云平台（如Amazon Lambda）中的无服务器应用程序的攻击；考虑一个无服务器的云应用程序，远程攻击者的主要目标是数据外泄。为此，攻击者可以利用各种传统技术和程序，比如二进制漏洞利用、命令注入、下载和执行渗透测试工具等；攻击者还能够采用上章所述的无服务器特有攻击技术，在这个环境中实现持久化和渗出数据。攻击者可以使用被攻击的函数来执行任何允许的系统流程来渗出数据，包括传输到外部网络，写到云中某处的持久性存储，甚至写到函数容器内的短暂性存储以便以后检索。虽然攻击者实际上在被攻击的功能实例中拥有自由支配权，但我们假设攻击者没有对受害客户账户的管理权限。因此，他们无法启动自己的功能，修改容器镜像，或篡改访问控制策略。

本文还做了如下的假设：

• 第三方云平台是可信的，并且提供商将正确部署函数，不会与攻击者合作。

• 提供商提供的是基于容器的无服务环境，而不是基于语言的环境，因为容器可以支持多种语言和运行时环境。

• 客户的访问控制策略可能存在错误或不足。

• 云平台中存在用于处理来自公共互联网的外部请求的API网关。

• 所有的无服务函数都通过使用REST API调用或远程程序调用。

• 事件跟踪机制和事件日志在使用时是正确的，并且云平台提供了安全存储日志的机制。

• 不考虑云端通道。

短暂的活动难以审计

无服务函数的生命周期很短暂，而现有的取证技术并不支持审计已不存在或不对当前系统状态产生影响的系统实体：以LogGC为例，它将此类事件视为视为 "垃圾"，并建议将其从日志中删除。各种审计框架也同样对重复事件或因果路径进行了删减。这种做法很可能会破坏重要的攻击活动证据。

漏洞的大量复制

一个函数中如果存在的漏洞，它进而会影响到许多函数和容器的安全性，而这些函数和容器可能被复制到不同的物理机器上的许多实例中。因此追溯漏洞根源并评估它对整个应用程序的潜在影响存在困难。

由于函数基础设施处于不断的重建和拆除状态，与典型Web请求相比，与函数调用相关的事件远远超出预期。因此，与无服务审计相关的开销可能会比传统服务器基础设施更大。

本文利用无服务器平台的一个关键设计——执行分区来应对上述挑战。在执行分区中，长期存在的流程被细分为独立的工作单元，这允许调查者在不跟踪不相关的输入的条件下，从流程的输出追踪到相关的流程输入。

作者评估了ALASTOR的性能开销，包括构建性能，运行时性能，CPU和内存利用率以及磁盘和网络利用率，并与标准的OpenFaaS进行比较。

Figure 3 (a)和(b)展示了ALASTOR构建镜像的大小和时间与标准OpenFaaS的比较。与Vanilla OpenFaaS相比，图像大小略有增加，这是由于额外的ALASTOR代码被编译到OpenFaaS的watchdog二进制文件中，以及追踪机制和代理证书的安装。构建时间的开销可归因于在图像构建期间安装系统调用跟踪和代理库。这些都是第一次构建镜像时产生的一次性成本。

Figure 4 (a)和(b)显示了每个函数的50次迭代的平均开销。从所有函数的平均值来看，ALASTOR的部署和拆除开销分别为3.2%和3.6%。

Figure 5显示了不同函数的响应延迟。作者指出，这些结果可能表明ALASTOR更适合于不执行大量文件I/O的事件驱动型应用程序。

Figure 8描述了执行product-purchase 工作流时生成的日志大小的比较。ALASTOR与其他系统审计框架有相似之处：虽然它以原始形式产生了大量的数据，但这些成本可以通过日志过滤和数据压缩技术的组合得到有效缓解。

Table 1展示了三个Hello,Retail!场景中的请求图的复杂度。作者将此归因于无服务器计算的短暂和事件驱动的性质；因为执行是短暂的和定义明确的，典型的图复杂性和依赖性爆炸问题不会出现在ALASTOR中。

结果表明，与标准的OpenFaaS相比，ALASTOR的性能开销在大多数情况下是可以接受的，尤其是在事件驱动的应用程序中。此外，该系统对于服务器的CPU和内存资源有一定的开销，但可以通过合理的扩展容器规模来解决。

RQ1：输出结果是否表明应用程序偏离了其正常行为？

Epsagon满足了RQ1，但这是一个弱的威胁指标，并不清楚具体异常原因。

RQ2：能否够解释攻击者在应用程序中的行为？

Epsagon记录了各种功能的元数据，但它没有记录与其他应用程序组件的连接，包括信用卡数据库，也没有记录与攻击者控制的远程服务器的连接。因此，Epsagon无法重构完整的攻击路径。

RQ3：能否诊断特定于无服务器的攻击技术？

Epsagon确实跟踪了一个相关的属性，cold_start，这表明存在容器重复使用。然而，容器重复使用本身并不是妥协的指标——它在任何应用程序中都是常见的情况。

本文提出了一个名为ALASTOR的无服务应用溯源框架，通过监控不同层次上的信息来收集无服务应用的完整溯源信息，从而应对无服务环境中的攻击检测挑战。ALASTOR能够跟踪环境中的无生命实体，同时还能与现有的Serverless平台轻松集成，仅带来小部分的额外开销。本文还将ALASTOR与商业Serverless跟踪工具Epsagon进行比较，证明了ALASTOR重建攻击路径的能力的优越性。

对于RQ1，Epsagon能做到，但应用程序偏离正常的行为是一个弱的威胁指标，因为异常的原因并不清楚。如果没有额外的支持性证据，该现象可能是一个性能错误，而不是一个复杂的入侵企图。

关于RQ2，尽管Epsagon记录了各种功能的元数据，但它没有记录与其他应用程序组件的连接，包括信用卡数据库，也没有记录与攻击者控制的远程服务器的连接。因此，Epsagon无法重构完整的攻击路径。

主要挑战：

a.短暂的活动难以审计。由于无服务器函数生命周期是短暂的，因此无法通过传统的取证方式来支持审计系统实体，这就需要开发新的审计框架来支持无服务器环境。

b.易复制的易受攻击程序。由于许多函数和容器会在不同的物理机器上复制，一旦一个函数存在漏洞，那么就会涉及到许多其他函数和容器的安全问题。因此，需要开发方法来跟踪漏洞并评估其对整个应用程序的潜在影响。

c.繁琐的审计成本。在无服务器环境中，由于容器处于不断的启动和关闭状态，与传统服务器基础架构相比，与函数调用相关的事件要更多。因此，需要开发新的审计框架来适应这种高开销的情况，以确保无服务器环境下的安全审计成本可控。

解决方案：ALASTOR使用执行分区技术解决无法审计短暂的活动的挑战，该技术将长时间运行的进程分成独立的工作单元，这允许调查者在不跟踪不相关的输入的条件下，从流程的输出追踪到相关的流程输入。此外，由于无服务器环境的事件驱动特性，高扇出过程（高扇出过程是指在系统或软件架构中，一个模块或组件同时与许多其他模块或组件交互的过程。）很少发生，因此不需要额外的执行分区。ALASTOR首先使用溯源收集器来收集每个函数实例的信息；然后，通过将从不同函数中收集的信息汇总到平台的中央存储库中，并将发现的因果依赖关系转化到全局数据溯源图中来实现无服务器攻击审计。

原文始发于微信公众号（复旦白泽战队）：白泽带你读论文｜ALASTOR