Bug Bounty故事 #bugbountytips

一个已修复但未支付赏金的故事…

时间线：

• 2019年10月21日报告
• 2019年10月23日验证为严重漏洞
• 2019年10月30日验证已修复
• 2019年11月12日声明赏金金额（10,000,000印尼盾≈700美元）
• 2019年11月16日提供支付信息
• 2020年3月13日 - 从未支付 - 发布博客文章
• 2020年3月19日 - 收到565.86美元赏金

许多应用程序都是SAAS - Shell即服务。Jupyter Notebook就是其中之一，具有运行代码功能和终端功能。

当我在Shodan上搜寻易受攻击的主机时，发现了一个属于Tokopedia的开放Jupyter Notebook。起初并不明显，但通过查看截图会清楚我是如何识别这一点的。

开放的Jupyter Notebook服务器

我在之前的文章中讨论过当发现GCP密钥时该怎么做。当人们将GCP服务账户密钥留在文件夹中时，这一点尤其重要。

当你将服务令牌留在文件夹中供所有人查找/使用时：

在这种情况下，它是base64编码的 - 但很容易修复。

Base64解码的服务账户令牌

它也在其中一个Jupyter Notebook的错误输出中：

我使用终端进行了一些基本探查以找到所有者：

一旦我确认它属于一个有Bug Bounty程序的人，我认为证明访问和影响是可以的。

根据GCP博客文章，一旦你拥有服务账户令牌，你就可以验证并与之有访问权限的服务进行交互。

在GCP计算主机上获得shell的方便之处在于所有GCP工具都已安装并"正常工作"。实际上，我不需要从外部主机做任何事情，我能够从Jupyter终端内部开始ssh到其他主机。

BigQuery表o_0

[+] BigQuery访问[+] bq ls --format=prettyjson --project_id tokopedia-970

数据计费表哟：

我喜欢支付表：

在这个过程中，我搜索了这家公司是谁。https://en.wikipedia.org/wiki/Tokopedia

最有趣的是…

2017年，Tokopedia从中国电子商务巨头阿里巴巴获得了11亿美元的投资。[7] 2018年，该公司又获得了由中国电子商务巨头阿里巴巴集团控股和日本软银集团领投的11亿美元融资轮[8]，使其估值达到约70亿美元。[9]

所以作为一个好人（tm），我报告了这个问题，并被分配了严重严重性。他们超级快速地修复了它，团队在修复之前相当响应。之后，花了2周时间才获得关于赏金的信息，我及时提供了支付信息，但我从未得到支付，并且他们停止回应我的询问。

解决方案：

在有限权限容器中运行（不能防止云元数据攻击）

新版本的Jupyter Notebook允许密码保护访问。这样做而不是向所有人开放。