一、概述
微服务架构中，API网关充当着非常重要的一环，它不仅要负责外部所有的流量接入，同时还要在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度的控制行为。API网关一方面将外部访问与微服务进行了隔离，保障了后台微服务的安全，另一方面也节省了后端服务的开发成本，有益于进行应用层面的扩展。与此同时，API网关也具备解决外界访问带来的安全问题，如TLS加密、数据丢失、跨域访问、认证授权、访问控制等。因而笔者认为云原生API网关暴露的风险值得我们去进一步探索。
本篇为云原生测绘系列的第三篇，笔者从测绘角度分析了目前主流的云原生API网关代表Kong和Apache APISIX存在的风险，内容包括资产发现、资产漏洞、资产脆弱性发现三个维度，最后还提供了一些安全建议供各位读者参考。
注：文中统计的测绘数据为近一个月的国内数据，相关技术仅供研究交流，请勿应用于未授权的渗透测试。
二、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年，根据CVSS 2.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）的影响面，具体见如下表格：
| 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所示（资产数较少的由于篇幅原因不在图中显示）：
图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等配置)中的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所示：
图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 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所示：
图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默认登录⽤户名与密码，并限制外部访问Apache APISIX Dashboard
- 针对CVE-2021-43557漏洞, 若使⽤⾃定义插件，可在使⽤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
[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
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。