目标：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内部如下：

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

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