mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
【漏洞预警】Fortinet FortiClientEMS SQL注入漏洞CVE-2025-59922、美国网络安全和基础设施安全局 (CISA) 命令联邦政府修复 Gogs 远程代码执行漏洞，该 0 day 漏洞已被攻击利用、Android Pixel 9 的零点击漏洞利用链全解析：从发送杜比音频解码到内核提权、密码重置漏洞挖掘指南：从原理到实战的完整路径、CNNVD关于微软多个安全漏洞的通报、【接口漏洞第六章第三节】隐藏在“&”和“#”背后的秘密：我是如何通过参数污染接管管理员账户的、
This commit is contained in:
test committed
1 parent
ee9f659b9b
commit
514731912f
7 files changed
+645
-1
No files matched your search
@@ -16710,5 +16710,11 @@
|
||||
"https://mp.weixin.qq.com/s/UOwZCl-WxvefyRv76t9Z6g": "北京大学 | ContractTinker：基于大语言模型的真实场景智能合约漏洞修复系统",
|
||||
"https://mp.weixin.qq.com/s/P3sWlLs3xrR_bVkO24Kreg": "【附POC及复现环境】Appsmith任意用户密码重置漏洞（CVE-2026-22794）",
|
||||
"https://mp.weixin.qq.com/s/3PMdID0xfTN7iyYRYF9Eug": "OA渗透测试的思维盲区：从漏洞猎人到系统拆解师",
|
||||
"https://mp.weixin.qq.com/s/XV5recnrGHolaTpSJvvJ9g": "人工智能重要漏洞通报（2026年第一期）"
|
||||
"https://mp.weixin.qq.com/s/XV5recnrGHolaTpSJvvJ9g": "人工智能重要漏洞通报（2026年第一期）",
|
||||
"https://mp.weixin.qq.com/s/iH1BrFH9L5jdui29ygz2dw": "【漏洞预警】Fortinet FortiClientEMS SQL注入漏洞CVE-2025-59922",
|
||||
"https://mp.weixin.qq.com/s/HTvxV0A0eZvqEmkCupdRaQ": "美国网络安全和基础设施安全局 (CISA) 命令联邦政府修复 Gogs 远程代码执行漏洞，该 0 day 漏洞已被攻击利用",
|
||||
"https://mp.weixin.qq.com/s/5ghBCECoOHZv98lVUnqD1w": "Android Pixel 9 的零点击漏洞利用链全解析：从发送杜比音频解码到内核提权",
|
||||
"https://mp.weixin.qq.com/s/U69lTph4yYBA2wgfgdFYWA": "密码重置漏洞挖掘指南：从原理到实战的完整路径",
|
||||
"https://mp.weixin.qq.com/s/kcSQCa7NWb2LAnq_7MVPsg": "CNNVD关于微软多个安全漏洞的通报",
|
||||
"https://mp.weixin.qq.com/s/TCoaB2A1Dr59aT9ghWRpSA": "【接口漏洞第六章第三节】隐藏在“&”和“#”背后的秘密：我是如何通过参数污染接管管理员账户的"
|
||||
}
|
||||
@@ -0,0 +1,145 @@
|
||||
# Android Pixel 9 的零点击漏洞利用链全解析：从发送杜比音频解码到内核提权
|
||||
原创 黑鸟
|
||||
黑鸟 黑鸟 2026-01-16 15:24
|
||||
|
||||
# 本文基于 Google Project Zero 于 2026 年 1 月发布的完整博客系列《Pixel 0-click Exploit Chain》（三部分），所有漏洞已在 2026 年 1 月 5 日的安全更新中修复。
|
||||
|
||||
现在的即时通讯应用（如 Google Messages）为提升用户体验，引入了自动语音转录、消息内容搜索等 AI 功能。
|
||||
|
||||
这些功能要求在用户未打开消息时，就对收到的音频附件进行解码和分析，从而将大量媒体解码器纳入零点击漏洞攻击面。
|
||||
|
||||
在 Pixel 9 上，不仅 Google Messages 会自动转录 RCS/SMS 音频，另一个进程 com.google.android.tts 也会解码所有收到的音频（可能用于增强搜索）。
|
||||
|
||||
需要注意的是，目前其他安卓手机系统还未确认有无该漏洞问题，因此需要谨慎对待。
|
||||
|
||||
两者均调用设备上所有可用解码器，包括 Dolby Unified Decoder（UDC），尽管日常消息极少使用 Dolby 格式（AC-3/EAC-3，主要见于商业影视）。
|
||||
|
||||
|
||||
Project Zero 团队通过系统性分析，发现并构建了仅需两个漏洞的完整零点击漏洞利用链：
|
||||
- CVE-2025-54957（Dolby UDC）：mediacodec 进程任意代码执行
|
||||
|
||||
- CVE-2025-36934（BigWave AV1 驱动）：内核任意读写 + root 提权
|
||||
|
||||
攻击流程为发送两条恶意构造的EAC-3 音频的消息附件，用户无需在任何交互。
|
||||
|
||||
## 第一阶段：Dolby UDC 整数溢出与 mediacodec 沙箱逃逸
|
||||
|
||||
### 漏洞是怎么形成的？
|
||||
|
||||
Dolby UDC 在处理 EAC-3 音频流时，会解析一种叫做 EMDF（Extensible Metadata Delivery Format）的额外元数据。这些元数据藏在音频帧的“skip”区域，最多可携带 3066 字节。
|
||||
|
||||
EMDF 结构中有一个关键字段：emdf_payload_size。它通过 variable_bits(8) 方式读取，这种读取机制允许数值无限扩展，没有硬性上限。
|
||||
|
||||
解码器会先根据这个大小在自定义的 evo heap 上分配内存，然后把相应数量的字节拷贝进去。
|
||||
|
||||
|
||||
但在分配时，代码为了内存对齐而调整总大小时，漏掉了整数溢出检查：当 payload_size 极大时，总大小会溢出变成一个小值，导致只分配一小块内存，却试图拷贝巨量数据——形成经典的堆溢出。
|
||||
|
||||
特别有利的是，拷贝字节的数量和内容受另一个字段 emdf_container_length 控制，攻击者可以精确决定溢出多少字节、写什么数据。
|
||||
|
||||
|
||||
|
||||
同时，如果把 emdf_container_length 设得比实际 skip 数据长，解码器还会越界读取后续内存（这些内存要么是零，要么已被溢出填充），形成可控的信息泄露原语。
|
||||
|
||||
简单说，这个漏洞同时提供了精准堆溢出和内存泄露两种强大能力。
|
||||
|
||||
### 漏洞利用是怎么一步步进行的？
|
||||
|
||||
|
||||
UDC 启动时会分配两块大内存区域：
|
||||
- static buffer（约 69 万字节）：存放核心数据结构
|
||||
|
||||
- dynamic buffer（约 8.5 万字节）：用于临时计算，包含 skip buffer
|
||||
|
||||
攻击者先构造多个小 EMDF payload 把 evo heap 填满，让溢出正好覆盖一个关键的 skip pointer。这个指针原本指向 skip buffer，一旦被控制，后续所有 skip 数据就能写入攻击者指定的任意地址。
|
||||
|
||||
|
||||
为了突破 evo heap 本身的容量限制，攻击者利用 Android 默认堆分配器 Scudo 的特性：通过反复触发解码过程（相当于反复打开/关闭恶意音频），让 dynamic buffer 被释放并重新分配。
|
||||
|
||||
|
||||
|
||||
|
||||
利用溢出精确修改它的 Scudo 二次分配头部，就能让下次分配时偷偷多出几千字节未初始化空间。在这些空间里植入伪造的 EMDF 容器，再配合泄露原语安全修改关键字段，最终获得在 static buffer 高地址区域任意写入 64 位值的强大原语(Primitive)。
|
||||
|
||||
|
||||
有了这些原语，攻击者在 static buffer 中找到两个高频调用的函数指针。通过部分覆盖（只改低位字节，绕过 ASLR 的低位随机化），结合 memcpy gadget 和一个能固定增量的 adder gadget，逐步把 libc GOT 表里的普通函数指针改写成 pwrite。
|
||||
|
||||
最后，用 pwrite 把精心准备的 shellcode 写入 libc 中一个会频繁触发的位置（如 __stack_chk_fail），一旦触发就执行攻击者代码，在 mediacodec 进程中实现任意代码执行。
|
||||
|
||||
|
||||
整个过程需要几十个精心设计的同步帧，分三条恶意音频消息发送，平均几分钟内完成。
|
||||
|
||||
## 第二阶段：BigWave 驱动漏洞与内核提权
|
||||
|
||||
### 漏洞是怎么形成的？
|
||||
|
||||
虽然 mediacodec 进程受 SELinux 严格沙箱限制，但它可以访问 /dev/bigwave——这是 Pixel SoC 上专责 AV1 视频硬件加速的内核驱动。
|
||||
|
||||
|
||||
每次打开这个设备，内核会分配一个 bigo_inst 结构（内嵌 bigo_job 子结构），挂在文件描述符的 private_data 上。
|
||||
|
||||
用户通过 ioctl（BIGO_IOCX_PROCESS）提交任务时，把寄存器值塞进 job，job 被放入优先队列，由独立的内核 worker 线程（bigo_worker_thread）异步处理。
|
||||
|
||||
|
||||
ioctl 在提交后会等待硬件完成，最多超时 16 秒。超时后它会尝试把 job 从队列移除。如果前面堆积了很多任务，worker 线程可能正好在处理这个 job，而 ioctl 已经认为超时并“删除”了它。此时用户迅速关闭文件描述符，bigo_inst 和 job 就被释放——但 worker 线程还在继续使用它们。
|
||||
|
||||
|
||||
释放后，worker 线程仍会：
|
||||
- 从硬件拉取当前寄存器状态，写入 job->regs 指向的地址（UAF 写）
|
||||
|
||||
- 在结尾执行 complete()，操作 job 内的链表结构
|
||||
|
||||
这就是典型的跨线程 Use-After-Free（UAF）漏洞。
|
||||
|
||||
### 利用是怎么一步步进行的？
|
||||
|
||||
|
||||
攻击者通过 Unix domain socket 消息喷洒大量小块内核堆对象，迅速重占释放的 job 内存，从而控制 job->regs（写入目标地址）。同时通过让硬件“不执行任何任务”，确保结束时的寄存器状态几乎与初始相同，从而精确控制写入内容。
|
||||
|
||||
这样就得到一个 2144 字节的半任意内核写原语。因为 Pixel 的 kASLR 实际存在固定线性映射偏移（无需完整泄露），可以直接针对内核 .data 区。
|
||||
|
||||
为了避免 worker 线程结尾的 complete() 操作导致崩溃（它会操作已释放对象的 swait_queue_head 链表），攻击者在 .data 区伪造安全的链表节点，指向无害的 init_task 结构。
|
||||
|
||||
随后利用这个大块写原语分两步：
|
||||
1. 先覆盖一个文件系统类型的 name 字符串指针，通过读取 /proc/self/mounts 泄露内容，转为可靠任意读，计算出真实 KASLR slide。
|
||||
|
||||
1. 再覆盖 ashmem 驱动的 fops 表，用 configfs 的 handler 制造类型混淆，通过普通 ASHMEM_SET_NAME ioctl 实现精准任意读写。
|
||||
|
||||
最终：关闭 SELinux 强制模式，fork 新进程，把它的 creds 指针改成 init_cred——瞬间获得 root 权限。
|
||||
|
||||
这一阶段的 payload 作为 Dolby 阶段的 shellcode 注入，体积仅几 KB（甚至用 LLM 辅助生成 syscall wrapper 以进一步压缩）。
|
||||
|
||||
## 第三阶段：经验教训与改进建议
|
||||
|
||||
|
||||
这个仅用两个漏洞的利用链，暴露了 Android 生态的几个系统性问题：
|
||||
- AI 功能无意扩大 0-click 攻击面，把不常用解码器（如 UDC）纳入高危路径
|
||||
|
||||
- 内核驱动仍是“软目标”，漏洞易找且影响大
|
||||
|
||||
- 部分关键防护在 Pixel 上未完全生效（如 seccomp 缺失、kASLR 实际可绕、MTE 未默认开启）
|
||||
|
||||
- 补丁延迟严重：UDC 漏洞报告后 139 天才有设备修补，Pixel 又晚近两个月，部分因厂商低估沙箱内 RCE 严重性
|
||||
|
||||
Project Zero 建议：
|
||||
- 从 0-click 路径移除不常用解码器
|
||||
|
||||
- 系统性 fuzz 和审计所有 0-click 攻击面
|
||||
|
||||
- 驱动逐步向 Rust 重写、严格限制无特权进程访问
|
||||
|
||||
- 强制启用 seccomp、编译时加 -fbounds-safety、默认开启 MTE
|
||||
|
||||
- 调整漏洞优先级矩阵，至少把利用链中一环评为 Critical
|
||||
|
||||
- 更多核心组件采用 APEX 机制实现 Play Store 快速更新
|
||||
|
||||
原文链接：
|
||||
- Part 1: https://projectzero.google/2026/01/pixel-0-click-part-1.html
|
||||
|
||||
- Part 2: https://projectzero.google/2026/01/pixel-0-click-part-2.html
|
||||
|
||||
- Part 3: https://projectzero.google/2026/01/pixel-0-click-part-3.html
|
||||
|
||||
#
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
# CNNVD关于微软多个安全漏洞的通报
|
||||
CNNVD
|
||||
CNNVD CNNVD安全动态 2026-01-16 14:12
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞情况**
|
||||
|
||||
近日，微软官方发布了多个安全漏洞的公告，其中微软产品本身漏洞111个，影响到微软产品的其他厂商漏洞3个。微软Microsoft Windows、Microsoft Dynamics、Microsoft Graphics Kernel、Microsoft Windows Remote Procedure Call Runtime等多个产品和系统受漏洞影响。目前，微软官方已经发布了漏洞修复补丁，建议用户及时确认是否受到漏洞影响，尽快采取修补措施。
|
||||
|
||||
## 一漏洞介绍
|
||||
|
||||
|
||||
2026年1月13日，微软发布了2026年1月份安全更新，共114个漏洞的补丁程序，CNNVD对这些漏洞进行了收录。本次更新主要涵盖了Microsoft Windows 和 Windows 组件、Microsoft Dynamics、Microsoft Graphics Kernel、Microsoft Windows Remote Procedure Call Runtime、Microsoft SharePoint、Microsoft Windows NTFS等。CNNVD对其危害等级进行了评价，其中超危漏洞1个，高危漏洞81个，中危漏洞32个。
|
||||
|
||||
微软多个产品和系统版本受漏洞影响，具体影响范围可访问微软官方网站查询：
|
||||
|
||||
https://portal.msrc.microsoft.com/zh-cn/security-guidance
|
||||
|
||||
****
|
||||
## 二漏洞详情
|
||||
|
||||
|
||||
此次更新共114个漏洞的补丁程序，包括111个新增漏洞的补丁程序和3个影响微软产品的其他厂商漏洞的补丁程序。
|
||||
|
||||
此次更新共包括111个新增漏洞的补丁程序，其中高危漏洞80个，中危漏洞31个。
|
||||
|
||||
|
||||
|
||||
此次更新共包括3个影响微软产品的其他厂商漏洞的补丁程序，其中超危漏洞1个，高危漏洞1个，中危漏洞1个。
|
||||
|
||||
|
||||
|
||||
## 三修复建议
|
||||
|
||||
|
||||
目前，微软官方已经发布补丁修复了上述漏洞，建议用户及时确认漏洞影响，尽快采取修补措施。微软官方补丁下载地址：
|
||||
|
||||
https://msrc.microsoft.com/update-guide/en-us
|
||||
|
||||
CNNVD将继续跟踪上述漏洞的相关情况，及时发布相关信息。如有需要，可与CNNVD联系。联系方式: cnnvd@itsec.gov.cn
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,94 @@
|
||||
# 【接口漏洞第六章第三节】隐藏在“&”和“#”背后的秘密：我是如何通过参数污染接管管理员账户的
|
||||
原创 升斗安全XiuXiu
|
||||
升斗安全XiuXiu 升斗安全 2026-01-16 15:01
|
||||
|
||||
**【文章说明】**
|
||||
- **目的**
|
||||
：本文内容仅为网络安全**技术研究与教育**
|
||||
目的而创作。
|
||||
|
||||
- **红线**
|
||||
：严禁将本文知识用于任何**未授权**
|
||||
的非法活动。使用者必须遵守《网络安全法》等相关法律。
|
||||
|
||||
- **责任**
|
||||
：任何对本文技术的滥用所引发的**后果自负**
|
||||
，与本公众号及作者无关。
|
||||
|
||||
- **免责**
|
||||
：内容仅供参考，作者不对其准确性、完整性作任何担保。
|
||||
|
||||
**阅读即代表您同意以上条款。**
|
||||
|
||||
****
|
||||
在关于“
|
||||
api接口参数污染漏洞”的前面两小节中，我们对
|
||||
参数污染的漏洞原理和利用方法都有较深的了解了，但并没有结合实际的真实场景来进行演练过。今天，我们就结合一个实际场景来对之前的一些理论知识做一次实战演练。
|
||||
|
||||
这次的实战场景是需要我们通过“
|
||||
参数污染
|
||||
”漏洞，来污染、发现系统中的脆弱点，并最终实现对超级管理员的接管，进行相关权限的操作。
|
||||
|
||||
同样的，访问系统功能，并审查访问系统后一些请求接口，看是否存在一些特殊接口。然后再进行下一步操作
|
||||
|
||||
我们发现一个有post请求的“忘记密码”的请求接口，且参数格式比较常见，我们就拿这个接口进行尝试突破：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
如上面，在随意输入用户名后，服务器会返回用户名不存在的提示。当用户名存在时，会直接触发服务器给对应用户的邮箱发送找回密码的动作。
|
||||
|
||||
这就非常可疑，我们猜测这个接口就存在服务器接口参数污染的情况。我们结合之前章节说到的一些方法来对这个接口进行深入测试。
|
||||
|
||||
首先，我们使用
|
||||
& 符号进行测试，注意使用url编码后的字符，即 %26 进行测试，直接拼接在用户名后，会发现服务器直接返回了“不支持该
|
||||
参数”
|
||||
的提示信息，这说明服务器很可能是将 & 符号后面的内容当做单独的一个参数，而不是用户名的一部分了。
|
||||
|
||||
|
||||
|
||||
虽然可以判断通过这个符号进行参数污染后，得知这个接口还存在其他参数了，但要怎么样继续挖掘后续参数呢？这个时候就要使用到
|
||||
# 符号了，用这个符号来进行截断，并看看服务器是否有一些信息返回，以辅助我们进一步挖掘。当然，也是要采用url编码后的字符 %23 来测试的，具体如下：
|
||||
|
||||
|
||||
|
||||
比较幸运的是，通过这个截断字符，我们得到的系统服务器返回的，缺少参数
|
||||
field ,这很重要！这说明我们已经做到了第一步，通过参数污染，找到了隐藏参数
|
||||
field ，接下来，我们就继续挖掘这个参数的值。因为得到了有效的参数名，只是要爆破参数的具体值了，所以在之前已有的参数名和值“
|
||||
username=administrator
|
||||
”后面，就要用
|
||||
&
|
||||
来拼接后面要爆破的参数名和值。
|
||||
|
||||
同样的，在被爆破的参数值后继续使用截断符
|
||||
# 来校验，一旦爆破成功，服务器就因为这个符号的参数污染，而不会继续往后面请求。使用burpsuite的intruder进行服务器常用参数值的爆破。具体如下：
|
||||
|
||||
|
||||
|
||||
爆破后得到有效的服务器隐藏参数名和值，得知这个参数是有两个值的，分别是
|
||||
email 和
|
||||
username
|
||||
|
||||
|
||||
|
||||
通过以上方式，我们就挖掘得知系统的隐藏参数和值，但这还无法支撑我们进一步实现获取 administrator 权限。我们继续来看系统中有没有一些有用的信息。
|
||||
|
||||
在系统的一个js文件中，发现了这么一串内容：
|
||||
/forgot-password?reset_token=${resetToken}
|
||||
|
||||
这串内容疑似是更新用户token的接口，我们前面通过参数污染已经发现了服务器的隐藏参数 filed ,而且是在拼接对应的参数名 email 或 username 后，就会返回对应的用户的邮箱和用户名。那么极有可能将这个js 中的 reset_token 作为参数值，就能实现获取对应用户的token值。我们来试下：
|
||||
|
||||
|
||||
|
||||
发现果真如此，能够直接获取到当前用户的
|
||||
token。通过前面js中返回的路径，还有通过参数污染获取到的 administrator 的token值，我们就可以直接构造修改 administrator 的请求
|
||||
/forgot-password?reset_token=获取到的token值
|
||||
并实现修改 administrator 密码的操作。
|
||||
|
||||
以上就是通过参数污染以及结合在参数污染后服务器返回的内容，一步步挖掘并实现修改超级管理员密码并接管最高权限。
|
||||
|
||||
关于api接口漏洞的相关内容，这边会持续输出，感兴趣的你，别忘了点点关注。
|
||||
|
||||
觉得内容对你有用或无用，欢迎点赞或留言，这边会不断更正。
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# 【漏洞预警】Fortinet FortiClientEMS SQL注入漏洞CVE-2025-59922
|
||||
cexlife
|
||||
cexlife 飓风网络安全 2026-01-16 15:29
|
||||
|
||||
|
||||
|
||||
漏洞描述:
|
||||
|
||||
Fоrtinеt FоrtiCliеntEMS是一款由Fоrtinеt公司开发的终端管理软件,用于管理企业内部的终端设备,该软件支持多个版本，包括7.4.3至7.4.4、7.4.0至7.4.1、7.2.0至7.2.10以及7.0所有版本
|
||||
|
||||
在这些版本中存在一个SQL注入漏洞,该漏洞源于软件未能正确中和SQL命令中的特殊元素。攻击者若拥有至少只读管理员权限,可以通过精心构造的HTTP或HTTPS请求,执行未授权的SQL代码或命令
|
||||
|
||||
影响产品及版本:
|
||||
|
||||
Fortinet FortiClientEMS,受影响版本包括:
|
||||
|
||||
FortiClientEMS < 7.4.5
|
||||
|
||||
FortiClientEMS < 7.4.2
|
||||
|
||||
FortiClientEMS < 7.2.11
|
||||
|
||||
FortiClientEMS 7.0（所有子版本）
|
||||
|
||||
检测方法:
|
||||
|
||||
检查FortiClientEMS的配置和日志,寻找异常的SQL命令执行记录
|
||||
|
||||
尽快升级到FоrtiCliеntEMS的最新版本,并确保所有终端设备都应用了安全补丁
|
||||
|
||||
缓解方案:
|
||||
|
||||
限制只读管理员权限,避免不必要的权限滥用,并监控异常的数据库访问行为
|
||||
|
||||
建议措施:
|
||||
|
||||
立即升级：将所有FortiClientEMS实例升级至7.4.5或更高版本，或确认已应用官方补丁。
|
||||
|
||||
权限最小化：严格审查并限制“只读管理员”权限的分配范围，仅对必要人员开放，并启用多因素认证（MFA）。
|
||||
|
||||
日志监控与检测：在FortiClientEMS系统中开启详细审计日志，监控异常的SQL查询行为（如包含UNION, OR 1=1, sleep()等特征的请求）,结合日志分析系统进行实时告警。
|
||||
|
||||
网络隔离：将FortiClientEMS管理接口部署于隔离区域，限制非授权IP访问，并通过WAF规则过滤恶意请求模式。
|
||||
|
||||
漏洞扫描常态化：定期对内部管理平台执行漏洞扫描与渗透测试，识别类似权限滥用或输入验证缺陷。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,262 @@
|
||||
# 密码重置漏洞挖掘指南：从原理到实战的完整路径
|
||||
点击关注 👉
|
||||
点击关注 👉 马哥网络安全 2026-01-16 13:02
|
||||
|
||||
密码重置功能是Web应用中最常见也最核心的环节之一，它直接关系到用户账户的安全。正因为其普遍性和高敏感性，一个细微的逻辑缺陷都可能导致整个账户体系的沦陷。密码重置漏洞核心思路为：站在攻击者的角度，尝试劫持任意用户的密码重置流程。
|
||||
# 前言：
|
||||
|
||||
密码重置功能是Web应用中最常见也最核心的环节之一，它直接关系到用户账户的安全。正因为其普遍性和高敏感性，一个细微的逻辑缺陷都可能导致整个账户体系的沦陷。密码重置漏洞核心思路为：站在攻击者的角度，尝试劫持任意用户的密码重置流程，整个过程可以概括为以下几个关键步骤：
|
||||
|
||||
1、初始化重置：为目标用户（受害者）发起密码重置请求。
|
||||
|
||||
2、拦截/篡改凭证：获取或控制用于身份验证的重置凭证（如Token、验证码、USERID等）。
|
||||
|
||||
3、接管流程：将本应发送给目标用户的凭证，转发或引导至攻击者控制。
|
||||
|
||||
4、完成重置：利用获取到的凭证，最终修改目标用户的密码。
|
||||
|
||||
下文将围绕密码重置漏洞常见类型与挖掘思路展开讨论。
|
||||
## 1、客户端状态校验不全
|
||||
|
||||
客户端响应篡改是逻辑漏洞的常见形式。应用程序将本应存储在服务器端、并由服务器端完全掌控和校验的关键业务状态（如“是否已通过身份验证”），错误地委托给了不可信的客户端（如用户的浏览器或APP）来存储和维护。当客户端将这些状态值返回给服务器时，没有在服务器端对其进行二次验证或溯源。
|
||||
### 1.1漏洞利用
|
||||
|
||||
进入忘记密码，任意输入验证码抓包修改返回包中的参数状态值。比如常见的code改为0，false改为true等等。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
下来正常输入新密码点击下一步抓包，继续修改响应值，成功重置密码。
|
||||
|
||||
|
||||
### 1.2挖掘思路
|
||||
|
||||
（1）寻找目标场景
|
||||
|
||||
前台忘记密码，找回账号等诸如此类的功能。如前台没有对应忘记密码功能，可以从前端js中提取接口进行测试。
|
||||
|
||||
（2）测试服务端是否缺少校验
|
||||
|
||||
通过修改客户端返回的状态值（例如将 "verified": false 改为 "verified": true），看服务器是否仅依据此值判断步骤是否完成。
|
||||
## 2、步骤分离与校验不足
|
||||
|
||||
密码重置往往涉及多个步骤（如身份验证、Token验证、设置新密码），如果步骤间状态校验不足，可能绕过关键验证。
|
||||
### 2.1 漏洞利用
|
||||
|
||||
本地搭建Dedecms（版本5.7），创建账户test1以及test2。
|
||||
|
||||
|
||||
|
||||
登录test1账户，随后构建payload，id修改为要修改的账户的id
|
||||
|
||||
|
||||
|
||||
发送请求获取key，成功获取key值后即可修改目标账户密码。
|
||||
|
||||
|
||||
### 2.2挖掘思路
|
||||
|
||||
（1）测试步骤间状态关联性校验
|
||||
|
||||
尝试直接访问重置流程的各个步骤的URL（例如 /reset/step2、/reset/step3），而不完成其前置步骤。观察系统是否允许直接跳转至后续步骤，并在后续步骤的请求中，缺乏对前置步骤已完成的验证（例如，缺少一个能证明你已通过第一步验证的Token或Session标识）。
|
||||
|
||||
（2）操作参数以便越权至其他用户
|
||||
|
||||
分析每一步请求中用于标识状态或用户的参数（如 user_id、temp_token、session_id）检查其是否可预测并尝试修改这些参数（例如递增或递减user_id）以查看是否能切换到其他用户的重置流程，随后检查其是否在步骤间保持一致，第一步生成的Token或Session标识，是否在第二步、第三步的请求中被正确校验并与当前用户绑定。
|
||||
## 3、鉴权不严使用简单可预测的用户标识符
|
||||
|
||||
许多系统在对用户身份进行认证时，会使用简单的参数作为用户的唯一标识，缺少鉴权，而这类标识容易被攻击者预测。例如，某些系统直接将USERID作为用户密码重置时的标识，攻击者只需枚举其他用户的USERID即可重置其他用户密码。
|
||||
### 3.1 漏洞利用：
|
||||
|
||||
针对某购物网站进行包监听时发现某接口的响应如下：
|
||||
|
||||
|
||||
|
||||
在响应体中，包含如下参数："showResetPassword": false,"showModifyEmails": false，参数值表示用户角色禁用了密码重置和电子邮件修改选项。在burp中对该流量包进行拦截，并修改响应包。
|
||||
|
||||
|
||||
|
||||
刷新页面后会发现两个新选项：
|
||||
|
||||
|
||||
|
||||
此处后端接口返回 JSON 字段 "showResetPassword": false 仅用于前端 UI 决策，未在后端任何鉴权逻辑中二次校验。攻击者通过篡改响应包为 "showResetPassword": true，即可让前端渲染出重置密码按钮。
|
||||
|
||||
随后对所拥有的账户进行密码重置修改，系统返回200并提供了有效密码重置链接。
|
||||
|
||||
|
||||
|
||||
|
||||
访问后发现密码重置成功
|
||||
|
||||
|
||||
|
||||
拦截密码重置接口包，发现请求中包括用户的数字ID，其请求体仅包含：{ "userId": 9438868, "resetAccessKey": false }，没有其他的鉴权参数。该端点未检查当前会话是否具备对 userId 的操作权限，也未校验当前用户权限。
|
||||
|
||||
|
||||
|
||||
重新抓包，将USERID修改为另一个账户USERID，密码修改成功并成功登陆。
|
||||
|
||||
|
||||
|
||||
|
||||
系统采用可预测、单调递增标识符使用连续数字 userId，此时攻击者只需遍历整数区间即可批量枚举有效用户，重置其他用户的密码。
|
||||
### 3.2 挖掘思路：
|
||||
|
||||
（1）收集令牌样本
|
||||
|
||||
通过直接请求，找到应用程序中生成令牌的功能点（如密码重置、邮箱验证、会话ID分配），并反复触发这些功能。应用程序在日志、调试页面或错误信息中也会意外泄露其他用户的令牌。
|
||||
|
||||
（2）分析模式与结构
|
||||
|
||||
拿到样本后，首先观察令牌由哪些字符组成？（仅数字？数字+大写字母？数字+大小写字母？是否包含特殊字符等）。观察编码方式（如Base64、Hex、Base36。随后尝试解码，对令牌进行常见的解码操作。解码后的数据可能显示出更明显的模式（如时间戳、序列号或特定结构）。最后分割对比，将多个样本放在一起，对比每一位字符的变化情况。寻找其中固定不变的部分和规律变化的部分。
|
||||
|
||||
（3） 破解生成算法
|
||||
|
||||
如果令牌是纯数字，且样本值接近当前时间，可能是时间戳（10位或13位）或时间戳的简单变换（如乘以一个系数），你可以记录获取令牌的时间，与令牌值进行比对；如果令牌是32位或64位的十六进制字符串，可能是MD5或SHA-256等哈希值，也可以尝试在前端源码中下断点去破解生成密码的算法等。另外可以尝试猜测其原始输入（如用户ID + 时间戳、邮箱 + 固定盐值），并进行哈希比对。如果你能获得足够多的连续输出，就有可能推断出内部状态并预测后续值。
|
||||
## 4、账号与校验参数未绑定
|
||||
|
||||
密码重置流程通常需要向用户发送验证凭证（如Token、验证码），如果接收端参数由客户端提供且可篡改，则可能导致凭证发送至攻击者控制的地址，下面将结合案例进行说明：
|
||||
### 4.1 漏洞利用
|
||||
|
||||
**案例一：接收端可篡改，请求包中包含接收端参数，可将凭证发至指定接收端。**
|
||||
|
||||
密码重置页面，输入任意普通账号，选择邮箱方式找回密码。在身份验证页面点击获取短信验证码：
|
||||
|
||||
|
||||
|
||||
拦截请求，发现接收验证码的邮箱为请求包中的参数，而此参数可控，直接篡改为攻击者的邮箱，此时攻击者成功接收邮箱验证码。
|
||||
|
||||
|
||||
|
||||
提交验证码后抓包修改其中邮箱为获取验证码的邮箱。此时仅校验了验证码与邮箱是否绑定，只要输入正确的验证码即可通过验证。下来正常执行 3、4 步即可成功重置该账号的密码。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
此处漏洞形成的主要原因就是服务器未绑定实际要重置得账号和验证码，导致输入其他用户邮箱正确的验证码也可以重置当前用户的密码。
|
||||
|
||||
**案例2：验证码转发**
|
||||
|
||||
在测试任意密码重置时，可以尝试在关键参数后面添加多个参数，转发验证码到攻击者。
|
||||
|
||||
|
||||
|
||||
攻击者收到验证码后直接填写验证码即可完整密码重置，修改受害人密码。
|
||||
|
||||
**案例三：利用校验正确验证码或者其他校验获取到正确凭证后，在凭证有效期内实现重置其他用户密码**
|
||||
|
||||
在密码重置流程的关键步骤（获取验证码、校验验证码生成凭证、使用凭证重置密码）中，使用重置密码凭证执行最终重置操作时，服务端没有严格校验和绑定令牌与最初申请者的身份关系，仅仅校验令牌是否失效或者是否使用。导致攻击者可以利用此缺陷，将本应属于用户A的权限“转移”或“应用”到用户B身上，从而实现越权操作。
|
||||
|
||||
|
||||
|
||||
当用户已经验证过验证码，在正确验证有效期内攻击者同时做重置密码操作，此时可以利用令牌未失效的情况下实现任意密码重置。
|
||||
|
||||
|
||||
|
||||
输入正确验证码后会触发校验接口，获取重置当前密码的凭证。另一个账号同样按以上方式操作，利用获取到正确凭证的间隙。回到攻击账号输入新密码抓包。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
看到其中有控制要重置账号密码的参数，修改此参数为受害人的参数即可重置其他用户的密码。
|
||||
### 4.2 挖掘思路
|
||||
|
||||
（1）还原正常的密码重置流程
|
||||
|
||||
记录关键步骤，通常包括输入用户名/邮箱/手机号、发送验证码、输入验证码、设置新密码等。随后拦截和分析请求，使用工具拦截每一个步骤的HTTP请求，仔细观察请求参数、响应内容。最后注意接收端如何被指定，在发送验证码的请求中，系统是直接从数据库查询与账号绑定的接收端，还是通过客户端传递的参数来指定。
|
||||
|
||||
（2）识别接收端参数
|
||||
|
||||
在拦截的请求中，仔细寻找任何可能与接收端相关的参数。这些参数可能是直接的，也可能是间接的。
|
||||
|
||||
直接参数：phone, mobile, phoneNumber,email, mail,to, receiver等
|
||||
|
||||
间接参数：user_id, uid, id，username, user_name, login_name,account等
|
||||
|
||||
（3）测试参数的可篡改性
|
||||
|
||||
发现可疑参数后，尝试篡改其值：
|
||||
|
||||
直接替换：如果参数直接指定了接收端（例如 phone=13333333333），尝试将其修改为你自己控制的接收端（例如你的手机号 phone=你的手机号），然后放行请求，观察验证码是否发送到了你的设备。
|
||||
|
||||
间接关联：如果参数是用户标识（例如 user_name=target_user），尝试将其修改为另一个你控制账户的用户名（例如 user_name=attacker）。系统可能会将验证码发送到 attacker 账户绑定的手机/邮箱，而你正好能访问这个接收端。
|
||||
|
||||
参数污染：尝试添加多个相同的参数（例如 phone=victim_phone&phone=attacker_phone），观察系统如何处理多个值。
|
||||
|
||||
（4）测试步骤间的关联性缺失
|
||||
|
||||
许多密码重置功能分多个步骤。测试在不同步骤中，系统是否正确地关联了用户身份和接收端，例如你输入目标用户名（userName=target_user），系统确认用户存在，随后拦截发送验证码的请求，该请求中可能有一个参数（如 user_name）用于指定从哪个用户获取绑定手机号。尝试将其修改为攻击者的用户名（user_name=attacker）。如果系统没有检查这个 user_name 是否与第一步的 userName 一致，就可能会将验证码发送到攻击者绑定的手机号上。
|
||||
|
||||
（5）测试验证码与接收端的绑定校验
|
||||
|
||||
在提交验证码和设置新密码的阶段，会再次校验验证码与目标用户是否匹配，可以尝试用接收到的验证码去重置目标用户的密码。如果成功，说明系统只验证验证码本身的有效性，而没有校验该验证码是由哪个用户请求、发送至哪个接收端的，就会存在严重逻辑缺陷。
|
||||
|
||||
|
||||
文章内容转自奇安信攻防社区
|
||||
|
||||
原作者：中铁13层打工人（侵删）
|
||||
|
||||
****
|
||||
|
||||
|
||||
|
||||
**今日福利**
|
||||
|
||||
为了帮助大家早日习得网络安全核心知识，快速入行网络安全圈，给大家整理了一套**【2026最新网安资料】**
|
||||
网络安全工程师必备技能资料包（文末一键领取），内容有多详实丰富看下图！
|
||||
|
||||
Web安全
|
||||
👇
|
||||
|
||||
|
||||
|
||||
渗透测试
|
||||
👇
|
||||
|
||||
|
||||
|
||||
安全面试题
|
||||
👇
|
||||
|
||||
|
||||
|
||||
代码审计
|
||||
👇
|
||||
|
||||
|
||||
|
||||
红队笔记
|
||||
👇
|
||||
|
||||
|
||||
|
||||
入门视频👇
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
以上所有资料获取请扫码
|
||||
|
||||
|
||||
|
||||
识别上方二维码
|
||||
|
||||
备注：
|
||||
**2026安全合集**
|
||||
|
||||
100%免费领取
|
||||
|
||||
（是扫码领取，不是在公众号后台回复，别看错了哦）
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# 美国网络安全和基础设施安全局 (CISA) 命令联邦政府修复 Gogs 远程代码执行漏洞，该 0 day 漏洞已被攻击利用
|
||||
Rhinoer
|
||||
Rhinoer 犀牛安全 2026-01-16 16:00
|
||||
|
||||
|
||||
|
||||
美国网络安全和基础设施安全局 (CISA) 已下令政府机构保护其系统免受 Gogs 高危漏洞的攻击，该漏洞曾被用于零日攻击。
|
||||
|
||||
Gogs 的设计初衷是作为 GitLab 或 GitHub Enterprise 的替代方案，它使用 Go 语言编写，通常在线开放以进行远程协作。
|
||||
|
||||
该远程代码执行 (RCE) 安全漏洞被追踪为CVE-2025-8110，它源于 PutContents API 中的路径遍历弱点，允许经过身份验证的攻击者通过符号链接覆盖存储库外部的文件，从而绕过针对先前已修复的 RCE 漏洞 (CVE-2024-55947) 实施的保护措施。
|
||||
|
||||
攻击者可以利用此漏洞，创建包含指向敏感系统文件的符号链接的仓库，然后使用 PutContents API 通过符号链接写入数据，从而覆盖仓库外部的目标。通过覆盖 Git 配置文件（特别是 sshCommand 设置），攻击者可以强制目标系统执行任意命令。
|
||||
|
||||
Wiz Research 在 7 月份调查影响客户面向互联网的 Gogs 服务器的恶意软件感染时发现了该漏洞，并于 7 月 17 日向 Gogs 维护人员报告了该缺陷。三个月后，即 10 月 30 日，他们确认了 Wiz 的报告，并在上周发布了针对 CVE-2025-8110 的补丁，该补丁在所有文件写入入口点添加了符号链接感知路径验证。
|
||||
|
||||
根据 Wiz Research 分享的披露时间表， 11 月 1 日出现了第二波针对此零日漏洞的攻击。
|
||||
|
||||
在调查这些攻击活动的过程中，Wiz 的研究人员发现超过 1400 台 Gogs 服务器暴露在网上（其中 1250 台仍然暴露），以及超过 700 个实例显示出被入侵的迹象。
|
||||
|
||||
|
||||
|
||||
CISA 现已确认 Wiz 的报告，并将该安全漏洞添加到其已被利用的漏洞列表中，并命令联邦民事行政部门 (FCEB) 机构在三周内（即 2026 年 2 月 2 日之前）进行修补。
|
||||
|
||||
FCEB 机构是指美国非军事行政部门机构，例如能源部、司法部、国土安全部和国务院。
|
||||
|
||||
此类漏洞是恶意网络攻击者常用的攻击途径，对联邦机构构成重大风险，”CISA警告说。“请按照供应商说明采取缓解措施，遵循适用于云服务的BOD 22-01指南，或者如果无法采取缓解措施，则停止使用该产品。
|
||||
|
||||
为了进一步减少攻击面，建议 Gogs 用户立即禁用默认的开放注册设置，并使用 VPN 或允许列表限制服务器访问。
|
||||
|
||||
此外，想要检查 Gogs 实例是否存在入侵迹象的管理员应该查找 PutContents API 的可疑使用情况，以及在两次攻击期间创建的具有随机八字符名称的存储库。
|
||||
|
||||
|
||||
信息来源：Bleepingcomputer
|
||||
|
||||
Reference in new issue
Block a user