面向云原生的API攻击诱捕技术研究

张 越,陈庆旺,刘宝旭,于存威,谭 儒,张方娇

(1.中国科学院 信息工程研究所,北京 100085;2.中国科学院大学 网络空间安全学院,北京 100049;3.中国人民解放军75841部队,湖南 长沙 410005)

1 引 言

随着云计算、大数据、物联网、移动互联网等新兴技术的快速发展,应用程序接口(Application Programming Interface,API)作为连接服务和传输数据的核心通道,已变得无处不在。根据Postman的监测数据显示,API已在全球范围内被充分接受,并呈现持续增长趋势。2021年,通过Postman平台的API通信遍布全球234个国家,较同期增长约56%。2019年到2020年,谷歌云的Apigee平台观察到其平台中的API通信流量增长了约46%,达到2.21万亿次调用。API正成为互联网上新兴的、最重要的信息基础设施。API承载着企业核心业务逻辑和敏感数据,其巨大价值的背后也隐藏着不可忽视的安全风险,相较于传统Web页面,API承载的数据价值更大,攻击成本更低。现阶段API的增速与API安全发展的不平衡,使得API成为企业安全建设中最薄弱的环节之一。GARTNER在《Hype Cycle for Application Security,2022》(2022年应用安全技术成熟度曲线)报告中阐明API作为企业数字化转型的重要基础设施已逐渐成为攻击者的主要攻击目标[1]。API面临的不仅是传统的Web攻击,如结构化查询语言(Structured Query Language,SQL)注入、命令执行等,更多的是业务层面的攻击,包括信息拖取、越权攻击、参数遍历、暴力破解、撞库攻击等[2]。

自2015年后,云服务主导了企业服务市场,企业将核心资源以“API+云服务”的形式向合作伙伴、客户及普通用户输出。云原生[3]技术能够解决传统云实践中的多种痛点问题,成为赋能业务创新的重要推动力,并已经应用到企业核心业务。云原生环境是一个完全API化的场景,API几乎承载了所有的服务间调用。云原生技术的应用也引入了各种新型安全风险和潜在的漏洞源。传统的API防护更重视边界防护,致力于通过身份验证解决方案和API网关来限制对API的访问,这类基于访问控制模型的防护措施无法解决API特定威胁,而且也不适用于云原生架构。当前针对云原生的API安全研究较少。文中主要解决云原生环境下的API安全问题,面向云原生架构提出了一种面向云原生的API攻击诱捕技术。主要贡献有以下3点:

(1) 提出了一种API安全防御方法,重点关注云API安全问题,设计并构造高交互诱饵API及高交互诱捕环境。

(2) 在诱饵API的构造上,不只研究了应用层诱饵API的构造,还增加了编排层诱饵API的构造。在编排层上针对当前云组件的API脆弱点,围绕Kubernetes组件(谷歌开源的一个容器编排引擎)以及Docker(一个开源的应用容器引擎)设计了API诱饵。在应用层上选取了15个Web API漏洞构造诱饵,并构建了对应的高交互诱捕环境。

(3) 针对应用层高交互API诱饵物理资源需求较高的问题,提出了一种基于当前网络流量的动态调度算法,在充分利用物理资源的同时最大化捕获效果。最后,形成原型系统并进行部署实验,结果证明了文中提出的API攻击诱捕技术的可行性和有效性。

2 相关工作

现有的API安全防御方法主要分为3类:传统API安全模型[4-5]、API网关[6-7]以及API安全开发[8-12]。传统API安全模型依赖访问控制、身份验证、流量限制等技术,围绕“网络边界”或“终端”构筑防线,可以极大降低安全风险,但缺乏API威胁发现及异常检测的能力;API网关是基于已知的攻击和漏洞威胁定制相应的安全策略以检测和过滤攻击流量,可以有效防御已知攻击,但由于漏洞的不可避免性,API网关在面对定向及持续性攻击时总能被绕过,不能检测和发现未知威胁;API安全开发引入了原生安全的概念,将安全融入到开发阶段,在软件开发生命周期和测试过程中引入API安全,但其实现过程缓慢,无法保护已存在漏洞的API。

