靶机实战(10)：OSCP备考之谷安172.16.33.53

谷安靶机：172.16.33.53

靶机官网：Tre: 1^[1]

实战思路：

1. 一、主机发现
2. 二、端口发现（服务、组件、版本）
3. 三、漏洞发现（获取权限）
1. 8082端口/HTTP服务
1. 组件漏洞
2. URL漏洞（目录、文件）
2. 80端口/HTTP服务
1. 组件漏洞
2. URL漏洞（目录、文件）
3. 22端口/SSH服务
1. 组件漏洞
2. 口令漏洞
4. 80端口/HTTP服务
1. URL漏洞（目录、文件）
4. 四、提升权限
1. tre用户
1. sudo
2. suid
3. cron
5. 后记

一、主机发现

本次攻击指定IP，不涉及主机发现过程。

二、端口发现（服务、组件、版本）

使用命令sudo -u root nmap 172.16.33.53 -n -Pn -p- --reason -sV -sC -O发现主机开放的端口、提供的服务、使用的组件、组件的版本。

开放的端口	提供的服务	使用的组件	组件的版本
22/tcp	ssh	OpenSSH	7.9p1
80/tcp	http	Apache httpd	2.4.38
8082/tcp	http	nginx	1.14.2
-	os	Debian Linux	？

三、漏洞发现（获取权限）

8082端口/HTTP服务

01、中间件组件：使用命令searchsploit nginx 1.，未发现组件nginx 1.14.2的Nday漏洞。

02、应用组件：使用Wappalyzer、FindSomething等浏览器插件自动识别，使用BurpSuite等工具手动识别，均未发现应用组件信息。

01、直接访问：使用浏览器打开http://172.16.33.53:8082/，只有一张竹子的图片。

02、目录扫描：使用命令dirb http://172.16.33.53:8082/ -R扫描网站的目录和文件，无收获。

03、模糊测试：基于当前已知信息，没有对网站的目录和文件进行FUZZ的必要。

04、信息收集：前面在Firefox访问网站的流量全都走BurpSuite代理，并使用HaE插件分析敏感信息，无收获。

这个报以最大期望的非标端口，竟就这样草草收场了。

80端口/HTTP服务

01、中间件组件：使用命令searchsploit Apache httpd 2.4.，未发现Apache httpd 2.4.38组件的Nday漏洞。

02、应用组件：使用Wappalyzer、FindSomething等浏览器插件自动识别，使用BurpSuite等工具手动识别，均未发现应用组件信息。

01、直接访问：使用浏览器打开http://172.16.33.53/，只有一张竹子的图片。

02、目录扫描：使用命令dirb http://172.16.33.53/ -R扫描网站的目录和文件，发现/cms/目录及其子目录和文件、/info.php文件、/system文件。

02-01、/cms/目录，打开会跳转到http://172.16.33.53/cms/site/页面。

02-01-01、使用Wappalyzer、FindSomething等浏览器插件自动识别应用组件，对于识别到版本的组件，使用searchsploit命令和搜索引擎查找Nday漏洞，未发现可以用于获取权限的漏洞。

02-01-02、直接访问http://172.16.33.53/cms/site/，发现是个静态页面，按钮都是href="#"的伪链接。

02-01-03、逐个访问前面目录扫描发现的/cms/下的子目录和文件，无收获。

