靶场实战(11)：OSCP备考之VulnHub Insanity 1
靶场思路
主机发现
端口发现（服务、组件、版本）
漏洞发现（获取权限）
21端口/FTP服务
组件漏洞
口令漏洞
22端口/SSH服务
组件漏洞
口令漏洞
80端口/HTTP服务
组件漏洞
URL漏洞（目录、文件）
提升权限
elliot用户
sudo
suid
cron
内核提权
信息收集
一、主机发现
本次靶场是Insanity: 1[1]，指定目标IP，不涉及主机发现过程。
二、端口发现（服务、组件、版本）
使用命令sudo -u root nmap 172.16.33.55 -n -Pn -p- --reason -sV -sC -O，发现主机开放的端口、提供的服务、使用的组件、组件的版本。
开放的端口 |
提供的服务 |
使用的组件 |
组件的版本 |
21/tcp |
ftp |
vsftpd |
3.0.2 |
22/tcp |
ssh |
OpenSSH |
7.4 |
80/tcp |
http |
Apache httpd |
2.4.6 |
- |
os |
CentOS Linux |
？ |
三、漏洞发现（获取权限）
21端口/FTP服务
组件漏洞
使用命令searchsploit vsftpd 3.，未发现vsftpd 3.0.2组件的Nday漏洞。
口令漏洞
使用命令ftp 172.16.33.55连接FTP服务，使用匿名账号anonymous和空口令登录。使用命令ls -la查看文件情况，没有发现文件，使用命令bye退出FTP服务。
使用命令ftp 172.16.33.55连接FTP服务，使用前面nmap发现的ftp账号和空口令登录。使用命令ls -la查看文件情况，没有发现文件，使用命令bye退出FTP服务。
22端口/SSH服务
组件漏洞
使用命令searchsploit OpenSSH 7.4，发现组件OpenSSH 7.4存在3个用户名枚举的EXP。
使用命令searchsploit -m EXP的ID将EXP拷贝到当前目录，发现3个EXP都是同一个漏洞CVE-2018-15473，其中2个EXP还是已经被验证过的。那么策略就是用这2个被验证过的EXP打一下，成就成，不成就算了。
使用命令grep print 45233.py | head -n 1发现print语句没有括号，所以45233.py脚本是用Python2编写的。使用命令python2 45233.py获得参数--userList USERLIST hostname，基于参数构造命令python2 45233.py --userList ../SSH/ssh_user.txt 172.16.33.55枚举用户名，发现一堆报错，于是决定放弃。
使用命令grep print 45210.py | head -n 1发现print语句没有括号，所以45210.py脚本是用Python2编写的。使用命令python2 45210.py获得参数hostname username，看来不能用字典，只能一个个用户名枚举，或者for循环枚举。基于参数构造命令python2 45210.py 172.16.33.55 root枚举用户名，发现存在root用户。但我敏感的职业嗅觉告诉我小心有诈，通过命令python2 45210.py 172.16.33.55 onemorethink发现存在onemorethink用户，看来EXP有误报。
口令漏洞
使用命令hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt 172.16.33.55 ssh，未发现弱口令。
80端口/HTTP服务
组件漏洞
01、中间件组件：使用命令searchsploit Apache httpd 2.4.，未发现Apache httpd 2.4.6组件的Nday漏洞。
02、应用组件：使用浏览器插件Wappalyzer自动识别应用组件，发现Popper和lsotope比较陌生。
使用命令searchsloit popper发现Popper组件存在3个EXP，经了解原来是Popper网页邮箱的漏洞，不是这里Popper.js脚本的漏洞。
使用命令searchsploit lsotope以及网上搜索，未发现lsotope组件的Nday漏洞。
通过浏览器浏览的方式，发现网站是基于Colorlib主题搭建的，搜索相关漏洞只发现XSS漏洞，需要有人点击触发，这种靶机没人给你点。
URL漏洞（目录、文件）
01、直接访问：浏览器打开http://172.16.33.55/，发现相关按钮都是href="#"的伪连接，是个静态网站，没有漏洞点。
02、目录扫描：使用命令dirsearch -u http://172.16.33.55/ -x 403扫描网站的目录和文件，有不少收获。逐个打开浏览一遍，发现/monitoring/login.php文件、/news文件、/phpmyadmin 文件、/phpinfo.php文件、/webmail文件等还挺有意思。
02-01、SquirrelMail：打开全部文件，其中/webmail文件打开后会跳转到/webmail/src/login.php，映入眼帘的SquirrelMail version 1.4.22直接击中灵魂。
02-01-01、使用命令searchsploit SquirrelMail 1.4.22，发现SquirrelMail 1.4.22组件存在远程代码执行漏洞。使用命令searchsploit -m 41918将EXP拷贝到当前目录，发现EXP没被验证过。使用命令vim 41910.sh进行代码审计，未发现脚本中存在恶意代码，同时获得了脚本参数，但也发现脚本需要网站的账号密码才能执行。构造参数执行命令./41910.sh http://172.16.33.55/webmail/src/redirect.php，果然需要网站的账号密码才能执行。
因为SquirrelMail是个邮件系统嘛，猜测账号可能是邮箱，所以打开http://172.16.33.55/news/的时候，映入演练的邮箱[email protected]再次击中灵魂。
使用BurpSuite的Intruder爆破该邮箱的密码，结果是全都响应Unknown user or password incorrect.，真是有心栽花花不开啊。
02-01-02、转战到http://172.16.33.55/monitoring/login.php，又是登录框，这次爆破个啥呢？
刚才被http://172.16.33.55/news/击中灵魂的时候，心情大好，读了下news，发现姓名Otis，试下爆破他吧。
使用BurpSuite的Intruder功能，和字典/usr/share/seclists/Passwords/Common-Credentials/best110.txt，爆破出Monitoring的账号Otis和密码123456，并成功登录Monitoring网站。
人逢喜事精神爽，竟然爽到想试一下SquirrelMail的账号会不会也是Otis。继续用BurpSuite的Intruder功能，和字典/usr/share/seclists/Passwords/Common-Credentials/best110.txt，爆破出SquirrelMail的账号Otis和密码123456，并成功登录SquirrelMail网站，真是无心插柳柳成荫呀。
再次使用命令./41910.sh http://172.16.33.55/webmail/src/redirect.php执行远程代码执行漏洞的EXP，提示Failed to upload the sendmail file.。
使用命令vim 41910.sh进行代码审计，发现EXP/tmp/smcnf-exp有成功下载，只是上传失败。查阅SquirrelMail远程代码执行漏洞[2]，可能是SquirrelMail的MTA没有设置成Sendmail，或者edit_identity没有设置成true。
翻找整个SquirrelMail也没找到配置项，应该是要后台配置。翻找SquirrelMail里的邮件，是空的，看来不仅RCE不行，信息泄露也不行，难道SquirrelMail这条路是断了？
02-02、Monitoring：回到Monitoring，发现是个网络拨测网站，如果网络不通就会发送告警邮件。既然我们在Monitoring和SquirrelMail都拿到了用户Otis的账号密码，那么我们在Monitoring拨测的地址，如果网络不通是否就会给SquirrelMail发送告警邮件？前台没有配置页面，看不到是否配置了Otis作为告警邮件接收邮箱，可能要在后台或配置文件配置，我们实际测试一下，发现猜想正确。
如果是用ping来拨测的，那最常见的漏洞不就是命令注入嘛。既然是网络不通才会发送告警邮件，那就构造payload169.254.1.1;id看看是否存在命令注入漏洞，结果告警邮件还是一样，没有带出命令执行结果，难道不存在命令注入漏洞。
那么告警邮件中的HostOneMoreThink，应该是Monitoring在发送告警邮件时，去数据库查出来并写到邮件正文的吧？那最常见的漏洞不就是SQLi和XSS嘛。先试一下价值比较大的SQLi漏洞，构造单引号闭合的payloadOneMoreThink'，结果告警邮件没啥异常。
构造双引号闭合的payloadOneMoreThink"，结果告警邮件发不出来了，Monitoring是每分钟发送一封告警邮件的，但现在已经12:32了，告警邮件还停留在12:26。应该是Monitoring在发送告警邮件时，去数据库查询Host Name时报错了所以查询失败，导致整个发送告警邮件的任务都失败了。太好了，发现SQLi漏洞。
那就拖数据吧，先看看是啥数据库，前面发现的页面/phpinfo.php可算派上用场了，查看PDO发现用了MySQL和SQLite数据库，那就先试试MySQL的information_schema吧。
需要注意的是，在Monitoring中点击Modify会返回Error，BurpSuite抓包查看发现Host Name OneMoreThink"的双引号被去掉了，在BurpSuite的Repeater中补上双引号，然后在浏览器中打开修改后的请求或响应，就能成功进入拨测任务编辑页面啦。
02-02-01、SQLi第一步，确定查询语句的字段数量。使用payload" order by 2#时告警邮件还能正常发出，看来至少有2个字段。
继续往上尝试，看来至少有3个字段。
继续往上尝试，到5的时候终于发不出告警邮件了，Monitoring的告警时间已经是13:24了，但是SquirrelMail的告警邮件还停留在13:21，看来查询语句的字段数量是4。
02-02-02、SQLi第二步，确定查询语句各个字段的数据类型、以及哪些字段会有回显。好家伙，4个字段全部都是字符串类型、而且全部都有回显。
因为告警邮件中Date Time加了双引号，所以不会是日期和时间类型，只能是字符串类型了。而ID和Status倒有可能是数值类型，所以这里4个字段全部都是字符串类型，还真是情理之中意料之外啊。
值得一提的是，经验丰富的人应该能够直接猜到：查询语句至少查询了4个字段，并且至少4个字段会有回显。因为告警邮件中的ID, Host, Date Time, Status就是4个字段。
02-02-03、02-02-04、SQLi第三第四步，爆库爆表。使用payload" union select 1,2,table_name,table_schema from information_schema.tables#，成功从information_schema库的tables表中读出数据库的所有库名和表名。