近年来,云计算发展迅速,云原生架构[3]逐渐成为云应用部署的主流架构,其能够尽可能地剥离云应用中的非业务代码,聚焦功能性业务,从而打造敏捷、智能的云计算服务。云原生的技术范畴,涵盖了云应用定义与开发流程、云应用的编排[13]与管理流程、监控与可观测性、云原生的底层技术、云原生工具集与无服务器计算架构(Serverless computing,Serverless)[14]等方面。无论是面对公有云或私有云部署[15],还是面对混合云等动态环境,善用云原生技术,都能够充分发挥云计算的弹性[16]和分布式优势,大幅提升开发效率,并构建高稳定的技术系统和可弹性扩展的应用程序。云原生代表性技术包含容器、微服务、服务网格[17]等。云原生架构下API数量爆发式增长,API调用关系复杂且API访问范围扩大导致攻击面变广,加剧了API安全风险。当前针对云API的安全研究较少。陈真等[18]梳理了云API面临的威胁以及防护方法,分析了云API的演化历程和类别划分,讨论了云API的脆弱性以及云API安全研究的重要性,提出了云API安全研究框架,涵盖了身份验证、云API分布式拒绝服务攻击、重放攻击防护、中间人攻击防护、注入攻击防护和敏感数据防护6个方面的相关研究工作综述;在此基础上,探讨了增加人工智能防护的必要性;最后给出了云API防护的未来挑战和发展趋势。TANG等[19]说明了移动云计算的安全挑战,并定义了一个端到端的安全移动云计算参考架构;指出了Web API安全是端到端安全栈的关键,提出了传统的API安全机制和两种多因素的Web API安全策略和机制;最后,比较了10个API网关提供商提供的安全特性。LI等[20]指出了当前深度伪造技术的快速发展,对云服务提供商以PaaS形式提供人脸动态验证API进行身份验证造成的真实性验证安全问题,提出了一种可对抗深度伪造的攻击框架LiveBugger,可对人脸动态验证API进行安全评估,最后讨论了提高人脸动态验证API安全性的可实施措施。当前针对云上API的防护技术大多是围绕应用程序API的身份验证和流量检测等被动威胁检测,面向云原生的API威胁发现的研究较少。欺骗防御是未来的安全技术趋势之一,护网和实战化攻防检测中证明了诱捕技术是一项极具价值的主动威胁检测技术。通过在防御方系统中布设体系化骗局,干扰并误导攻击者对被保护系统的感知与判断,同时对攻击者的攻击行为进行分析并找到有效的应对方法,从而达到发现、延迟或阻断攻击者活动的目的。当前尚未发现面向云原生的API攻击的诱捕技术研究。因此文中主要研究相应的主动诱捕技术,针对不同种类的API威胁构造多种API诱饵,形成API攻击诱捕系统并部署在公网环境中吸引攻击者,通过实时监控诱饵API,并对受访情况、被调用情况等进行多维度分析,进而发现潜在威胁。

3 API攻击诱捕框架

文中提出的API攻击诱捕框架如图1所示。云服务模式共分为3个层次:基础设施即服务(Infrastructure-as-a-Service,IaaS)、平台即服务(Platform-as-a-Service,PaaS)和软件即服务(Software-as-a-Service,SaaS)。文中根据不同层次的云服务中典型的API调用场景,设计如认证授权API、登录访问API、数据获取API、重要业务API等一系列诱饵API并构造诱饵数据,以此为基础搭建相应的诱捕系统并部署在公网环境中吸引攻击者。当攻击者访问诱捕系统时,攻击者对诱饵API的探测和后续的攻击行为等信息都会被记录在日志文件中。通过对日志进行分析,可以获得攻击者的IP信息、API的受访情况以及被调用情况等,从而发现潜在的API攻击行为。

图1 API攻击诱捕框架

API诱饵的构造是API攻击诱捕的核心。在IaaS基础设施层中,客户端使用授权的访问令牌(AccessKey)对云基础设施进行敏感操作的过程,其本质上是向云基础设施发送API请求的过程。攻击者可利用泄露的访问令牌攻击云基础设施,但当前云服务厂商会定期扫描泄露的访问令牌,攻击者利用API进行攻击的概率相对较小。因此笔者将重点放在PaaS和SaaS两个云服务层次上的API诱饵构造,即针对当前不同云服务层次的特性分别在这两个层次上构造高交互API诱饵。在PaaS平台层(文中统称为容器编排层)上,大部分系统都依赖于容器编排技术,攻击者利用编排层API存在的安全问题实现容器逃逸,进而获得权限提升和权限持久化,最终获取Master节点(Kubernetes集群的控制节点)的访问权限。文中分析了当前云组件的API脆弱点,主要设计了针对Kubernetes和Docker的API诱饵。在SaaS应用层上,该场景下的API安全问题和具体的应用软件相关,选取了危害性较大且利用频率较高的API漏洞,构建了对应的高交互API诱饵。

