Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

0
0
【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

2017-02-10 13:53:47
来源:blog.filippo.io 作者:胖胖秦

阅读:513次
点赞(0)
收藏





【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

翻译:胖胖秦

预估稿费:200RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


前言

Ticketbleed(CVE-2016-9244)是存在F5产品的TLS堆栈中的软件漏洞,它允许远程攻击者一次性提取多达31个字节的未初始化内存数据,像Heartbleed一样,它可以包含任意的敏感信息。

如果您不确定是否会受到此漏洞的影响,您可以在ticketbleed.com(包含在线测试)或F5 K05121675文章中找到详细信息和缓解说明。


【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

在这篇文章中,我们将讨论如何找到,验证和披露Ticketbleed。


JIRA RG-XXX

这要从CloudFlare Railgun产生的一个错误报告说起。

rg-listener <> 原始请求失败,错误命令是"local error: unexpected message"

rg-listener <> 原始流量包被记录并显示在握手之间触发了一个TLS警告.

值得注意的是客户在Railgun 和原始服务器之前使用了一个F5的负载均横:visitor > edge > cache > rg-sender > F5 > rg-listener > F5 > origin web server

Matthew不可能在Go中使用一个基本的TLS.Dial 来复现它,所以问题似乎很棘手

Railgun的位置:Railgun通过建立永久优化的连接并对HTTP响应执行增量压缩来加速Cloudflare edge和原始网站之间的请求。


【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞
Railgun连接使用基于TLS的自定义二进制协议,两个终端都是Go程序:一个终端位于Cloudflare edge,另一个安装在客户服务器上。这意味着整个连接都要通过Go TLS栈,crypto/tls。

连接失败的错误代码是:local error: unexpected message,这意味着客户端发送了一些Railgun的Go TLS堆栈无法处理的数据。由于客户端在Railgun和我们之间运行着F5负载均衡,这也表明Go TLS栈和F5之间存在不兼容性。

但是,当我的同事Matthew试图使用crypto/tls.Dial连接到负载均衡上来重现错误时,它成功了。

深入分析PCAP

由于Matthew正坐在我对面,他知道我一直在使用Go TLS协议来实现TLS 1.3。于是我们很快完成了联合调试。

下面是我们分析的PCAP。


【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

上图中有ClientHello和ServerHello数据包,然后马上发送ChangeCipherSpec消息。在TLS 1.2中,ChangeCipherSpec代表的意思就是”让我们开始加密吧”。只有一种情况,ChangeCipherSpec会在握手之前先发送,那就是会话复用。

事实上,通过观察ClientHello,我们可以发现Railgun客户端发送了一个Session Ticket。


【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

Session Ticket携带着先前会话的一些加密密钥信息,来告诉服务器复用先前会话,而不是协商新的会话。


【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞

要了解有关TLS 1.2会话复用的更多信息,请阅读Cloudflare Crypto Team TLS 1.3Take的第一部分,阅读副本或Cloudflare博客上的“TLS会话复用”的帖子。

在发送ChangeCipherSpec消息之后,Railgun和Wireshark变的不知所错(HelloVerifyRequest?Umh?)。所以我们有理由确定这个问题与Session Ticket有关。

在Go中,您需要在客户端上设置ClientSessionCache来显式开启Session Ticket。我们验证Railgun开启了这个功能,并写了这个小测试:

packagemain import( "crypto/tls" ) funcmain(){ conf:=&tls.Config{ InsecureSkipVerify:true, ClientSessionCache:tls.NewLRUClientSessionCache(32), } conn,err:=tls.Dial("tcp","redacted:443",conf) iferr!=nil{ panic("failedtoconnect:"+err.Error()) } conn.Close() conn,err=tls.Dial("tcp","redacted:443",conf) iferr!=nil{ panic("failedtoresume:"+err.Error()) } conn.Close() }

这足以证明错误的发生(local error: unexpected message)与Session Ticket有关。


深入分析crypto/tls

只要我们能在本地重现它,就能弄懂它。crypto/tls的错误消息缺少详细的信息,但是快速的调整允许我们精确定位错误在哪里发生。

