云原生服務風險測繪分析（三）： Kong和Apache APISIX

一、概述

微服務架構中，API網關充當著非常重要的一環，它不僅要負責外部所有的流量接入，同時還要在網關入口處根據不同類型請求提供流量控制、日志收集、性能分析、速率限制、熔斷、重試等細粒度的控制行為。API網關一方面將外部訪問與微服務進行了隔離，保障了后臺微服務的安全，另一方面也節省了后端服務的開發成本，有益于進行應用層面的擴展。與此同時，API網關也具備解決外界訪問帶來的安全問題，如TLS加密、數據丟失、跨域訪問、認證授權、訪問控制等。因而筆者認為云原生API網關暴露的風險值得我們去進一步探索。

本篇為云原生測繪系列的第三篇，筆者從測繪角度分析了目前主流的云原生API網關代表Kong和ApacheAPISIX存在的風險，內容包括資產發現、資產漏洞、資產脆弱性發現三個維度，最后還提供了一些安全建議供各位讀者參考。

注：文中統計的測繪數據為近一個月的國內數據，相關技術僅供研究交流，請勿應用于未授權的滲透測試。

二、Kong資產風險測繪分析

Kong是一個云原生，快速可擴展的分布式微服務抽象層（通常被稱作API網關，API中間件），Kong于2015年被Mashape公司開源，其在Github上擁有31.6K的Star以及4.2K的Fork數量。Kong的核心價值主要體現在高性能和可擴展性上。擴展性上，Kong主要在Nginx的反向代理基礎上，通過Lua實現了腳本化的擴展，同時所有管理功能都可通過RESTful API來實現。性能層面上，由于Kong內部使用了大量的緩存機制，從而很大程度上避免了阻塞式操作，使用性能上被廣泛開發人員認可。

2.1 Kong資產暴露情況分析

借助測繪數據，我們可以了解到國內Kong資產地區和版本的分布情況，筆者也以這兩個維度為各位讀者進行介紹。

2.1.1 Kong資產地區分布

筆者從測繪數據中得到Kong相關資產共5860條數據，地區分布如圖1所示（資產數較少的由于篇幅原因不在圖中顯示）：

圖1. Kong資產地區分布

以上Kong資產暴露的端口情況筆者進行了統計，如圖2所示：

圖2. Kong資產端口分布

由圖1，圖2我們可以得出如下信息：

• 國內暴露的Kong資產信息中有約85%的數據來源于北京市、廣東省、浙江省、上海市、香港特別行政區、江蘇省、臺灣省、寧夏回族自治區，其中北京市暴露1630條數據位居第一
• 國內暴露的Kong資產使用的端口主要分布在443、80、8000、8443端口，其中443端口數量2131個位居第一、80端口數量2017個位居第二

2.1.2 Kong資產版本分布

借助測繪數據，筆者對國內暴露的Kong資產版本進行了分析，其分布情況如圖3所示（資產版本數較少的由于篇幅原因不在圖中顯示）:

圖3. Kong資產版本分布

上圖可以看出在統計的Kong資產中，37%的資產未獲取到具體版本信息，剩余約63%資產中，絕大多數資產暴露版本分布在1.4.3、2.4.1、2.1.4、0.14.1、0.11.0、2.2.0、1.5.1、2.5.0、1.3.0、2.0.1之中，值得注意的是，0.14.1版本為2018年8月發布的版本，為相對早期的版本，但在公網上暴露的資產數量確不少。

2.2 Kong漏洞介紹

Kong于2015年開源至今，已有約7年時間，在此期間一共曝出三個漏洞[1][2]][3],可以說漏洞數量相對還是比較少的，從CVE編號信息我們可以看出漏洞披露時間主要集中在2020-2021年，根據CVSS2.0標準，其中含高危漏洞2個，中危漏洞1個。漏洞類型主要為未授權訪問及權限提升，其中CVE-2021-27306漏洞在市面上曝光度較大，筆者也針對這些漏洞進行了信息匯總，其中包括公開暴露的PoC及ExP信息，如圖4所示：

圖4. Kong漏洞介紹

2.3 Kong資產脆弱暴露情況分析

借助測繪數據，筆者從Kong漏洞維度，統計了現有暴露資產的漏洞分布情況，如圖5所示:

圖5. Kong漏洞分布

可以看出，在國內互聯網暴露的Kong資產中，有3028個資產被曝出含有CVE-2021-27306漏洞（未授權訪問），2171個資產被曝出含有CVE-2020-11710漏洞（未授權訪問）, 814個資產被曝出含有CVE-2020-35189漏洞（枚舉），其中每個資產可能命中多條CVE。

