Kong_Admin_API未授权访问漏洞-CVE-2020-11710

由 mayoterry 发布

1、概述

根据官方描述,Kong是一个云原生,快速,可扩展的分布式微服务抽象层(也称为API网关或API中间件)。 它的核心价值是高性能和可扩展性,于2015年作为一个开源项目提供。

参考腾讯之前发的漏洞通告,在一次红蓝对抗中,攻击队利用了kong未授权访问漏洞,成功通过该组件访问到了目标内网核心设施,进而进行了一些列的内网渗透 。在通告kong官方后,官方对该问题进行了修复,还申请了对应了CVE漏洞编号-CVE-2020-11710。

kong官方github项目针对本次问题修复的commit

image-20200503202545987.png

可以看到官方的修复方式就是在docker-compose里把kong admin api的绑定地址由0.0.0.0改为了127.0.0.1,这种方式可以说得上“简单粗暴” 。参考修复方式,不难看出,这是一个典型的 “ 应用配置不当 ”造成的安全问题。

查阅kong官方使用文档,可以发现,造成kong admin api未授权的另一个原理就是kong的开发者对kong开源版本的admin api接口根本没提供鉴权能力,这也导致运维人员在面对这个未授权漏洞的时候” 有点懵 “。

另外官方在开源版本和企业版本的功能差异里也说明了,api接口的鉴权能力只在企业版本里提供:

image-20200503204634154.png

综上,我们可以判断,无论哪个版本的kong,只要运维人员没有正确的设置admin api的端口开放情况,都可能存在未授权漏洞。

漏洞总结概述:

  1. kong admin api未授权漏洞默认出现在dokcer部署的场景中,在version <=2.0.2 ,api的端口默认绑定在了0.0.0.0上,在2.0.3及之后的版本中,官方的修复方式是把api的端口默认绑定在127.0.0.1上;
  2. 在kong的所有版本中,如果运维人员误操作把admin api接口开放到了公网,并且该接口未设置鉴权,那么依然存在未授权漏洞;
  3. 只有企业版kong默认提供了api接口的鉴权能力。

2、漏洞环境搭建

为了方便,我们使用docker部署搭建kong环境,拉取kong官方在dockerhub上的镜像,这里我们选择2.0的版本:docker pull kong:2.0-ubuntu 。注意,docker镜像的启动方式不能参考dockerhub的介绍文档(版本可能比较旧),可以参考官方的文档

因为2.0版本在漏洞的影响版本范围内,所以8001 ,8443(admin api默认开放端口)端口绑定在0.0.0.0上

image-20200503210941805.png

直接访问目标地址的8001或者8443端口,如果出现kong相关配置的json信息,就说明存在未授权访问漏洞。

image-20200503211601165.png

3、Kong API 网关基础使用

在使用前,我们需要搞清楚kong服务的各个端口功能:
image-20200503213717673.png

参考官方使用文档 ,以下列举API的基础使用

查看用户设置的Service:

curl -i http://example.com:8001/services/

查看用户设置的Route:(example-service为自定义名称)

curl -i http://example.com:8001/services/example-service/routes

添加用户Service:(http://10.10.1.1是需要访问的内网地址)

curl -i -X POST \
  --url http://example.com:8001/services/ \
  --data 'name=example-service' \
  --data 'url=http://10.10.1.1'

为Service添加对应的Route:(apache-site为用户设置的任意名称;proxy01为url访问路径)

curl -i -X POST http://example.com:8001/services/example-service/routes \
--data 'paths[]=/proxy01' \
--data 'name=apache-site'

访问目标代理地址:

curl http://example.com:8000/proxy01

这里需要说明一点,如果你需要访问上例内网中目标url:http://10.10.1.1/test.php?1=abc ,在配置完Service和Route后,你可以直接访问地址 http://example.com:8000/proxy01/test.php?1=abc 即可。

4、漏洞利用

泄漏敏感信息

在真实业务环境中,如果管理员误操作将admin api接口暴漏在公网,攻击者首先可以查询已有的services ,进而可以访问一些敏感的内网接口地址。

通过zoomeye,我们可以搜索暴漏在公网的kong admin api接口:
image-20200503220531404.png

通过下面接口,我们可以查看一些敏感的services和routes,进而访问对应内网资源:

curl -i http://example.com:8001/services/
curl -i http://example.com:8001/services/example-service/routes

image-20200503220951750.png

SSRF

除了访问kong api网关配置的一些已有services,我们还可以通过自定义设置kong的代理地址,进而通过SSRF来探测内网的一些WEB服务。

我们可以使用脚本来批量探测内网IP段的常用Web端口,例如80,81,8001,8080等,也可以根据url指纹信息,来识别内网常见存在1day的资产,如struts2,thinkphp ,weblogic 等。

正向代理服务器

正向代理本是kong api服务的基本功能,但是由于暴漏了admin api的接口给攻击者,导致攻击者可以自定义kong的正向代理目标地址,进而达到“内网漫游”的目的。

中间人/钓鱼

由于攻击者可以任意修改services的配置信息,导致代理的目标内网地址可以被攻击者任意修改,这就使得kong服务存在被中间人(MITM)劫持的风险,攻击者可以实施钓鱼伪造,进而获取正常用户一些敏感信息,如账号密码和key等。

image-20200503224947790.png

5、漏洞修复

  1. 将kong admin api端口绑定在127.0.0.1(这种方式可能并不满足业务需求);
  2. 使用严格的ACL,禁止kong admin api端口开放至公网;
  3. 如果用户有条件,可以使用kong企业版本,增加鉴权能力,或者用户通过二次开发或其他第三方组件,增加API的鉴权能力。

暂无评论

发表评论