3.1 容器编排层诱饵构造

PaaS是一种由第三方提供服务器平台的服务模式,是云计算的重要组成部分。PaaS为用户提供了一个框架,允许用户开发、运行和管理自己的应用,而无需构建和维护与该流程相关联的编排行为;开发者只需关注自己的业务逻辑,不必关心底层基础架构的维护和更新。当前主流的PaaS系统中,大都依赖于容器编排技术,其中以生产级开源容器编排系统Kubernetes最具代表性。依托以Docker为代表的容器技术,Kubernetes已经广泛用于自动部署、扩展和管理容器化服务。在PaaS系统中,API安全问题主要来源于Kubernetes组件和Docker,因此,文中围绕Kubernetes和Docker进行编排层API诱饵的构造。

Kubernetes API Server(Master节点的组件之一)是Kubernetes内部的核心组件。Kubernetes集群中各功能模块之间通过API Server提供的表述性状态传递(REpresentational State Transfer,REST)接口来实现身份认证和数据资源操作,从而实现各模块之间的信息交互。也正因API Server在集群中的关键地位,一旦其遭到攻击,那么攻击者就可以通过控制API Server来控制整个集群。在现实场景中,由于高权限服务账户(Service Account,SA)凭证泄漏或用户登录凭证泄露而导致攻击者通过API Server接管集群的案例数不胜数。此外,Kubelet(集群中的节点代理)作为集群中每个节点的云组件,负责接收并处理来自API Server下发的任务,在节点中以守护进程的形式存在。Kubelet也提供了RESTful API(REST 指一组架构约束条件和原则,满足这些约束条件和原则的Web API就是 RESTful API)供API Server调用来管理Kubernetes上的资源[21],一旦某个节点的Kubelet API因配置不当而受到攻击,那么该Kubelet所在的节点资源就可能被攻击者接管;如果节点上存在诸如高权限服务账户凭证等敏感信息,攻击者就可以进一步对整个集群发起攻击。

Docker作为容器技术的代表,相较于传统的虚拟机技术具备更快的启动和创建速度、更少的资源占用以及更方便的部署方式,在云服务中得到了大量的应用。然而,由于Docker本身需要较高的系统权限,且Docker的指令本质上都是通过向目标机器的Docker守护进程发起的API请求,一旦目标机器的Docker守护进程上的API存在配置不当的问题,那么攻击者就有可能向Docker守护进程的API发起未授权请求,借助Docker的高权限执行一些危险操作,如创建特权容器来进行容器逃逸等。

针对上述云组件中API存在的脆弱点,设计了3个编排层的API诱饵,具体如表1所示。由于一些云组件的漏洞(如CVE-2022-3172)依赖特定的云组件版本,且不同漏洞所依赖的版本无法兼容。此外,一些漏洞的利用难度高,利用条件过于苛刻,难以用于实际环境。为了保证诱捕系统的可用性,文中没有选择依赖特定云组件版本的漏洞和难以被利用的漏洞来构造诱饵。

表1 编排层API诱饵

3.2 应用层诱饵构造

SaaS是一种将应用软件托管给云厂商,而用户通过Web浏览器或API连接并使用软件的服务模式。在该模式下,云厂商负责从硬件到软件的全部工作,包括软件更新、安全修补和编排升级等,而普通用户只需连接网络即可使用软件服务,无需安装特定的软件。SaaS场景下的API安全问题主要发生在应用层面。对2017年至2022年危害性较大且利用率较高的应用程序API相关漏洞进行了调研,最终选出15个漏洞,详情如表2所示。需要注意的是,即便是属于同一个组件的漏洞,其依赖的组件版本也不尽相同,因此需要分别构建单独的诱饵环境。

表2 应用层API诱饵

4 系统设计与实现

