2024年有一项研究工作在三个不同的会议上都进行了（或即将）宣讲（Real World Crypto Symposium 2024, Black Hat USA 2024, and USENIX Security Symposium 2024），这项工作实际上在2023年就已经完成，它就是今天我们要介绍的针对SSH的terrapin attack（terrapin是主要生活在北美的水龟，因此我们把它称为水龟攻击）：
简单来说，水龟攻击是一种针对SSH协议的握手（handshake）阶段的攻击，它的发现者、来自德国波鸿鲁尔大学的研究人员认为它是第一种在实际中出现的“前缀截断”攻击（prefix truncation attack）。一图胜千言，我们借助下面这张图就可以了解水龟攻击的基本原理：
从这张示意图我们可以看到，水龟攻击（在不考虑细节的情况下）就是通过往SSH协议的握手阶段插入一个攻击包（IGNORE包）同时丢弃掉原来的EXT_INFO包来实现攻击。在上图中我们注意到里面有一些数字，这代表了包的sequence number，那些粗体的数字则代表sequence number受到可认证加密（authenticated encryption）的保护，而没有标记粗体的数字就表示这个包的sequence number在面对中间人攻击时有可能被篡改！这也是水龟攻击能够成功的一个重要的前提条件。作者也是这样总结的：
除了没有能够对握手阶段的所有包进行严格的完整性保护之外，水龟攻击能够执行的另一个前提条件是SSH协议没有把握手阶段和后续的安全信道阶段的数据包的sequence number进行区分处理。在比较安全的网络协议实现中，当安全信道建立好之后，一般会把数据包的sequence number计数器进行重置，而SSH协议则没考虑这一步，让安全信道阶段的数据包的sequence number接着前面的握手阶段继续累加。这种设计就留下了一个安全隐患，后面我们会看到这个设计是怎么导致攻击的。
现在开始讲一下攻击的细节，首先介绍的是SSH的IGNORE包，这个是为了防止流量分析引入的一个安全特性，让SSH通信可以插入一些随机数据来防止（针对安全信道的）流量特征分析。问题是这个包在握手阶段并没有什么用（此时还没有建立安全信道），而SSH协议却依然允许握手阶段使用这个特性，因此攻击者可以通过注入（特定数目的）IGNORE包来让整个协议发送的数据包的sequence number增加或者减少（减少这个有点tricky，假定的是你能注入超过2的32次方这么多个IGNORE包，让计数器回滚，不过这个大概率会让SSH连接超时断开）。作者其实研发了一套对sequence number进行操控的技术（如下图所示），细节大家可以去看原文。
也许你要问，这个sequence number就那么重要吗？它的关键性体现在哪里呢？在水龟攻击中，通过前缀截断，中间人可以删除一个安全信道的最初n个包（通过在握手阶段注入n个包，然后再把安全信道的最前面n个包删掉），但是删掉了这些包并不能完全保证后续的安全信道通信正常进行，问题在于SSH的加密模式上：SSH协议中规定了好几种不同的加密模式，而有些加密模式的状态（state）是和sequence number以及特定的包相关的，如果你随便删掉一个包，整个加密状态可能就会出问题。作者发现，在SSH支持的几种加密模式里面（见下表），ChaCha20-Poly1305模式是完全无法抵御水龟攻击的，而基于Encrypt-then-Mac（EtM）模式（包括使用CBC和CTR分组加密模式）的时候，水龟攻击有一定的概率会成功，这可能是本文最重要的结论，我们接下去稍微展开解释一下。
首先看一下受影响的ChaCha20-Poly1305模式，由于这是一个使用流密码（stream cipher）的可认证加密模式，而且对于每个包，SSH规定只会根据收到的这个包的sequence number来进行相关的密钥流的推导，因此水龟攻击删掉前面的包，并不会影响后面的包，这就导致了前缀截断攻击可以完全应用在使用该模式的SSH通信上~
再来看看EtM模式，这里分为两种情况——使用CTR分组加密模式和使用CBC分组加密模式，在前一种情况中，虽然sequence number能够保持不变，但是加密使用的IV是和block的数目（block counter）相关的，你只要删掉一个包，这个block counter就变了，后面所有的解密内容都不对了，因此通信就大概率完全没法继续工作了；而对于CBC模式，情况稍微有点tricky：它进行消息校验的MAC只和每个包的长度、密文内容和sequence number相关，也就是说你删掉前面的包并不会影响后面的包的MAC计算（也就不会引起完整性错误）；但是，删掉前n个包，只会让第n+1个包的解密得到的值变成随机内容（注意，这是因为删掉了一些包，导致IV不同步，但只会让这一个包解密出错，而且这个不影响完整性校验），而仅仅是这一个包的错误，往往可能会被SSH协议忽略，从而导致水龟攻击得逞。作者分析了一些SSH通信的情况，指出很多场景下，第一个包的格式其实是有很多冗余（也就是说，随机值也能给你解析出来一些信息），这样一个错误的解密包也能“蒙混过关”，然后后续的通信就继续下去了。感兴趣的读者可以去看看到底是哪些相关的格式容易“放过“这种错误包。
上面的一系列基础技术，其实只是为水龟攻击搭好了炮台，要真正发挥攻击的威力，当然需要结合具体的通信内容。作者在论文里面介绍了两个场景，第一个场景是针对SSH协议用到的扩展协商机制（RFC 8308），这个机制是为了让标准的SSH安全信道建立之后，再增加一些额外的（安全或者非安全）特性所设计的协商机制，故而它肯定是安全信道建立后最先发送的信息（上图中的EXTINFO信息）。然而通过水龟攻击，我们完全可以把这部分协商内容给删掉，导致SSH并不能提供安全特性，也就（一定程度上）起到了降级攻击的作用。
作者讨论的第二个实例是一个Python SSH实现——AsyncSSH，这个实现的问题是，它不仅支持EXTINFO消息，而且支持在handshake阶段收到的EXTINFO消息（好奇怪），因此就会让攻击者结合水龟攻击和（基于明文的）中间人攻击来深入控制SSH的连接特性。
最后，作者进行了全网扫描，发现在所有SSH公网服务中，ChaCha20-Poly1305（最容易攻击的模式）的使用率和优先使用率都很高（大于50%），因此水龟攻击对SSH安全的影响还是显而易见的！
在作者为水龟攻击建立的网站（https://terrapin-attack.com）上，作者不仅介绍了相关技术，也提供了一个漏洞扫描器，可以帮助大家去扫描自己的SSH服务端和客户端，看是否受到水龟攻击影响，如果你是管理员，那就赶紧去测试一下吧！
论文：https://terrapin-attack.com/TerrapinAttack.pdf
网站：https://terrapin-attack.com/
Artifacts：https://github.com/RUB-NDS/Terrapin-Artifacts
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2024-06-05 SSH“水龟”攻击
