题目很好玩,为QEMU模拟运行的x86简易裸机系统,和目标的交互方式只有ping,漏洞为ICMP栈溢出,无任何防护手段,最终通过shellcode将flag塞回到ICMP的reply报文中并重新计算ICMP校验和完成带出。
StarCTF 2022 AArch64 kernel Pwn babyarm
aarch64:linux5.17,一个存在栈溢出漏洞的ko。我的利用方法为通过ROP调用set_memory_x开启内存的执行权限然后在内核态执行shellcode,shellcode中使用了读文件的内核函数并把flag存到寄存器中,然后主动触发崩溃,打印的崩溃现场寄存器会把flag泄露出来。
JTAG 开启 判断
更新中…
感染ko:在linux内核模块中植入代码
本是想将目标代码运行在一个已有root shell并支持insmod的设备内核态中,具体底座为 arm:linux3.18.71,并不是要搞Rootkit。但直接去编译对应内核版本的ko(内核模块)在insmod时会发生崩溃,而他自带的ko却可以正常insmod,后排错一天无果。故不得已才想到可以将目标代码揉进他自带的ko中,这个行为无意间就和Rootkit保持一致了,即感染ko。说酷炫点是感染,其实就是patch,本以为和patch用户态ELF一样简单,在ko的.init.text段糊上目标代码就完了。但没想到ko外部符号重定位的实现方法,居然是内核直接根据符号信息修改ko代码本身。所以我糊上的代码,就有可能由于ko原有的重定位信息被内核改的乱七八糟。最后我通过直接删除ko中重定位section的方法,将代码固定在了ko中并可以被稳定执行。
HITCON 18 Super Hexagon(1/2)
HITCON18的 ARM64/32 系统Pwn题,总共6关,目前打到第3关。最近要忙毕设,所以估计后三关得过几个月才能打完了。此题相关内容都在:https://github.com/xuanxuanblingbling/SuperHexagon中,详解为superhexagon.pdf。
IoT 正向开发:iMX6 开发板 选型
最近需要使用一个通信模组的SDK,其运行在嵌入式linux上,包括了设备树和内核的patch、驱动、用户态库和可执行程序等,文档中说明其适配了i.MX6QSABRESD(ARM32)。我知道市面上有非常多的iMX6的开发板,作为练习IoT正向开发的开始,我希望自己编译uboot、linux运行在板子上,然后探索其中的道理。同时也是为了在使用SDK的过程中,能更好的排错。我先后体验了四家公司的开发板,分别是:百问网、迅为、飞思卡尔、野火。本以为很容易,没想到的是,倘若是怀着探索实现原理心态去看一些的开发板教程,那真是如此的令人费解。所以本篇的选型,说的不是性能,而是在我踩坑的过程中,看到了谁家的开发板能让学习者对计算机看的更透,更清楚。
ByteCTF 2021 AArch64 shellcode exsc
赛后和王皓共同完成,目标为AArch64纯字符shellcode,认真看论文把编解码器抠出来即可。赛时没做出此题着实该反思。
ByteCTF 2021 AArch64 Pwn Master of HTTPD
AArch64:libc2.27:ubuntu18.04,题目是在mini_httpd的baisc认证处塞了个栈溢出,远程不是qemu-user,应该是真机,所以不能直接ret2shellcode。故必须要ROP,使用AArch64通用gadget调用mprotect,再shellcode即可。
ret2csu __libc_csu_init 这段 通用 gadget 的本质道理
一段C级别的源码,编译在不同指令集上,最终功能一致,这固然理所应当。但它却能做到在汇编层面,以黑客ROP视角的高度统一,使自己能够跨越不同指令集成为真正的通用gadget,仔细想想会觉得很神奇,再多想一点可能会感到暗藏杀机。
L3HCTF 2021 MISC bootflag
破解新版本AMI的BIOS密码,其实就是存储在flash的nvram区中的一个SHA256。
L3HCTF 2021 MISC a-sol
需解密IPMI协议的流量,此协议运行在服务器的BMC(Baseboard Management Controller)上,可理解为独立的小核,可能实现为arm:linux等,用于带外管理,如远程装机等操作。虽然通信过程中,有认证,有加密,有完整性保护,但此协议本身设计的并不足够安全,导致在捕获到合法用户的认证流量后,可对其登录口令进行离线破解,最终解密其通信流量。
为啥路由器的WAN口不好打?
你猜?
凯韬教我GDB:下划线的堆调试
在GDB中可以使用p或call指令调用进程内存中的任意函数,这并不新奇,但用此法直接去调函数调试堆,则需要调用一套带下划线的函数: __libc_malloc()、__malloc()、__libc_free() 、__free() ,而不能直接用malloc()、free(),这是为什么呢?
和徐老一起学Pwn 之 Pwnable.tw CVE-2018-1160
和徐老一起完成,HITCON2019时为netatalk的1day,漏洞是由于memcpy长度没限制导致的越界写,可覆盖关键变量,最终可导致有一次任意地址写,主要挑战为绕过ASLR。由于程序通过fork出一个子进程来处理每一个连接,所以在任意地址写时,可从低到高逐字节的覆盖并爆破原本的合法地址。比较麻烦的是,因为没有和Pwnable远程题目一模一样的环境,所以从合法地址到libc基址仍需要再爆破一次。最后通过覆写位于ld.so数据段_rtld_global结构体,并在程序超时退出时(远程tcp close后需要三分钟),完成控制流劫持并反弹shell。
Netgear PSV-2020-0432 / CVE-2021-27239 漏洞复现
漏洞位于/usr/sbin/upnpd,是ssdp(UDP 1900)协议的解析过程中,对MX字段的strncpy引发的栈溢出。由于是字符串拷贝,最终的利用方法仍与 PSV-2020-0211 一致,采取栈迁移的方法规避空字符截断。具体来说就是先把带00的ROP链打上栈,然后再触发栈溢出,用 ADD SP, SP, #0x800; POP {R4-R6,PC} 这种gadget完成栈迁移并将控制流打到ROP的gadget上。
使用 VMware 调试功能 观察 x86_64 虚拟机 的 特权寄存器
在misty的帮助下完成,方法是使用由VMware提供的自定义gdb命令:monitor来查看特权寄存器,如 monitor r cr3。其实叫特权寄存器并不准确,其主要包括了x86的控制寄存器和系统地址寄存器,但又没有很好的统称,故就按照其属性:只能由运行在ring0级别的特权指令来操控,统称他们为特权寄存器。查看特权寄存器的目的,是为了更彻底的理解操作系统。
新版本 binwalk 无法提取 ELF 文件 的 解决办法
最近发现自己的binwalk在提取一些直接包裹在其他数据中的ELF文件时失效,但是识别是有结果的,一顿折腾最新版本还是不行,但发现用老版本就可以正常提取。经过分析,最终找到了问题的根源,新版本的默认提取规则配置文件:extract.conf,把单个ELF提取的规则给注释了…
0CTF / TCTF 2021 final - Secure JIT II
和xkt共同完成,题目是一个用python3运行的简易python解释器,可以任意地址写,读内存的功能被patch了。比赛时因为没发现ubuntu18.04默认的python3是没开PIE且GOT表可写的,所以采取了野蛮的解法:任意地址写,可以泄露栈地址,所以直接写栈上的main函数返回地址为one_gadget,复用main函数返回到的libc_start_main地址的高字节,写低三字节,需要爆破1.5字节,概率为1/4096。
长城杯 2021 Pwn
许久未见我这水平能做的堆了…
树莓派3B底层玩法:OP-TEE、Kernel module、JTAG
当年买树莓派的时候是为了研究ARM底层一些东西,比如Linux内核、JTAG、TEE啥的,却没成想配到的书籍都是教你用一些封装好的python库控制树莓派的GPIO,以控制外部一些简单的零部件、传感器啥的,很是失望,然后就把树莓派扔到一遍,买了讯为的4412开发板。后来随着自己平日研究的深入,还有也是遇到了纽创,发现其实树莓派可以胜任这些底层的学习与研究,只不过相关中文资料虽然有:从底层玩转树莓派,但是很少,也就更不会作为树莓派商家的配套教程了。本文按照前辈wellsleep之前的工作,构建了一个:① Ubuntu18.04和OP-TEE的混合系统 ② 并可以正常编译内核模块 ③ 开启了JTAG 的树莓派3B镜像。对未来的ARM底层研究,搭建好了一个可以调试的真实环境。当然学习ARM底层可以用qemu完成,但还是感觉在真实设备上更踏实。(我一直以为我手中的设备是3B+,经过网友提醒发现是3B…之前坑人了,对不起大家…)
TOTOLINK MESH系列路由器 telnet 开启分析
本文是徐老文章:物联网设备消息总线机制的使用及安全问题中TOTOLINK的MQTT业务的具体分析过程,由一个开启telent的功能出发,逆向分析出设备业务的处理过程,最终定位到漏洞挖掘的目标。意在强调对于设备的业务逻辑逆向过程,类似强网杯 2021 线下 RW Mi Router。
用忽略configure的方式 交叉编译 静态链接 的 tcpdump
在开源软件的编译过程中,一般都是先使用configure检查编译环境并生成makefile,然后使用make进行编译。但是对于IoT安全研究来说,经常要遇到两个坎,一个是交叉编译,一个是静态链接。如果是单个c代码文件,类似shellcode或者后门,使用相应的交叉编译工具,在加上 -static 参数直接编译就好了,可是对于一个有configure以及makefile的软件,我们该怎么跨过这两个坎呢?一般的交叉编译都是在configure处做一系列的配置,这个配置虽然方便,但却令人困惑,我们配置的那些变量到底在哪生效的呢?如:交叉编译+静态编译。不过,最终编译还是makefile的事,所以其实可以在某些比较简单的情景下,直接忽略configure。由于make的命令行参数优先于makefile文件中的变量,所以可直接在make命令后加相应的参数,进而完成交叉编译和静态链接。本篇采用这种奇怪的方法,编译出5种架构(x86_64,arm,aarch64,mips,mipsel)下的静态链接的tcpdump程序。
linux 内核 初探:运行你代码在内核态
正向开发是理解一个复杂系统的必要过程,我们熟悉linux用户态的Pwn,是因为随手就能写出一个helloworld,然后编译、运行、逆向、调试一条龙,进而理解它完整的生命周期。linux内核Pwn的文章有很多,不过大都是以完成一道题目的视角行文的。而本文希望,我们能熟悉内核态的代码的运行状态,具体来说就是:在 ubuntu20.04 (linux 5.11.0-25) 的本机环境下完成 ① 正向开发:将我们的代码送进内核态运行,了解有哪些可以使用的内核函数,基于这些函数实现一些功能。② 内存调试:使用log大法看到内核的内存。③ 内核本体:不同于源码视角,我们要找到内核二进制代码本体,认识一下。
强网杯 2021 线下 RW Mi Router
这题淼哥基本写的差不多了:QWB-2021-Final:RealWorld MiRouter WriteUp,补充些淼哥没写的:设备串口开SSH、eCos业务分析、流量分析、多人策略、只开一个窗口的exp。另外今年的文章省去了一些基础操作,如果想看新手教学可以看去年的:思科路由器 RV110W CVE-2020-3331 漏洞复现。与去年相比这次没有考察二进制漏洞的利用,而是一个命令注入漏洞点的触发路径分析,明年再来一个和云侧、app侧结合的,后年再来一个从空口打的,这样IoT的大面就基本考全了。
0CTF / TCTF 2021 tile
Tile-gx指令集的linux用户态程序,除了qemu-user可以运行这个程序以外,没有任何的辅助工具,并且该架构的
qemu-user
即qemu-tilegx
没有实现-g
的调试功能。所以其他工具(逆向、调试、编译shellcode)全部要自己找到或者搞定,做题时找到并且编译了这个架构的gdb客户端和交叉编译工具,以及对qemu源码魔改了一个此架构下能读写寄存器的gdb桩。运行发现,此程序的功能是以标准输入输出为接口的httpsevrer。有了查看寄存器的能力后,即对此程序瞎发包进行测试,最终在basic认证处发现了不确定是不是栈溢出的控制流劫持。因为是qemu-user,没有NX,还给了和远程环境一样的docker,故ret2shellcode即可。比赛时这题只有More Smoked Leet Chicken
和我们Redbud
做出来了,老外的解法更正统和出色。
用 西湖论剑IoT闯关赛 蓝牙赛题 理解 蓝牙协议
虽然之前总结过:关于蓝牙的漏洞研究,但对于蓝牙还是很懵,因为从来没有实践过,西湖论剑IoT比赛时,蓝牙的题目一个也没做出来。每次看到蓝牙都不知道在说哪一层的协议,看到wireshark抓的包也感觉之前看的蓝牙包不长这样啊。这次经过一段时间的研究,才大概的明白:(1)蓝牙的协议栈之所以复杂,是由于历史的变迁,以及兼容性的考虑,导致出现了(老的)经典蓝牙和(新的)低功耗蓝牙并存复杂的协议栈,单独来看这新老两个技术的协议栈,都没有很复杂,并且其结构都是很清晰的。(2)蓝牙的数据包在其从用户程序发送到空中的过程中,封包并非如TCP/IP协议仅仅将上一层的数据进行简单的封装就传递到下一层,相邻层之间的数据变换可能比较复杂,于是就导致了由于抓包的层次不同,看到的同一过程的数据的组织方式是不同的,典型就是在空口抓包以及在HCI层抓包。(3)另外以西湖论剑的三道蓝牙题目为例子,总结了主机控制蓝牙不同层次的收发包工具以及背后原理。
armv5l 稳定 shellcode:shell reverse tcp (Null free)
最近需要在一个采用了海思解决方案HI3518 CV100(armv5l)的设备上打一个反连并且没有空字节的shellcode,但是网上直接找shellcode大部分都是在armv7l上测试成功的,能够在armv5l的指令集上兼容的shellcode并不多。并且设备上的busybox的启动sh时,execve的第二个参数也必须布置好,否则会启动失败,网上的大多shellcode第二个参都是直接0。最后拼接了两位前辈(rtmcx、Ken Kitahara)的shellcode,并在HI3518 CV100、 Allwinner F1C200s上测试通过。
栈溢出时发现了00截断,应该怎么办?
IoT设备上出现的真实内存漏洞大多都是对字符串操作不当所引发的,于是就必然会出现对于空字符的截断,进而导致我们的利用变得异常艰难。不过即使如此,黑客也可以使用各种花了呼哨的手段来完成利用。以下整理:由于字符串操作引发的栈溢出时,可以考虑的利用方法。
CTF Pwn 题中 libc 可用 函数指针 (攻击位置) 整理
更新中…在内存破坏漏洞的攻击过程中,攻击者的最终目标一般来说是控制流劫持。如果攻击者能获得一个任意地址写(aaw)的能力,则之后的需要做的就是修改的在间接跳转过程中被使用的关键数据。首先能想到的就是函数指针,因为其内容就是间接跳转的目标地址。另外还有可能是对间接跳转的起着间接影响的数据,比如多级指针、数组索引等,不过落到最后仍然是函数指针。攻击大流程走到这步,攻击这个动词的宾语就变成了某个数据、变量、内存位置,比如攻击
__free_hook
。本文对CTF Pwn题中 常见的 位于libc中的 可以被攻击者利用进行控制流劫持的 函数指针 以及 触发方式 进行了整理。
CTF Pwn 题中 目标本体ELF 可用 函数指针 (攻击位置) 整理
对CTF Pwn题中 常见的 属于目标程序本体中的 可被攻击者利用进行控制流劫持的 函数指针 以及 触发方式 进行了整理。
虎符 2021 线下 PKS体系攻防实战 Kysec 机制绕过
这次运气不错,因为PKS的题目,Redbud包揽此次比赛的所有头奖。PKS的含义是:Phytium(飞腾CPU) + Kylin(麒麟OS)+ Security(安全能力),是我们国产自主化的一套体系。题目是突破它的安全机制,包括用户态强制访问控制机制Kysec,安全内存模组HSDIM-Lite以及安全启动。我打的主要是Kysec,就还是主要鼓捣用户态这套东西,从头打到尾发现并利用了五个洞:进程的
/proc/pid/mem
可被同用户读写、进程允许被同用户ptrace
、安全机制仅在启动前检查程序是否合法、交互式python允许未校验的python代码执行、一个后装程序的root进程的命令注入。
虎符 2021 Pwn apollo
aarch64:libc2.27,主要难度在逆向,根据提示,题目是个可以开车在地图(一个堆空间)上移动的程序,构造地图上的红绿灯,可以让车开出地图(堆上越界写)。由于自己逆向比较菜,只设计出了一个溢出单字节的地图,不过也够用了,相当于off-by-one。利用方法为:构造堆块重叠修改tcache块的fd,在malloc回来即可完成泄露libc与任意地址写,最后修改__free_hook为system即可getshell。
纵横杯 2020 线下 Pwn
三道Pwn,比赛时均没有写出利用,看出并修上两个题的洞,另外一个没看出洞,当然也没修上。
HWS 2021 结营赛 Pwn
更新中…结营赛还有非常多值得探索的东西
IoT安全研究视角的交叉编译
IoT安全研究员使用交叉编译的主要目的,就是编译一段能运行在目标嵌入式设备上定制的恶意代码,以达到我们邪恶的目的。根据目标情景的不同,编译前的工具选择、编译中的参数设置、编译后的成品形态也不同。如果目标是linux,那我们的目标成品一般有三种形态:可执行ELF,动态库so,以及用于内存破坏漏洞的shellcode。如果是非linux,则可能是一段shellcode,甚至是整个固件。本文介绍了交叉编译工具本身,获得这些工具的办法,以及针对以上不同目标的编译方法。
HWS 2021 入营赛 Pwn/固件/内核
本次入营赛时长4天半,仍然由安恒承办,赛题只有四类:固件、内核、逆向、Pwn。对于二进制选手足够友好,其中固件题目与IoT实战结合紧密,难度总体来说不大,入门友好型赛题。自己在比赛中也学到了很多东西,最终AK了Pwn和固件,内核和逆向分别做出来最简单的一个,总成绩排名第二。
StarCTF 2021 RISC-V Pwn Favourite Architecture
题目底座为
riscv:rv64:libc2.27:ubuntu18.04
,漏洞是该用户态程序栈溢出。不过远程环境是patch过的qemu,其功能限制了模拟程序去执行特定的系统调用,即没有riscv:rv64执行层面的execve。Pwn题总共两问:(1)读文件(2)Getshell。读文件就正常写orw的shellcode,本文也着重练习了shellcode的制造流程。Getshell的解法是:因qemu-user对模拟起来的代码访存隔离不完全,导致qemu-user模拟的程序可以直接修改qemu-user本体进程的内存,最终导致可以直接在qemu-user本体进程(x86_64层面)上Getshell。比赛时抢了第一问的一血,也是人生第一次xctf的一血,后在煜博的提示下解出第二问,感谢煜博。
python 负数 和 任意位数 补码 互转
对于补码,最简单的理解是最高位的权值是负数,而不是取反加一。
思科路由器 RV130W 中 ARM:uClibc 的 ROP寻找
在思科的RV130W路由器,因为字符串拷贝存在许多栈溢出漏洞,故利用时要考虑到空字符截断,一般来说存在这种限制条件的漏洞是不容易利用的。但不知为何,在思科这个系列的路由器中,进程加载动态库的地址是固定不变且位于高地址的,故可以通过各种动态库中的gadget来完成整个漏洞的利用,这里抽象出一道练习题进行练习寻找ROP的过程。
XCTF华为鸿蒙专场 HARMOFS01
更新中…
XCTF华为鸿蒙专场 ARM Pwn1
栈溢出,ARM题目的一般环境是QEMU用户态,默认不支持NX,故直接ROP+栈迁移然后写shellcode即可。
XCTF华为专场 三道RISC-V Pwn
更新中…没有一道题是看出洞来,因为没工具不会看,全是手测然后调出来的…
纵横杯 2020 Pwn wind_farm_panel
house_of_orange原题
JAVA 后门 shell_reverse_tcp 实现
遇到情景是可以在android上安装任意apk,执行apk后有个反弹shell的效果。一般来说直接用msf就可以生成android后门,但不知为何在目标设备上无法正常使用,故决定自己编写一个简单的apk以完成反弹shell。最终实现三个纯JAVA版的shell_reverse_tcp,当然塞进apk也好使。开始自己完成了一个无法完全交互的shell,类似一句话木马那种伪tty。因为思路也是web的思路,执行->取结果字符串->发送结果字符串。后来参考msf的实现,人家是使用线程直接转发了启动shell的输入输出流到反弹的socket的输入输出流,不仅可以获得一个完全交互的shell,还省去了byte流转字符串的操作。这个其实就是和shellcode的思路一样了,类似dup socket的文件描述符到程序的输入输出流中。二者最重要的区别就是执行顺序上,因为自己对线程不熟,没有想到转发的过程其实是持续的,是伴随着我们对后门的操作的。也是因为自己的编程水平还停留面向过程的1234,不容易想到多个实体一起执行的情景,想的总是执行完第一步,然后第二步…最后找到一个单线程死循环获得完全交互shell的写法,通过判断输入流是否可用来进入转发,是目前看到的最短实现。
CTF中常见的C语言输入函数截断属性总结
函数 | 截断字符 | 截断属性 | 截断字符是否保留 | 截断后加 |
---|---|---|---|---|
read(0,a,0x100) |
EOF | 无 | 无 | 无 |
*a = getchar() |
EOF | 无 | 无 | 无 |
scanf("%c",a) |
EOF | 无 | 无 | 无 |
scanf("%s",a) |
EOF 0x09 0x0A 0x0B 0x0C 0x0D 0x20 | 截断字符前有有效内容则截断,如无有效内容则跳过截断字符读后面 | 不保留 | 0x00 |
sscanf(a,"%s",b) |
0x00 0x09 0x0A 0x0B 0x0C 0x0D 0x20 | 截断字符前有有效内容则截断,如无有效内容则跳过截断字符读后面 | 不保留 | 0x00 |
gets(a) |
EOF 0x0A | 截断字符前无论有无有效内容均截断 | 不保留 | 0x00 |
fgets(a,256,stdin) |
EOF 0x0A | 截断字符前无论有无有效内容均截断 | 保留 | 0x00 |
sscanf(a,"%[^;];",b) |
0x00 0x3B | 无 | 不保留 | 0x00 |
sprintf(b,"%s",a) |
0x00 | 无 | 保留 | 无(相当于截断字符不保留,截断后加0x00) |
strcpy(b,a) |
0x00 | 无 | 保留 | 无(相当于截断字符不保留,截断后加0x00) |
strcat(b,a) |
0x00 | 无 | 保留 | 无(相当于截断字符不保留,截断后加0x00) |
strncat(b,a,0x10) |
0x00 | 无 | 保留 | 无(相当于截断字符不保留,截断后加0x00) |
strncat(b,a,0x10) |
到达拷贝长度 | 无 | 保留 | 如果到达拷贝长度,则自动补上0x00 |
Getshell稳定:命令注入 > 内存破坏
不要瞧不起命令注入,因为你不得不承认,命令注入型漏洞就是要比内存破坏型漏洞要稳。在实际的攻击中,我们发现的漏洞代码的运行实体可能是单蹦儿的一个进程,也可能是某个进程的一个线程。如果攻击发生在某个线程中,对其他线程,以及线程所属的进程会不有影响呢?在这种情况下,内存破坏漏洞的表现怎么样呢?
Getshell动作:system与execve的原理与异同
命令注入本身就是system函数,内存破坏漏洞的利用如果想获取shell,控制流劫持后也无非是system和execve,那么这二者又有什么区别呢?当你控制流劫持,并成功的getshell后,你可想过,被你打的漏洞进程,他现在过的怎么样了呢?
Getshell远程:真·RCE 正连?反连?不连?
真实的网络程序和Pwn题目中把输入输出映射到网络端口,二者程序本体的交互接口显然是不同的,后一种的CTF题目,真的具有现实意义么?如果是真的网络程序,我控制流劫持后直接执行system(“/bin/sh”)可以拿到shell么?如果不能,我如何才能Getshell呢?本篇我们通过一个例题回答上述问题。
Getshell载荷:payload的量级
Getshell的背后就是代码执行,执行的是shell程序,并且此进程的输入输出可控。不过由于漏洞位置不同,输入点不同,达到Getshell目标的攻击载荷也不同。可以按照攻击载荷的量级来对payload进行分类,个人分为如下四类:shellcode,ELF,param,command。
Getshell尾声:盗取与操控
黑客费尽心机Getshell后,有危害的(在现实的生活中产生恶意影响)最终意图无非两种,盗取和操控,其中操控无非是软件或者硬件。比如CTF就是盗取flag,三体中killer5.2病毒对罗辑的刺杀就是操控各种外部硬件。当然操控外部硬件的意图可能仍然为盗取,比如操控门锁打开,则最终意图是入室行窃。总之,这些事可以概括的称为:后渗透。
后门加密通信分析:ByteCTF 2020 Final MSF6 android/meterpreter_reverse_http
后门通信分析,比较容易的是Metasploit是开源的,故可以直接分析其后门工具meterpreter,以及对端的后门程序的源码。发现新版MSF6中的meterpreter与后门程序通信是使用了RSA和AES,即后门程序使用攻击者发过来的RSA公钥对之后通信的AES秘钥进行加密,此AES秘钥由后门程序随机生成,所以正常情况下应该是无法解密其双方通信的。但题目中公钥给了个可以被分解的素数,导致通信可被破译。另外对于密码算法的操作非常陌生,解题过程中感谢楚涵和gml的帮助。
后门加密通信分析:HITCTF 2020 Godzilla
通信,至少两个实体才有通信这一说,通信各方都需要实现共同的一套通信逻辑,而这个通信逻辑就是我们要分析的,这个逻辑可能是软件实现,也可能是硬件实现。所以柿子要挑软的捏,找到通信各方里,最好分析的实体,一般来说肯定是软件了。Godzilla这款后门管理软件虽然没有开源,但是他的对等实体,也就是他自己的php后门,肯定是可以随便看以及调试的,也就是说并不需要知道他通信加密的所有细节,直接用后门php脚本里的函数就一定可以对发往该脚本的流量进行解密了。如果是对称加密的话,双向的流量也都可解。
X-NUCA 2020 Final 团队赛:QMIPS
题目为网络接口的Web Server,瞎发包测出来的栈溢出,没审出来的原因是给出的目标程序的指令集是MIPS32 rel6(第六个大版本的MIPS32的指令集),比赛时手中的IDA7.5并不能正确的分析出其伪代码。当然有现场直接看汇编看出来毛病的同学,人家是厉害。因为是qemu环境,所以利用直接就是ret2shellcode就完了,不过shellcode只在堆上存在,但因为是qemu-user所以堆的地址在一个环境中是固定的,还是可以猜大概的地址来完成攻击的。
X-NUCA 2020 Final 个人赛:PWN1
32位静态链接程序,开了canary和NX,可以溢出可控的IO_FILE结构体,之后会fclose该结构体,所以非常容易控制流劫持。但因为静态链接,也没有后门函数,只能靠系统调用,但因为没法控制栈,也就没法找到一条gadget就能完成execve(“/bin/sh”,0,0)的。比赛时没做出来,比赛后发现他还有个没有canary可以输入的栈溢出函数,控制流劫持到这然后ROP就完了。
HITCTF 2020 三道 Pwn
比较简单的Pwn,其中的MIPS Pwn是人生中拿到的第一个Pwn的一血,全是4哥的功劳。
HITCTF 2020 蓝牙原始数据解析
给出了非常长的01串,并告知这是用ubertooth抓到的原始数据,其中含有蓝牙的广播报文,请解析报文。
X-NUCA'2020 rtos
卡住了…更新中…rt-thread的main函数栈溢出,不用getshell,ROP/shellcode读出根目录下的flag即可:
西湖论剑 2020 IoT闯关赛 赛后整理
本次IoT闯关赛为西湖论剑的其中一个赛项,由安恒的海特实验室出题,时长8小时,采用定制硬件为解题平台,玩法新颖,题目底座为armv5:linux5.4.75:libc2.30。但考察点偏CTF风格,与IoT安全实战尚有一定距离,最终赛况如下:
思科路由器 RV110W CVE-2020-3331 漏洞复现
Realworld赛题,要求挖掘并利用CISCO RV110W-E-CN-K9(固件版本1.2.2.5)中的漏洞,获取路由器的Root Shell。攻击演示时的目标设备端口只开启了443端口的https服务,且不知道路由器的Web登录账号,故其实要求就是路由器Web的前台getshell。
HWS赛题 入门 MIPS Pwn
以HWS夏令营的两道题目入门MIPS Pwn,都是栈溢出,但栈地址是否已知这个利用前提不同,故利用方式有也所不同。
2020京津冀大学生安全挑战赛 easy_vm
HWS夏令营 之 GDB调一切
HWS夏令营的课程分为三个部分,IoT固件安全,linux内核安全、IoT硬件安全。GDB作为一个出色的调试工具,也在三个部分的课程中频频登场,说哪都有他一点也不过分。三个部分中,我们用GDB依次调试了:arm,mips等与本机x86(x64)不同架构的linux用户态应用程序、x86(x64)的linux内核、STM32裸机程序。前两者目标的运行方法是qemu,后者是用的STM32单板以及JLINK仿真器。
TSGCTF 2020 beginners_pwn
题面非常简单,scanf格串参数可控。但无任何输出函数,无法泄露libc,不过程序syscall指令。利用方法:scanf格串构造任意地址写,写stack_chk_fail的GOT表,然后继续利用scanf栈溢出触发canary报警,控制流劫持,但是只找到两个能利用rdi和rsi的gadget,无法直接控制rax和rdx。最后在程序中找到一段gadget(0x4011DE)能间接控制rax和rdx,不过需要劫持rbp才能满足这段约束的条件。总之最后一顿ROP到syscall上即可execve(“/bin/sh”,0,0)。
能运行Linux的名片 入门 硬件制作
更新中…
Checkm8 漏洞研究
更新中… 一句话描述漏洞:对USB请求处理不当造成的UAF漏洞。淘宝卖了一个二手iPhone6,决定研究一下checkm8这个漏洞。checkra1n虽然可以越狱iPhone6,但是ipwndfu不支持iPhone6,于是我又买了一个iPhone7。
SCTF 2020 EasyWinHeap 入门 Windows Pwn
本文是写给只会Linux Pwn,而对Windows Pwn一窍不通的朋友,对照Linux Pwn的工具、原理、方法,讲解Windows下对应的内容。通过本文可以了解到:1.一种在Win下搭建Pwn题环境的方法(socat+pwntools+IDA) 2. Windows用户态进程运行的基本原理与一些实用工具 3.Windows堆管理的基本方法。本题的漏洞点是存在悬空指针可以UAF,而且对于该悬空指针可以继续show、edit、free。利用方式为通过UAFleak堆地址,然后通过unlink完成堆上的节点索引的改写进而继续leak出程序基址,进而继续改写堆上的索引节点leak出ucrt的基址,最后继续修改索引节点的函数指针为system并控制参数为cmd即可getshell。
SCTF 2020 Password Lock Plus 入门STM32逆向
本文通过SCTF2020的STM32门锁固件题目,介绍了STM32的正向开发方法,逆向分析方法,以及IDA在分析固件的时候一些使用技巧。最终,通过静态分析以及动态模拟调试的方法分别获得 flag1:门锁密码 以及 flag2:UART输出的信息 。
SCTF 2020 AndroidDisplayBridge
本题官方分类是杂项,题目情景来自于一个实际的android投屏软件,出题者给出的解题目标非常明确,解析数据包中的视频流即可看到flag。这种杂项题目就非常的友好,实际软件、目标明确、思路清晰,并且自己在本题也收获了一些视频方面相关知识,故做此记录。解题方法概括为:1. 识别:识别投屏软件以及软件采用的视频技术。 2. 提取:从数据包中提取出原始的视频流信息。 3. 恢复:将视频流封装成文件并播放。
从树莓派的wiringPi库分析Linux对GPIO的控制原理
前一阵给媳妇买了个树莓派4B,教程里使用wiringPi这个c库对GPIO口进行控制。但是说到底硬件接口肯定是需要通过操作系统进行控制的,wiringPi这个库到底是怎么跟操作系统打交道的呢?换句话说,操作系统提供了什么样的接口让用户程序来控制硬件?操作系统又是怎样真正的完成了一次硬件的控制呢?答案是:树莓派上的Linux通过对映射到硬件寄存器的内存地址读写来真正的控制硬件,提供的接口为GPIO设备文件。不过root用户可以通过
/dev/mem
这个文件,来直接控制物理内存,从而绕过GPIO设备文件,对GPIO进行控制。这就是wiringPi这个库的原理,有些黑客。
Meltdown复现 与 linux检测Meltdown的原理分析
本实验来自清华大学张超老师的《数据安全》课程中侧信道攻击小节作业,内容为:给定一个存在Meltdown漏洞的CPU并且安装了老版本linux系统的低权限用户,进行读取目标驱动的内存中的flag字符串,其中目标驱动的源码给出,真正flag的在源码中被隐去。作业环境为学生使用低权限用户通过ssh登录到一台机器上,然后对目标驱动的设备节点进行攻击,因为ssh环境终究会关闭,而且有驱动源码,所以决定自己动手复现一遍这个环境并完成攻击实验,首先是想了解一下Meltdown漏洞,不过重点也是想入门一下linux驱动。最终参考SEEDLabs的实验文档,使用自己的笔记本电脑,CPU为Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz,通过在vmware中安装了官方原版ubuntu12.04完成了实验。并且在过程中读完了宋宝华老师的《Linux设备驱动开发详解》前半本,以及左耳朵耗子的《跟我一起写Makefile》。
第五空间 2020 Pwn
三道题的题目附件:5space_attachment.zip
RCTF 2020 Pwn note
漏洞点为索引没有过滤负数以及堆溢出。利用方法为首先通过负数索引泄露libc,然后构造堆溢出到tcache的fd为
__malloc_hook
的地址,再触发两次对应大小的malloc即可实现任意地址写,写入one_gadget
即可。另外题目环境为libc2.29
,本文还使用了ld-2.29.so
直接加载题目的方式,介绍了在任意版本的ubuntu下做任意libc版本Pwn题的方法。
Rockwell/AB PLC 泄露机架模块脚本
Rockwell/AB PLC 的ENIP协议经过简单的构造session即可实现正常通信,通过抓取组态软件和PLC通信的数据包,找出读取架子信息的流量,构造遍历架子序号,即可泄露机架上的模块信息。
Pwnhub 故事的开始 calc
漏洞点为一个整数溢出和一个堆溢出,其中整数溢出可以转化为另一个堆溢出。本题利用方法为利用原生的堆溢出漏洞,可以覆盖一个存在间接跳转的二级指针,因为没有开启NX,所以结合堆喷即可getshell。虽然堆喷解法的exp很简单,但本题的逆向却是是很耗时的。
TSCTF 2019 Pwn 薛定谔的堆块
这是一道堆喷思想和堆风水思想结合的题目,漏洞点是堆上变量初始化。利用方式和本题代码强相关,通过堆喷思想控制堆上的未初始化的变量,然后综合利用堆风水和堆喷泄露出堆块的布局信息以及libc基址,然后在利用堆喷思想劫持控制流并完成栈迁移到堆上,最后进行ROP即可getshell。
三菱PLC控制脚本
三菱系列PLC,Melsoft私有协议,但如果没有配置口令,则可以直接进行重放攻击,通过wireshark抓取组态软件与PLC的通信报文即可获得控制PLC的数据包,重放即可。
网鼎杯 2020 Pwn boom1
多亏mcfx指导,才能做出这题,感谢。64位程序,保护全开,可以执行我们发送的c代码,但可以执行的代码有些限制,不能执行system之类的函数,但可以任意写内存。最终通过利用栈上的数据,获得了libc的基址,完成了对__malloc_hook的劫持,进而getshell。
De1CTF 2020 Pwn stl_container
漏洞点是:使用C++中的STL中vector存储对象的指针时,在earse清除其中元素时,总会调用最后一个对象的析构函数,最终导致存在悬空指针,并且可以被使用,即UAF。其使用的方式是可以继续free以及show其内容。
De1CTF 2020 Web+Pwn mixture
本题前面是Web,SQL注入注出管理员的密码,然后能任意读取文件,发现php使用了一个自定义的函数,读取到这个函数的实现的动态链接库,去除花指令后发现有个栈溢出,但是在利用的过程中需要注意栈的使用情况。
我的世界minecraft相关
大学的时候第一次接触到我的世界,觉得是个很自由浪漫的游戏,可以在游戏里天马行空的创造,当时也是因为这个游戏第一次要指定JAVA路径,听到了什么JDK、JRE的相关名词。最近和家人一起在玩这个游戏,正巧前几天的比赛里也出了游戏相关的题目,而且在CTF中出现MC也不是第一次了,所以借着这个机会玩一下游戏,也研究研究的运行原理,整理下我知道的方方面面。
和媳妇一起学Pwn 之 fengshui
IDA动态调试:arm架构的IoT设备上运行armlinux_server错误的一种解决办法
解决了在arm架构的32位linux下,由于链接器不同,动态库不全导致的IDA的调试server无法运行的问题。后来发现这种方法调试多进程时IDAserver会崩溃,应该是libthread_db.so.1与环境不兼容。另外其实有更简单的方法,直接在运行时设置环境变量,然后用本地的ld运行,ELF为参数即可:
LD_PRELOAD=./libthread_db.so.1 /lib/ld-2.25.so ./armlinux_server
QEMU使用记录
每次看QEMU启动有一堆参数,很是害怕,所以抽出空来彻底整理一下见过的QEMU用法,从使用者的角度对QEMU做一个梳理。
和媳妇一起学Pwn 之 babyfengshui
和媳妇一起学Pwn 之 BookWriter
本题总结点较多,之后总结
和媳妇一起学Pwn 之 seethefile
漏洞点是:存在一个位于bss段的变量输入溢出,溢出后可以覆盖一个IO_FILE结构体的指针。
2020年3月26日国内HTTPS访问GithubPage劫持事件分析
我猜这么诡异的动作,应该是墙,然后用iptables尝试复现了劫持的情景
和媳妇一起学Pwn 之 Secret Garden
漏洞点是:存在悬空指针,并且可以被使用,即UAF。其使用的方式是可以继续free。
gdb带源码调试libc
在使用gcc编译时,如果采用带
-g
选项编译,即可在二进制文件中附加调试信息以便gdb进行源码级别的调试。如果二进制中存在调试信息并且源码文件存在,则可以使用gdb的list命令来查看源码。通过在ubuntu中安装带调试信息的libc,并下载libc源码,即可配置gdb跟入libc的库函数后进行源码级别的调试
为啥要分析固件的加载地址?
计算机最讲道理。凭啥计算机知道加载地址,而我不知道?答:裸机程序中不必要包含自己的加载地址,如果没有加载地址,就无法对绝对地址的引用有正确的解析。所以分析的固件如果是裸机层面的代码,就需要知道其加载地址。
XCTF高校战疫 移动赛题GetFlag出题记录
出了一个攻击真机的题目:利用ssh的端口转发以及一台公网服务器,将apk绑定本地的对应端口映射到公网上。漏洞点为app中的
Runtime.getRuntime().exec
的参数拼接,利用方式为:使用其本身执行的wget
程序的--post-file
参数将保存在应用私有目录下的flag带出。最终解出本题的队伍个数为33,前三名为0ops,天枢,NU1L。
和媳妇一起学Pwn 之 Tcache Tear
漏洞点是:存在悬空指针,并且可以被使用,即UAF。其使用的方式是可以继续free。
x86架构的CPU加电后的第一条指令到底在哪?
本文讨论的第一条指令的概念是存储于CPU外部的指令,因为真正意义上的第一条指令应当位于CPU内部。这个问题其实看intel的CPU手册就知道了!
x86架构的CPU到底有多少个寄存器?
这其实是个不明确的问题,问题的主语应该具体到每一颗不同型号的CPU上,而非一类架构的CPU集合。
和媳妇一起学Pwn 之 applestore
漏洞点是:本题预留了一个彩蛋,触发后可将一块栈内存的地址记录到堆上,并且可通过一些函数的输入控制这块栈内存。
ARM PWN入门
本意是参考https://ctf-wiki.github.io/ctf-wiki/pwn/linux/arm/arm_rop-zh学习ARM相关的漏洞以及利用,却在搭建环境的问题上弄了好久,不明白QEMU启动一堆镜像都是啥,所以采用暴力的方式直接在ARM机器上学习,采用了树莓派,还有装了Termux的android手机直接gdb本地调试,安装zio本地利用。例题:jarvisOJ_typo
Termux(一个免root的android上shell环境与包管理器)
Wargames
和媳妇一起学Pwn 之 hacknote
本题可以申请任意大小的堆块,并且在删除时未清空指针数组导致悬空指针,从而产生UAF。利用方式为通过UAF调用一个存在于堆块,并且被一系列堆操作篡改的函数指针,控制流劫持进而getshell。
Write Some Paper (大小姐教我入门堆)
本题可以申请任意大小的堆块,并且在删除时未清空指针数组导致悬空指针,从而产生UAF。利用方式为通过FastbinAttack的DoubleFree的实现有限制的目标地址写,将GOT表项改写为后门函数。