回归最本质的信息安全

一个简单的配置错误,成功拿下BBC

2017年11月30日发布

89,032
0
4

导语:这篇文章中,我将详细介绍我是如何设法突破BBC的开发者门户,并对2500个API进行了全面的控制,从移动应用程序到网站(包括the news-bbc.co.uk & bbc.com),还有电台。

目标:BBC -TwitterFacebookWebsite

漏洞:Misconfiguration(错误配置)

严重性:8

状态:Patched(修补)

赏金(如果可以):N / A

这篇文章中,我将详细介绍我是如何设法突破BBC的开发者门户,并对2500个API进行了全面的控制,从移动应用程序到网站(包括the news-bbc.co.uk & bbc.com),还有电台。

接下来,我们直入主题:

我和我的朋友Derp曾经一起参加了一些漏洞赏金项目,在项目中我们进行了一些子域名劫持操作。受此启发,我突发奇想决定看看是否能劫持BBC的任何一个子域名。首先,我使用了由Ahmed Aboul-Ela(@aboul3la)编码,被叫做Sublist3r的脚本列举了bbc.co.uk的子域名。该脚本的公开下载地址如下:https://github.com/aboul3la/Sublist3r。

Sublist3r是一个功能非常强大的脚本,用其能进行非常全面的子域名查找——下面只列出了其查找资源的一部分:使用公共搜索引擎进行子域名查找,如Yahoo, Google, Bing等;使用DNSdumpster,Virustotal,ThreatCrowd以及更多的工具进行查找。Sublist3r查找功能强大的结果,直接导致会查找出大量的子域名,因此,我可以直接列出730个查找到的bbc.co.uk的子域名。但是使用SubJack查找,一个也查找不到。在这么多结果中,任何一个子域我都劫持不了——鉴于此,我决定做一些手动审计,并尝试在这些子域名上发现漏洞。

首先,通过一个叫做alive-host的脚本,来运行子域名列表,它是一个简单的bash脚本,它使用nmap来验证主机是否还存在——这样做可以缩小依然还存在的子域名的范围,节约了我大量的时间去浏览不再存在的子域名。

在浏览了相当多的子域名之后,我发现了一些在JSON中输出错误的问题。这一发现让我很兴奋。在对下面的错误信息进行了一些研究之后,我发现他们使用的是一个第三方API管理软件和分析预测器,名为APIgee。我觉得是时候进行深入探索了。错误信息如下:

{"fault":{"faultstring":"Unable   to identify proxy for host: default and url:   /v1/","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

我从所有由JSON错误输出的那些子域名开始,不断的进行搜索,搜索,扫描,扫描,等待,等待,结果什么都没有。在这些子域名中,找不到任何漏洞。因此,是时候测试最后的子域名了,该子域名运行的似乎是API管理软件。我运行了大量的脚本,希望能找到一些东西。但是结果仍然是一无所获。我再次检查了下面这个错误信息:

{"fault":{"faultstring":"Unable   to identify proxy for host: default and url:   /v1/","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

下面的问题引起了我的注意:

default and url: /v1/似乎说明服务器被配置了一个在目录/v1/的代理,但是还没有对该目录进行设置。这个错误让我很兴奋,所以我决定浏览一下目录/v1/,看看里面保存了什么。当我浏览/v1/时,服务器用以下数据作了回复:

[null,"Basic   YXBpQGJiYy5jby51azpEVmM3VG5MSm9Z[REDACTED]="]

服务器回复的数据显然是一个64位的字符串,解码后如下:

[null,"Basic   YXBpQGJiYy5jby51azpEVmM3VG5MSm9Z[REDACTED]="]

然后我浏览了APIGee,并尝试使用一些细节信息进行登录。竟然登录成功了,并且进入到一个能够控制所有BBC的API的管理员帐户中。而这一系列动作利用的竟是一个简单的错误配置。由于人的惰性导致了这种微小的错误配置,进而导致数千名开发人员的用户名、个人电子邮件地址、员工ID、私有产品和应用程序等都被暴露。

dashboard内部如下:

1.png

11.png

111.png

1111.png

2.png

22.png

222.png

2222.png

由于BBC不希望公之于众,本文不会介绍信息披露时间表.

鉴于涉及信息安全,本文仅能介绍以上的全部内容。虽然内容没有太多干货,但是我认为还是值得给大家分享。不管怎样,这么大的公司不应该犯这种低级错误。

本文翻译自:https://www.daley.cc/how-i-owned-the-bbc-with-a-simple-misconfiguration-due-to-human-laziness,如若转载,请注明原文地址: http://www.4hou.com/info/news/8852.html

点赞 4
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

Change

Change

嘶吼编辑

发私信

发表评论