最近有个项目,客户需要通过手机app通过机器wifi热点连接,从而实现对机器的设置及视频的实时预览等各种功能。这两天一直在搞rtl8188eu的wifi热点,驱动服务都搭建好了,但是出现设置密码后无法连接,折腾了好几天也没找到原因及解决办法,
wifi热点已经可以正常扫描识别,在设置wpa=0(不采用wpa加密,无需密码可以直接连接)时候,设备可以正常连接到该热点。
F12查看源码发现一个文件名奇怪的js,功能是定时发送请求.
请求内容比较奇怪,猜测就是考点,xxe了.
随便改了下xml,就发生500报错.
尝试了下常见的payload,猜测逻辑,如果xml合法则无返回,xml异常则500报错.
网上翻相关资料,找到关键点
文件不存在,那就找一个linux系统默认存在的,直接去linux全局文件搜索
找一个可以用的,报错xxe成功获取flag
随便测试了一下,发现[[9*9]]中的内容被执行了输出了49.
网上搜索发现了几个可用的payload
然后队内师傅提醒下,直接读文件.
绕过思路和ciscn的一样,就是没回显
百度一下oppo cattch,原来是个手机的宣传语
由于check使用的是read函数,则我们可以直接输入开头的字符串来进行绕过,然后strlen的长度就为0,则后面的strncmp判断必定成功。
之后的漏洞函数中,a1是我们之前输入的第八个字符,如果我们输入\xff时,则在read时a1会进行符号填充,那么我们就可以读入(-1)个字节,这将直接导致栈溢出,之后就行常规的ROP。
第二道签到题,靶机环境是glibc-2.23。
内置一大堆漏洞,这里我用最简单的heap overflow。
在Add_text功能中,size的大小是由用户决定的。
而且由于Text结构的输入没有null截断,我们可以直接泄露libc地址。
因为劫持Text结构体更简单,而且可以实现任意地址读写,我们只需要提前布置好heap 结构就行。
要是能开启PIE并且使用glibc-2.23.so的话,相信能成为更优质的挑战。
程序流还是非常清晰明了的。
在Free功能中,虽然将malloc_ptr置为0,但是并没有将ptr_array置为0,则我们可以直接输入index为0,这样会直接导致double
修改stdout结构体为了泄露地址信息
一般在有PIE的情况下,我们需要利用chunk残余的fd和bk来对stdout的地址进行爆破,但是这里没有PIE,而且stdout的地址就在bss段上,我们可以直接利用tcache
byte,而且修改stdout地址的话,调用printf函数时会发生阻塞现象,所以我们只能爆破对程序基本没有影响的stderr的地址了,下面的代码功能就是爆破bss段的stderr的地址的低二位字节,使其指向stdout->_IO_write_base的地址,这里是1/16的几率。
之后将地址指向我们要泄露的信息,通过调试可得:
其实漏洞非常简单,只不过其中大量的结构体一开始就吓跑了很多人,刚开始看到这么复杂的结构体我自己也吓了一跳,但是随着仔细的分析,程序慢慢变得简单。
下面是程序要用到的结构体:
这是我乱打payload无意间发现的,下面是我的payload:
分析了Handle功能之后,发现其三个结构都有一个致命的UAF漏洞。
在Handle功能中,处理的数目是由用户来确定的,但是当number为0时,悲剧就发生了。
由于源程序代码复杂功能简单,所以脚本我也就写的简单一点。
由于使用的calloc函数,它不会从tcache里面拿chunk,所以我们必须要先绕过tcache,方法也很简单,就是不停的free就行。
这里需要进行利用realloc来进行栈调整,才能执行one gadget。
题目给了一个压缩程序,但是没有相对应的解压程序,还给了一个压缩过的文件,要求我们根据分析压缩程序的算法写出相对应的解压程序即可。
根据IDA还原的算法源码:
通过下面测试,已经和原先的程序行为基本一致:
分析代码可得,这是一个根据重复字符来压缩的算法,但是其长度和举例都是有限的,其长度是17,也就是byte_202040的长度,而最大距离则正好是buf的0x1000。
buf为该压缩算法的缓冲区,大小为0x1000,其压缩的目的也主要取决于该缓冲区。
这是一个按位压缩的算法,从compress函数的上面代码可知,该协议分为标志位和携带内容,当标志为1时,其协议长度分为9 bit, 第一个bit为标志位,后面八个bit为一个字符。
当标志为0时,其协议长度分为17 bit, 第一个bit为标志位,然后12个bit为buf缓冲区的地址,然后4个bit为重复的次数,在解压的时候直接将其复制过来就行,这里主要是压缩重复的字节流。
只要知道压缩原理之后,只要按照其协议解压即可。下面是我写的解压程序:
之后用该程序进行解压,可以获得一张图片,flag就在图片里。
本文为安全脉搏专栏作者发布,转载请注明: