Cve

一、前言 本文主要是讲述用静态分析平台——破壳平台进行批量漏洞快速挖掘和扫描的思路分享。 破壳平台在近日提交了TP-Link，TENDA，D-Link，Linksys，Edimax，Netgear等系列设备六十余个漏洞点，并已经获得30个CVE的批复。 CVE-2024-57357,CVE-2025-22900,CVE-2025-22903,CVE-2025-22904,CVE-2025-22905,CVE-2025-22906,CVE-2025-22907,CVE-2025-22911,CVE-2025-22912,CVE-2025-22913,CVE-2025-22916,CVE-2025-25456,CVE-2025-25458,CVE-2025-25453,CVE-2025-25455,CVE-2025-25454,CVE-2025-25457,CVE-2024-57536,CVE-2024-57537,CVE-2024-57538,CVE-2024-57539,CVE-2024-57540,CVE-2024-57541,CVE-2024-57542,CVE-2024-57543,CVE-2024-57544,CVE-2024-57545,CVE-2024-42520,CVE-2025-25579 后面我们会从三个方面来讲一下查询的策略： 边界二进制寻找 漏洞模式分析及规则编写 平台使用 二、边界二进制寻找 所谓边界二进制就是用户可以访问到的二进制，一般我们进行漏挖也是主要针对这些程序进行针对性，无需对固件中所有的程序都进行分析。 而对于静态分析来说，上传的文件越多那么分析速度和查询速度就会相应的越慢。因此需要有一个初步的文件过滤的步骤来帮助我们初步筛选一些边界二进制。根据平时的漏洞挖掘经验对于常见的路由器，摄像头，nvr等设备，其http服务及相关cgi是漏洞出现的重灾区。 上传平台后平台会自动对压缩包，固件进行解压。同时平台可以设置正则表达式进行过滤： \b(?:\w*httpd\w*|\w*.cgi|\w*onvif\w*|\w*boa\w*|\w*webs\w*|\w*goahead\w*)\b 个人平时在漏洞挖掘时也习惯使用下面的方式来大致确定一些具有网络服务的边界二进制： cd usr grep -r "bind" . | grep Binary 主要是因为值得分析的二进制一般会位于usr目录下，根目录下的bin和sbin一般是linux系统自己的系统服务。且边界二进制必然会监听端口，因此存在bind字符串的很大概率是边界二进制。 三、漏洞模式分析及规则编写 在物联网漏洞挖掘中，命令注入和缓冲区溢出是最为常见的高危漏洞类型。在我初期的自动化工作中也先以这两种漏洞模式进行查询。下面介绍这两种漏洞类型中我所使用的常见漏洞模式。 2.1 命令注入漏洞模式 大部分命令注入漏洞都会经过字符串拼接函数。 edimax CVE-2025-22905 下图是平台漏洞个查询结果，可以看到这个漏洞就是从websGetVar中获取到了对应字段，然后经过了字符串拼接后传递给了system函数，造成了命令注入漏洞。 tplink-8630 CVE-2024-57357 这个漏洞其实从调用流程上来说比较复杂，首先他会使用aes解密用户传入的数据为json，然后从json中拿取一个字符串，然后根据这个字符串去一个虚标中调用对应的函数，然后再经过一个虚表调用后再经过一个假鉴权最终达到命令注入，但是核心漏洞点就是字符串拼接后执行了system 在sub_424ab0函数中会将v20这个变量直接传递给system函数作为参数。 查询规则 针对于大部分命令注入漏洞都会经过字符串拼接函数这个漏洞模式，，使用正则进行字符串匹配或者单纯直接寻找sprintf和system函数作为危险函数点总体来说误报还是比较多的，而且不支持跨函数的情况。 因此个人采用的是使用snprintf,sprintf函数的参数作为source点，常见的命令执行函数作为sink点，然后使用平台进行污点分析，相对来说误报较少，能查到的很大概率是会存在漏洞的。 MATCH (n:identifier)<-[:ast*2]-(code:code_line) WHERE n.callee in ["snprintf","sprintf"] and n.index in [2,3,4,5,6] and code.name contains "%s" WITH collect(id(n)) as sourceSet MATCH (m:identifier{index:0}) WHERE m.callee in ['system', '_system', '_popen', 'popen', 'wpopen', '_wpopen', 'spawn', '_wexecl', '_wspawnv', 'eval', '_wsystem', 'spawnve', '_wspawnlp', '_spawnl', 'execle', '_wspawnve', '_texeclp', '_wexeclp', '_spawnlpe', '_execvp', '_exec', 'COMM_SystemEx', '_wspawnl', '_wspawnvp', 'execlp', 'system_en', '_wspawnvpe', '_wexecv', 'WinExec', '_wspawnle', '_texecvp', 'CreateProcessW', 'twsystem_nowait', '_texecle', '_execv', '__system', '_spawn', 'spawnvp', '_tspawnl', 'doSystemCmd', 'callSystemCmd', '_tspawnlpe', 'CreateProcess', '_spawnve', '_tspawnv', 'spawnlp', 'spawnlpe', 'g_spawn_command_line_async', '_wexecle', 'spawnl', '_spawnvp', '_tspawnlp', '_tspawnle', '_execl', '_wexec', '_wexeclpe', '_tspawnve', 'spawnv', '_tspawn', 'twsystem', '_spawnle', '_execle', 'execvp', '___system', '_wspawn', '_texecl', '_tspawnvp', '_eval', '_texecv', '_spawnlp', '_spawnvpe', 'spawnle', '_execlp', 'execl', '_execlpe', 'CreateProcessA', '_spawnv', '_tspawnvpe', '_texec', '_wexecvp', 'bstar_system', 'prctl_runCommandInShellBlocking', 'execv', 'spawnvpe', '_wspawnlpe', '_texeclpe', 'execlpe', 'jhl_system', 'ATP_UTIL_ExecCmdNoHang', 'j_ATP_UTIL_ExecCmdNoHang', 'bs_SetCmd', 'ExeShell','doSystemCmd','lxmldbc_system'] WITH sourceSet,collect(id(m)) as sinkSet CALL VQL....

