v2ray-core在v4.23.2版本之前存在重大安全漏洞,可导致服务器遭到主动探测特征识别,请大家尽快更新

v2ray-core在v4.23.2版本之前存在重大安全漏洞主要包含两个漏洞:HTTP伪装存在潜在的特征识别风险 #2537vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) #2523,截止本文发出前,最新版本是v4.23.4,已经对这两个漏洞进行了修复,请大家尽快更新。

HTTP伪装存在潜在的特征识别风险

这个问题并不算严重。问题主要出在HTTP伪装的服务器,可以使用主动探测的方法与正常服务器进行区分,而伪装的HTTP流量可能遭到潜在的被动检测。

v2ray的HTTP伪装如果开启,服务端对入站请求的处理过于笼统,且失败时回应为硬编码:

func (a HttpAuthenticator) Server(conn net.Conn) net.Conn { 
    if a.config.Request == nil && a.config.Response == nil { 
        return conn 
    } 
    return NewHttpConn(conn, new(HeaderReader), a.GetServerWriter(), formResponseHeader(&ResponseConfig{ 
        Version: &Version{ 
            Value: "1.1", 
        }, 
        Status: &Status{ 
            Code:   "500", 
            Reason: "Internal Server Error", 
        }, 
        Header: []*Header{ 
            { 
                Name:  "Connection", 
                Value: []string{"close"}, 
            }, 
            { 
                Name:  "Cache-Control", 
                Value: []string{"private"}, 
            }, 
            { 
                Name:  "Content-Length", 
                Value: []string{"0"}, 
            }, 
        }, 
    })) 
}

对于任何不符合规定的头部,均使用一个硬编码的500回复进行回复。

我们可以猜想存在这样一种检测,用以区分正常HTTP服务器和伪装的v2ray服务器:

v2ray的HTTP伪装,是在TCP流量开始处,添加一个HTTP头部,此后便不再添加HTTP头部。服务端到客户端的通讯亦如此。这种奇怪的TCP连接,有可能遭到防火墙的怀疑。

对于这样的流量,防火墙可以构造标准的HTTP请求,以及一个随机载荷,对服务器进行主动探测。

如果标准HTTP请求和随机载荷得到的服务器响应,均形如

HTTP/1.1 500 Internal Server Error
Connection: close
Cache-Control: private
Content-Length: 0
Date: Tue, 02 Jun 2020 17:15:26 GMT

则该服务器为使用了HTTP伪装的v2ray服务器。

如果标准的HTTP请求,得到了404/403/200/500等回应,并且随机载荷得到了400的回应,则这是一个正常的HTTP服务器。

vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别

v4.23.4及以后已经采取随机读取多个字节的方式阻止P的侧信道泄漏,目前下面的PoC(16次探测)以及概率探测(暴力发包探测)的PoC已经失效,无法准确探测vmess服务。但是,由于这是协议设计层面的问题,彻底解决问题需要引入AEAD等无法向下兼容的设计。好消息是,这一缓解可以为我们讨论制订新协议争取非常多的时间。vmess+tcp的组合仍然存在一定风险,不建议使用。

先说结论:开启了tcp+vmess的服务端,在和客户端进行通讯时,攻击者可以通过重放攻击的方式准确判定是否为vmess服务。

这个缺陷的利用基于重放攻击和密文填充攻击,需要以下条件(经过讨论,结合之前ss遭到的重放攻击,我们认为对于GFW来说,此条件并不苛刻):

攻击者可以进行中间人攻击,捕获vmess的TCP流前16 + 38字节。

攻击者可以在30秒内据此发送16个探测包

目前的缓解方案均可以被绕过,唯一解决方案是修改协议实现 。

个人认为,最好的解决方案是采用gcm等具有认证能力的aead加密模式对指令部分进行加密,而不是cfb。这和现有vmess设计冲突且无法向下兼容,可能需要重新设计vmess协议。

mkcp+vmess和tls+vmess等底层传输不使用tcp的组合不受此问题直接影响,但有可能收到波及。

分享此页面

Comments