通過上圖我們也可以看出命中CVE-2021-27306漏洞的資產數約占總資產數的52%，命中CVE-2020-11710漏洞的資產數約占總資產數的37%，可見這兩個CVE漏洞影響面較大，通過前面的Kong漏洞介紹，我們可以進一步了解這三個漏洞，篇幅原因此處不再贅述。此外，筆者還統計了Kong漏洞在現有已知版本資產中（數量3707）的影響面，具體見如下表格：

2.4 安全建議

• 根據官方補丁版本及時對Kong進行更新
• 根據官方提供的緩解措施進行臨時緩解

三、Apache APISIX資產風險測繪分析

Apache APISIX是一個云原生、高性能、可擴展的云原生API網關，基于OpenResty(Nginx+Lua)和Etcd來實現，對比傳統的API網關，具有動態路由和熱插件加載的特點。系統本身自帶前端，可以手動配置路由、負載均衡、限速限流、身份驗證等插件，操作方便。Apache APISIX于2019年6月6日開源，同年10月17日進入Apache孵化器，正式成為 Apache項目，歷時孵化9個月后，畢業成為Apache頂級項目。

3.1 Apache APISIX資產暴露情況分析

借助測繪數據，我們可以了解到國內APISIX資產地區和版本的分布情況，筆者也以這兩個維度為各位讀者進行介紹。

3.1.1 Apache APISIX資產地區分布

筆者從測繪數據中得到APISIX相關資產共1126條數據，地區分布如圖6所示（資產數較少的由于篇幅原因不在圖中顯示）：

圖6. Apache APISIX資產地區分布

以上APISIX資產暴露的端口情況筆者進行了統計，如圖7所示：

圖7. Apache APISIX資產端口分布

由圖6，圖7我們可以得出如下信息：

• 國內暴露的APISIX資產信息中有約75%的數據來源于北京市、廣東省、浙江省、上海市，其中北京市暴露316條數據位居第一
• 國內暴露的APISIX資產使用的端口主要分布在9000、443、80端口，其中9000端口數量471個位居第一、443端口數量446個位居第二

3.1.2 Apache APISIX資產版本分布

借助測繪數據，筆者對國內暴露的APISIX資產版本進行了分析，其分布情況如圖8所示:

圖8. Apache APISIX資產版本分布

上圖可以看出在統計的APISIX資產中，84%的資產未獲取到具體版本信息，剩余約16%資產中，絕大多數資產暴露版本分布在2.0、2.9、2.1之中。

3.2 Apache APISIX脆弱性及漏洞介紹

3.2.1 Apache APISIX脆弱性配置分析

筆者將APISIX的脆弱性配置進行了匯總，主要包含以下三處：

Admin API 的 X-API-KEY 默認配置

Admin API 的 X-API-KEY 指 config.yaml?件(APISIX的配置文件，其中包含Etcd、Plugins、Admin API Key等配置)中的AdminAPI Key項，它是Admin API的訪問token,其默認值為edd1c9f034335f136f87ad84b625c8f1 ，配置信息如下所示：

apisix:#... ...admin_key-  name: "admin"  key: edd1c9f034335f136f87ad84b625c8f1  role: admin

為保護AdminAPI，用戶需對系統默認key(如上所示)進?修改，關閉此配置意味著訪問Admin API無需進行任何認證。

例如，若用戶未對AdminAPI默認訪問token進行修改，攻擊者可利用該token控制APISIX [10],從而獲取路由信息，如圖9所示：

圖9. 通過默認token獲取路由信息

若用戶使用其它token訪問Admin API,則不會獲取相應路由信息，并返回401狀態碼，如圖10所示：

圖10. 通過非默認token返回401狀態碼

APISIX Dashboard默認登錄信息配置

APISIX Dashboard登錄信息默認存儲在/usr/local/apisix/dashboard/conf/conf.yaml?件中。可通過修改authentication.users項來進?登錄項配置。在2.6版本中，Dashboard默認登錄信息為admin/admin，若用戶未對默認登錄配置進行修改，攻擊者可在進?Dashboard后添加?定義路由信息，并通過在接?路由中寫?擴展腳本，從?達到執?系統命令的效果，添加擴展腳本如圖11所示：

圖11. 通過在Dashboard接口路由中填寫擴展腳本實現系統命令執行

APISIX插件配置