02-02、/info.php文件，打开后是phpinfo()`页面，泄露的信息目前没有利用方式。

02-03、/system文件其实是/system/目录，需要HTTP Basic Authorization才能访问，随手测一个admin/admin竟然对了，随后跳转到http://172.16.33.53/system/login_page.php页面，是Mantis Bug Tracker的登录页。

02-03-01、Wappalyzer、FindSomething等浏览器插件自动识别到的应用组件和前面的一样，不再深入排查。

02-03-02、在MantisBT 2.0 Admin Guide^[2]找到默认账号administrator和密码root，但无法登录。

使用BurpSuite的Intruder爆破账号密码，也没有收获。

尝试注册账号进行登录，提示会发送邮件验证邮箱，但这种内网系统，邮件怎么发得出来嘛。

02-03-03、使用命令dirb http://172.16.33.53/system/ -R扫描目录和文件，响应码是401 Unauthorized，咦那刚才爆破Mantis Bug Trackerhttp://172.16.33.53/system/login_page.php的账号密码也没说要认证呀。

重新使用命令dirb http://172.16.33.53/system/ -R -u admin:admin扫描，发现一些目录。

逐个翻看目录，只有/system/config/有点意思。/system/config/目录下的a.txt文件，内容和config_inc.php.sample文件一样，是MantisBT的配置文件，而且有些参数已经配置上了，猜测是曾经用过的配置文件。查看文件大小，a.txt和config_inc.php.sample一样，但是比config_inc.php大很多，所以当前正在使用的config_inc.php有可能未修改账号密码，只是删减了无用的注释和配置。此处先记下MySQL数据库的账号密码mantissuser/password@123AS。

使用收集到的账号密码重新爆破一下Mantis Bug Tracker的登录页，无收获。

03、模糊测试：基于当前已知信息，没有对网站的目录和文件进行FUZZ的必要。

04、信息收集：前面在Firefox访问网站的流量全都走BurpSuite代理，并使用HaE插件分析敏感信息，无收获。

22端口/SSH服务

使用命令searchsploit OpenSSH 7.，未发现OpenSSH 7.9p1组件的Nday漏洞。

使用命令hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt 172.16.33.51 ssh，以及前面收集到的账号密码，都没发现弱口令。

80端口/HTTP服务

通过查看WriteUp，终于取得重大突破。原来是前面用的dirb自带字典不行呀，调查了kali自带的三个URL爆破工具，也就dirsearch可堪大用，看来后面是要弃dirb从dirsearch呀。

使用命令dirsearch -u http://172.16.33.53/扫描网站的目录和文件，除了之前dirb的3个发现以外，还发现了/adminer.php文件。

01、访问http://172.16.33.53/adminer.php发现是数据库管理工具Adminer，使用命令searchsploit adminer未发现Adminer4.7.7组件的Nday漏洞。

02、直接用前面拿到的数据库配置文件a.txt中的账号密码，成功登录Adminer。目的明确，翻库翻表翻字段，翻出两个用户的账号密码，密码哈希值解不开，但是realname怎么这么像密码？使用账号密码administrator/XiBejMub、root/XiBejMub、tre/Tr3@123456A!分别尝试登录Mantis Bug Tracker网站和SSH服务，最终使用tre/Tr3@123456A!成功登录SSH服务。

四、提升权限

tre用户

使用命令sudo -l查看当前用户能以谁的权限执行什么命令，发现能以任意用户的权限执行/sbin/shutdown命令，但在GTFOBins^[3]没查到可用于提权，网上也搜不到利用方式，于是作罢。

使用命令find / -perm -u=s -ls 2>/dev/null查看哪些命令在执行时会以属主的权限执行，还不少，但在GTFOBins^[4]没查到可用于提权，于是作罢。

使用命令find /var/spool/cron/ -type f -ls 2>/dev/null查看计划任务，发现没有，使用命令find /var/spool/cron/ -type f -ls显示报错，原来是没有权限。

使用命令find /etc/*cron* -type f -ls 2>/dev/null查看计划任务，发现还不少，使用命令find /etc/*cron* -type f -ls -exec cat {} ; 2>/dev/null > /tmp/cron.txt转存计划任务，使用命令grep '*' /tmp/cron.txt查看，没发现有引入我们有read和write权限的程序或脚本。

使用命令find / -perm -o=rw -type f ! -path "/proc/*" -ls 2>/dev/null查看other用户具有read和write权限的程序或脚本，如果这些程序或脚本在/var/spool/cron/中被其它用户的计划任务引用，那么我们就能在这些程序或脚本中写入反弹shell，从而获得相关用户的权限。（可能是越权，也可能是提权。）

发现/usr/bin/check-system比较可疑，先将echo里的信息写入系统日志，然后每秒一次不断执行while循环里的命令。使用命令ps -ef | grep -v '['就能验证：很久之前root用户执行过一次/bin/bash /usr/bin/check-system，而while循环里的命令sleep 1是当前时间执行的。

那如果往while循环里写入反弹shell代码，不就能源源不断地接收来自root用户的权限了？但实际上并不会。难道是定时任务的时间周期很长？或者这个脚本压根没被定时任务引用？那到底什么条件下会执行这个脚本？

留意到root用户上次执行/bin/bash /usr/bin/check-system的时间还是将近5小时前，如果是定时任务，那时间周期确实有点久。如果不是定时任务，那触发条件又是什么？使用命令uptime查看系统运行时间，发现也是将近5小时，难道触发条件是系统开机？

刚好我们有/sbin/shutdown的权限，使用命令sudo -u root /sbin/shutdown -r now以root用户的权限立即重启服务器，看下会不会触发root用户执行/bin/bash /usr/bin/check-system。

使用命令nc -nvlp 3353监听反弹shell，最终成功获得root权限，而且退出后再监听还是能获得，果然是源源不断呀。

后记

迫不及待验证/bin/bash /usr/bin/check-system命令是否计划任务执行的，使用命令crontab -l发现root用户没有计划任务，看来不是计划任务执行的，难道是启动项或自启服务？但是使用命令service --status-all查询自启服务，使用命令find /etc/rc*d -ls查询启动项，都无收获，真是奇了怪了。

迫不及待验证前面80 端口/HTTP服务时，第02-03-03小节关于当前正在使用的数据库配置文件的猜想，使用命令cat /var/www/html/system/config/config_inc.php查看，果然未修改账号密码，只是删减了无用的注释和配置。

参考资料

[1]

Tre: 1: https://www.vulnhub.com/entry/tre-1,483/

[2]

MantisBT 2.0 Admin Guide: https://www.mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/

[3]

GTFOBins: https://gtfobins.github.io/

[4]

GTFOBins: https://gtfobins.github.io/

原文始发于微信公众号（OneMoreThink）：靶机实战(10)：OSCP备考之谷安172.16.33.53