惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Vulnerabilities – Threatpost
博客园 - 司徒正美
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
大猫的无限游戏
大猫的无限游戏
酷 壳 – CoolShell
酷 壳 – CoolShell
Forbes - Security
Forbes - Security
D
Darknet – Hacking Tools, Hacker News & Cyber Security
小众软件
小众软件
人人都是产品经理
人人都是产品经理
Know Your Adversary
Know Your Adversary
Security Latest
Security Latest
雷峰网
雷峰网
Cisco Talos Blog
Cisco Talos Blog
Latest news
Latest news
GbyAI
GbyAI
Last Week in AI
Last Week in AI
Hacker News: Ask HN
Hacker News: Ask HN
U
Unit 42
S
SegmentFault 最新的问题
月光博客
月光博客
Security Archives - TechRepublic
Security Archives - TechRepublic
Attack and Defense Labs
Attack and Defense Labs
S
Secure Thoughts
N
News and Events Feed by Topic
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
A
Arctic Wolf
Schneier on Security
Schneier on Security
C
CERT Recently Published Vulnerability Notes
I
Intezer
V
Visual Studio Blog
Microsoft Security Blog
Microsoft Security Blog
SecWiki News
SecWiki News
Google Online Security Blog
Google Online Security Blog
N
Netflix TechBlog - Medium
I
InfoQ
T
Tor Project blog
腾讯CDC
T
Tenable Blog
Webroot Blog
Webroot Blog
Y
Y Combinator Blog
TaoSecurity Blog
TaoSecurity Blog
Google DeepMind News
Google DeepMind News
AI
AI
C
Cisco Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V2EX - 技术
V2EX - 技术
PCI Perspectives
PCI Perspectives
C
CXSECURITY Database RSS Feed - CXSecurity.com
G
GRAHAM CLULEY
S
Schneier on Security

Ming Blog

OpenClaw安全实战系列(四):幽灵连通性—揭秘CVE-2026-32038沙箱网络隔离绕过与靶标实战 OpenClaw安全实战系列(一):Agent Skill 供应链投毒路径重现与靶标建设 OpenClaw近期生态安全事件解读:从RCE漏洞到Skill供应链投毒分析 OpenClaw安全实战系列(二):白名单也防不住?复盘 CVE-2026-28363 授权绕过全过程 OpenClaw安全实战系列(三):利用网关劫持实现 OpenClaw 控制端 1-Click RCE (CVE-2026-25253) 从现网到靶场:2025云上AI安全事件深度复盘 提示词注入:近期大模型安全漏洞案例剖析 大模型生态的数据泄露危机:从向量数据库到AI助手的“失控链” 2025 Verizon DBIR解读 | 供应链攻击30%+勒索软件44%:边缘设备漏洞与AI滥用催生新风险 开源大模型推理软件的攻击面分析:云上LLM数据泄露风险研究系列(四) LLM数据泄露风险研究系列(三):基于LLM应用的攻击面分析 从环境构建到漏洞利用:如何用Metarget和Coogo复现K8s IngressNightmare攻击链 网盘数据泄露探索:从访问控制突破到敏感信息发现 从数据库沦陷到供应链投毒:大模型安全危机背后的“隐形战场 2024 Verizon DBIR解读 | 数据泄露转向连接云的第三方软件供应链 洞见RSA2024 | Kubernetes攻击与防御技术综述 RSAC 2024创新沙盒|Aembit:面向IAM的云工作负载访问控制平台 那些年陪自己走过的歌声 客户端文件直传对象存储的便捷与安全性探究 无题 日常记录 Service Mesh未来发展趋势浅析 云攻防课程系列:云计算基础与整体安全 RSA创新沙盒盘点Dazz — 面向SaaS化的云安全漏洞缓解平台 云原生API安全:背景、态势与风险防护 OpenTelemetry Operator for Kubernetes实践 利用Serverless函数造成的DoS攻击分析 Goodbye 2022, what up 2023 如何正确地使用CI/CD工具 红岩子游 云原生服务风险测绘分析【五】:Etcd Neosec — 面向API安全的SaaS化防护方案 云原生服务风险测绘分析【四】:Prometheus 巨浪 云原生服务风险测绘分析【二】:Harbor 平衡 云原生服务风险测绘分析【一】:Docker、Kubernetes 读书笔记 猫咪 one little candle 【云原生应用安全】云原生应用安全防护思考(二) 【云原生应用安全】云原生应用安全防护思考(一) 【云原生应用安全】云原生应用安全风险思考 RSA 创新沙盒盘点| WABBI — 面向应用全生命周期的安全防护方案 新年寄语 陀螺 主流开源Serverless平台OpenFaaS安全性研究 电影《Tschick》观后感 电影《Jojo Rabbit》观后感 Serverless安全研究 — Serverless安全防护 Serverless安全研究 — Serverless安全风险 夜晚随笔 云原生攻防研究 — 针对AWS Lambda的运行时攻击 Serverless安全研究 — Serverless概述 Music Corner 怀念2017的新西兰之旅 好书推荐 — Kubernetes安全分析 【云原生攻防研究】Istio访问授权再曝高危漏洞 RSA 创新沙盒盘点| AppOmni—面向SaaS数据泄漏的持续性监控和告警防护 主流云原生微服务API网关成熟度与安全功能对比分析 浦明的博客 浦明的博客 浦明的博客
云原生服务风险测绘分析【三】:Kong和Apache APISIX
Ming Blog · 2022-04-16 · via Ming Blog

本文转自绿盟科技研究通讯公众号云原生服务风险测绘分析(三):Kong和Apache APISIX

专题:【云原生服务风险测绘分析】

往期回顾:

云原生服务风险测绘分析(一):Docker和Kubernetes

云原生服务风险测绘分析(二):Harbor

一. 概述

微服务架构中,API网关充当着非常重要的一环,它不仅要负责外部所有的流量接入,同时还要在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度的控制行为。API网关一方面将外部访问与微服务进行了隔离,保障了后台微服务的安全,另一方面也节省了后端服务的开发成本,有益于进行应用层面的扩展。与此同时,API网关也具备解决外界访问带来的安全问题,如TLS加密、数据丢失、跨域访问、认证授权、访问控制等。因而笔者认为云原生API网关暴露的风险值得我们去进一步探索。

本篇为云原生测绘系列的第三篇,笔者从测绘角度分析了目前主流的云原生API网关代表Kong和Apache APISIX存在的风险,内容包括资产发现、资产漏洞、资产脆弱性发现三个维度,最后还提供了一些安全建议供各位读者参考。

注:文中统计的测绘数据为近一个月的国内数据,相关技术仅供研究交流,请勿应用于未授权的渗透测试。

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所示(资产数较少的由于篇幅原因不在图中显示):

image
图1. Kong资产地区分布

以上Kong资产暴露的端口情况笔者进行了统计,如图2所示:

image
图2. Kong资产端口分布

由图1,图2我们可以得出如下信息:

  • 国内暴露的Kong资产信息中有约85%的数据来源于北京市、广东省、浙江省、上海市、香港特别行政区、江苏省、台湾省、宁夏回族自治区,其中北京市暴露1630条数据位居第一

  • 国内暴露的Kong资产使用的端口主要分布在443、80、8000、8443端口,其中443端口数量2131个位居第一、80端口数量2017个位居第二

2.1.2 Kong资产版本分布

借助测绘数据,笔者对国内暴露的Kong资产版本进行了分析,其分布情况如图3所示(资产版本数较少的由于篇幅原因不在图中显示):

image
图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年,根据CVSS 2.0标准,其中含高危漏洞2个,中危漏洞1个。漏洞类型主要为未授权访问及权限提升,其中CVE-2021-27306漏洞在市面上曝光度较大,笔者也针对这些漏洞进行了信息汇总,其中包括公开暴露的PoC及ExP信息,如图4所示:

image
图4. Kong漏洞介绍

2.3 Kong资产脆弱暴露情况分析

借助测绘数据,笔者从Kong漏洞维度,统计了现有暴露资产的漏洞分布情况,如图5所示:

image
图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)的影响面,具体见如下表格:

CVE ID 影响资产数 影响面
CVE-2021-27306 3028 82%
CVE-2020-11710 2171 37%
CVE-2020-35189 814 22%

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所示(资产数较少的由于篇幅原因不在图中显示):

image
图6. Apache APISIX资产地区分布

以上APISIX资产暴露的端口情况笔者进行了统计,如图7所示:

image
图7. Apache APISIX资产端口分布

由图6,图7我们可以得出如下信息:

  • 国内暴露的APISIX资产信息中有约75%的数据来源于北京市、广东省、浙江省、上海市,其中北京市暴露316条数据位居第一

  • 国内暴露的APISIX资产使用的端口主要分布在9000、443、80端口,其中9000端口数量471个位居第一、443端口数量446个位居第二

3.2.2 Apache APISIX资产版本分布

借助测绘数据,笔者对国内暴露的APISIX资产版本进行了分析,其分布情况如图8所示:

image
图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等配置)中的Admin API Key项,它是Admin API的访问token,其默认值为edd1c9f034335f136f87ad84b625c8f1 ,配置信息如下所示:

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

为保护Admin API,用户需对系统默认key(如上所示)进⾏修改,关闭此配置意味着访问Admin API无需进行任何认证。

例如,若用户未对Admin API默认访问token进行修改,攻击者可利用该token控制APISIX [10],从而获取路由信息,如图9所示:

image
图9. 通过默认token获取路由信息

若用户使用其它token访问Admin API,则不会获取相应路由信息,并返回401状态码,如图10所示:

image
图10. 通过非默认token返回401状态码

APISIX Dashboard默认登录信息配置

APISIX Dashboard登录信息默认存储在/usr/local/apisix/dashboard/conf/conf.yaml ⽂件中。可通过修改 authentication.users项来进⾏登录项配置。在2.6版本中,Dashboard默认登录信息为admin/admin,若用户未对默认登录配置进行修改,攻击者可在进⼊Dashboard后添加⾃定义路由信息,并通过在接⼝路由中写⼊扩展脚本,从⽽达到执⾏系统命令的效果,添加扩展脚本如图11所示:

image
图11. 通过在Dashboard接口路由中填写扩展脚本实现系统命令执行

APISIX插件配置

如之前所述,APISIX的config.yaml文件中支持用户对使用的插件(Plugins)进行声明,若用户声明了含有漏洞的插件,则可能会导致一定风险。如Apache APISIX 2.12.1之前的版本中,启⽤ Apache APISIX batch-requests 插件(该插件含有漏洞)后,会存在改写X-REAL-IP header的⻛险,进而攻击者会通过 batch-requests 插件绕过Apache APISIX 数据⾯的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所示:

image
图12. Apache APISIX漏洞介绍

3.3 Apache APISIX资产脆弱暴露情况分析

借助测绘数据,笔者从APISIX漏洞维度,统计了现有暴露资产的漏洞分布情况,如图13所示:

image
图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默认登录⽤户名与密码,并限制外部访问Apache APISIX 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 | Apache APISIX® – Cloud-Native API Gateway

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