云原生服务风险测绘分析(四):Prometheus

VSole2022-05-09 14:33:53

一、概述

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服务风险暴露情况有更清晰的认识。

二、Prometheus资产风险测绘分析

2.1 Prometheus资产暴露情况分析

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

2.1.1 Prometheus资产地区分布

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

图1. Prometheus资产地区分布

笔者针对以上Prometheus资产暴露的端口情况进行了统计,如图2所示:

图2. Prometheus资产端口分布

由图1,图2我们可以得出如下信息:

国内暴露的Prometheus资产信息中有约81%的数据来源于北京市、上海市、广东省、浙江省、香港特别行政区、江苏省,其中北京市暴露1403条数据位居第一

国内暴露的Prometheus资产使用的端口主要分布在9090端口,9090为Prometheus Dashboard提供HTTP服务的默认端口,使用9090端口的资产数约占整体资产数的94%

2.1.2 Prometheus资产版本分布

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

3. Prometheus资产版本分布

上图可以看出在统计的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 change logs 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. Prometheus数据泄露接口返回内容1

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

图5. Prometheus数据泄露接口参数定义[4]

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

  • /api/v1/targets

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

 

图6. Prometheus数据泄露接口返回内容2

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

图7. Prometheus数据泄露接口返回内容3

  • /api/v1/status/flags

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

图8. Prometheus 数据泄露接口返回内容4

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

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

图9. Prometheus 数据泄露接口返回内容5

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

  • /api/v1/status/buildinfo

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

图10. Prometheus 数据泄露接口返回内容6

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

图11. Prometheus漏洞介绍

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

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

图12. Prometheus漏洞介绍

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

2.4 安全建议

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

三、总结

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

参考文献

[1] https://security.archlinux.org/CVE-2021-29622

[2] https://www.cvedetails.com/vulnerability-list/vendor_id-20905/product_id-61503/Prometheus-Prometheus.html  

[3] https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-admin-apis  

[4] https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config  

[5] https://soundcloud.com/  

[6] https://sre.google/sre-book/practical-alerting/  

[7]https://prometheus.io/docs/introduction/faq/#why-dont-the-prometheus-server-components-support-tls-or-authentication-can-i-add-those

往期回顾:

云原生服务风险测绘分析(三):Kong和Apache APISIX

云原生服务风险测绘分析(二):Harbor

云原生服务风险测绘分析(一):Docker和Kubernetes

漏洞挖掘prometheus
本作品采用《CC 协议》,转载必须注明作者和本文链接
Prometheus是一套开源的监控、告警、时间序列数据库的组合工具。与Kubernetes由Google内部Borg系统演变而来相似,Prometheus由Google内部的Borgmon[6]监控系统演变而来,最初在2012年由前Google工程师Matt T. Proud于SoundCloud[5]进行研发使用并在短时间内迅速受到业界广泛认可,后于2015年初在GitHub上开源,目前已有4
本文介绍了在集群中利用危险的RBAC配置提权至集群管理员的案例,并总结了同类的技术和方法和对应的防御思路
痛苦的纯文本日志管理日子一去不复返了。虽然纯文本数据在某些情况下仍然很有用,但是在进行扩展分析以收集有洞察力的基础设施数据并改进代码质量时,寻找一个可靠的日志管理解决方案是值得的,该解决方案可以增强业务工作流的能力。 日志不是一件容易处理的事情,但无论如何都是任何生产系统的一个重要方面。当您面临一个困难的问题时,使用日志管理解决方案要比在遍布系统环境的无休止的文本文件循环中穿梭容易得多。
0x01 确定目标无目标随便打,有没有自己对应的SRC应急响应平台不说,还往往会因为一开始没有挖掘漏洞而随意放弃,这样往往不能挖掘到深层次的漏洞。所以在真的想要花点时间在SRC漏洞挖掘上的话,建议先选好目标。0x02 确认测试范围前面说到确定测什么SRC,那么下面就要通过一些方法,获取这个SRC的测试范围,以免测偏。
漏洞挖掘工具—afrog
2023-03-20 10:20:07
-t http://example.com -o result.html2、扫描多个目标 afrog -T urls.txt -o result.html例如:urls.txthttp://example.comhttp://test.comhttp://github.com3、测试单个 PoC 文件 afrog?-t http://example.com -P ./testing/poc-test.yaml -o result.html4、测试多个 PoC 文件 afrog?
但又没登录怎么获取的当前用户的Access-Reset-Ticket真相只有一个,看看接口哪里获取到的原来是在输入要找回的用户就会获取当前用户的Access-Reset-Ticket6到了,开发是我大哥尝试修改可行,修改管理员账号,然后起飞下机。漏洞已修复,厂商也修复了漏洞更新到了最新版本。
漏洞挖掘是指对应用程序中未知漏洞的探索,通过综合应用各种技术和工具,尽可能地找出其中的潜在漏洞。cookie的key为RememberMe,并对相关信息进行序列化,先使用aes加密,然后再使用base64编码处理形成的。在网上关于Shiro反序列化的介绍很多,我这里就只简单介绍一下,详情各位可以看下大神们对其源码的分析。
这里建议doc文档,图片可以贴的详细一些。爆破完好了,一样的6。想给它一个清晰完整的定义其实是非常困难的。
一、漏洞挖掘的前期–信息收集 虽然是前期,但是却是我认为最重要的一部分; 很多人挖洞的时候说不知道如何入手,其实挖洞就是信息收集+常规owasp top 10+逻辑漏洞(重要的可能就是思路猥琐一点),这些漏洞的测试方法本身不是特别复杂,一般混迹在安全圈子的人都能复现漏洞。接下来我就着重说一下我在信息收集方面的心得。
VSole
网络安全专家