1. 项目概述一次对SSH协议根基的“降维打击”最近在安全圈里Terrapin攻击CVE-2023-48795这个词被反复提及。乍一看这又是一个CVE编号似乎只是安全公告里又一个需要打补丁的漏洞。但当我深入其技术细节后发现事情远非那么简单。这并非某个SSH服务器软件如OpenSSH的实现缺陷而是直接针对SSH传输层协议RFC 4253本身设计逻辑的一次精准打击。它动摇了我们长期以来对SSH“坚不可摧”加密通道的信任基础——即便连接本身被完整加密攻击者依然有能力在特定条件下像幽灵一样操纵连接建立的初始握手过程破坏安全通道的完整性。简单来说Terrapin攻击允许一个具备中间人MitM位置的攻击者在SSH连接建立的最初几步密钥交换阶段通过有选择地丢弃特定的数据包序列来破坏“扩展协商”机制的安全性。这可能导致客户端错误地认为服务器不支持某些关键的安全增强功能如aes128-gcmopenssh.com这类认证加密模式从而被迫降级到安全性较弱的算法或者更危险的是破坏某些基于序列号的安全机制为后续更复杂的攻击打开一扇窗。理解它不仅是为了修复一个漏洞更是为了重新审视我们视为“默认安全”的基础设施协议。这篇文章我将从一个实践者的角度带你从零开始彻底拆解Terrapin攻击的原理。我们不会停留在概念描述而是会深入到RFC的字节层面并最终通过一个可控的实验环境亲手复现这一攻击的核心部分亲眼看看攻击者是如何“掐掉”协议握手过程中的关键信息从而影响后续的安全决策的。无论你是运维工程师、安全研究员还是对网络协议安全感兴趣的开发者这次探索都将让你对SSH协议有更深一层的认识。2. SSH协议安全模型与Terrapin的攻击面要理解Terrapin攻击的精妙与危险之处我们必须先回到SSH协议设计的基本盘。SSHSecure Shell协议簇为我们提供了在不安全网络上建立安全通信的能力其核心安全模型建立在几个关键阶段协议版本协商、算法协商密钥交换、用户认证和连接通道建立。Terrapin攻击的舞台就搭建在“算法协商”这个环节更具体地说是其中容易被忽视的“扩展协商”子环节。2.1 SSH握手流程与安全假设一个标准的SSH连接建立过程以广泛使用的OpenSSH实现为例大致如下TCP连接建立客户端连接到服务器的22端口。协议版本交换双方交换标识字符串例如SSH-2.0-OpenSSH_8.9p1。密钥交换初始化客户端发送SSH_MSG_KEXINIT消息列出自己支持的密钥交换算法、加密算法、消息认证码MAC算法等。服务器响应服务器回复自己的SSH_MSG_KEXINIT消息双方从中选出第一个共同支持的算法组合。密钥交换与认证执行选定的密钥交换算法如curve25519-sha256生成会话密钥并交换主机密钥进行服务器认证。新密钥启用双方发送SSH_MSG_NEWKEYS消息标志着之后的所有通信都将使用新协商的密钥进行加密和完整性保护。在此之后才是用户认证如公钥、密码认证。一个根深蒂固的安全假设是一旦SSH_MSG_NEWKEYS消息交换完成后续通信就处于一个加密且完整性受保护的通道中中间人无法再篡改或窥探。Terrapin攻击的突破点在于它发现在NEWKEYS之前存在一个攻击窗口。2.2 扩展协商Extension Negotiation机制RFC 8308引入了SSH的“扩展协商”机制。它允许客户端和服务器在密钥交换阶段就一些额外的功能或算法进行协商。这个协商过程是通过在SSH_MSG_KEXINIT消息中附加一个EXT_INFO扩展并在密钥交换完成后、NEWKEYS发送之前通过SSH_MSG_EXT_INFO消息来传递具体信息实现的。例如OpenSSH 8.5及以上版本支持aes128-gcmopenssh.com这种将加密和认证合二为一的认证加密AEAD算法。服务器可以通过SSH_MSG_EXT_INFO告诉客户端“我还支持这个更先进的算法哦”。如果客户端也支持它们可能会在后续的重新密钥Rekey过程中启用它。关键问题来了SSH_MSG_EXT_INFO消息是在密钥交换之后、但在NEWKEYS启用新密钥之前发送的。这意味着传输这部分关键协商信息的通道其完整性保护尚未生效。协议设计者可能认为既然密钥交换已经完成中间人无法解密或伪造消息顶多只能丢弃数据包。而丢弃包通常会导致连接失败似乎不会引发安全问题。Terrapin攻击正是利用了对“丢弃数据包”这一行为后果的低估。2.3 Terrapin的攻击原理有选择的序列删除Terrapin攻击的核心是一种“有选择的序列删除”攻击。攻击者MitM需要能够拦截和修改客户端与服务器之间的TCP流量例如在公共Wi-Fi或受控网络环境中。攻击者并不试图解密或伪造SSH_MSG_EXT_INFO消息的内容因为这需要破解加密而是简单地丢弃客户端或服务器发送的SSH_MSG_EXT_INFO消息。由于SSH协议在传输层使用连续的序列号来标识数据包丢弃一个消息会导致后续所有消息的序列号发生偏移。攻击者可以通过精心计算在丢弃EXT_INFO消息后再丢弃紧随其后的一个或多个普通数据包使得序列号的偏移看起来“天衣无缝”从而让连接不会因序列号错乱而立即中断。造成的后果安全功能降级如果服务器发送的EXT_INFO被丢弃客户端就收不到服务器支持AEAD等增强算法的通知。客户端可能会因此使用安全性较低的默认加密模式如CBC模式从而降低了连接的整体安全强度。破坏特定实现的完整性一些SSH实现如某些Paramiko版本的安全逻辑严重依赖于扩展协商的完整性。丢弃EXT_INFO消息可能会干扰其内部状态理论上可能结合其他漏洞导致更严重的问题。注意Terrapin攻击本身不直接导致密钥泄露或认证绕过。它的危险性在于其为后续攻击创造了条件降级攻击并打破了“SSH握手后即绝对安全”的心理模型。它提醒我们即使在加密通道建立的过程中初始的、未受完整性保护的握手阶段也同样需要谨慎对待。3. 实验环境搭建与核心工具解析纸上得来终觉浅绝知此事要躬行。要真正理解Terrapin攻击没有什么比亲手搭建一个实验环境并观察攻击流量更有效的了。我们的实验目标不是去攻击任何生产系统而是在一个完全受控的实验室环境中复现攻击者进行“序列删除”的操作并验证其对SSH扩展协商的影响。3.1 实验拓扑设计我们需要一个简单的三节点环境客户端运行一个易受攻击的SSH客户端例如特定版本的OpenSSH或Paramiko。服务器运行一个支持扩展协商的SSH服务器例如OpenSSH 8.5。攻击者MitM作为中间人能够对客户端与服务器之间的TCP流量进行拦截、分析和修改。为了简化我们可以使用两台虚拟机VM或容器来模拟这个环境。一台同时扮演客户端和攻击者使用工具进行流量转发和篡改另一台作为服务器。推荐配置系统Ubuntu 22.04 LTS或其他现代Linux发行版。网络确保两台机器在同一局域网可以互相ping通。为服务器分配一个静态IP例如192.168.56.101。3.2 关键软件安装与配置在服务器端确保安装并运行OpenSSH服务器版本最好在8.5以上以支持扩展协商。sudo apt update sudo apt install openssh-server -y ssh -V # 查看版本确认支持为了实验清晰建议在服务器的SSH配置中明确启用一些扩展算法。编辑/etc/ssh/sshd_config确保包含类似行Ciphers aes128-gcmopenssh.com,aes256-gcmopenssh.com,chacha20-poly1305openssh.com,aes256-ctr,aes192-ctr,aes128-ctr KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256修改后重启SSH服务sudo systemctl restart sshd。在客户端/攻击者机器安装必要的网络工具和Python环境。sudo apt install net-tools tcpdump python3 python3-pip -y安装scapy。这是一个强大的Python数据包操作库我们将用它来构建我们的攻击脚本。pip3 install scapy3.3 核心攻击工具基于Scapy的流量操纵器我们不会使用现成的漏洞利用工具而是自己编写一个简化的攻击脚本以便理解每一个步骤。这个脚本的核心任务是ARP欺骗可选用于局域网MitM让客户端认为攻击者的MAC地址是服务器的反之亦然从而将流量引流到攻击者主机。在实验环境中如果攻击者就是网络网关或我们使用路由规则可以跳过此步直接进行流量转发。流量拦截与转发启用IP转发并设置iptables规则将SSH流量重定向到我们的Python脚本。数据包解析与篡改使用Scapy监听网络接口识别出SSH协议握手阶段的SSH_MSG_EXT_INFO数据包并将其丢弃模拟攻击。序列号修复丢弃EXT_INFO后需要调整后续TCP数据包的序列号和确认号以维持连接不中断。这是Terrapin攻击的技术难点和精髓所在。下面是一个高度简化的脚本框架展示了如何用Scapy嗅探并识别SSH流量#!/usr/bin/env python3 from scapy.all import * import sys # 设置网络接口和IP CLIENT_IP 192.168.56.1 SERVER_IP 192.168.56.101 INTERFACE eth0 # 根据你的实际网卡名修改 def packet_callback(pkt): # 过滤TCP流量目标端口为22SSH if pkt.haslayer(TCP) and pkt.haslayer(Raw): if pkt[TCP].dport 22 or pkt[TCP].sport 22: # 尝试解析为SSH协议 payload bytes(pkt[Raw].load) # SSH协议通常以字节SSH-2.0或消息类型开头 # 这里需要实现复杂的SSH协议解析逻辑来定位EXT_INFO消息 # 这是一个复杂部分需要参考RFC 4253的二进制格式 # 此处仅为示意 if payload.startswith(bSSH-2.0): print(f[*] SSH Version String: {payload[:50]}...) # 更精细的解析需要分析SSH二进制数据包结构识别消息类型如EXT_INFO类型为7 # 实际攻击代码需要在此处判断是否为SSH_MSG_EXT_INFO (type 7)然后丢弃该包并调整序列号 # 开始嗅探 print(f[*] Starting SSH packet sniffer on {INTERFACE}...) sniff(ifaceINTERFACE, filterftcp and host {SERVER_IP}, prnpacket_callback, store0)实操心得在实际编写攻击脚本时最大的挑战在于正确解析SSH协议的二进制格式。你需要深入理解RFC 4253中数据包封装packet_length,padding_length,payload,random padding以及消息类型编码。SSH_MSG_EXT_INFO的消息类型是7。此外TCP序列号的调整必须极其精确一个字节的错误都会导致连接重置RST。建议先从使用tcpdump -w捕获一次正常的SSH握手流量然后用Wireshark和脚本离线分析开始逐步构建你的解析器。4. 攻击复现步骤详解与流量分析现在让我们进入最核心的动手环节。我们将一步步引导流量经过我们的攻击脚本并观察Terrapin攻击的效果。请注意以下操作应在隔离的测试环境中进行。4.1 步骤一建立基线——捕获正常握手流量在发动攻击前我们首先需要知道一次正常的、包含扩展协商的SSH握手是什么样的。在攻击者机器上启动tcpdump捕获客户端到服务器的所有SSH流量并保存到文件。sudo tcpdump -i eth0 -w ssh_normal.pcap tcp port 22 and host 192.168.56.101从客户端发起一次到服务器的SSH连接可以是不执行命令的ssh -v或者直接连接后退出。ssh -v user192.168.56.101捕获完成后CtrlC停止tcpdump使用Wireshark打开ssh_normal.pcap。过滤ssh协议。在Wireshark中你可以清晰地看到握手流程找到Client: SSH_MSG_KEXINIT和Server: SSH_MSG_KEXINIT。在密钥交换消息如SSH_MSG_KEXECDH_INIT之后寻找Server: SSH_MSG_EXT_INFO。在Wireshark的Info列你可能会看到“Extension Negotiation (RFC 8308)”以及其包含的算法列表。紧随其后的是SSH_MSG_NEWKEYS消息。记录下SSH_MSG_EXT_INFO数据包的TCP序列号、长度等信息。这是我们的“正常参照物”。4.2 步骤二实施中间人攻击与流量转发为了拦截流量我们需要将客户端的SSH流量导向我们的攻击脚本。启用IP转发sudo sysctl -w net.ipv4.ip_forward1设置iptables重定向规则将目的地为服务器22端口的流量重定向到攻击脚本监听的本地端口例如2222。sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222运行攻击脚本我们需要运行一个修改版的脚本它不仅嗅探还要能转发流量。脚本的基本逻辑是接收客户端发来的数据包。检查是否是SSH_MSG_EXT_INFO通过解析SSH二进制负载判断消息类型字节是否为7。如果是则丢弃这个包并记录下这个包的长度L。将后续所有从服务器发往客户端的数据包的TCP序列号SEQ减去L并将所有从客户端发往服务器的数据包的TCP确认号ACK减去L。这样才能让两端保持同步。转发所有其他数据包。由于编写一个完整的、能处理所有TCP状态和重传的MitM代理非常复杂这里仅提供核心逻辑的概念代码# 伪代码/概念展示 def forward_and_modify(pkt_from_client): if is_ssh_ext_info(pkt_from_client): dropped_length len(get_ssh_payload(pkt_from_client)) log(f[!] Dropped EXT_INFO, length: {dropped_length}) # 不转发这个包相当于丢弃 return else: # 转发普通包 send_to_server(pkt_from_client) def handle_server_response(pkt_from_server): # 在丢弃EXT_INFO后需要调整后续服务器包的序列号 if sequence_offset 0: pkt_from_server[TCP].seq - sequence_offset # 同样调整客户端ACK号的包也需要处理 send_to_client(pkt_from_server)4.3 步骤三观察攻击效果启动你的攻击脚本监听2222端口。从客户端再次发起SSH连接。此时流量会经过你的脚本。在客户端使用ssh -v连接观察输出。在正常的连接中你可能会在调试信息中看到类似以下行debug1: kex: server-client cipher: aes128-gcmopenssh.com ...这表示扩展协商成功使用了AEAD算法。而在攻击成功后即EXT_INFO被丢弃你可能看到连接仍然成功建立因为核心密钥交换未受影响。但协商出的加密算法可能降级为列表中的下一个非AEAD算法例如aes256-ctr。更明显的迹象是ssh -v的输出中关于aes128-gcmopenssh.com的调试信息可能消失。同时在攻击脚本的控制台你应该能看到类似“[!] Dropped EXT_INFO”的日志。4.4 步骤四使用Wireshark验证再次使用tcpdump捕获攻击过程中的流量ssh_attack.pcap用Wireshark打开分析对比ssh_normal.pcap和ssh_attack.pcap。在攻击数据包中你应该找不到Server: SSH_MSG_EXT_INFO这个消息。观察TCP流。你会发现在服务器本应发送EXT_INFO的位置攻击者机器没有转发该包。但由于攻击脚本修正了后续的TCP序列号整个TCP会话的SEQ/ACK号流看起来依然是连续的连接得以维持。这正是Terrapin攻击“有选择序列删除”的直接证据。注意事项这个实验的难点在于编写一个健壮的、能处理TCP所有复杂情况如乱序、重传、窗口调整的MitM代理。在实际研究中攻击者使用的是高度优化的工具。我们的实验旨在理解原理。如果脚本编写不完善很容易导致连接断开这本身也证明了实施此类攻击所需的技术精度。5. 影响分析、缓解措施与深度思考成功复现攻击的核心原理后我们需要跳出实验从更广阔的视角审视Terrapin攻击带来的影响以及如何应对。5.1 受影响范围与真实世界风险Terrapin攻击并非一个可以远程直接利用的“武器化”漏洞。它的利用需要先决条件中间人位置攻击者必须能够拦截和修改客户端与服务器之间的网络流量如ARP欺骗、Wi-Fi Evil Twin、被入侵的路由器或ISP。使用易受攻击的算法组合连接必须使用ChaCha20-Poly1305或CBC加密模式与ETM模式的MAC组合。实际上许多现代OpenSSH默认配置的优先算法是安全的。客户端或服务器支持扩展协商这是攻击发挥作用的目标。因此其直接风险相对受限。然而它的象征意义和潜在风险更大协议级漏洞它证明了SSH协议规范存在模糊地带在启用完整性保护之前的短暂窗口期存在风险。降级攻击入口它可以被用作一个跳板迫使连接使用已知存在弱点或未来可能发现弱点的加密模式。破坏安全工具一些自动化安全工具或脚本如Ansible、Fabric使用的SSH库如Paramiko可能因为此攻击而产生意外行为。5.2 缓解与修复方案应对Terrapin攻击需要从客户端、服务器和协议规范多个层面进行。1. 服务器端与客户端更新最直接有效OpenSSH升级到OpenSSH 9.6或更高版本。该版本在协议层面进行了修改即使EXT_INFO消息在传输中丢失也会导致连接立即终止彻底关闭了Terrapin攻击的窗口。这是首选的修复方案。查看当前配置即使暂时无法升级可以检查SSH配置优先使用不受影响的算法。例如在/etc/ssh/sshd_config和~/.ssh/config中确保优先使用CTR模式或GCM模式并避免使用-etmopenssh.com的MAC算法。 # 安全的配置示例 Ciphers aes256-gcmopenssh.com,aes128-gcmopenssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-256-etmopenssh.com,hmac-sha2-512-etmopenssh.com,hmac-sha2-256,hmac-sha2-512 2. 网络层防护始终使用VPN或加密隧道访问关键SSH服务器这可以防止攻击者获得中间人位置。在可控环境内使用静态ARP绑定、交换机端口安全等功能增加实施ARP欺骗的难度。3. 协议规范增强Terrapin攻击促使IETF讨论对SSH协议进行修订考虑将扩展协商等关键信息纳入到受完整性保护的握手阶段中或引入更严格的握手确认机制。5.3 从Terrapin攻击中学到的安全启示Terrapin攻击给所有基础设施工程师和安全研究员上了一课“加密”不等于“全阶段安全”即使是一个以安全为设计目标的协议其建立安全通道的“引导过程”本身也可能是脆弱的。我们需要关注通信的每一个阶段包括握手、协商和密钥交换。对“降级”保持零容忍任何可能导致安全协议降级的漏洞无论其直接利用难度多高都应被严肃对待。降级往往是更复杂攻击链的第一环。深度防御不要单一依赖协议本身的安全。结合网络隔离、证书钉扎SSH Known Hosts、多因素认证等层层防护即使某一层被突破整体系统依然安全。主动监控与更新建立对基础服务如SSH漏洞的监控机制及时评估和更新。像OpenSSH这样的核心工具其安全更新应被赋予最高优先级。通过这次从原理到复现的深度探索我们不仅看清了Terrapin攻击的技术脉络更重要的是它强化了我们的一种思维在安全领域没有一劳永逸的银弹只有持续的理解、审视和加固。下次当你敲下ssh命令时或许会对屏幕背后那场悄无声息的加密握手多一份敬畏。