一、前言 全球著名防火墙公司Palo Alto Networks近日在官网公布了一个CVE-2024-3400的漏洞信息，该漏洞存在于部分PAN-OS系统的GlobalProtect功能中，在某些配置打开的情况下，攻击者可以对运行该系统的设备进行未授权RCE，并且拿到系统的root权限，本文以研究学习为目的对漏洞的成因进行详细的分析。 二、影响版本 根据官网提供的信息，我们选取了PAN-OS 11.0.0版本固件作为本文的研究对象。 三、GlobalProtect分析 GlobalProtect是PAN-OS中的VPN组件，可以在管理端配置GlobalProtect Portal门户页面，其页面如下，可供VPN用户进行登录。 对固件进行解包，在/etc/nginx/sslvpn中发现了GlobalProtect Portal的服务器配置文件，查看location.conf文件，可以知道VPN的API请求直接被代理到了内部的20177端口。 通过查看端口占有情况，可知VPN请求由gpsvc程序进行处理。 四、gpsvc逆向分析 gpsvc使用golang语言编写，分析HTTP服务的调用链 net_http__ptr_conn_serve -> net_http_serverHandler_ServeHTTP -> github_com_gorilla_mux__ptr_Router_ServeHTTP -> net_http_HandlerFunc_ServeHTT -> main__ptr_GpTaskMgmt_MainHttpEntry -> main__ptr_GpTask_RunHttp -> main__ptr_GpTask_initHttp 其中main__ptr_GpTask_initHttp函数会解析请求数据包，审计该函数，注意到此处是对Cookie中的SESSID字段的处理。 在此处下断点并追踪对SESSID的处理，最终会来到main__ptr_SessDiskStore_New函数， 分析该函数的代码，其中name就是传入的SESSID，调用net_http__ptr_Request_Cookie从Cookie中获取SESSID的值，然后赋值给session->ID.str。 接下来会将session->ID.str进行简单的路径拼接，得到filename完整路径，然后传递给main_loadSessFile。 我们直接在main_loadSessFile下断点，然后调试，使用如下的测试脚本进行触发： from pwn import * import os import requests ip = '192.168.177.149' port = 20077 payload = 'POST /ssl-vpn/hipreport.esp HTTP/1.1\r\n' payload += 'Host: aa.bb.cc\r\n' payload += 'Cookie: SESSID=/aaaaaaaaaaaaa;\r\n' payload += '\r\n' sh = remote(ip,port) sh.send(payload) sh.interactive() 可以看到SESSID的内容成功拼接到filename，由于是简单的拼接，能否尝试一下/../../这种路径穿越的path?修改测试脚本。 #coding:utf8 from pwn import * import os import requests ip = '192....

