Gogs管理端CSRFGit Hook RCE完整指南Exploitarium两步链从跨站伪造到代码执行【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitariumExploitarium是一个公开漏洞 PoCProof of Concept概念验证与研究写作的存档合集收录了多个尚未上报的漏洞利用研究。本次聚焦其中一条精彩案例针对Gogs自建 Git 代码托管平台的管理端CSRF跨站请求伪造漏洞结合Git HookGit 钩子RCE远程代码执行仅需两步就能从伪造管理员请求一路打到在服务器上执行任意命令。本文用通俗的方式拆解这条攻击链的每一步帮你理解跨站伪造漏洞如何升级成代码执行。什么是 Gogs 管理端 CSRF 漏洞先补两个背景概念Gogs一款开源的轻量级 Git 服务常用于团队自建 Git 仓库可理解为自托管版 GitHub。CSRF跨站请求伪造攻击者诱导已登录的受害者在不知情的情况下由浏览器向目标网站发出带受害者身份的请求。关键在于——网站没有校验这个请求真的是用户本人主动提交的吗。这条漏洞的根源在于Gogs0.15.0dev版本中管理后台的用户编辑表单POST /admin/users/:userid在服务端不校验任何 CSRF 令牌。该表单恰好有两个危险开关admin设为站点管理员和allow_git_hook允许编辑 Git 钩子。攻击者构造一个跨站请求只要登录中的管理员点了某个链接表单就会被替管理员提交——攻击者自己的账号瞬间被加上管理员权限和 Git Hook 编辑权限。两步链从跨站伪造到代码执行整条攻击链只有两步但每一步都踩在关键点上第一步CSRF 提权——普通账号变管理员攻击者向 Gogs 发送一个伪装成跨站提交的请求请求头中带有Sec-Fetch-Site: cross-site等跨站特征表单内容只做了两件关键事adminon allow_git_hookon服务端直接信任了管理员会话把攻击者账号的IsAdmin与AllowGitHook两个字段改写为开启状态。数据库里的变化一目了然攻击前(2, attacker, ..., 0, 0, 1) ← 无管理员、无 Hook 权限 攻击后(2, attacker, ..., 1, 1, 1) ← 已是站点管理员此时攻击者再登录Web API 会如实报告isAdmin: true。提权完成。✅第二步Git Hook RCE——一次普通 push 触发任意命令执行有了管理员身份攻击者走原生 Gogs 网页路由创建一个仓库再通过官方的 Git Hook 编辑器写入post-receive钩子脚本。这个钩子的内容非常朴素#!/bin/sh id /tmp/gogs_hook_proof.txt pwd /tmp/gogs_hook_proof.txt之后攻击者只需执行一次普通的git pushGogs 服务端就会在推送处理流程中执行custom_hooks/post-receive脚本——任意命令以 Gogs 服务进程的权限落地运行。实测验证输出显示命令确实被执行uid1000(owner) gid1000(owner) groups1000(owner),...服务端日志也留下了完整证据链管理员账号更新记录、仓库创建记录、以及推送触发的TriggerTask事件。PoC 文件结构研究材料都在哪本案例的完整材料位于gogs-admin-csrf-git-hook-rce-poc/目录核心文件只有两个文件作用gogs-admin-csrf-git-hook-rce-poc/README.md漏洞文档受影响版本、源码调用链追踪、验证记录、修复方向gogs-admin-csrf-git-hook-rce-poc/poc.py单文件 PoC 脚本仅用 Python 标准库 系统git命令PoC 脚本的执行流程可以概括为 8 步用管理员账号建立会话或直接注入管理员会话 Cookie发送带跨站请求头的 CSRF 表单给攻击者账号提权以攻击者身份登录确认 API 返回isAdmin: true通过/repo/create创建攻击者仓库通过/settings/hooks/git/post-receive写入钩子脚本关键逻辑见 poc.py通过 HTTP 协议克隆该仓库提交一个触发文件并git push输出仓库信息、push 结果与标记文件内容形成完整证据。其中模拟跨站请求的核心代码非常短就是发送一个带Origin/Referer指向外部站点的 POST参见 poc.py直观展示了为什么没有 CSRF 校验就能伪造成功。README 中还附了一张源码追踪表把从路由注册cmd/gogs/internal/web/web.go、无令牌表单模板templates/admin/user/edit.tmpl、参数绑定internal/form/admin.go到钩子执行cmd/gogs/hook.go的完整路径一一列清非常适合学习如何阅读 Go 项目的请求处理链。本地复现环境要求与运行方式复现前需要克隆整个 Exploitarium 存档git clone https://gitcode.com/GitHub_Trending/ex/exploitarium验证环境要求详见 README.mdPython3.10 与系统git命令行一台原版未打补丁Gogs0.15.0dev实例验证用 commit5f51118ab513522462a54cef30599d7ddffcc55f一个站点管理员账号 一个普通攻击者账号一个 Gogs 进程可写的服务器标记路径如/tmp/gogs_hook_proof.txt。运行一条命令即可完成全流程复现脚本支持两种管理员身份注入方式账密模式--admin-user--admin-password脚本自动登录会话模式--admin-cookie直接复用已登录管理员的浏览器会话 Cookie更贴近真实诱导管理员点链接的场景。本地验证时再追加--local-marker参数指向标记文件的宿主机路径脚本会直接打印标记内容让你亲眼看到命令确实执行了。️修复方向与防御建议README 给出的修复建议对任何 Web 开发者都有参考价值核心五招恢复服务端 CSRF 校验对所有需要会话认证的非安全方法POST/PUT/DELETE强制校验表单内嵌一次性令牌经典 HTML 表单应包含每次请求不同的 CSRF token校验请求头元信息对敏感的状态变更路由校验Origin、Referer与 Fetch Metadata 头高危变更二次确认授予管理员权限、Git Hook 权限、改密码等操作应要求重新认证或二次确认收紧钩子权限并审计Git Hook 编辑是高风险权限每次更新都应记录审计日志。对 Gogs 用户而言最直接的行动是升级到已修复版本并检查现有账号中是否存在被异常开启admin或 Git Hook 权限的条目。️写在最后负责任地使用Exploitarium 仓库明确强调这些材料仅可用于自有的、已获授权的测试系统与防御性回归工作。作者发布这些未上报的 PoC初衷是把更多人吸引进安全研究这个领域而非提供武器——滥用这些漏洞属于违法行为请务必守住边界。如果你对CSRF 如何与高权限功能组合成完整攻击链感兴趣本案例堪称教科书式样本一条无令牌的表单 一个原生钩子编辑器两步完成从跨站伪造到 RCE 的跨越。完整研究写作用中文环境阅读无障碍建议直接精读 gogs-admin-csrf-git-hook-rce-poc/README.md仓库中的 cves.md 则汇总了该研究已获得的 CVE 编号方便你了解后续披露进展。【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考