每次发生错误时,都会调用setErrorLocked记录错误,并确保所有后续操作失败。该函数通常从错误的站点调用。

我们应该在panic(err)处进行堆栈跟踪,它会告诉我们消息在哪出现异常。

diff--gita/src/crypto/tls/conn.gob/src/crypto/tls/conn.go index77fd6d3254..017350976a100644 ---a/src/crypto/tls/conn.go +++b/src/crypto/tls/conn.go @@-150,8+150,7@@typehalfConnstruct{ } func(hc*halfConn)setErrorLocked(errerror)error{ -hc.err=err -returnerr +panic(err) } //prepareCipherSpecsetstheencryptionandMACstates panic:localerror:tls:unexpectedmessage goroutine1[running]: panic(0x185340,0xc42006fae0) /Users/filippo/code/go/src/runtime/panic.go:500+0x1a1 crypto/tls.(*halfConn).setErrorLocked(0xc42007da38,0x25e6e0,0xc42006fae0,0x25eee0,0xc4200c0af0) /Users/filippo/code/go/src/crypto/tls/conn.go:153+0x4d crypto/tls.(*Conn).sendAlertLocked(0xc42007d880,0x1c390a,0xc42007da38,0x2d) /Users/filippo/code/go/src/crypto/tls/conn.go:719+0x147 crypto/tls.(*Conn).sendAlert(0xc42007d880,0xc42007990a,0x0,0x0) /Users/filippo/code/go/src/crypto/tls/conn.go:727+0x8c crypto/tls.(*Conn).readRecord(0xc42007d880,0xc400000016,0x0,0x0) /Users/filippo/code/go/src/crypto/tls/conn.go:672+0x719 crypto/tls.(*Conn).readHandshake(0xc42007d880,0xe7a37,0xc42006c3f0,0x1030e,0x0) /Users/filippo/code/go/src/crypto/tls/conn.go:928+0x8f crypto/tls.(*clientHandshakeState).doFullHandshake(0xc4200b7c10,0xc420070480,0x55) /Users/filippo/code/go/src/crypto/tls/handshake_client.go:262+0x8c crypto/tls.(*Conn).clientHandshake(0xc42007d880,0x1c3928,0xc42007d988) /Users/filippo/code/go/src/crypto/tls/handshake_client.go:228+0xfd1 crypto/tls.(*Conn).Handshake(0xc42007d880,0x0,0x0) /Users/filippo/code/go/src/crypto/tls/conn.go:1259+0x1b8 crypto/tls.DialWithDialer(0xc4200b7e40,0x1ad310,0x3,0x1af02b,0xf,0xc420092580,0x4ff80,0xc420072000,0xc42007d118) /Users/filippo/code/go/src/crypto/tls/tls.go:146+0x1f8 crypto/tls.Dial(0x1ad310,0x3,0x1af02b,0xf,0xc420092580,0xc42007ce00,0x0,0x0) /Users/filippo/code/go/src/crypto/tls/tls.go:170+0x9d

让我们看看异常的消息警报会发送到哪里conn.go:672。

670caserecordTypeChangeCipherSpec: 671iftyp!=want||len(data)!=1||data[0]!=1{ 672c.in.setErrorLocked(c.sendAlert(alertUnexpectedMessage)) 673break 674} 675err:=c.in.changeCipherSpec() 676iferr!=nil{ 677c.in.setErrorLocked(c.sendAlert(err.(alert))) 678}

所以异常的消息是ChangeCipherSpec。让我们检查上一级的堆栈,看看是否有线索。让我们看看handshake_client.go:262。

