Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性

[RPRX]

这个问题是昨天发现的，本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。

顺便研究了一下 SS AEAD 的安全性，我脑洞比较大，考虑得比较多，比如是否可以造成 对客户端的攻击，简述如下：

1. 对于 TCP，Shadowsocks AEAD 往返是完全一样的加密结构，HKDF 的 info 也相同，且响应的加密完全独立于请求
2. 对于 UDP，同样存在上面的问题（甚至可以与 TCP 杂交），更糟糕的是，UDP 往返连明文结构都是完全一样的

以上“特性”的利用方式太多了，真的很难排列组合完，还是主要说对客户端的攻击：

在不需要密码的情况下，可以随意对客户端接收的数据进行移花接木或重放等操作，使得被代理程序收到的数据没有任何可靠性。

比如将 A、B 两条 TCP 连接返回的数据对调，Shadowsocks AEAD 客户端是无法发现异常的，只会成功解密并传给被代理程序。

一些 SS 实现是全局共用 IV 过滤器，只能在单一客户端且不重启（which is impossible）的前提下防御重放，防不了移花接木。
Shadowsocks 流加密也存在此问题，有兴趣的可以研究一下 SSR 的 auth_chain_* 系列是否也存在此问题。

建议先用 VMess AEAD（实际上它有其它问题，但不是这种严重漏洞），最后感谢某个开发者群成员参与讨论与验证。

---

需要说明，这里主要是描述存在的漏洞，而对漏洞的利用有很多方式，比如 移花接木、重放、自交、杂交 等，欢迎补充测试结果。

开发者群成员进行了 本地 echo 的 PoC，并根据测试结果得出 TCP / UDP 移花接木猜想，后者尚未进行 PoC

注意⚠️：下文提及的 “问题” 仅限于本地 echo 自交，不包含其他问题的受影响程度

注意⚠️：没发出 PoC 不代表没有问题，不受 echo 攻击影响的不代表没有问题

什么是 本地 echo

本地 echo：将 Client 原本要发给 Server 的流量重新发回给 Client，但 Client 解密成功发回给上层应用
Client 收到了返回来的包，成功解密后发给上层应用
但他没有意识到，这包其实是不久前自己发出的，原封不动地又被发了回来

经过实践验证，echo 方式影响的软件 / 实现：

• V2Ray / Xray 内 Shadowsocks 任意 method （AEAD / 非 AEAD）
• SSR 任意 method + origin + plain （怕不是没人用了） 对不起我高估了，还有好多人在用
• ss-libev 非 AEAD 加密受影响 （AEAD 仅仅不受 echo 影响，其他攻击向量仍然可行）

复现过程（仅本地 echo 方式，其他攻击方式后续发布）

1. 搭建本地 echo 环境
   socat UDP4-LISTEN:2000,fork EXEC:'cat' 和 socat TCP4-LISTEN:2000,fork EXEC:'cat'
2. 启动任意上述受影响的实现
3. 使用 proxychains 或 cgproxy （因为 proxychains 不能处理 UDP 流量） 代理 nc 进行连接
   proxychains nc 任意IP地址 任意端口号
cgproxy nc -u 任意IP地址 任意端口号
4. 输入任意内容， 即可发现内容被 echo 返回

参考复现结果 （仅参考）

TCP

UDP

需要说明的是，这种情况下 nc 收到的回包内包含目标地址块（即图一中的 y 和图二中的 ‘）：

[zonyitoo]

This is vulnerable because somebody can "fake" the response stream / packets from a known shadowsocks server.

• If the attacker doesn't know the correct password, then he can only replay some known respond streams or packets.
• If the attacker knows the correct password, then he doesn't need to do this.

So the key is to prevent replay on the client side.

Here are some of my stupid guess about the applications of this vulnerability:

• Most users uses shadowsocks for accessing HTTP services, so if he is accessing a HTTP (without the S) service, then the attacker can respond to him a "fake" website. If possible.
• The attacker just want to destroy your shadowsocks connection, and he just makes some random respond to you.

But these vulnerability doesn't seem to affect personal and private users. :P

[RPRX]

@zonyitoo 想象一下引发 TLS 错误从而根据报错长度来判断是代理。以及，SS AEAD 作为一个加密传输层，本应保证回应可靠。

[Mygod]

What happened to random IV?

[bdbai]

@Mygod Client IV, even random, does not reflect in a server response by any means. While Server IV may be random because it is out of control. Therefore, an arbitrary Shadowsocks stream, either uploading or downloading, could be reused by a MITM as a response stream to another request as long as both of them involve the same Shadowsocks service.

[zonyitoo]

What happened to random IV?

This issue indicates that the respond stream / packet could be faked.

Consider a senario, a client makes 2 independent TCP connections to a server, then a attackers sliently swaps these 2 connections' respond packets to the client. The client won't notice but only find errors from the applications, because the shadowsocks' client can always decrypt the two respond streams successfully.

Further application still unknown, but it should be a problem because sslocal doesn't know it is being attacked.

[Mygod]

Random IV should prevent cross session reordering. You should somehow ensure the IV is random.

As for reordering within the same TCP stream, I don't remember how it is implemented but we could presumably authenticate the previous tag as well, similar to Merkle-Damgard.

[zonyitoo]

Random IV should prevent cross session reordering. You should somehow ensure the IV is random.

The swapping happens before the client receives the first respond packet from the server. So it is unrelated that whether the IV is random. A correct implementation of server returns a random IV for every independent connection, but the situation described by this issue can still happen.

[Mygod]

Sure. I guess in this case, you could resolve it by having server's real IV to be random xor client IV for TCP. I don't think this is an issue for UDP as UDP is designed to be unreliable.

Anyway this is a very active adversary, which is not very realistic in most cases. Although we could implement these mitigations (xored IVs and Merkle-Damgard authentication) in the future, I do not see the urgency at the moment.

[zonyitoo]

you could resolve it by having server's real IV to be random xor client IV for TCP.

And then client xor it back? Hmm, that is a rather good idea.

But the attacker can still have your client's IV, so he can also make it happens.

[Mygod]

Yeah never mind 😜. We should maybe authenticate client's IV as additional data instead.

P.S. Also now that I think about it the IV autoincrements so nothing needs to be done there. Oops.

[viRikaRe]

I just wonder what kind of MITM attacker will ever use this vulnerability.

• When ISP/GFW doesn't suspect you, it shall not mess-up the connection. Otherwise it degrades the service and may impact other software.
• When ISP/GFW is suspecting you, does this method reveal a distinctive pattern to confirm the suspicion?
• When ISP/GFW confirms you are using proxy, why not just cut off your network?
• If other MITM attacker wants to destroy your network, why not just drop the packets?

Anyway, a fix would be appreciated, but I don't see much priority.