为了验证所提的API攻击诱捕技术的有效性,设计并实现了API攻击诱捕系统。诱捕系统的总体架构如图2所示。诱捕系统主要包括工作节点和控制节点两大模块。工作节点负责部署应用层诱饵和编排层诱饵,控制节点负责流量的转发、日志记录和应用层诱饵的调度。为了增强迷惑性并充分利用物理资源,控制节点将不同的应用层API诱饵聚合并对外伪装成单个系统,使用提出的动态调度算法对应用层API诱饵进行动态开启和关闭。

图2 诱捕系统总体架构

4.1 工作节点

工作节点由应用层API诱饵、Docker API 诱饵、Kubelet API诱饵、SA凭证诱饵以及其他一些维持集群运转的云组件构成。该节点主要负责诱饵的部署和运行。应用层API诱饵以容器的形式被封装在Kubernetes pod(集群中可以创建和管理的最小单元)中,互相隔离并运行在一个单独的命名空间中,每个应用层API诱饵中都放置了一个SA凭证诱饵。

为了更加全面地收集攻击者在工作节点上的攻击行为,诱捕系统会收集工作节点上的命令执行日志、Docker守护进程日志和Kubelet守护进程日志。文中在工作节点上设置了定时任务,将Docker守护进程日志和Kubelet 守护进程日志定期发送到控制节点的日志服务中。为了捕获攻击者在工作节点上的命令执行行为,还对bash(Unix shell的一种)的源码进行了修改和重新编译,并用其替换了工作节点和每个应用层API诱饵中原有的shell程序(俗称壳,一个命令解析器);每当攻击者执行命令,修改后的bash就会将攻击者执行的命令发送到控制节点的日志服务中,即便攻击者后续清理了命令执行日志,也能在日志服务中看到完整的命令执行历史。

4.2 控制节点

控制节点由重定向器、调度器、日志服务、API Server和其他云组件构成。重定向器和调度器分别负责流量的转发和应用层诱饵的动态调度,API Server负责对工作节点上的应用层诱饵下发控制指令,同时记录来自工作节点的攻击者请求。

4.2.1 重定向器

贾召鹏等[22]提出了蜜罐簇思想,能够将多个不同的Web蜜罐聚合起来,对外伪装成单个应用系统,从而达到迷惑攻击者的目的。文中的重定向器借鉴了该思想,重定向器维护着一个诱饵地址表,在接收到攻击请求时,重定向器会对请求进行分析,并使用事先预置的特征规则对请求的内容进行匹配。对于匹配成功的攻击请求,重定向器将会首先按照诱饵地址表中的键值对把攻击请求通过容器网络转发到对应的应用层API诱饵,然后将攻击请求的信息发送给调度器和日志服务。最后,由于攻击者可能需要和诱饵进行多次交互,为了避免每次请求都要重定向器进行特征匹配而导致系统效率低下,重定向器会记录本次的请求源IP和请求诱饵作为缓存信息;当接收的请求源IP在缓存中已经存在,且该请求与所有特征规则均不匹配时,重定向器会把该请求转发给缓存中源IP对应的目标诱饵。

4.2.2 调度器

应用层的诱饵均为高交互类型,相较于低交互类型的诱饵会有更高的物理资源需求。若开启所有的应用层API诱饵,将会造成极大的系统物理资源负担,从而影响系统整体可用性。为此,提出了基于当前网络流量的动态调度算法,在充分利用物理资源的同时最大化捕获效果。调度器是应用层诱捕的核心组件,负责实现系统的动态调度算法。动态调度算法会首先综合考虑每个应用层诱饵的当前被访问频率和历史被访问频率,根据给定的权重和衰减率来更新每个应用层诱饵的优先度,然后根据应用层诱饵的优先度大小排序,并设置前N个应用层诱饵为开启状态,将剩下的应用层诱饵设置为关闭状态;N的取值由系统管理员设置,最大不超过应用层诱饵总数。调度器接收到重定向器发送的信息时,会将其记作对应诱饵的一次访问。每隔一段时间,调度器会根据每个应用层诱饵在这段时间内的被访问次数来计算当前访问频率,并根据当前访问频率fnow、诱饵历史最高访问频率fhis、诱饵权重w和优先度衰减率l,计算诱饵的优先度p：

(1)

