云原生服务风险测绘分析【四】：Prometheus

本文转自绿盟科技研究通讯公众号云原生服务风险测绘分析（四）：Prometheus

专题：【云原生服务风险测绘分析】

往期回顾：

一. 概述

Prometheus是一套开源的监控、告警、时间序列数据库的组合工具。与Kubernetes由Google内部Borg系统演变而来相似，Prometheus由Google内部的Borgmon[6]监控系统演变而来，最初在2012年由前Google工程师Matt T. Proud于SoundCloud[5]进行研发使用并在短时间内迅速受到业界广泛认可,后于2015年初在GitHub上开源，目前已有42.2K的Star数和7.1的Fork数。其用户社区非常活跃，拥有将近700位贡献者，并在多数云原生组件中被集成。

2016年5月，Prometheus成为继Kubernetes之后第二个正式加入CNCF的项目，同年六月发布1.0版本，并与2018年8月顺利毕业。Prometheus现已被众多的企业、互联网公司和初创公司在其微服务业务环境下使用。

本篇为云原生服务测绘系列的第四篇，主要从资产发现、资产漏洞、资产脆弱性发现三个维度对国内暴露的Prometheus进行了测绘分析，最后笔者针对Prometheus提供了一些安全建议，希望各位读者通过阅读此文可对Prometheus服务风险暴露情况有更清晰的认识。

注：文中统计的测绘数据为近一个月的国内数据，相关技术仅供研究交流，请勿应用于未授权的渗透测试。

Kong是一个云原生，快速可扩展的分布式微服务抽象层（通常被称作API网关，API中间件），Kong于2015年被Mashape公司开源，其在Github上拥有31.6K的Star以及4.2K的Fork数量。Kong的核心价值主要体现在高性能和可扩展性上。扩展性上，Kong主要在Nginx的反向代理基础上，通过Lua实现了脚本化的扩展，同时所有管理功能都可通过RESTful API来实现。性能层面上，由于Kong内部使用了大量的缓存机制，从而很大程度上避免了阻塞式操作，使用性能上被广泛开发人员认可。

2.1 Kong资产暴露情况分析

借助测绘数据，我们可以了解到国内Prometheus资产地区和版本的分布情况，笔者也以这两个维度为各位读者进行介绍。

2.1.1 Prometheus资产地区分布

笔者从测绘数据中得到Prometheus相关资产共5908条数据，地区分布如图1所示（资产数较少的由于篇幅原因不在图中显示：

以上Kong资产暴露的端口情况笔者进行了统计，如图2所示：

由图1，图2我们可以得出如下信息：

国内暴露的Prometheus资产信息中有约81%的数据来源于北京市、上海市、广东省、浙江省、香港特别行政区、江苏省，其中北京市暴露1403条数据位居第一
国内暴露的Prometheus资产使用的端口主要分布在9090端口，9090为Prometheus Dashboard提供HTTP服务的默认端口，使用9090端口的资产数约占整体资产数的94%

2.1.2 Prometheus资产版本分布

借助测绘数据，笔者对国内暴露的Prometheus资产版本进行了分析，其分布情况如图3所示（资产版本数较少的由于篇幅原因不在图中显示）：

上图可以看出在统计的Prometheus资产中，24%的资产未获取到具体版本信息，剩余约76%资产中，绝大多数资产暴露版本分布在2.32.1、2.34.0、2.31.1、2.26.0、2.28.1、2.27.1、2.30.3之中。

2.2 Prometheus脆弱性风险和漏洞介绍

2.2.1 脆弱性风险介绍

Prometheus的2.24.0版本（2021.1.6发布，当前版本为2.35.0）之前，Prometheus未内置认证授权等安全机制，究其原因，笔者查看了官方Q&A文档[7]，其中官方是这样解释的：

TLS and basic authentication is gradually being rolled out to the different components.Please follow the different releases and changelogs to know which components have already implemented it.

The components currently supporting TLS and authentication are:

Prometheus 2.24.0 and later
Node Exporter 1.0.0 and later

可以看出官方计划将TLS和Basic认证机制在不同的组件中实现，目前还在进行中，并给出了当前支持认证机制的具体版本范围，这也同时意味着在2.24.0及之前的版本中，只要用户对外暴露Prometheus的9090端口，那么任何人都可以对Prometheus Dashboard进行未授权访问。虽然Prometheus在2.24.0版本后针对Dashboard引入了TLS及Basic认证方式，但由于引入时间较晚，许多企业及组织已在云上部署了Prometheus，且未及时启用官方提供的认证机制，从而导致大量暴露在互联网Prometheus服务存在未授权访问风险。通过进一步挖掘，笔者发现这些Prometheus服务存在敏感数据泄露的风险，并将一些敏感的数据接口梳理如下：

