CVE

一、前言 全球著名防火墙公司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，因此无法达到预期的效果。...