其中,诱饵当前访问频率fnow和应用层诱饵历史最高访问频率fhis由调度器计算得出,诱饵权重w和优先度衰减率l均由系统管理员设置。诱饵权重w代表系统管理员对不同漏洞的重视程度,由于fhis只会增加且≥0,因此w越大,fhis增加时对p的影响越大;优先度衰减率l代表诱饵当前访问频率降低时优先度的降低程度,l越高,fnow降低时对p的影响越大,诱饵更容易被调度算法关停。默认条件下每个应用层诱饵的权重和优先度衰减值均相同,系统管理员可以根据不同应用层诱饵所代表漏洞的严重程度进行自定义调整。比如,当系统管理员更关心Apache Log4j远程代码执行漏洞(CVE-2021-44228)的利用情况,那么可以对该漏洞对应的应用层诱饵予以更高的权重和更低的衰减率。

动态调度算法的伪代码描述如下:

输入:用户请求,{fhisi},{fnowi},{wi},{li},{patterni},{pi},N

输出:诱饵状态表{statei}

① whilei≤N

② 用patterni对用户请求内容进行正则匹配,结果记作result

③ if result=true then

④fnowi←fnowi+1

⑤ iffnowi>fhisithen

⑥fhisi←fnowi

⑦ end if

⑧ end if

⑩i←i+1

4.2.3 API Server

API Server是Kubernetes集群的核心组件之一,在系统中负责根据调度器的指示向工作节点上的Kubelet 发送命令以控制应用层诱饵的开启和关闭。此外,API Server也会接受来自工作节点的API请求,通过在配置文件中启动日志记录功能就可以记录来自工作节点的API请求,其中包括来自攻击者获取到服务账户凭证后的调用请求。为了防止API Server被攻陷进而导致系统被攻击者接管,文中关闭了API Server的不安全端口并确保工作节点无法对集群核心组件进行操作。

4.2.4 日志服务

日志服务负责聚合来自不同来源的日志并按照时间顺序进行整合。日志来源如表3所示。

表3 日志来源

4.3 风险控制

为了防止攻击者接管集群从而导致诱捕系统不可用,系统会每隔一段时间使用快照保存当前诱捕系统的状态。当检测到攻击者执行危险操作可能导致诱捕系统不可用时,可以将诱捕系统回滚至上一个快照并封禁攻击者的IP。

5 实 验

5.1 实验环境

为了检验诱捕系统的有效性,笔者在真实环境中进行了测试。将诱捕系统部署在两台阿里云公网服务器上,服务器操作系统均为Centos 7,配置均为2核CPU,2 GB内存,30 GB硬盘容量。其中一台服务器作为控制节点,另一台作为工作节点。应用层诱饵的最大开启数量设置为3,诱饵权重值按照漏洞危害程度设置,危害越高的漏洞,其对应诱饵的权重越大,具体如表4所示,衰减率统一设置为0.3。实验时间从2022年12月1日到2023年1月1日。由于当前市面上缺乏针对云原生环境API攻击的诱捕系统,文中将关闭调度算法后的系统单独部署在另外的两台服务器上用于对比实验,规定对比实验中的应用层诱饵最大开启数量同样为3,由于缺少调度算法,应用层诱饵在一定时间段内的开启时间均等。将系统中的应用层诱饵3个一组,分为5组,每天轮流开启4.8 h,这样对比实验中每个应用层诱饵在一天当中具有相同的开启时间。对比实验的操作系统、配置环境及实验时间均相同。

表4 应用层API诱饵权重值

5.2 实验结果分析

实验期间收到了来自1 274个独立IP的4 875次Web API请求。根据是否访问/robots.txt路由初步判别该请求是否由搜索引擎发起,随后使用WHOIS(一种查询域名的IP以及所有者等信息的传输协议)对初步筛选出的IP进行批量查询,从中识别出属于搜索引擎的IP有4个,将属于搜索引擎爬虫的请求流量过滤,剩余1 270个独立IP以及4 146次Web API请求。在这4 146次请求中,有2 425次GET请求(HTTP协议的一种请求方法),1 721次POST请求(HTTP协议的一种请求方法)。这些请求来自77个不同国家或地区,使用GeoLite2数据集对这些请求的源IP进行查询和统计,得到IP数量前20的国家或地区,如图3所示。这些请求共触发了15个应用层诱饵中的12个,对触发次数进行排序,得到了最受攻击者青睐的前10个漏洞,如图4所示。从图4可以看到,攻击者偏好业务逻辑类的API漏洞,攻击目的更多是获取目标服务器权限。

