search

Niccolo19 / Blog

MIT License
0 stars 0 forks source link

Uploading Redirect attack on Shadowsocks stream ciphers 解析 #1

Open Niccolo19 opened 4 years ago

Niccolo19 commented 4 years ago

Redirect attack on Shadowsocks stream ciphers.pdf

简单讲一下这个攻击的原理和防御方法。非安全专业，用词可能不精准，凑合看。

client <---> 55-1ocal <--[encrypted]--> 55-remote <---> target

这是55协议的模型。"client"是本机，"ss-1ocal"是本地代理，"[encrypted]"是已加密的公网连接，"55-rem0te"是远端代理，"target"是本机想要连接的外部服务器。

这个攻击是一种重放攻击，由于s0cks5数据包的固定pattern和AES流式密码的弱点。首先，攻击者把"55-remote"发给"55-10cal"的数据流截获，这种数据流的特点是首部是AES所使用的IV，紧跟着是数据payload。攻击者假设流量大概率是HTTP协议，所以payload的开头会是“HTTP1.”字符串。

所以，如果我们能把"HTTP1."字符串替换成s0cks5的请求头，即远端服务器的IP地址，我们就可以欺骗55-remote去解密数据包（一般情况下55-local和55-rem0te使用的密码一致），并且发送解密后的数据包到我们选定的的IP地址。这样就完成了一次攻击。

替换的原理也很简单，正常的加密是encrypted(IV) XOR "HTTP1."。我们需要计算encrypted(IV) XOR "HTTP1." XOR "HTTP1." XOR "1.2.3.4"就可以在不得知密码的情况下替换密文。

具体的操作文档里已经有写了。这个攻击巧妙，但是应该很老套了。因为原理确实比较简单。

防御方法以下几种：

最直接的方法是55-remote和55-local之间使用不同的密码。

禁止IV重用或者添加混淆。

高级一点的方法是对数据包进行校验，防止篡改与重放。个人认为推荐的AES-GCM并不太实用，因为它需要频繁的握手，增加了实现的复杂度。简单的修改方法是直接对数据包打一个MAC码进行校验，不成功就拒绝服务。

更重要的问题是，如果攻击者是为了判断某机器是否是55-remote，那么只要攻击者成功了一次就可以封禁这个IP地址。所以一定要禁止不安全的协议的使用，才能仅可能的保证安全。

Niccolo19 commented 4 years ago

现在已经有猜测和（非确定性）的证据，表明类似的攻击已经存在。