Git 漏洞主要分为两类:Git 软件本身的安全漏洞和因配置不当导致的 Git 仓库泄露。以下是详细解析及防御方案:
一、Git 软件自身漏洞(CVE 漏洞)
Git 客户端或服务端(如 GitLab、GitHub)的代码缺陷可能被利用,导致远程代码执行(RCE)、权限提升等风险。
典型案例
- CVE-2018-11235
-
- 漏洞类型:远程代码执行(RCE)。
- 触发条件:攻击者构造恶意 Git 子模块名称,当受害者执行
git clone --recurse-submodules
时触发。 - 影响版本:Git < 2.13.7、2.14.x < 2.14.4、2.15.x < 2.15.2 等。
- 修复方案:升级 Git 到安全版本。
- CVE-2022-24765
-
- 漏洞类型:路径遍历导致恶意代码执行。
- 触发条件:Git 在多用户系统上因默认配置不安全,攻击者通过
git clone
到特定路径提权。 - 防御措施:设置
safe.directory
配置项或更新到 Git >= 2.35.2。
二、Git 仓库泄露漏洞(配置不当)
因部署或配置错误,导致 .git
目录暴露在公网,攻击者可下载完整源码及历史记录。
攻击原理
- 暴露
.git
目录:
-
- 开发者将代码部署到服务器时,未删除
.git
文件夹。 - 服务器未配置禁止访问
.git
的规则(如 Nginx/Apache 未过滤)。
- 开发者将代码部署到服务器时,未删除
- 利用工具:
-
- 使用
dvcs-ripper
、GitHack
等工具可还原完整仓库:
- 使用
# 示例:用 GitHack 下载源码
python GitHack.py http://target.com/.git/
泄露风险
- 源码泄露:直接获取业务代码(含敏感逻辑)。
- 历史记录泄露:通过
git log
查看提交历史,可能发现硬编码的密码、密钥。 - 分支信息泄露:未合并的分支可能包含测试接口或未上线功能。
真实案例
- 案例1:某电商网站
.git
泄露,攻击者通过历史提交找到支付接口密钥,伪造交易。 - 案例2:企业 GitLab 配置错误,公网可访问内部仓库,导致员工个人信息泄露。
三、检测 Git 泄露
1. 手动检测
- 访问目标 URL,检查是否存在
.git
目录:
curl -I http://target.com/.git/HEAD
-
- 若返回
200 OK
且内容为ref: refs/heads/master
,则存在泄露。
- 若返回
2. 自动化工具
- 扫描工具:
-
- GitLeaks:检测代码中的敏感信息。
- TruffleHog:扫描 Git 历史中的密钥。
- 渗透工具:
-
- GitHacker:自动化下载并恢复
.git
仓库。
- GitHacker:自动化下载并恢复
四、防御措施
1. 防止 .git
泄露
- 部署前清理:
# 删除 .git 目录
rm -rf .git
-
- 使用 CI/CD 工具(如 Jenkins、GitLab CI)时,添加清理步骤。
- 服务器配置:
-
- Nginx 禁止访问
.git
:
- Nginx 禁止访问
location ~ /\.git/ {
deny all;
return 403;
}
-
- Apache 配置:
<DirectoryMatch .*\.(git|svn)/>
Require all denied
</DirectoryMatch>
2. 安全使用 Git
- 定期更新 Git:修复已知 CVE 漏洞。
- 审查敏感信息:
-
- 使用
git filter-branch
或BFG Repo-Cleaner
彻底删除历史中的密码、密钥。
- 使用
- 权限控制:
-
- GitLab/GitHub 设置最小化访问权限(如仅允许合并请求,禁止直接 push 到主分支)。
3. 监控与响应
- 日志监控:记录异常访问(如频繁请求
.git
目录)。 - 应急响应:若泄露发生,立即重置所有涉及密钥,删除历史记录。
五、Git 服务端安全(如 GitLab、Gitea)
- 及时升级:修复公开漏洞(如 GitLab 的未授权 RCE 漏洞 CVE-2022-2992)。
- 启用 2FA:强制用户开启双因素认证。
- 仓库加密:对敏感仓库进行静态加密(如使用
git-crypt
)。
总结
- Git 软件漏洞:关注 CVE 公告,及时升级版本。
- Git 仓库泄露:90% 源于配置错误,部署时务必清理
.git
并配置服务器规则。 - 安全习惯:代码审查时检查敏感信息,最小化仓库权限。
作为安全工程师,Git 泄露是渗透测试中的“低垂果实”,掌握其原理和利用工具能显著提升实战能力!