Kong API 网关 (https://github.com/Kong/kong) 是目前最受欢迎的云原生 API 网关之一，有开源版和企业版两个分支，被广泛应用于云原生、微服务、分布式、无服务云函数等场景的API接入中间件，为云原生应用提供鉴权，转发，负载均衡，监控等能力。腾讯蓝军在红蓝对抗实战演练中发现云原生 API 网关的特性和能力，可能成为从外网渗透进内网的新入口；且此前 Kong 在容器场景的默认配置、文档和实践，都可能会导致用户将这个风险暴露给外网。

这个安全问题是如何发现的？

腾讯蓝军在一次红蓝对抗安全演练过程中，根据对云原生和应用容器化实践的理解，我们把外网攻击入口锁定在 API 网关这个管理南北流量的服务组件上，成功通过该组件访问到了内网核心设施进行内网渗透。

这个安全问题的影响是什么？

Kong 使用 Kong Admin Rest API 作为管理 Kong Proxy 能力的关键入口，以支持最大程度的灵活性；在开源分支里，这个管理入口是没有鉴权能力的(Kong企业版支持对 Kong Admin Rest API 进行角色控制和鉴权)，Kong建议用户在网络层进行访问控制；当攻击方可以访问到这个 API，他就具有了 Kong Proxy 的所有能力，可以查看和修改企业当前在南北流量管理上的配置，可以直接控制 API 网关使其成为一个开放性的流量代理(比SSRF更便于使用和利用)；从攻击方的角度思考，控制了这个 API 等于是拥有了摸清网络架构和打破网络边界的能力。

企业在使用 Kong 作为云原生架构的API网关时，通常会使用容器的方式进行搭建，以支持分布式和可扩展性；而在 2.0.3 版本之前，当企业遵循官方文档或默认配置使用 Docker 容器的方式搭建 Kong API 网关时，官方文档和默认配置都会指引用户将未经鉴权的 Admin 管理能力对公网开放（0.0.0.0），导致攻击者可以控制网关的全部能力，修改 upstreams、services、router 等配置，进而攻击企业内网。这也是为什么，在公网上开放的 Kong Admin Rest API 并不少见，可以从 hostname 等配置信息可以看出绝大部分是基于 docker 容器进行搭建的。后来，我们在这个问题上和 Kong 安全团队进行交流，Kong 团队很快就调整了容器场景的安全设计。

如何判断企业资产是否受该问题影响？

使用扫描器或HIDS去发现这里的风险是比较直接的。腾讯蓝军和漏洞扫描洞犀团队、主机安全洋葱团队一起在去年12月25日上线了相关策略已覆盖对云原生API网关组件的风险发现能力，并集成到内部 devops 平台供业务团队使用。

Kong Admin Rest API 的根目录 banner 包含了很多明显的特征，根据这些特征可以比较容易的获取到开放在外网的 Admin Rest API，同时也有很标准的 server response header: Server: kong/0.10.3，例如：

  1. HTTP/1.1200 OK
  2. Date:Wed,15Apr202003:03:16 GMT
  3. Content-Type: application/json; charset=utf-8
  4. Connection: keep-alive
  5. Access-Control-Allow-Origin:*
  6. Server: kong/2.0.2
  7. Content-Length:8312
  8. X-Kong-Admin-Latency:2
  9. {
  10. "plugins":{
  11. "enabled_in_cluster":[],
  12. "available_on_server":{}
  13. },
  14. "tagline":"Welcome to kong",
  15. "configuration":{
  16. "...":"...",
  17. "kong_env":"/usr/local/kong/.kong_env",
  18. "cassandra_schema_consensus_timeout":10000,
  19. "log_level":"notice",
  20. "admin_ssl_cert_key_default":"/usr/local/kong/ssl/admin-kong-default.key",
  21. "real_ip_recursive":"off",
  22. "proxy_error_log":"/dev/stderr",
  23. "ssl_cipher_suite":"intermediate",
  24. "router_consistency":"strict",
  25. "pg_port":5432,
  26. "cassandra_keyspace":"kong",
  27. "ssl_cert_default":"/usr/local/kong/ssl/kong-default.crt",
  28. "nginx_http_ssl_session_timeout":"1d",
  29. "error_default_type":"text/plain",
  30. "role":"traditional",
  31. "admin_ssl_enabled":false,
  32. "trusted_ips":{}
  33. },
  34. "version":"2.0.2",
  35. "node_id":"0bfe4d56-c5f3-4df0-9af1-4fabb0cba108",
  36. "lua_version":"LuaJIT 2.1.0-beta3",
  37. "prng_seeds":{
  38. "pid: 22":772511031151,
  39. "pid: 1":431556103185
  40. },
  41. "timers":{
  42. "pending":9,
  43. "running":0
  44. },
  45. "hostname":"72f74e7bd339"
  46. }

我们使用知道创宇的 ZoomEye 快速对目前公网上的 Kong 资产进行检索，可以找到 5 万多个 kong 服务在公网开放，根据上述特征可以发现有 3 千多个 Admin Rest API 未鉴权对外；ZoomEye 在网络空间搜索能力上的优越性极大的帮助了我们对此风险的整体评估和分析。

Kong 之外的API网关组件

为支持云原生、微服务等应用的需求，API 网关在实现的过程中都会对配置的灵活性有所侧重，所以把配置能力从主机层开放成可访问可动态修改的配置服务是很多 API 网关组件都会优先支持的，相似的问题也在类似的网关组件中存在，可以使用相同的攻击手法进行利用。

同时也需要注意：大部分情况下云原生 API 网关是不会附带一个 Web Dashboard 供用户使用的，所以针对像 Kong 这类较著名的 API 网关组件，业务团队在使用过程中可能会搭建第三方 Kong Dashboard 方便进行配置，而这些 Dashboard 的鉴权设计是远远无法满足一个运维平台的安全需求的。

时间线

  • 2020/03/19 腾讯蓝军同Kong安全团队交流在容器场景安全风险

  • 2020/03/20 Kong团队开始逐步对产品和文档进行调整

  • 2020/03/31 Kong团队发送致谢邮件并反馈产品修复细节

  • 2020/03/31 向 CNVD 报告该漏洞和利用场景

  • 2020/04/12 根据在 Docker 场景存在的问题分配 CVE-2020-11710

  • 2020/04/15 腾讯蓝军发布漏洞提醒和漏洞信息

参考链接

  • https://github.com/Kong/kong

  • https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11710

  • https://github.com/Kong/docker-kong/commit/18c4029ee3d4acfece679fa87b5dd081fb56fdd5

  • https://www.zoomeye.org/

注: 在复盘过往的红蓝对抗过程中，突然发现此处的风险可能攻防两方都会有所疏忽，仓促之间发布公告，请业界的大佬们斧正。

声明：本文来自腾讯安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。