威胁情报动态：CVE-2024-6387“regreSSHion”暴露面核查与内网权限边界处置

背景

OpenSSH 项目于 2024 年 7 月披露 CVE-2024-6387，安全社区将其称为“regreSSHion”。该漏洞源于 sshd 在处理登录超时时的信号处理竞争条件：特定版本在 SIGALRM 信号处理器中调用了非异步信号安全函数。在基于 glibc 的部分 Linux 环境中，未经认证的远程请求理论上可能触发 sshd 进程内存状态异常，并进一步影响 root 权限边界。

受影响范围主要是 OpenSSH Portable 8.5p1 至 9.7p1。OpenBSD 不受该问题影响；Linux 发行版通常会回移补丁，因此不能只根据 ssh -V 的上游版本号判定是否存在漏洞。本文重点是公开威胁情报落地后的授权核查、日志判断和修复验证，不包含利用代码。

单次连接失败、banner 探测或大量 pre-auth 断连，只能说明存在扫描或异常访问，不能直接证明漏洞利用成功。应结合包补丁状态、sshd 崩溃记录、认证日志和主机行为综合判断。

问题定位：先确认暴露面，再判断补丁状态

核查时建议将资产分成三层：互联网直接暴露的 SSH 服务、通过负载均衡或端口映射暴露的跳板机、仅内网可达但承担横向管理功能的 SSH 服务。后两类经常被资产清单遗漏，却可能在边界主机失陷后形成内网攻击链路。

在获得授权的管理网段内，可以先进行低强度服务识别。不要使用高并发连接或反复触发登录超时，因为该漏洞本身与超时竞争有关，粗暴验证可能造成 sshd 资源消耗。

# 从授权扫描节点识别 SSH 服务版本；限制速率，避免对生产环境造成压力
nmap -sV -Pn -p 22,2222 --version-light --max-rate 20 \
  -oA openssh-inventory 10.20.0.0/24

# 本机确认 OpenSSH 客户端版本，仅可作为初步线索
ssh -V

# 查看服务端软件包版本
# Debian/Ubuntu
dpkg-query -W -f='${Package} ${Version}\n' openssh-server
apt-cache policy openssh-server

# RHEL/Rocky/AlmaLinux
rpm -q openssh-server
rpm -q --changelog openssh-server | grep -i -E 'CVE-2024-6387|regresshion'

# 查看服务实际监听地址和端口
ss -lntp | grep -E 'sshd|:22 |:2222 '

# 输出 sshd 生效配置，避免只检查主配置文件
sshd -T | grep -E '^(port|listenaddress|logingracetime|maxstartups|permitrootlogin|passwordauthentication|allowusers|allowgroups) '

版本判断需要对照发行版安全公告。例如发行版可能保留 9.2p1 的主版本号，但通过软件包修订号回移修复。若只用“低于 9.8p1”作为漏洞判据，容易产生大量误报。可靠顺序应为：发行版公告、已安装包修订号、变更日志、厂商漏洞状态页，最后才是远程 banner。

技术分析：为什么该漏洞影响权限边界

sshd 监听进程通常以 root 启动，以便绑定端口、读取主机密钥并在认证后切换用户。OpenSSH 已通过特权分离、预认证沙箱和子进程模型缩小攻击面，但 CVE-2024-6387 发生在认证完成前的超时处理路径中。LoginGraceTime 到期后，SIGALRM 可能打断正常执行流程；若信号处理器调用不安全函数，并恰好遇到特定堆状态，就可能产生竞争条件。

这类问题的验证不能简化为“端口开放即已失陷”。实际风险还受操作系统、C 库、编译选项、地址空间随机化、发行版补丁和网络延迟影响。公开研究通常需要大量尝试才能命中竞争窗口，因此生产排查更应关注持续并发、接近 LoginGraceTime 的连接生命周期以及 sshd 异常退出，而不是运行来源不明的 PoC。

在内网攻防链路中，风险较高的场景包括：