MikroTik作为网络基础设施供应商，其产品和RouterOS被广泛采用。目前，至少有超过 300 万台设备在线运行 RouterOS。该漏洞是Pwn2Own上orange团队利用的漏洞，达到了认证前RCE。且该漏洞存在了9年未被发现，基本影响了RouterOS6版本和7版本中的大多数设备。 0x00 CVE信息 What this issue affects: The issue affects devices running MikroTik RouterOS versions v6.xx and v7.xx with enabled IPv6 advertisement receiver functionality. You are only affected if one of the below settings is applied: 通过官方描述，得知漏洞存在于ipv6的RA协议中。 Router Advertisement（RA）是IPv6协议中的一种控制消息，用于告知网络中其他设备关于路由器的存在和IPv6地址分配信息。RA消息通常由网络中的路由器定期广播，以便其他设备可以获取路由器的信息并使用IPv6协议与其通信。 在RouterOS中，RA功能是路由器的一个基本功能，它可以通过配置路由器的接口参数来启用。当启用RA功能后，路由器将会在指定的接口上定期广播RA消息，使得其他IPv6设备可以通过接收这些消息来自动配置自己的IPv6地址和路由信息。 0x01 前置知识 IPV6 SLAAC 所谓 IPV6 SLAAC 即 Stateless address autoconfiguration，无状态地址自动配置。这里我们需要了解几个概念。 路由器请求RS（Router Solicitation）报文：很多情况下主机接入网络后希望尽快获取网络前缀进行通信，此时主机可以立刻发送RS报文，网络上的设备将回应RA报文。 路由器通告RA（Router Advertisement）报文：每台设备为了让二层网络上的主机和设备知道自己的存在，定时都会组播发送RA报文，RA报文中会带有网络前缀信息，及其他一些标志位信息。 我们的电脑可以通过路由器发送的RA来接收ipv6前缀从而配置ipv6地址，同样的我们也可以向路由器发送RA来对路由器的ipv6地址和一些其他信息（比如DNS）进行配置。 通过分析这个协议我们可以发现，在这种场景中，路由器其实是一个既充当了客户端，又充当了服务端的功能。其他的客户端可以给路由器发送配置，路由器会将这些配置存储。而路由器本身又会作为客户端存在，把自身的配置向其他设备进行广播。而作为客户端情况存在往往会疏于检查从而存在漏洞。 0x02 漏洞分析 在RouterOS7.9版本中，找到负责RA协议处理的二进制radvd进行bindiff，发现新版本的patch主要在下面这段代码（以下是在7.9版本中未修复的代码） while ( v21 != a2 + 1 ) { v9 = sub_804E434(v8);Mikrotick if ( (_BYTE)v9 ) { v10 = operator<<(&unk_80554C0, "adding DNS server option, address=", v9, v9); v11 = operator<<(v16, v21 + 3, v10, v21 + 3); v12 = operator<<(v11, v20, v17, v18); endl(v12); } v19 = v21[4]; v13 = v21[5]; v14 = v21[6]; *(_DWORD *)(a1 + v3) = v21[3]; *(_DWORD *)(a1 + v3 + 12) = v14; *(_DWORD *)(a1 + v3 + 4) = v19; *(_DWORD *)(a1 + v3 + 8) = v13; v3 += 16; tree_iterator_base::incr((tree_iterator_base *)&v21); } 可以看到这段逻辑循环终止条件是v21这个vector到末尾，并且在循环过程中会把vector中的内容向a1上拷贝。其实再向上追一下可以发现a1是上层函数中的一个栈上的变量且大小是固定的。因此只要这个vector中的内容足够大便可以造成栈溢出。...