实验期间,诱捕系统捕获到1 203次对编排层诱饵的攻击。其中,1 189次是公网IP对Docker API 诱饵的访问,8次是攻击者使用高权限服务账户向API Server发起的请求,6次是攻击者对未授权Kubelet API的访问。原因是Docker API诱饵仅须通过公网请求即可触发,而API Server诱饵和Kubelet API诱饵则需要攻击者在应用层API诱饵环境中获得权限后有意识地去探测内网环境才能发现,绝大多数攻击者在应用层API诱饵环境中获得权限后都只进行了权限维持或下载挖矿木马,并没有发觉这是一个容器环境。实验证明文中提出的诱捕系统能够有效地捕获应用层和容器编排层的API攻击行为。

对比实验中的诱捕系统接收到了4 706次请求,捕获到了1 304次针对应用层诱饵的攻击,触发了15个应用层诱饵中的8个,诱饵的触发情况如图5所示。对比实验证明,所提诱捕系统的动态调度算法对提升应用层攻击诱捕能力起到了一定作用。

图5 对比实验应用层诱饵触发情况

5.3 案例分析

介绍了具体的攻击案例,证明文中提出的攻击诱捕系统能够捕获云原生环境下的API攻击行为。

北京时间2022年12月10日凌晨2点,在发现针对solr系统漏洞(CVE-2019-17558)的探测流量增加后,系统及时做出响应并自动开启了对应诱饵。12月10日凌晨3点,系统捕获到了来自IP地址152.89.196.211的攻击,该IP属地为荷兰阿姆斯特丹。攻击者首先向应用层诱饵系统发送了探测请求,系统对探测请求进行特征匹配后重定向到CVE-2019-17558漏洞所对应的应用层诱捕环境,将具备漏洞特征的响应返回给了攻击者,并将攻击者的IP信息进行缓存以保证后续的攻击行为都在该应用层诱捕环境中执行,攻击者的探测行为和后续的攻击行为都会被记录在日志文件中。随后攻击者访问API“/solr/admin/cores”获取到了应用层诱饵solr系统中所有的核心名,随后攻击者针对名为“demo”的核心部件,对API“/solr/demo/config”发起了未授权请求,将“params.resource.loader.enabled”设置为true,该配置允许攻击者执行自定义的Velocity(一种基于Java的模板引擎)模板代码,攻击者利用该漏洞写入了反弹shell定时任务。在3 h 57 min后,攻击者通过反弹shell开始执行命令,由于应用层诱饵中的shell可执行文件已被修改并替换,攻击者在应用层诱饵系统内执行的所有命令都会被发送到日志服务器中。在反弹shell中,攻击者下载并执行了挖矿程序xmrig,其门罗币地址为43j1QxAbHdoRsR1Xm6P4UEHvqur4nR7QDV5PmSteCUi5 XpSSUn55VeJXhEpFGNJcZtUHhPpGpQ6XWj52BS4XbUVhUZCKacZ,但由于被阿里云的防护软件侦测,挖矿行为未能成功。

12月13日21时,攻击者通过反弹shell对应用层API诱饵中的文件进行探测,在发现环境中存在服务账户凭证后,攻击者将针对容器环境的攻击工具cdk上传到诱饵中,随后使用cdk向API Server发起了创建DeamonSet(守护进程集)的API请求来达到容器逃逸的目的,对应的日志记录如图6所示。由于严格控制了服务账户的权限,攻击行为失败。出于风险控制考虑,封禁了该攻击者的IP并将诱捕系统还原到上一个快照的状态。

6 结束语

API逐渐成为攻击者的重点攻击对象。针对当前云原生环境下API存在的安全问题,提出了一种API攻击诱捕技术并在其基础上实现了原型系统。系统在容器编排层和应用层两个层次上分别有针对性地设计了API诱饵并搭建了诱捕环境。在系统部署的一个月内共捕获到1 270个独立IP以及4 146次请求,真实的案例也显示了提出的方案不仅可以捕获云原生环境中API攻击行为,还可以捕获完整的攻击过程,证明了文中提出的API攻击诱捕技术的有效性。