漏洞分析 – Kong未授权访问漏洞(CVE-2020-11710)

释放双眼,带上耳机,听听看~!

简介

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的默认端口与用途如下。
端口用途 HTTP port HTTPS port 备注
Admin Restful API 8001 8444 Kong社区版 Admin Restful API端口 应仅能被管理员访问
Proxy Port 8000 8443 提供给公网访问

该漏洞根本原因:不恰当的配置导致”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不恰当配置导致存在未授权漏洞,危害更大。

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

本文来自先知社区

人已赞赏
安全教程

PHP代码审计之关于PHP_SELF的简单利用

2020-4-27 0:19:46

安全教程

CVE-2018-18557复现与分析

2020-4-27 0:20:00

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索