下面您将详细了解已发现的漏洞，该漏洞使我能够从 Atlassian 云中获得大约 15000 美元的赏金。这个故事发生在大约一年前。出于道德原因，我没有立即发布它。
一切都始于我和朋友决定寻找那一天一个在 Hackerone 有很大范围的公司的漏洞。该公司允许提交范围之外的严重漏洞。想到的第一件事就是在 Github 上寻找各种漏洞。没过多久，结果就出来了。我们偶然发现了公司的员工工作凭证。凭据本身并不是很有用。在几个登录表单上尝试了我们的命运后，我们意识到这不可能是一个严重的漏洞。最后，我的朋友决定在 atlassian.com 上检查登录名和密码对。并且有一个有趣的结果。他登录了，但登录后出现了一个页面，要求他确认自己的帐户。由于我们无法访问用户的电子邮件收件箱以验证泄露的帐户，因此我们决定放弃。但是在表格的最后附有确认帐户的建议，
几周过去了，我们决定再次尝试从这家公司找到工作凭证。我们遇到了新的登录名和密码。最后，我们甚至没有注意到我们是如何偶然发现之前找到的登录名和密码的。哦，天哪 – 这次登录到 Atlassian Cloud 成功了。这个故事然后与我们之前没有找到的其他几个凭据一起工作，根本没有重新确认消息。并且没有2fa。这些显然是公司的关键问题。我们发送了报告并获得了一些分类和解决状态。
然而，过了一段时间，该公司改变了对其他尚未分类的报告问题的立场。错误赏金政策已更改。我们被要求向数据遭到泄露的客户做出负责任的披露报告。
这有几个原因。
1）登录系统是代表员工完成的，但系统并不总是我们目标列表中公司的“财产”。其实我也觉得很奇怪，只是一开始我并没有太在意。
2) 评估暴露数据的严重程度非常困难，因为事实上，这是一个我们没有关注的受损目标。从那个地方看，差点不小心戴上了“黑帽子”……
你知道这一切发生的原因吗？因为我们调查的公司是大型集成商（咨询业务）。并且公司的员工能够为不同的客户工作。通过泄露这家公司员工的凭据 – 很有可能获得不属于该公司的服务，而该公司有一个错误赏金计划。您可能有疑问——但正是他们的员工在机密数据方面犯了安全错误！所以这也是他们的问题！
我可以同时同意和不同意你的观点。如果您是一家拥有大量顾问的大公司，那么您的任务就是保护您公司的机密数据和您保存的客户数据。在客户服务层面保护客户数据是客户自己关心的问题。但当然，员工必须遵循最佳实践并防止密码泄露。客户自己应该考虑确保与外部顾问合作的方式。
因此，当计划政策的条款发生变化时，我们停止了我们的活动。但是有很多事情让我担心。
1) 为什么员工在与客户域无关的域上使用他们的工作凭据访问客户的系统？
2）为什么在某些情况下，我们会收到与客户没有任何关系的员工的访问权限？我偶尔会找到一些人，我们一开始就可以从他们那里登录系统。但是这个人的职位与我们正在访问的项目无关。
3）如果是配置问题，问题出在哪里？
4）这个问题可能是 Atlassian 方面的一个错误吗？
5）它会影响其他组织还是只是一个边缘情况。
我花了几天时间，才能够回答所有问题。当然，我们应该考虑到泄露的密码是一个单独的问题。但是我发现了一些不需要泄露凭据的东西。你知道主要问题在哪里吗？！
在 Atlassian.com 上的主注册页面中！！！
整个注册流程有点奇怪。在我看来，这个问题可能广泛存在于其他服务中。我甚至在测试其他服务的过程中发现了这一点。
现在让我们详细了解整个过程。
我们第一次发现未经确认的帐户并向用户发送了“重新确认通知”——此时，我们不得不怀疑我们如何再次尝试登录系统。
问题是，当您执行注册帐户的过程时，您作为用户必须输入 — 电子邮件、姓名和密码！
此时，您还没有确认您拥有该帐户，而是您设置的帐户密码。
然后通知用户已为他创建了 Atlassian 帐户，他需要通过单击电子邮件中的链接来确认他是该帐户的所有者。只需单击电子邮件中的链接即可。请记住，这不是网络钓鱼电子邮件。这是来自 Atlassian 的合法电子邮件。
单击链接后，您可以使用电子邮件和密码登录到 Atlassian.com，其中包含已在example.com域中为用户配置的所有 Atlassian 空间。
攻击的原理很简单。
1) 攻击者使用电子邮件和密码注册此人
2) 此人收到确认帐户的通知。在这种情况下，有一些方法可以提高确认链接的点击转化率。不幸的是，我还不能告诉你。
3）成功点击用户的链接后，攻击者可以登录到用户的帐户。（如果攻击者执行了该帐户注册）
这个故事有几个BUT。
1) 用户在 Atlassian 云上的账户可能为空。
2) 用户邮箱可能已被使用，无法重新注册。
在这两点上，我有两个论点。
1）如果公司足够大。通常，超过500-1000名员工，那么登录后获得一些数据的机会会非常高。都是因为在大公司有 Atlassian Cloud 空间，其中会自动添加具有特定域的用户。这是通过自动添加用户的特殊配置实现的——“批准以下域”。
2) 仍然可以注册第二个电子邮件！诀窍是使用这样的组合[email protected]。并且只需要等待用户确认即可。
把所有的想法放在一起，我复制了几个大型组织的帐户注册。这些组织对我很友好。我曾经为一些人工作过。有些人有朋友或我认识的人。当我尝试注册新帐户时，我获得了惊人的帐户确认成功率，然后可以访问组织的机密信息。部分问题是“批准的域”设置，无需验证云空间即可自动分配用户。但这些问题的根本原因是帐户注册过程中的缺陷。如果您为您的用户或客户开发了注册表。如果用户尚未确认帐户的所有权，则不应为其设置密码！
我汇总了我的研究结果，并通过 Bugcrowd 的漏洞赏金计划向 Atlassian 发送了一份报告。我尽可能详细地描述了这个问题。我展示了实施成功攻击的所有方法。还展示了使此类攻击的成功率尽可能高的方法。
你知道接下来发生了什么吗？这是正确的。我在我的报告中从分类器中得到了N/A状态，因为这个攻击向量需要用户交互。你必须点击链接。并且它不是网络钓鱼链接并不重要。
第一个问题，要求受害者通过单击电子邮件中发送的链接来确认帐户注册。如果他们没有在那里注册，则不应单击该链接。您提到的第二个问题是在产品上可配置的，该实例的管理员可以启用或禁用它。滥用产品安全功能是用户的责任，而不是 Atlassian。
因此，我将此关闭为 N/A。
在这一点上，我认为我在尝试解决 Atlassian 方面的问题方面已经做得足够了。在那之后，我决定休息一下。一路上，我继续寻找漏洞。
那时，我正在对另一家范围广泛的大公司进行大量研究。所以，我没有错过在 Atlassian 注册新账户的机会。我获得了批准，并为该公司的多个域注册了帐户。几天过去了，我在这个大型组织的 Atlassian Cloud 中至少有 2 个工作帐户。结果也不统一。所有帐户都可以访问与公司本身相关的云空间。有银行、大型农业公司、零售公司、珠宝公司的云空间。也就是说，实际上他们是不小心被黑客入侵的。
所有这些公司都无条件信任我进入的域中的帐户。整个域在“批准的域“配置。
也就是说，我使用关闭为 N/A 的漏洞，毫不费力地访问了几个组织的机密数据。
由于这个故事，所有受影响的组织都通过负责任的披露得到了通知。所有组织都在“批准的域”Atlassian 菜单中更改了他们的配置。
对我来说更明显的是，这个问题的风险相当高，有必要以某种方式引起对这个问题的关注，以便它可以得到解决。我再次尝试联系 Atlassian。这次我通过安全电子邮件而不是 Bugcrowd 与他们联系。在电子邮件中，我写道我提交了一个较早的漏洞，但被拒绝为 N/A。我有几个客户端通过此漏洞受到损害的证据。我想就这个问题发表一些意见。
在这条消息之后，故事从死点开始了。Atlassian 团队成员审阅了我的报告。重开，设置危急等级为P3，后来修复了注册流程，发了奖励。当然，关键程度和赏金金额都有些争议。
现在，在注册帐户时，用户必须在确认帐户归他所有而不是其他人所有后指定密码。
至于 Atlassian Cloud Space 中的“已批准域”设置——那么这个设置就保持不变，没有任何变化。但我个人建议不要使用它。同样，当您作为客户邀请顾问并通过批准来自顾问域区域的所有帐户来授予他们在您的 Cloud Space 中进行协作的访问权限时，我不建议使用此设置。最好的解决方案是为顾问提供一个单独的帐户来完成他们的工作。我真的不明白为什么您要允许来自另一个域的所有用户。毕竟，它会通过入侵您的顾问/承包商来破坏系统的高风险。
如果你认为这样的故事是一系列的巧合，我会让你失望的。
最近，在测试另一家公司的过程中，我发现了一组完全相同的问题。
1) 注册时，用户可以在确认步骤之前指定密码
2) 每个用户可以注册多个电子邮件帐户，即有效的系统帐户
3) 在服务中可以添加一个帐户到“组织”的基础在电子邮件中的域名上。
总而言之，这个故事变得非常有趣。许多人的主要教训应该是，应该通过像[email protected]这样的特殊帐户来设置对 Atlassian 云的第三方访问。或者通过每个受邀用户的手动审核。从“友好”域中添加每个人的做法可能非常危险。对您的域帐户进行双重身份验证将是整个组织数据安全的保证。顺便说一句，关于新帐户的管理员和用户通知从未有助于防止此类问题。通知无法阻止已经发生的入侵。
这个问题的披露是与 Atlassian 安全团队协调的。对此我深表感谢！此外，Atlassian 针对这个漏洞奖励了我 600 美元?♂️，而受到攻击的公司的总奖励约为 15,000 美元。
转载请注明出处及链接