259func(hs*clientHandshakeState)doFullHandshake()error{ 260c:=hs.c 261 262msg,err:=c.readHandshake() 263iferr!=nil{ 264returnerr 265}

这是doFullHandshake函数。等等,这里的服务器显然正在进行会话复用(在Server Hello之后立即发送一个Change Cipher Spec),而客户端正在尝试进行完整握手?

看起来情况是,客户端提供Session Ticket,服务器接受它,但是客户端并不知道并继续执行下去。


深入RFC

在这一点上,我查阅了TLS 1.2的相关信息,以了解服务器是如何表示接受Session Ticket?

RFC 5077,过时的RFC 4507:

当携带一个ticket时,客户端会在TLS ClientHello中生成并包含一个Session ID. 如果服务器接收了ticket并且Session ID不为空,它必须马上返回与ClientHello相同的Session ID.

因此,客户端不应该猜测是否Session Ticket会被接受, 客户端应该发送一个Session ID并在服务器的回显中查找这个Session ID。

crypto/tls中的代码很明显的说明了这一点。

func(hs*clientHandshakeState)serverResumedSession()bool{ //IftheserverrespondedwiththesamesessionIdthenitmeansthe //sessionTicketisbeingusedtoresumeaTLSsession. returnhs.session!=nil&&hs.hello.sessionId!=nil&& bytes.Equal(hs.serverHello.sessionId,hs.hello.sessionId) }

深入分析Session IDs

一定是这里出错了。让我们加入一些基于打印输出的调试。
diff--gita/src/crypto/tls/handshake_client.gob/src/crypto/tls/handshake_client.go indexf789e6f888..2868802d82100644 ---a/src/crypto/tls/handshake_client.go +++b/src/crypto/tls/handshake_client.go @@-552,6+552,8@@func(hs*clientHandshakeState)establishKeys()error{ func(hs*clientHandshakeState)serverResumedSession()bool{ //IftheserverrespondedwiththesamesessionIdthenitmeansthe //sessionTicketisbeingusedtoresumeaTLSsession. +println(hex.Dump(hs.hello.sessionId)) +println(hex.Dump(hs.serverHello.sessionId)) returnhs.session!=nil&&hs.hello.sessionId!=nil&& bytes.Equal(hs.serverHello.sessionId,hs.hello.sessionId) } 00000000a8732fc4c980e2efb8e0b7dacf0d71e5|.s/...........q.| 00000000a8732fc4c980e2efb8e0b7dacf0d71e5|.s/...........q.| 0000001000000000000000000000000000000000|................|

F5服务器将Session ID填充到它的最大长度32字节,而不是当客户端发送它时再返回它。crypto / tls在Go中使用16字节会话ID。

从这里看错误就很明显了:服务器认为它告诉客户端使用Ticket而客户端认为服务器启动了新会话,于是意外就发生了。

在TLS空间中,我们发现了一些不兼容性。为了不与某些服务器实现发生冲突,ClientHellos必须小于256字节或大于512字节。

0000000079bde5a877558b9241e98945e1503125|y...wU..A..E.P1%| 0000000079bde5a877558b9241e98945e1503125|y...wU..A..E.P1%| 000000100427a84f6322de8beff9a313dd665cee|.'.Oc".......f\.|

噢哦。等等。这些不是零也不是填充。那是...内存?

在这一点上,和Heartbleed的处理类似。服务器申请和客户端的会话ID一样大的缓冲区,然后总是返回32个字节的数据,在额外的字节里携带着未分配的内存数据。


深入浏览器

我最后一个疑问是:为什么之前没有发现这个漏洞?

答案是:所有浏览器使用32字节的SESSION ID来协商SESSION TICKET。我和Nick Sullivan一起检查了NSS,OpenSSL和BoringSSL来确认这个问题。以BoringSSL为例。

/*GenerateasessionIDforthissessionbasedonthesessionticket.Weuse *thesessionIDmechanismfordetectingticketresumption.Thisalsofitsin *withassumptionselsewhereinOpenSSL.*/ if(!EVP_Digest(CBS_data(&ticket),CBS_len(&ticket), session->session_id,&session->session_id_length, EVP_sha256(),NULL)){ gotoerr; }

BoringSSL使用SHA256作为SESSION TICKET,正好是32个字节。

(有趣的是,在TLS中,有人提到使用1字节的SESSION ID,但是没有人对它进行测试。)

至于Go,可能是客户端没有启用SESSION TICKET。


深入披露

在意识到这个问题的影响之后,我们在公司内部进行了分享,我们的支持团队会建议客户禁用SESSION TICKET,并试图联系F5。

我们与F5 SIRT联系,交换PGP密钥,并提供报告和PoC。

报告已提交给开发团队,确定问题是未初始化的内存,但是仅限于Session Ticket功能。

目前还不清楚哪些数据可以通过此漏洞泄露,但是HeartBleed和Cloudflare Heartbleed Challenge告诉我们未初始化的内存是不安全的

在规划时间表时,F5团队面临着严格的发布计划。综合考虑多种因素,包括有效的缓解(禁用Session Ticket),我决定采用由Google's Project Zero发布的业界标准的披露政策:在115天之后,如果漏洞没有被修复,就会被披露。

巧合的是今天正好是计划发布修复补丁的截至日期。

我要感谢F5 SIRT的专业性,透明度和协作性,这和我们在业内经常听到的对抗性形成鲜明对比。

该漏洞已分配CVE-2016-9244。


深入互联网

当我们向F5报告问题时,我已经针对单个主机测试了该漏洞,该主机在禁用Session Ticket后很快变得不可用。这意味着漏洞具有低信度,并且没有办法再现它。

这是进行互联网扫描的绝佳场合。我选择了由密歇根大学授权Censys.io的工具包:zmap和zgrab。

zmap是一种用于检测开放端口的IPv4空间扫描工具,而zgrab是一种Go工具,通过连接到这些端口并收集大量协议详细信息来进行跟踪。

我在zgrab添加对Session Ticket复用的支持,然后让zgrab发送一个31字节的会话ID,并将其与服务器返回的ID进行比较。我写了一个简单的Ticketbleed检测器。

diff--gita/ztools/ztls/handshake_client.gob/ztools/ztls/handshake_client.go indexe6c506b..af098d3100644 ---a/ztools/ztls/handshake_client.go +++b/ztools/ztls/handshake_client.go @@-161,7+161,7@@func(c*Conn)clientHandshake()error{ session,sessionCache=nil,nil hello.ticketSupported=true hello.sessionTicket=[]byte(c.config.FixedSessionTicket) -hello.sessionId=make([]byte,32) +hello.sessionId=make([]byte,32-1) if_,err:=io.ReadFull(c.config.rand(),hello.sessionId);err!=nil{ c.sendAlert(alertInternalError) returnerrors.New("tls:shortreadfromRand:"+err.Error()) @@-658,8+658,11@@func(hs*clientHandshakeState)processServerHello()(bool,error){ ifc.config.FixedSessionTicket!=nil{ c.resumption=&Resumption{ -Accepted:hs.hello.sessionId!=nil&&bytes.Equal(hs.serverHello.sessionId,hs.hello.sessionId), -SessionID:hs.serverHello.sessionId, +Accepted:hs.hello.sessionId!=nil&&bytes.Equal(hs.serverHello.sessionId,hs.hello.sessionId), +TicketBleed:len(hs.serverHello.sessionId)>len(hs.hello.sessionId)&& +bytes.Equal(hs.serverHello.sessionId[:len(hs.hello.sessionId)],hs.hello.sessionId), +ServerSessionID:hs.serverHello.sessionId, +ClientSessionID:hs.hello.sessionId, } returnfalse,FixedSessionTicketError }

选择31字节的原因是我可以确保不泄露敏感信息。

然后,我从Censys网站下载最近的扫描结果,其中包括什么主机支持Session Ticket信息,并使用pv和jq完成了管道。

在11月份的Alexa top 1m列表中的前1,000个主机中有2个存在漏洞,我中断了扫描,避免泄露漏洞,并推迟到了披露日期。

在完成这篇指导时,我完成了扫描,0.1%和0.2%的主机容易受到攻击,0.4%的网站支持Session Ticket。


阅读更多

欲了解更多详情,请访问F5 K05121675文章或ticketbleed.com,在那里你会发现一个技术总结,受影响的版本,缓解指令,一个完整的时间表,扫描结果,扫描机器的IP地址,并可以进行在线测试。

否则,你应该关注我的Twitter。



【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞
【技术分享】如何发现F5 BIG-IP设备的TicketBleed漏洞
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://blog.filippo.io/finding-ticketbleed/

Viewing all articles
Browse latest Browse all 12749