一、背景 JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成。它基于JavaScript语言标准ECMA-262第3版（1999年12月）的一个子集。随着时间的推移，JSON已经超越了JavaScript，成为许多编程语言支持的标准数据格式之一。 如HTTP 请求走私等攻击一样，json解析器之间以及多阶段请求处理的差异可能引入严重的漏洞，即使是在严格遵守规范的解析器，也不可避免的与规范存在偏差，这是为什么？ 关于JSON的规范有多个，各规范定义有一定的差异 ECMAScript Standard：ECMAScript是JavaScript语言的标准化名称，定义了JSON作为JavaScript的一个子集，但实际应用超出了JavaScript； IETF JSON RFC 8259：提供了一个严格和精确的JSON数据交换格式规范，这个标准旨在确保JSON数据的交换在不同的系统间能够保持一致性和可靠性。 规范文档对于一些定义是开放式的描述，例如 IETF JSON RFC 8259 对重复键的描述： An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only....

一、前言 在IoT小设备中由于运行资源（CPU、存储、内存等）受限，通常会使用轻量级的 Web server，例如uHTTPd、lighttpd、micro_httpd、mini_httpd、GoAhead、boa等，其中uHTTPd、lighttpd此类Web server通常不会由开发者修改源码新增功能代码，而是纯粹作为一个类似流量转发的框架；而micro_httpd、mini_httpd、GoAhead、boa此类通常是由开发者将一些业务代码集成到Web server中，导致在server代码中产生漏洞的概率增大。 本文由于篇幅原因，仅仅针对IoT小设备（光猫、路由器、摄像头等）中常见的两个开源Web server框架GoAhead和mini_httpd，分别从源码处理数据、漏洞存在点、经典CVE漏洞分析这三个方面，浅析其漏洞挖掘思路。 本文不会完全分析Web server代码实现、架构，而是聚焦于安全研究较为关注、通常由开发者实现的数据包处理部分。文章的大概阐述思路如下： 首先结合源码说明数据包处理特性，主要涉及鉴权、路由处理 简述数据包处理中可能存在的漏洞点 结合经典漏洞进行分析 二、GoAhead篇 GoAhead是一个轻量化、适用于嵌入式设备的Web server，采用C语言编写，代码量不大，具有高度的可移植性和扩展性。GoAhead支持多进程、多线程，能够处理大量的并发连接，支持SSL/TLS加密和基本的身份认证，支持CGI、ASP，满足了绝大部分的Web server业务场景。 GoAhead由Embedthis Software LLC开发，早年间是完全开源的，可以直接在Github上下载到源码。但是在2022年的时候，似乎转为了商业定制，官方在Github删除了代码库，因此在Github上无法下载，但是在Gitee上还有镜像库。下载地址：GoAhead: GoAhead WebServer 在D-Link的主流路由器中，例如DIR系·列，很多使用了GoAhead作为Web Server；除此之外还有Tenda、NETGEAR、BEC等许多厂家都有在其设备中使用GoAhead。 2.1 数据包处理逻辑 GoAhead会对数据包按照优先级进行顺序处理，处理方式是通过注册的回调函数： 优先级为1注册的回调函数：所有数据包都需要首先经过该回调函数进行处理，此处也通常被用来做数据包鉴权、请求路径合法性判断、未授权访问路径定义等等； 优先级为0注册的回调函数：通常用来定义认证后可访问到的接口逻辑实现； 优先级为2注册的回调函数：处理没有匹配到注册路径的数据包，也就是非法路径的数据包。 int websUrlHandlerDefine(char_t *urlPrefix, char_t *webDir, int arg, int (*handler)(webs_t wp, char_t *urlPrefix, char_t *webdir, int arg, char_t *url, char_t *path, char_t *query), int flags) 重要的参数： char_t *urlPrefix：指定URL的前缀，也就是需要处理的URL开头部分 int (*handler)：URL对应的回调函数 int flags：URL处理优先级标志，有如下的两个选择： #define WEBS_HANDLER_FIRST 0x1：所有的数据包都会通过该回调函数进行处理 #define WEBS_HANDLER_LAST 0x2：没有回调函数匹配的数据包会通过该回调函数进行处理 如下是一个设备DIR-878，固件版本1.02B02中的GoAhead反编译代码，可以看到GoAhead对于数据包是否已经通过认证，是通过注册一个flags=WEBS_HANDLER_FIRST=1的回调函数websSecurityHandler来进行验证的，这意味着所有的数据包都会通过函数websSecurityHandler进行处理，验证数据包发送者的权限。 websUrlHandlerDefine((int)"/", 0, 0, (int)websSecurityHandler, 1); websUrlHandlerDefine((int)"/HNAP1/", 0, 0, (int)websFormHandler, 0); websUrlHandlerDefine((int)"/cgi-bin", 0, 0, (int)websCgiHandler, 0); websUrlHandlerDefine((int)&unk_497DEC, 0, 0, (int)websDefaultHandler, 2); 例如对一个请求的完整处理过程：使用POST请求访问/HNAP1/，...