• 互联网入口跳板机同时允许访问服务器管理网，入口失陷后可直接扩大横向范围。
• sshd 以默认配置监听 0.0.0.0，安全组只考虑业务端口，未限制管理端口来源。
• 多台服务器复用同一运维私钥，边界主机失陷后权限可跨主机扩散。
• 允许 root 直接登录，或普通运维账户拥有无密码 sudo，导致权限边界形同虚设。
• 容器宿主机、备份服务器和虚拟化管理节点共用同一 SSH 管理平面。

日志与主机侧排查

优先确定观察时间窗，再关联网络侧和主机侧事件。常见扫描会留下大量未完成认证、连接关闭或 banner 交换记录，但不同发行版和 LogLevel 下日志文本存在差异。

# Debian/Ubuntu：查看最近 24 小时 SSH 日志
journalctl -u ssh --since '24 hours ago' --no-pager
zgrep -hE 'Timeout before authentication|Connection closed|banner exchange|preauth' \
  /var/log/auth.log*

# RHEL 系：服务单元通常为 sshd
journalctl -u sshd --since '24 hours ago' --no-pager
zgrep -hE 'Timeout before authentication|Connection closed|banner exchange|preauth' \
  /var/log/secure*

# 检查 sshd 崩溃、段错误、OOM 和 core dump
journalctl -k --since '7 days ago' | grep -iE 'sshd|segfault|oom|killed process'
coredumpctl list sshd
systemctl show sshd -p NRestarts -p ExecMainStatus -p ActiveEnterTimestamp

# 统计认证前日志中的来源地址；字段位置可能因日志格式不同而需调整
journalctl -u sshd --since '24 hours ago' --no-pager \
  | grep -E 'preauth|Timeout before authentication|banner exchange' \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -nr | head -30

# 查看当前未完成的 22 端口连接状态
ss -ant '( sport = :22 )' | awk 'NR>1 {print $1}' | sort | uniq -c

如果出现 sshd 反复崩溃或异常重启，应保留 journal、认证日志、core dump 元数据、进程启动时间和边界设备流量记录。不要在未取证前直接清理 core 文件。若发现可疑登录，还应检查该账户的 authorized_keys、sudo 使用、systemd 持久化和计划任务。

# 最近登录与失败登录
last -Fai | head -50
lastb -Fai | head -50

# 核查近期写入的 SSH 公钥文件
find /root /home -xdev -type f -name authorized_keys \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %m %p\n' 2>/dev/null | sort -r

# 检查 sudo 与账户变更线索
journalctl --since '7 days ago' | grep -E 'sudo|useradd|usermod|passwd'

# 查找最近七天新增或修改的 systemd 单元和计划任务
find /etc/systemd/system /etc/cron.d /var/spool/cron -xdev -type f \
  -mtime -7 -ls 2>/dev/null

上述结果只能用于发现线索。例如 authorized_keys 最近修改可能是正常密钥轮换，必须与变更单、堡垒机审计和管理员操作记录核对。若没有登录成功记录，但 sshd 出现无法解释的崩溃、异常子进程或出站连接，应按疑似主机失陷流程隔离并取证，而不是仅完成软件升级。

授权验证步骤

• 建立资产清单：记录主机、监听端口、网络区域、OpenSSH 包版本、发行版版本和业务负责人。
• 核对厂商状态：确认当前软件包是否包含 CVE-2024-6387 回移补丁，不以远程 banner 作为唯一依据。
• 读取生效配置：使用 sshd -T，必要时通过 sshd -T -C user=测试用户,host=主机名,addr=测试地址 检查 Match 条件后的配置。
• 验证网络边界：从互联网、办公网、运维网和业务网分别测试 22 端口可达性，确认安全组与主机防火墙策略一致。
• 关联日志：检查高频 pre-auth 连接、接近登录宽限时间的断连、服务崩溃和异常重启。
• 修复后复测：重新确认软件包、进程启动时间、生效配置和端口可达范围，避免“升级完成但旧进程仍运行”。

# 检查带 Match 条件时的最终配置示例
sshd -T -C user=opscheck,host=server01,addr=10.20.30.40 \
  | grep -E '^(logingracetime|permitrootlogin|passwordauthentication|pubkeyauthentication|maxstartups) '

