挖洞经验 | ServiceNow错误配置管理实例导致的信息泄露漏洞

本文讲述了作者通过云服务管理公司ServiceNow产品,发现很多ServiceNow企业客户未对其中的知识库服务端设置必要的权限和身份验证措施(Misconfiguration),导致内网信息泄露。作者通过该漏洞收获了将近$30,000的奖励。

背景介绍

ServiceNow是美国一家云计算平台公司,提供软件即服务 (Software as a service),帮助企业运营管理数字化工作流程。ServiceNow专注于信息技术服务管理 (IT service management)、信息技术运营管理(IT operations management)和信息技术商务管理(IT business management)的服务研究,为企业客户通过各种应用和插件管理项目、团队和客户互动关系。

ServiceNow产品基于根本原因(Root Cause)识别模型提供服务,以帮助用户确定问题,并帮助用户通过自助服务纠正问题。该服务模型ServiceNow产品中显示为具体的任务(tasks)、活动(activities)和流程(processes),各种应用服务由不同的云服务实现分离。

例如,你公司的ServiceNow服务管理实例可由以下链接访问到:

https://yourcompanyname.service-now.com

漏洞所在

首先,我研究的一个模块是ServiceNow的知识库 (Knowledge Base,KB),ServiceNow的知识管理(Knowledge Management,KM) 应用程序具备知识库的信息共享,其知识库中包含了指导用户进行问题排查和自助任务解决的操作说明书。
用户可以自行创建知识库(KB)以便进行保存分享,创建好一个知识库后,ServiceNow会为其分配一个唯一识别号,如以下界面中的KB00110XX:

当用户打开每个知识库对应的文件时,会执行以下请求调用:

https://company.service-now.com/kb_view_customer.do?sysparm_article=KB00xxxx

漏洞利用

经测试发现,很多部署了ServiceNow的公司企业虽然对ServiceNow服务管理实例设置了Okta或onelogin的身份验证措施,但对上述知识库(KB)服务端根本未设置有必要的权限和身份验证手段。

因此,我结合ServiceNow产品的管理实例,以.service-now为域名枚举对象,针对一些大型企业和组织机构做了探测发现。一旦其中有ServiceNow知识库实例,我就用burp intruder对其知识库唯一识别号(KB001XXXX)后四位进行枚举,再结合burp Grep/Match功能对其中响应的关键字进行匹配,如password, internal, credentials, confidential等。

发现结果

大多数公司泄露的知识库用途超出预期,总体来说比较严重,主要是以下几方面数据信息的泄露:

公司内部流程、标准作业程序SOP、图表、开发计划;
密码、登录内部网站的用户令牌;
包含IP地址的用户请求附件内容;
公司雇员交流过程中泄露的一些客户个人身份信息(PII)。

当然,也有一些公司觉得这不算什么太大的安全风险,但我还是鼓励他们进行修复处理。

漏洞奖励 – $30,000

ServiceNow是一家排名前五的云服务管理提供商,很多大公司都采用了其云管理体系。我花了两天时间,经由H1 & bugcrowd平台和朋友关系对存在上述漏洞的多家公司进行了通报,目前为止已经收获了将近$30,000的奖励,还有一些漏洞报告正在分类中。

这是ServiceNow公司的产品漏洞吗?

不。这只是部署了ServiceNow产品的企业未对其中的知识库服务端设置恰当的访问控制权限,导致一些涉及公司内部的知识库文件曝露在互联网上,究其原因就是企业客户自身的错误配置漏洞。

*参考来源:medium,clouds 编译整理,转载请注明来自 FreeBuf.COM