一、前言 D-Bus （Desktop Bus）是一个用于在 Linux 和 Unix 系统上进行进程间通信的消息总线系统，它提供了一种机制，使得软件组件可以互相交流、传递消息和调用服务。 尽管 D-bus 最初是为桌面环境设计的，但它的通信机制和功能使其在非桌面环境中同样适用，以下是一些非桌面环境中使用 D-Bus 的例子： 服务间通信：D-Bus 可以用作服务之间进行通信的机制，无论是在服务器环境、嵌入式系统还是其他非桌面应用中。它可以帮助不同的服务或守护进程相互交流和协调工作。 系统管理：D-Bus 在系统管理领域也有广泛的应用。例如，系统服务可以使用 D-Bus 在后台进行通信，以便进行配置、监控和控制。这对于系统管理工具、系统监控应用和自动化任务非常有用。 嵌入式系统：D-Bus 在嵌入式系统中也可以发挥作用。它可以用于不同的组件之间进行通信，如硬件驱动程序、系统服务和用户应用程序。通过使用 D-Bus，这些组件可以共享信息、传递事件和协调操作。 IoT（物联网）设备：D-Bus 在物联网设备中的应用也在增加。它可以用于不同设备之间的通信，例如智能家居设备、传感器、控制器等。通过使用 D-Bus，这些设备可以相互通信、共享数据和提供服务。 然而，就像任何其他的通信协议一样，D-Bus通信也存在一些安全风险。本文将介绍 D-Bus 的通信机制，并分析其中的安全问题。 二、D-Bus 通信 2.1 D-Bus 通信背景知识 D-Bus 消息总线：D-Bus 使用消息总线作为通信的中心枢纽，允许不同进程之间消息传递。 总线名称和对象路径：每个 D-Bus 消息都与一个特定的总线名称和对象路径相关联，以确定消息是由哪个进程发送和接收。 接口和方法调用：D-Bus使用接口和方法调用的概念，进程可以调用其它进程公开的方法来进行通信。 D-Bus 通信比较常见，很多系统设置相关的操作都会触发 d-bus 通信。比如：修改用户头像操作，可以通过命令行在发送的 D-Bus 消息实现。 dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetIconFile string:/home/fish/Pictures/1.jpg 2.2 D-Bus 消息介绍 D-Bus 消息由header和body组成，hedaer包含消息的基本信息，包括发送进程的链接名，方法，消息类型等。 消息类型有以下四种： CALL方法调用：发起进程发出的消息； REPLY 方法返回：方法调用返回的结果； ERROR 消息：方法调用返回一个异常； SIGNAL 消息：通知，广播消息。 消息结构如下图所示： 2.3 D-Bus Hello 消息 在 D-Bus 通信中，第一个数据包被称为 “Hello” 消息。它是在客户端应用程序连接到 D-Bus 守护进程时发送的。...

