内容简介:该篇Writeup介绍了作者通过TURN服务器的中继作用,实现对Slack的内部网络和AWS元数据资源的访问。文中涉及到了STUN、TURN协议和WebRTC知识,还用到了一个未公开的STUN协议安全测试工具Stunner。我们一起来看看。在现实的互联网环境中,大多数客户端主机都位于防火墙或NAT之后,像在视频会议、视频通话、在线教育等实时传输场景下,我们都希望网络中的两台主机能够直接穿透NAT限制进行通信,即所谓的P2P通信,而不需要其他公共服务器的中转。因此,STUN和TURN协议就应运而生了。
该篇Writeup介绍了作者通过TURN服务器的中继作用,实现对Slack的内部网络和AWS元数据资源的访问。文中涉及到了STUN、TURN协议和WebRTC知识,还用到了一个未公开的STUN协议安全测试工具Stunner。我们一起来看看。
STUN和TURN介绍
在现实的互联网环境中,大多数客户端主机都位于防火墙或NAT之后,像在视频会议、视频通话、在线教育等实时传输场景下,我们都希望网络中的两台主机能够直接穿透NAT限制进行通信,即所谓的P2P通信,而不需要其他公共服务器的中转。因此,STUN和TURN协议就应运而生了。
STUN协议(Simple Traversal of UDP Through NATs),在RFC3489中定义为一种简单的NAT穿透解决方案,即用UDP实现的简单NAT穿透方法。在新的RFC5389修订中把STUN协议定义为穿透NAT的提供工具,在原有UDP的基础增加了TCP穿透,英文全称为Session Traversal Utilities for NAT,即NAT会话穿透。
TURN协议(Traversal Using Relays around NAT),在RFC5766中的定义是,使用中继穿透NAT,它是STUN协议的一种中继扩展。即在STUN的基础上实现中继或“中间人”方式的NAT穿透。
漏洞概况
Slack部署的TURN服务器允许把客户端请求的UDP包和TCP请求,中继到Slack内部网络和架设在AWS服务上的元数据资源中。
由于TURN是STUN的一个扩展协议,它通过中继方式来连接NAT之后的对等客户端,这有点类似我们渗透测试视角下的“代理”。在TCP中继模式下,TURN使用了RFC 6062规范中提到的 0x000A消息连接方法 ;而在UDP中继模式下,TURN则使用了RFC 5766规范中 提到的0×006消息指示方法 ,和另外具有 同样功能的channel方法 。
这里,可能有人会有疑问,那么,这和WebRTC又有啥关系呢?
WebRTC应用中的TURN实现
WebRTC(Web Real-Time Communication),即网页实时通信,它实现了基于网页的语音对话或视频通话,目的是无插件实现web端的实时通信的能力,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现。WebRTC提供了视频会议的核心技术,包括音视频的采集、编解码、网络传输、显示等功能,并且还支持跨平台:windows,linux,mac,android。
通常,基于NAT的限制条件下,在WebRTC和VoIP应用中,棘手的问题是如何让通信双方或多方的媒体流信息能互相流通,因此,STUN的出现在很大程度上解决了这一问题,且TURN的扩展使用也弥补了相应的不足。之后,交互式连接(Interactive Connectivity Establishment,ICE)机制更让STUN和TURN的应用更加完美,它通过综合运用STUN、TURN、RSIP等NAT穿透方式,优化性能,以弥补单独使用其中任何一种方法所带来的固有缺陷。其实也可以说,ICE机制是绑定TURN来使用的。
因此,对大多WebRTC系统来说,一个关键因素是当防火墙或NAT设备不允许对等实体之间进行直接的媒体流量通信交互时,那么就需要有一个TURN服务器在对等实体之间来中继消息。
Slack部署的TURN服务
在我们测试Slack应用时发现,TURN被用来基于安全实时传输协议(Secure Real-time Transport Protocol,SRTP)建立媒体流通信,Slack的这种TURN用法在Yoshimasa Iwase的文章 《Is Slack’s WebRTC Really Slacking?》 中有过详细阐述,在此就不作深入讨论。但这里要强调的一点是,相对于解决媒体通信,TURN服务器被部署在Slack架构中的关键位置却是我们更关心的。
测试Slack的TURN服务器时发现的问题
经过测试我们发现,利用Slack的TURN服务器,客户端的TCP/UDP流量不仅可以中继到其TURN服务器本身,还能中继到Slack架设在AWS上的内部地址。这对于Web应用类型的渗透测试来说有些熟悉,因为这可能成为SSRF(服务端请求伪造)的利用方式 。然而,与常规SSRF漏洞不同之处在于,这里可以利用(或滥用)的不仅局限于HTTP协议,可能还涉及到一种开放式代理,比如socks proxy或基于CONNECT方法的web proxy。
那利用Slack的这种TURN服务器问题,可以实现哪些安全测试目的呢?
1、可以连接到AWS的元数据服务端 http://169.254.169.254 获取一些临时的身份识别和访问管理凭据,如下图;
2、可以连接到Slack本地主机探测一些未曝露在互联网上的开放端口,如node exporter的系统监测服务,22, 25, 53, 443, 515, 5666, 8500, 8888, 9090或9100端口等;
3、在Slack 的AWS架构-10.41.0.0/16 中进行端口扫描,发现一些服务器管理应用,然而进一步利用这些“可信”服务。
至此,有些人可能会觉得Slack的TURN服务器貌似没有做任何身份验证或授权限制,但其实Slack是做了身份验证的。而且,每当客户端有WebRTC会话请求过来时,Slack的TURN服务器都会为其生成一个临时凭据,作为攻击者来说,要深入利用必须获取到这些凭据信息。因此,我们采取了以下步骤来进行尝试:
1、把我们的浏览器设置成Burp代理模式;
2、在Burp中的 Proxy > HTTP history 按键下,过滤Slack的桌面协作应用关键字screenhero;
3、在Slack中点Call发起一个通话;
4、Slack的TURN服务器发起对/api/screenhero.rooms.create的请求,响应消息中包含了临时的用户名密码信息,以及TURN主机名和端口;
5、我们编写了一个内部测试工具Stunner对这些信息进行了利用,最终形成了一个有效的漏洞。
Stunner就是一个STUN协议的测试工具,当然也能检测一些TURN下的不同协议漏洞。其中有意思的一个子命令就是TURN对等端扫描,它针对特定的对等端主机,通过TURN中继进行端口扫描。下列视频中我们用到了turn peer httpproxy命令,它能通过让Web浏览器配置成HTTP代理模式与Stunner工作,由于Stunner会把HTTP请求和响应代理到Slack的TURN服务器,这样Stunner和TURN服务器之间就形成了一个HTTP流量交互。
演示视频
视频展示了以下几个方面:
获取TURN服务器为客户端生成的凭据;
利用我们自己的IP地址测试TURN服务器到互联网端的中继;
连接到Slack的内部网络和架设在AWS上的元数据服务。
漏洞修复
修复该漏洞,可以在TURN服务器中设置访问控制规则,去阻止一些内部非公开地址在TURN消息中被指定为对端地址XOR-PEER-ADDRESS。实际环境中,包括Slack在内的大多系统都用到了集成STUN/TURN/ICE 协议且支持 P2P 穿透防火墙的Coturn应用,因此,我们建议实施以下规则:
no-multicast-peers denied-peer-ip=0.0.0.0-0.255.255.255 denied-peer-ip=10.0.0.0-10.255.255.255 denied-peer-ip=100.64.0.0-100.127.255.255 denied-peer-ip=127.0.0.0-127.255.255.255 denied-peer-ip=169.254.0.0-169.254.255.255 denied-peer-ip=127.0.0.0-127.255.255.255 denied-peer-ip=172.16.0.0-172.31.255.255 denied-peer-ip=192.0.0.0-192.0.0.255 denied-peer-ip=192.0.2.0-192.0.2.255 denied-peer-ip=192.88.99.0-192.88.99.255 denied-peer-ip=192.168.0.0-192.168.255.255 denied-peer-ip=198.18.0.0-198.19.255.255 denied-peer-ip=198.51.100.0-198.51.100.255 denied-peer-ip=203.0.113.0-203.0.113.255 denied-peer-ip=240.0.0.0-255.255.255.255
漏洞上报和处理进程
2017.11 把TURN滥用方式加入到了我们的内部测试工具Stunner中
2017.12 在某邀请测试中发现了TURN漏洞
2018.2 对Slack进行了测试且发现了其漏洞
2018.4 向Slack上报漏洞,并帮助其在不同场景下复现了漏洞
2018.5 Slack向现用的服务器打补丁
2010.1 征求Slack漏洞公开意见
2020.3 公布漏洞,更多详情参考 HackerOne
PS: 我们在视频语音服务的测试中都用到了Stunner工具,但现阶段我们暂不打算开源该工具。
*参考来源: rtcsec ,clouds 编译整理,转载请注明来自 FreeBuf.COM
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 挖洞经验 | 利用CSRF漏洞劫持Youtube用户的通知消息
- 挖洞经验 | 利用XML和ZIP格式解析漏洞实现RCE
- 挖洞经验 | 从XSS漏洞到四步CSRF利用实现账户劫持
- 挖洞经验 | 利用Acunetix发现Google的一个$5000美金XSS漏洞
- 挖洞经验 | 利用周六休息日狂赚两万欧的漏洞发现
- 挖洞经验 | 利用Jira的邮件服务器连通测试功能发现其CSRF漏洞
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
图解网站分析(修订版)
[日] 小川卓 / 沈麟芸 / 人民邮电出版社 / 2014-10 / 69.00元
本书以图配文,结合实例详细讲解了如何利用从网站上获取的各种数据了解网站的运营状况,如何从数据中攫取最有用的信息,如何优化站点,创造更大的网站价值。本书适合各类网站运营人员阅读。 第1 部分介绍了进行网站分析必备的基础知识。第2 部分详细讲解了如何明确网站现状,发现并改善网站的问题。第3 部分是关于流量获取和网站内渠道优化的问题。第4 部分介绍了一些更加先进的网站分析方法,其中详细讲解了如何分......一起来看看 《图解网站分析(修订版)》 这本书的介绍吧!