我如何发现1500名名人的大量信息泄露
在我们进入细节之前，只需要澄清一些事情：
- 我今天写这篇文章的原因是为了通知更多的质量检查工程师，他们应该更加谨慎地工作，并专注于许多事情。 不要忘记信息安全方面。
2.我有道德地砍。 没有个人利益。 虽然，我相信黑客应该为他们的贡献而获得积极的奖励。
不久前，这个有趣的故事发生在我身上。 在业余时间，我在youtube上观看英语视频博客。 在其中一个vlog中，我注意到了一个非常有趣的应用程序。 那是iOS设备的本机应用程序。 那人迅速显示了出来。 他告诉人们，这如何使他的生活更轻松，从而可以在世界任何地方订购赞助项目。 老实说，我有点喜欢这家公司。 而且我无法通过此申请。
首先，有必要说此应用程序放置在特殊的网页上。 以特殊Beta版本的形式。 下载数量很少。 对于android设备，下载数量接近1000–5000。 但这足以解决问题的严重性。 实际上，有很多问题，但首先要解决。
首先，我研究了应用程序如何与服务器端通信。 而且，最重要的是，它与哪个服务器一起工作。
令人惊讶的是，我在那里没有找到HTTPS协议。 这已经很奇怪了。 确定目标之后，我必须选择服务器中的漏洞。 但是最后，我遇到了一个没有受到暴力攻击保护的登录表单。 强制暴力…当然，我没有变得无礼。 毕竟，现在我生活在一个甚至连洪流都受到严厉惩罚的国家。 如果我进行此类攻击，那不是最正确的举动。 虽然没有恶意。 简而言之，无论您居住在哪个国家/地区，我们通常都会记住大约272条俄罗斯法律。
当我启动应用程序时，我发现了密码字段。 当然，我们不知道密码。 所以过了几天。 我从早上到晚上都沉迷于主要工作。 而且几乎没有时间做某事。 然后该应用程序提醒自己。 他给我发送了推送通知。 这不仅仅是通知。 这是有关新发表文章的信息性消息。 带有本文标题的本身来自内部系统。
它立即使我更加仔细地查看了该应用程序。 首先，无法轻易地将通知发送给未经授权的用户。 毕竟，我从未登录过应用程序。 我刚打开它并移到后台。 其次，我从内部系统收到了通知文本。 而且我根本无法访问该系统。
我考虑的第一件事-也许我对系统有一个“令牌”，我可以重复使用它来从内部系统中读取内容。
一切都按照我的想法。 像那样。 实际上，比我想象的要糟糕得多。
启动应用程序时，它会向内部系统发送一个请求，以读取需要显示的数据。 来自应用程序的第一个请求落入401错误。 从原则上讲，这是合理的。 毕竟，我们是未经授权的用户。 但是随后应用再次快速发送另一个请求，但带有令牌，该请求被硬编码到应用中。 并从服务器端获取200。 这是什么意思？ 这意味着您无需输入任何登录名和密码，就可以从内部系统读取数据。
在分析该应用程序的第一种方法中，我只是没有检查两个请求的值。 最重要的是-没有检查服务器响应的大小。 在屏幕截图中，它位于红色箭头的右侧。 json格式的几兆字节数据。
结果是什么？
典型的应用程序启动会显示带有徽标的初始屏幕。 加载此屏幕与从内部系统获取带有信息的json响应并行。 然后应用程序询问用户一些密码数据。 如果用户已登录，则他可以处理接收到的数据。 但是我们不是普通用户，我们可以打开接收到的json看看有什么。
这是史诗般的。 在对json文件进行粗略检查时，我发现有关170名与该公司互动的名人的个人数据的完整披露。 个人电话，电子邮件地址，通过朋友或父母的紧急电话号码，有关该知名人物的经理的全名和完整个人信息。 要说我很惊讶-不要说什么。
在处理了接收该json文件的请求的参数之后，我设法获得了该公司与之互动的知名人士的绝对完整列表。 一分钟来，已经有1454人。
基本上，我设法从内部系统中提取了完整的广告列表。 例如，该公司新产品的出现。 或者像我们这样-展示了我们出色的应用程序，它可以安全地显示2-3个月内的所有数据。
当我发现这个时我做了什么？ 我已经尽力而为，找到了一个直接负责这家公司安全的人员。 真的只在这个linkedin上对我有帮助。 在其他所有沟通方式中，我要么都没有得到答案。 最后，几天后，两个应用程序都从公共访问权限中删除。 在应用程序中进行了硬编码的令牌仍然留有从内部系统读取数据的可能性。 但是所有敏感数据都从内部系统带到外部。 通常，在有令牌的情况下，不清楚在ios和android应用中对该令牌进行硬编码，在base64中反复编码令牌本身时他们的想法。 那么为什么要编码呢？ S-安全。
顺便说一句，我向负责安全的人员声称他们没有security@domain.com邮箱。 毕竟，我试图在那儿写东西，但是收到了一个邮件守护进程。 作为回应，他告诉我有一个盒子。 它称为securitynotification@domain.com。
让我们返回到推送通知。 这是第一次信息公开。
推送通知出现问题的原因非常简单，即配置推送通知服务时出错。 对于这些通知，他们使用了第三方服务。 为了使用它，您必须具有：REST API密钥通知服务和您的应用程序API密钥。
它是根据官方网站上的说明进行配置的…但是没有人进行管理。
最后，您做了什么？ 正确！ 在应用程序中进行了硬编码，所有必要的工作。
当您启动应用程序时，我们将从发送这些通知的服务中扣除200英镑。
美丽。
总结一下，我们有：
1）该应用程序没有被教为可以在httpS上工作。 而且，我怀疑他们不会修复它。
2）尝试猜测密码时，无法防止暴力攻击。 实际上，应用程序中的密码组合大约为10,000。 它移动得足够快。
3）为应用程序分配了唯一的令牌，以从内部系统读取数据。 这是直接双赢。
4）该应用程序已向通知服务注册，该服务配置不正确。
5）在应用程序中没有角色划分。 任何用户都可以从内部系统读取任何内容。
我认为，所有这些都可以通过测试来避免。 是的，在测试级别，应该在发布之前发现这些开发和设计错误。
年表：
6月29日-第一份报告已发送
6月30日-已确认所有问题
7月7日-提供奖励
7月10日-修复了所有问题
7月27日-我选择去阿姆斯特丹参加一次有趣的活动作为奖励