简介
本文描述Slack漏洞悬赏项目中，使用黑盒渗透测试，从一个50刀的server status泄露变成9000刀的敏感信息泄露和垂直权限绕过的过程。
感谢Slack安全团队
我想感谢Slack安全团队的Leigh Honeywell和Max Feldman在我报告漏洞过程中温和而又专业的沟通合作。
信息收集
为了弄清基础架构、获取关于所用的框架的信息，我开始检查HTTP响应头，发现Slack在使用的是Apache httpd服务器。于是我尝试识别常见的Apache目录和指令，比如“/icons/README”、“/manual/”、“/server-info”和“/server-status”。
我可以访问你的内部数据吗？
Slack在服务器上运行mod_status。这个模块能使服务器管理员发现他们的服务器表现如何以及哪个ip地址请求了哪些资源。攻击者可能会利用这种信息来计划对网络服务器的攻击。
https://secalert-hackerone.slack.com/server-status
当我尝试访问服务器状态指令时，服务器将我重定向到*.tinyspeck.com域名的一个登录页面。所以这个路径是受保护的。
超出范围的域名！又是什么问题？
如果你很懒，请注意Slack漏洞悬赏项目是禁止暴力破解的。于是一般人会尝试用一些注入技术绕过登录页面，但不幸的是登录页面本身位于一个允许范围之外的完全限定域名（FQDN）上，所以这个办法行不通。我必须找到一个方法留在secalert-hackerone.slack.com 的允许范围之内。
路由？筛选？——黑盒测试
一开始我觉得如果他们在用Apache httpd和mod_status，那么用重写模块会触发重定向。mod_rewrite模块是Apache的一个很强大的模块，用于在运行中重写URL。然而强大的能力伴随着高风险。配置mod_rewrite时容易产生错误，引发安全问题。以mod_rewrite文件中的一项配置为例：
|
1
|
RewriteRule ^/somepath(.*) /otherpath$1 [R]
|
如果是这样的话，他们可能会在重写规则中配置出错，因此我可以仅仅添加一个斜杠就绕过它。为什么？请求
http://yourserver/somepath/secalert
会重定向，不出所料地返回页面http://yourserver/otherpath/secalert。然而，请求
http://yourserver//somepath/secalert
会绕过这一项重写规则。针对Slack而言，这种方式绕过是不可能的。所以我必须打开思路。
为了绕过潜在的基于简单字符串的过滤保护，我尝试了斜杠的很多表示形式。
https://secalert-hackerone.slack.com/%2fserver-status%2f
https://secalert-hackerone.slack.com/%252fserver-status
为了绕过过滤，我使用RTLO序列进行了尝试，提交了其后为反向字符串的RTLO序列。
|
1
|
https://secalert-hackerone.slack.com/{u+202e here}sutats-revres
|
|
1
|
https://secalert-hackerone.slack.com/%e2%80%aesutats-revres
|
绕过访问控制！
几番测试之后，我觉得他们可能在框架中使用了路由策略，我可以通过添加多个正斜杠来绕过这种路由机制或访问控制。应用的过滤方法检查是否以特定的字符串开头，然后去掉一个正斜杠，但没有能递归地去掉所有的斜杠。这招终于管用了。
|
1
|
https://secalert-hackerone.slack.com/////server-status
|
成功！
赏金只有50美金？
在给Slack on hackerone写报告时，我决定添加一些截屏作为证据。当时我以为至少获得50美金作为报告这项配置失误的赏金，因为如果请求资源是我自己的Slack工作区的一部分，server-status文件通常不会泄露任何敏感信息给我，对吧？我登出了我的Slack账号，然后在没有登录的情况下请求服务器状态！这意味着一个攻击者有可能通过访问一个给定的工作区的服务器状态指令从而获得非授权访问任何Slack站点的请求资源的权限！
秘密揭晓，赏金增加！
一些罗列的请求如“/callbacks/chat.php?secret=...”和“/users.list?token=...”肯定是敏感数据。所以我添加了一些截图，有可能因此我能到手的赏金达到了2000美元。再次感谢Slack慷慨的赏金。
谷歌索引
在获得Slack第一笔丰厚的赏金之后，我有动力寻找更多漏洞。我用谷歌搜索了Slack网站上的常见文件扩展名，找到了缓存的url，这意味着Slack以前或现在确实有后端管理面板，它被编入谷歌以前的索引中。当我尝试访问这些页面时，我又被重定向到了登录页面。但是，既然Slack解决了先前报告的问题，我的机会很渺茫，是吗？
绕过访问控制 第二部分
在数次请求之后，我发现在通向管理面板的特定路径上，如果我使用4个斜杠，我可以绕过限制。这只对这个特定的控制器有效！
后端访问->第二份赏金！
Slack的员工能够访问一个名为“任务控制”的后端管理面板。在这个指挥中心面板上，被授权的人能够通过给相应的控制器传一个id来读取大量关于Slack用户和Slack工作区的元数据。由于所需的id暴露于我自己的Slack工作区所呈现的html上，我读取了我自己的账号的相关数据并把这些截图发给了Slack安全团队。除此之外，这还证明了通过猜测用户的id并向指挥中心面板相应的“重置”控制器发送请求，攻击者将能够重置任何一名用户的密码。这将使攻击者能够夺走任何账号！这个漏洞使我获得了7000美元的赏金。
结语
要有耐心！有时你可能会发现一个在技术层面上微不足道的缺陷，但它可能会对受影响的公司产生巨大的商业冲击或者严重的数据隐私问题，因此他们对这些风险的评估可能和你你一开始的想法不一样。
参考
https://api.slack.com/methods/users.list
https://httpd.apache.org/docs/current/mod/mod_status.html
时间线
Apr, 11th 2016: 发现并报告漏洞
Apr, 11th 2016: slack验证
Apr, 13th 2016: 漏洞修复
Apr, 13th 2016: 收到$2.000赏金
Apr, 14th 2016: 发现并报告第二个漏洞
Apr, 14th 2016: slack验证漏洞
Apr, 24th 2016: 漏洞全球范围修复
Apr, 24th 2016: 成功获得$7.000赏金
Oct, 20th 2016: 发布这篇文章
本文由 安全客 翻译，翻译：lxghost
原文链接：http://secalert.net/slack-security-bug-bounty.html