挖洞经验 | COVID-19期间数百个曝露在互联网上的内部服务台系统（Service Desks）

作为intigriti众测平台的白帽主管，Inti De Ceukelaire在工作之余也会努力去发现漏洞。最近，考虑到新完疫情影响下的远程办公场景，Inti De Ceukelaire从全球10000家公司网站中发现了大量曝露在互联网上的Atlassian JIRA 内部服务台系统（Service Desks），通过这些系统可以实现员工创建、信息获取、数据查询甚至是服务器代码执行，会对远程办公的公司系统产生影响。漏洞最终收获了>$10,000的奖励。

内部服务台系统（Service Desks）

鉴于近期的COVID-19新冠疫情，全球数百万家公司机构只能让员工在家开展远程办公，不出所料，即使对于已经熟悉远程办公解决方案的公司来说，这也是一项艰巨挑战。尽管很多安全专家对远程办公的安全隐患表示担忧，但也很少有人能给出网络安全状况在COVID-19期间受影响的实际数据和态势。

JIRA和Asana等内部工单应用工具（Internal ticketing tools ）或服务系统（Help desk、Service desk）能让企业以结构化方式高效率完成工作，很多公司企业在远程办公环境中都采用了这种内部工单工作模式。企业员工可以通过创建工单实现业务请求、变更或请求帮助。无论是创建工号、请求授权、报销费用或解决登录问题等操作，都是在远程网络环境中凭工单或凭据就能进行的。当然，从安全角度来看，如果这种内部服务系统存在漏洞风险，那么黑客伪装成内部员工利用这些公司内部系统了。

很多公司的Atlassian JIRA 内部服务台系统（Servicedesks）存在错误配置问题，由此可导致任意人注册登录，虽然实际来说，你可能认为有些内部服务台系统（Servicedesks）完全是可以公开的，但是，这些服务台系统中很多操作实例设置了内部工单访问端，致使攻击者完全可以冒充工作人员创建合法的内部请求。另外，因为总不可能走到同事身边询问吧，所以离线验证也几乎是不可能的，最终结果就是，企业即使受到攻击也无从得知。

漏洞问题

互联网上有大量的曝网内部服务台系统（Servicedesks），攻击者可以根据公司名去访问服务台系统的登录页面，就像这里我在https://yourcompanyname.atlassian.net网站创建的以下Atlassian实例一样，只要访问相应的登录链接，就会跳转到默认的Atlassian登录页面，一般来说该页面是不应被公开访问到的。

攻击者只需访问以下登录链接即可跳转到上述登录页面：

https://yourcompanyname.atlassian.net/servicedesk/customer/user/login

另外，通过该页面点击其中的“sign up”（注册）按钮，还可继续跳转到注册页面：

之后的可选项目模板中有IT、HR、设备、财务和法律等多种应用，它们都能被公开注册任意选择。

漏洞利用

基于以上曝网的内部服务台系统（Service Desks）问题，我就想尝试自动化去发现到底会有多少家公司存在类似问题。最终，我从全球公司相关的10000个域名网站中发现，在1972个部署了Atlassian实例的网站中，存在288个曝网的Atlassian内部服务台系统。对比去年夏天我的自动化扫描结果来看，该数量在COVID-19疫情后，粗略增加了近12%。

接下来我要做的就是去尝试注册这些曝网的内部服务台系统（Service Desks）了，很快我发现，仅从服务标题就可判断这些曝网的Service Desk根本不应该公开在互联网上，如下图所示，出于漏洞保密，截图经redacted掩去了公司名：

上图只是那两百多个曝网内部服务台系统（Service Desks）系统中的一个例子，这些内部服务台系统涵盖了各种企业内部支持功能，如人力资源（HR）、内部IT故障解决、开发任务、办公帮助、数据&信息请求、信息安全、用户体检设计（UX）、市场营销、数据科学（Data Science）等等。这些所有的功能下又包含了各种名样的子功能操作，如：

在这里就不一一详细贴出来了，总体来说，其中包含的敏感操作包括：

请求获得进入办公室门禁的工号；

新员工入职；

请求加薪；

查询员工信息；

查询****；

更改在线系统或网页内容；

请求访问社交媒体频道账号；

请求访问公司内部工具；

查询内部安全评估报告；

解除用户锁定；

重置多因素身份验证；

申报费用；

为客户发起通用数据保护条例（GDPR）请求；

获得VPN白名单；

请求对数据库执行查询；

请求在公司的网络服务器上执行代码；

……

曝网内部服务台系统（Service Desks）导致大量个人身份信息（PII）泄露

在测试过程中，大约有1/3的曝网Service Desks可以执行对其他员工指派工单任务，而如果网站外用户通过电子邮件向公司发起帮助请求或咨询，那么从中的服务配置中竟然能看到与姓名对应的电子邮箱地址，所以这种交互式渠道将会泄露任何向公司网站发起请求帮助的用户信息。截图如下：

漏洞上报：从开始的被忽视到后来获得>$10,000的奖励

因为我唯一要做的事就是检查曝网的内部服务台系统（Service Desks）是否存在注册页面，所以我能容易地对数百家公司进行测试，而不会陷入法律纠纷风险：因为这些服务台系统是公开可访问的。一旦确定了存在曝网和注册可能的系统，接下来的漏洞报送过程也是非常痛苦和麻烦的：因为超过85%的存在漏洞的公司根本没有开通漏洞披露渠道或平台，尽管我努力地通过客户服务渠道去联系这些公司，但超过一半的公司就根本没有升级联系渠道。

还好，在过去的几周时间里，我与大约25家公司进行了合作，很好地保护了它们的内部服务台系统。漏洞影响和评级从最初的“可接受风险”到“危急”（Critical），一些公司也决定给予奖励，赏金范围从 €50 到 $10,000 （愿意给一万美刀的是因为可以从其服务台系统中实现恶意代码执行）。但最后，有很多公司我都没有联系到，漏洞就曝露在那里没人管。所以我觉得，不管公司是否愿意为安全漏洞提供奖励，但至少应该提供一个联系方式或渠道，让那些好心白帽报告安全漏洞吧，不要搞得报洞无门，白给都不要。

FAQ

1、这是 Atlassian的产品漏洞吗？

不，这只是一些通常的公司内部错误配置问题，比如一些公司早期的内部服务台系统（Service Desks）完全是公开的，后随着业务升级就转为内部使用了，但就忘记了系统还公开在互联网上这回事。

2、受该问题影响的公司有多少？

确切数字很难统计，我只是从10000个公司网站中进行了测试，在其中1972个部署了Atlassian实例的网站中存在288个曝网且可任意注册的内部服务台系统（Service Desks）。目前，我手动注册了其中一些系统，并向25家公司进行了责任披露，赏金范围最少的是€50，最多的是$10000。

3、作为公司如果来防范这种问题？

去查询Atlassian提供的文档吧，其中有很明确的设置步骤。

4、外部攻击者是否可以访问一些现存的工单任务？

从我的测试来看，还没遇到新注册用户可以访问到现存工单任务的情况。

5、这和社会工程学攻击外部支持代理有什么区别？

这种错误配置问题导致的影响是高度关联的，成功的渗透利用决定于支持代理应用的期望模式。在面向客户的环境中，相对于公司内部来看，更应该有理由怀疑一些恶意请求。而对一些大型公司机构来说，恶意工单处理的风险似乎更大，因为其涉及到工单创建者或是开发团队。在我想像中这些公司应该具备严格的审核程序，但现实并不如此。

6、那是否说明公开在互联网上可以注册的内部服务台系统（Service Desks）就有漏洞？