/api/v1/status/config

访问该接口将返回Prometheus服务相关的配置文件内容，文件格式为YAML,该文件内容包括Alertmanager组件（Prometheus告警组件）相关的配置、告警匹配规则、Prometheus任务配置、Prometheus监控的目标节点信息等，完整的内容可参考官方文档[4],示例配置文件如下图所示：

值得注意的是，通过官方文档[4]，笔者发现该接口返回的内容定义包含basic_auth配置项，通过此配置项Prometheus可访问到目标服务或监控服务，此配置项含有用户敏感信息，如下图所示[4]：

从以上信息我们可以看出若用户将目标服务或监控服务的认证信息写入配置文件，将会导致敏感数据泄露。

/api/v1/targets

访问该接口将返回Prometheus目标服务的当前状态，包括活动状态（activeTargets）、下线状态（DroppedTargets）等，示例如下图所示：

我们还可以通过“/targets”接口看到目标服务状态的可视化UI，如下图所示：

/api/v1/status/flags

访问该接口将返回Prometheus配置的flag值,如下所示：

其中，config.file参数提供用于存放Prometheus配置文件（该配置文件与/api/v1/status/config接口返回的配置文件信息一致）的完整目录，若配置文件存放在/home目录下，则可能导致系统用户名泄露。

此外，该接口返回的内容中还包含web.enable-admin-api参数，该参数代表用户是否可以使用其它Web Admin API的权限，默认值为false，如下所示：

根据官方文档[3]，若用户将web.enable-admin-api项参数值设为true,则将额外开启一些管理API供操作者调用，这些管理API允许用户删除Prometheus所有已保存的监控指标以及关闭相应的监控功能，因而攻击者可针对未设置认证机制的Prometheus服务进行访问，并通过修改web.enable-admin-api项为false，直接关闭或删除Prometheus服务提供的指标，危害巨大。

/api/v1/status/buildinfo

访问该接口将返回Prometheus服务的构建信息，其中包括Prometheus版本、Go版本、构建日期等敏感信息，如下图所示：

2.2.2 漏洞介绍

Prometheus于2013年开源至今，已有约9年时间，在此期间一共曝出两个个漏洞[2],漏洞数量相对较少，从CVE编号信息我们可以看出漏洞披露时间分别在2019、2021年，根据CVSS2.0标准，两个漏洞均为中危漏洞。CVE-2021-29622漏洞类型为开放式重定向、CVE-2019-3826为XSS，其中CVE-2021-29662漏洞在市面上曝光度较大，笔者也针对这两个漏洞进行了信息汇总，其中包括公开暴露的PoC及ExP信息，如图11所示：

2.3 Prometheus资产脆弱性暴露情况分析

借助测绘数据，笔者从Prometheus漏洞维度，统计了现有暴露资产的漏洞分布情况，如图12所示:

可以看出，在国内互联网暴露的Prometheus资产中，有713个资产被曝出含有CVE-2021-29622漏洞（XSS），从上图我们也可以看出命中CVE-2021-29622漏洞的资产数约占总资产数的12%，该漏洞是个重定向漏洞，虽然对业务自身运行无影响，但重定向漏洞可用来作钓鱼攻击，仍存在一定危害。CVE-2019-3826漏洞在互联网上并未发现有疑似暴露信息，从前面的Prometheus漏洞介绍，我们可以进一步了解这两个漏洞，篇幅原因此处不再赘述。

2.4 安全建议

升级Prometheus版本为最新版本
Prometheus Dashboard使用认证机制，如Prometheus提供的Basic认证，使用TLS保证数据传输安全
禁止将用户名密码等敏感信息以明文形式写入Prometheus的配置文件中

三．总结

Prometheus是CNCF第二个毕业的项目，也是除了Kubernetes之外被开发者普遍认为最火爆的项目，在其被大规模部署的同时，脆弱性配置及漏洞导致的风险也不容忽视，本文从测绘角度分析了国内暴露的Prometheus服务及其存在的风险，下一篇笔者将继续针对云原生环境下的其它组件进行相应的测绘风险分析，欢迎各位读者持续关注，若有任何问题欢迎提出，互相交流学习。