# 配置语法检查；返回为空且退出码为 0 才表示通过
sshd -t
echo $?

# 修复升级后重启服务，并确认进程实际更新时间
systemctl restart sshd || systemctl restart ssh
systemctl status sshd --no-pager || systemctl status ssh --no-pager
ps -C sshd -o pid,lstart,args

风险处置与修复建议

如果短期内确实无法升级，上游建议可将 LoginGraceTime 设置为 0，以避免触发对应的登录超时信号路径。但这会允许未认证连接长期占用资源，增加拒绝服务风险，只能作为临时缓解措施，并应同时收紧来源地址、配置连接数限制和监控连接状态。

# 临时缓解示例：必须结合网络白名单和连接限制评估
# /etc/ssh/sshd_config
LoginGraceTime 0
MaxStartups 10:30:60
PermitRootLogin no
PasswordAuthentication no

# 修改后先检查语法，再平滑加载
sshd -t && systemctl reload sshd

不要为了测试修复效果在生产主机上运行公开利用程序。该漏洞属于概率型竞争条件，“没有打成功”不能证明安全，而高频尝试反而可能造成连接耗尽和服务异常。验证的闭环应是补丁状态、暴露面、配置和日志四项同时满足。

总结

CVE-2024-6387 的处置重点不是批量读取 SSH banner，而是识别真正的管理面暴露、确认发行版回移补丁、检查 sshd 生效配置，并将扫描日志与崩溃及登录行为关联。对承担跳板、备份或虚拟化管理职责的主机，应按更高优先级处理，因为这些节点一旦越过认证前权限边界，往往可以继续进入内网管理平面。修复完成后还需重启旧进程、复测网络访问路径并复核运维密钥边界，才能形成完整闭环。

核查时建议把“端口可达、软件包是否受影响、补丁是否生效”分开记录。CVE-2024-6387 是 sshd 认证前的信号处理竞态，重点关注使用 glibc 的 Linux；上游 OpenSSH 8.5p1～9.7p1 属于重点排查范围，9.8p1 已修复。但发行版可能回补补丁，不能仅凭 SSH banner 或版本字符串下结论，仍需对照发行版安全公告和软件包完整版本。

# 在主机侧确认监听位置、关键配置与安装包版本
sudo ss -lntp | grep sshd
sudo /usr/sbin/sshd -T | grep -E '^(port|listenaddress|logingracetime|maxstartups) '

# Debian / Ubuntu
dpkg-query -W openssh-server

# RHEL 系
rpm -q openssh-server

暴露面不要只统计公网 22 端口。非标准 SSH 端口、IPv6、NAT 转发，以及办公网、VPN、容器节点到服务器的可达路径都应纳入。尤其检查“普通终端网段能直接访问服务器 SSH”的情况：先在网络侧仅放行堡垒机或管理网段，避免一台终端失陷后直接触达整片服务器。

暂时不能升级的受影响主机，可将 LoginGraceTime 0 作为临时缓解；代价是未认证连接不再按该超时释放，更容易耗尽连接资源，并非无副作用修复。

# 修改实际生效的 sshd 配置：
LoginGraceTime 0

# 校验通过后再重载；服务名按发行版选择 sshd 或 ssh
sudo /usr/sbin/sshd -t && sudo systemctl reload sshd
sudo /usr/sbin/sshd -T | grep '^logingracetime '

操作前保留现有管理会话，并确认配置包含文件没有覆盖预期值。正式更新后，还要确认监听进程已经切换到修复后的二进制，不能只看包管理器显示“已安装”。

日志侧可关联认证前超时、连接骤增、sshd 子进程崩溃及服务异常重启，但这些只能作为排查线索，不能单独证明利用成功；没有登录成功记录也不能排除风险。若已有失陷迹象，应按可能取得主机 root 权限评估，重点追查该机可读取的部署凭据、服务账号密钥及其下游访问权限，而不只是重置 SSH 密码。