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

近日,VLESS协议Xray的作者rprx发现Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性。具体来说,便是Shadowsocks AEAD防重放设计有缺陷,中间人可以随意对客户端接收的数据进行移花接木或重放,比如对调两条 TCP 连接所返回的数据,达到隐蔽式拒绝服务攻击的目的。

更多详情请参考:

1. 利用防重放机制自动对 Shadowsocks、VMess 等未知流量代理进行“隐蔽式拒绝服务攻击”

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

一下是相关issue的转载:

这个问题是昨天发现的,本来我只是想先给 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(实际上它有其它问题,但不是这种严重漏洞),最后感谢某个开发者群成员参与讨论与验证。


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


 

由于 #183 ,我在研究“对服务端与客户端的逐字节重放”,并且取得了一些成果,此时又开了一下脑洞:

如果布隆过滤器被人恶意打满呢?不过可操作性不强,还有太多未知变量。

接着就想到了如题:众所周知,某中间人一直在对未知流量进行重放,导致现在大多数实现都有防重放机制。


而利用服务端的防重放,中间人不需要破坏连接,只需提前发送未知流量的前 32 个字节(或更多),即可使这些代理实质性失效。

不需要封锁任何 IP 或端口,精准阻断未知流量类代理。 某种程度上还是无解的,允许重放又会存在问题。

这个机制简单可行,好消息是,它尚未被部署,坏消息是,一旦部署会很棘手。

其实只会阻断这类协议:未知流量、0-RTT、有重放过滤器听起来是不是很熟悉?而且并没有封你,是你自己封了自己。

 

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注