一、漏洞简介 FortiGate二月份发布版本更新，修复多个中高危漏洞，其中一个严重级别漏洞是SSL VPN的未授权越界写漏洞，漏洞预警称该漏洞可能被在野利用。本文将介绍笔者分析利用该漏洞，实现远程代码执行的过程。 二、漏洞分析 本文漏洞分析使用的环境是FGT_VM64-v7.4.2.F-build2571。 2.1 diff patch 对修复版本的二进制进行对比（7.4.2和7.4.3），分析发现修复代码位于函数sub_18F4980(7.4.2)。 分析该函数不难发现，该函数逻辑是读取HTTP POST请求的body数据。同时根据Transfer-Encoding请求头判断是按照chunk格式读取，还是根据Content-Length读取。根据控制流图对比结果，存在两处代码修改： 解析chunk格式时，调用ap_getline读取分块长度，检查ap_getline的返回值是否大于16，大于16认为是非法的chunk length。 读取chunk trailer时，写入\r\n的偏移line_off的赋值来源，修复前line_off的值来源于*(_QWORD *)(a1 + 744)，修复后line_off为ap_getline的返回值。 继续向前回溯，可以找到*(_QWORD *)(a1 + 744)的值正是第一处校验的chunk length字段的长度 同时阅读代码可以得知，当chunk length字段经过hex解码后值为0时，就会进入到chunk trailer读取的逻辑。 2.2 触发越界写 经过对patch的分析，我们可以得到以下结论： 1、解析chunk时，如果chunk length字段hex解码后值为0，则开始chunk trailer的读取。 2、调用ap_getline读取chunk trailer后，会根据chunk length字段的长度向缓冲区中写入\r\n。 因此，如果chunk length字段传入很多个0，0的长度大于剩余缓冲区长度的1/2时，就会触发越界写入\r\n。通过调试可知目标缓冲区位于栈上（函数sub_1A111E0），偏移0x2028的位置保存了返回地址。如果在偏移0x202e的位置写入\r\n，当函数返回执行ret指令恢复rip时就会因地址非法产生崩溃。 Crash PoC： pkt = b"""\ GET / HTTP/1.1 Host: %s Transfer-Encoding: chunked %s\r\n%s\r\n\r\n""" % (hostname.encode(), b"0"*((0x202e//2)-2), b"a") ssock = create_ssock(hostname, port) ssock.send(pkt) ssock.recv(4096) 崩溃现场： 三、漏洞利用 通过分析漏洞成因可知，利用该漏洞可以实现栈上越界写\r\n两个字节，越界范围接近0x2000。由于写入的内容非常有限，无法通过直接劫持rip实现RCE。因此需要把目光放在栈上保存的内存指针上。 3.1 失败的尝试 比较容易想到的是劫持rbp，通过覆盖rbp的低字节，使rbp刚好指向可控的内存区域。当上一级函数返回执行leave ret指令时，就可以完全劫持rip。然而验证时发现即使覆盖了栈上的rbp，也无法劫持rsp和rip，甚至程序不会产生崩溃。继续向上回溯，找到sub_1A111E0的父函数sub_1A26040，该函数在返回时并没有调用leave ret来恢复rsp，而是直接add rsp, 0x18，因此无法达到预期的效果。...