如之前所述，APISIX的config.yaml文件中支持用戶對使用的插件（Plugins）進行聲明，若用戶聲明了含有漏洞的插件，則可能會導致一定風險。如Apache APISIX 2.12.1之前的版本中，啟? Apache APISIXbatch-requests 插件（該插件含有漏洞）后,會存在改寫X-REAL-IPheader的?險，進而攻擊者會通過 batch-requests 插件繞過ApacheAPISIX 數據?的IP限制，如繞過 IP ??名單限制。更多詳細信息可參考CVE-2022-24112的官方說明[11]

3.2.2 Apache APISIX漏洞介紹

Apache APISIX從開源至今共被曝出6個漏洞[9]，從CVE編號信息我們可以看出漏洞披露時間主要集中在2020-2022年，根據CVSS 2.0標準，其中含高危漏洞2個，中危漏洞4個。漏洞類型主要為未授權訪問、路徑遍歷、權限提升、訪問控制繞過，其中CVE-2021-45232漏洞在市面曝光度較大，筆者也針對這些漏洞進行了信息匯總，其中包括公開暴露的PoC及ExP信息，如圖12所示：

圖12. Apache APISIX漏洞介紹

3.3 Apache APISIX資產脆弱暴露情況分析

借助測繪數據，筆者從APISIX漏洞維度，統計了現有暴露資產的漏洞分布情況，如圖13所示:

圖13. Apache APISIX漏洞分布

可以看出，在國內互聯網暴露的APISIX資產中，有279個資產被曝出含有CVE-2021-45232漏洞（未授權訪問），248個資產被曝出含有CVE-2022-24112漏洞（未授權訪問）,184個資產被曝出含有CVE-2022-25757漏洞（訪問控制繞過），173個資產被曝出含有CVE-2021-13945漏洞（訪問控制繞過），其中每個資產可能命中多條CVE。

通過上圖我們也可以看出命中CVE-2021-45232、CVE-2022-24112漏洞的資產數約占總資產數的37%，且均為未授權訪問類型漏洞，從Kong曝出熱度最高的CVE漏洞（CVE-2021-27306）來看，未授權訪問是目前云原生API網關在云上面臨的第一大風險，值得我們去關注。

3.4 安全建議

• 根據官方補丁版本及時對APISIX進行更新
• 根據官方提供的緩解措施進行臨時緩解
• 針對CVE-2022-24112漏洞，可在APISIX的配置?件中注釋掉batch-requests ，并且重啟 Apache APISIX以規避?險
• 針對CVE-2021-45232和CVE-2021-33190漏洞，建議?戶及時更改Dashboard默認登錄?戶名與密碼，并限制外部訪問ApacheAPISIX Dashboard
• 針對CVE-2021-43557漏洞, 若使??定義插件，可在使? ngx.var.request_uri 變量前進?路徑規范化處理。同時額外檢查 ctx.var.upstream_uri 和 ctx.var.uri 變量，雖然已有被規范化的可能，但可防患于未然
• 禁止在APISIX的配置文件中對含有漏洞的插件進行聲明

四、總結

近年來，隨著技術的不斷演進，許多企業、互聯網廠商紛紛將其業務系統由單體架構遷移至微服務架構，在實現大規模落地的同時，云原生API網關作為不可或缺的一環承擔起微服務應用的入口守衛，通過流量管控、可視化追蹤、安全防護等機制為微服務的應用提供了可靠保障。本文筆者從測繪角度出發，通過真實測繪數據對主流的云原生API網關Kong和Apache APISIX進行了風險分析，可以看出由于API網關本身的脆弱性配置以及相應曝出的漏洞，已然導致公網上大范圍的未授權訪問風險，作為安全從業人員，我們應對風險及時進行處理，避免發生意外。下一篇筆者將繼續針對云原生環境下的其它組件進行相應測繪風險分析，歡迎各位讀者持續關注，若有任何問題歡迎提出，互相交流學習。

參考文獻

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11710

[2] https://sewan.medium.com/cve-2021-27306-access-an-authenticated-route-on-kong-api-gateway-6ae3d81968a3

[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-35189

[4] https://github.com/1135/Kong_exploit

[5] https://github.com/Ifory885/CVE-2021-45232/blob/main/CVE-2021-45232.py

[6] https://github.com/wuppp/cve-2021-45232-exp

[7] https://www.exploit-db.com/exploits/50829

[8] https://github.com/xvnpw/k8s-CVE-2021-43557-poc

[9] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apisix

[10] Admin API | ApacheAPISIX? -- Cloud-Native API Gateway

[11] https://apisix.apache.org/zh/blog/2022/02/11/cve-2022-24112