Open Niccolo19 opened 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"就可以在不得知密码的情况下替换密文。
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地址。所以一定要禁止不安全的协议的使用,才能仅可能的保证安全。
现在已经有猜测和(非确定性)的证据,表明类似的攻击已经存在。
Redirect attack on Shadowsocks stream ciphers.pdf
简单讲一下这个攻击的原理和防御方法。非安全专业,用词可能不精准,凑合看。
这是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地址。所以一定要禁止不安全的协议的使用,才能仅可能的保证安全。