简介

Kong是开源的、"云原生"(cloud-native)的API Gateway应用程序，使用Kong gateway的各种插件可实现对访问流量的精细控制、访问鉴权。

其官方称Kong是针对与云与混合架构的下一代API平台.
Next-Generation API Platform for Multi-Cloud and Hybrid Organizations.

• 为什么要用API Gateway ? 举个例子:业务web提供了一个"微服务"API接口，可查看全国天气数据
  • 用API Gateway对该API接口设置 访问频率限制(如5分钟1次)，可避免被频繁访问
  • 用API Gateway对该API接口设置 鉴权(Basic auth等)，可允许有预定义的凭据的client访问
  • 用API Gateway对该API接口设置 Proxy Caching ，可避免重复请求带来的压力
  • 用API Gateway对该API接口设置 负载均衡
  • 用API Gateway对该API接口设置 数据转换
  • ...

更多Fetures参考Kong官方资料:

What is an API Gateway? - KongHQ

Fetures

基本信息

• 版本分类
  • Kong Gateway Community - 社区版，使用默认配置存在未授权漏洞的是社区版 version <=2.0.2
  • Kong Enterprise - 企业版，支持角色控制和鉴权，不存在该漏洞。目前2020.4.16的最新版本号是1.5.x

• 默认端口，Kong的默认端口与用途如下。

该漏洞根本原因：不恰当的配置导致"Admin Restful API的端口可被公网访问".

漏洞分析

根据修复漏洞CVE-2020-11710的diff https://github.com/Kong/docker-kong/commit/18c4029ee3d4acfece679fa87b5dd081fb56fdd5

可知修复方法是把Admin Restful API端口(8001 和 8444) 的监听从0.0.0.0改成了127.0.0.1

复现漏洞：根据修复漏洞前的官方安装步骤 - 使用docker安装Kong Gateway Community进行安装：

可发现，以下命令中有不恰当的配置，导致了"Admin Restful API的端口可被公网访问"：
（1）倒数第3行的8001:8001表明，访问 0.0.0.0:8001 就等于访问容器"kong"的8001端口。
（2）倒数第2行的8444:8444存在同样的情况。

$ docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 8001:8001 \
     -p 8444:8444 \
     kong:latest

所以根据修复漏洞前的安装步骤进行安装后，默认情况下，Kong的4个端口可被公开访问，其中包括了Admin Restful API所用的2个端口(HTTP port:8001 , HTTPS port:8444)，攻击者可利用Admin Restful API来管理Kong Gateway的全部功能。

漏洞检测

https://github.com/1135/Kong_exploit/

通过Kong的未授权漏洞实现了可回显的SSRF，几乎等于突破了网络边界，危害巨大！

如，对某内网系统进行访问:
(页面内的css资源使用了相对路径,没获取到,如果需要获取再创建一个"服务"即可)

漏洞危害

• 攻击者利用"Kong未授权访问漏洞"可以执行的操作包括但不限于：
  • 信息泄露 - 查看当前配置信息("服务"地址等)
  • Basic SSRF - 可回显Response的SSRF: 通过添加Route到内网其他重要"(web)服务"实现
  • MITM - 如获取所有普通用户发向某个"(web)服务"的HTTP/HTTPS请求、响应

因为Kong常搭建在云环境中，云环境中的SSRF漏洞的危害更大，参考云安全 - 研究云环境下对SSRF的检测与防御（以AWS为例 ，简单说就是利用SSRF漏洞->访问云提供商自带的管理API->获取云服务器访问权限。

MITM全过程原理

正常逻辑

一个普通用户的正常访问过程
请求过程 client --request--> Kong api_1 --request--> service 1
响应过程 client <--response-- Kong api_1 <--response-- service 1

实现MITM全过程

只看"请求"劫持的全过程("响应“劫持也是类似的)

• 第1步
  • "复制" 原本就存在的Kong api_1 得到Kong api_2 它们都指向 service 1
  • 此时，如果普通用户发出HTTP请求到api_2，与访问api_1得到的Response Body完全相同
• 第2步 创建并配置MITM站点
  • (1) 创建中间人站点 mitm.evil.com
  • (2) 配置MITM站点，实现请求处理(保存/修改/丢弃...) ; 最后将处理后的请求 转发到 Kong api_2
• 第3步 修改Kong api_1指向的服务
  • Kong api_1原本指向 service 1
  • Kong api_1(hijacking) 现在指向 mitm.evil.com
  • 这一步是MITM全过程中最后进行的一步,放到最后做可以避免正常用户访问失败

MITM的效果

一个普通用户的访问过程(Kong api_1已被劫持)
请求过程 client --request--> Kong api_1(hijacking) --request--> mitm.evil.com(forwarding) --request--> api_2 --request--> service 1
响应过程 client <--response-- Kong api_1(hijacking) <--response-- mitm.evil.com(forwarding) <--response-- api_2 <--response-- service 1

• 一个普通用户的访问(被劫持全过程):
  • (1)一个普通用户的请求发向 Kong api_1(hijacking) ，Kong把请求发到其指向的"web服务":MITM站点
  • (2)MTIM站点实现Request处理(保存/修改/丢弃...)并将Request转发到 Kong api_2
  • (3) Kong api_2 将请求发到其指向的"web服务":service 1 得到Response,返回给:MTIM站点
  • (4) MTIM站点实现Response处理(保存/修改/丢弃...)并将Response转发到 Kong api_1(hijacking)
  • (5) 这个普通用户得到了Response

检测MTIM

• 如何检测这种MTIM？本次MITM攻击会产生这些异常:
  • Kong api_2指向的那个正常服务service 1，正常情况下会收到来自不同源IP的请求，如上MITM攻击后，只能收到来自mitm.evil.com的请求。
  • kong的服务器会主动连接互联网的mitm.evil.com(流量大小 取决于被劫持接口的正常流量大小)

修复方法

1.仅本机可访问Admin Restful API. 修改 docker-compose.yaml: 将8001:8001 改为127.0.0.1:8001:8001,将8444:8444 改为127.0.0.1:8444:8444
2.设置严格的ACL,仅允许必要的访问

总结

Kong未授权漏洞根本原因：不恰当的配置导致"Admin Restful API的端口可被公网访问"。
所以不管使用哪个版本，只要进行了不恰当的配置，导致Admin Restful API可被攻击者访问，都会存在风险。

Kong的用途决定了它可以管理一些南北向流量，内网可访问的范围大。
而且Kong是"云原生"(cloud-native)应用，常部署在云环境上，如果Kong不恰当配置导致存在未授权漏洞，危害更大。

漏洞原理简单，但应重视不恰当配置导致的漏洞。