面向云原生的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承載的數據價值更大,攻擊成本更低?，F階段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攻擊誘捕技術的有效性。