1. 先搞懂Git才明白为什么“泄露”会发生1.1 Git到底在本地存了什么很多人对Git的印象停留在“它是一个版本控制工具”日常操作就是git add、git commit、git push剩下的全靠IDE点按钮。但真正遇到Git泄露问题的时候你如果只懂这三个命令会完全不知道从哪儿下手。Git和SVN这类集中式版本控制最大的区别在于Git的每个仓库都是一个完整的“本地镜像”。你在本地执行git init或者git clone之后项目根目录下会产生一个.git文件夹这个文件夹里保存的不只是“当前版本的源代码”而是从第一次提交到现在为止的全部提交历史、全部版本快照、全部分支引用、全部提交者信息。换句话说开发这台机器上曾经出现过的任何代码片段包括已经删除的文件、写错了又改回来的内容、配置里的数据库密码都被安静地记录在.git/objects下面。具体来说.git目录里几个关键位置config仓库配置里面可能有远程仓库地址、用户信息甚至残留的账号Token。HEAD指向当前分支的引用通常内容就是ref: refs/heads/master。index暂存区快照记录了当前已经git add但还没有提交的文件状态。objects/Git的对象数据库所有的commit、tree、blob都以压缩形式存在这里。logs/所有分支的完整操作记录包括reset、rebase、checkout的历史。refs/分支和标签的引用。拿生活打个比方.git目录就像你家书房里的一本“全屋改造流水账”不仅记着现在房子长什么样还记着十年前砸掉的那堵墙、五年前拆掉的阳台、前任业主留下的水管路线图。外人只要拿到这本账本就能把你家翻个底朝天。所以当网站服务器把.git目录暴露出来的时候攻击者拿到的不是“一份源码”而是这个项目从出生到现在的完整时间线。很多CTF题目里的flag就藏在某个已经被“遗忘”的历史提交里。1.2 导致Git泄露的三类部署现场Git泄露在真实世界里非常常见我总结下来基本就三类原因。第一类是开发环境打包上线。开发者在本地把项目开发完直接把整个项目文件夹往服务器上一扔.git目录也没删。如果Web服务器把项目根目录作为网站根目录那外部就能通过http://目标/.git/直接访问。第二类是服务器上用git做自动化部署。很多团队用git pull或者git clone把代码同步到生产服务器但搞完以后没有把.git目录删掉或者没有在Nginx/Apache层面对.git、.svn这类隐藏目录做访问拦截。这时候服务器上的“代码副本”带着完整的历史记录等于把开发仓库明晃晃地摆在了门口。第三类是Web服务器配置失误。nginx的root配置指到了项目上一级目录或者Apache的Options Indexes开启了目录列表导致.git里的文件能被逐个列出来。这种情况下即使开发者没有刻意上传.git目录只要公共目录里存在它就会被扫出来。这里要强调一个关键点Git泄露和.git目录本身没有必然的“漏洞”关系真正的漏洞是Web服务器把不该公开的静态文件目录暴露了出去。Git本身没有安全机制去防止别人读取这些文件它只管记录版本不管“谁能看”。所以你在实战里发现带有.git的网站大概率不是网站被黑了而是部署流程不规范。1.3 一次泄露可能暴露多少东西如果你的目标是CTF拿flag那Git泄露通常能让你拿到源码然后在源码里找答案。但如果是真实环境一次Git泄露能暴露的东西远不止源代码全部历史版本的源码包括被删除、被掩盖的敏感功能。config文件里的数据库连接串、第三方API密钥、后台登录凭证。测试环境和正式环境的差异代码比如测试环境里开了调试模式。提交者姓名、邮箱、提交时间可以用于后续钓鱼或社工。未公开的内部接口文档、自动化脚本中的用户名密码。所以Git泄露在OWASP和各类安全测试里都被列入“信息泄露”类高危问题危害程度一点都不低。2. 环境准备Git安装、dirsearch与githack2.1 先把Git装好完成基础配置用Git处理泄露仓库之前你自己机器上得先有一个能用的Git环境。Windows用户最省事的方式是去Git官网下载Git for Windows一键安装装的时候默认选项即可但有一个点要注意在“Adjusting your PATH”这一步建议选“Git from the command line and also from 3rd-party software”这样稍后在cmd或者PowerShell里也能直接敲git。如果选错了装完以后在cmd里敲git会提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。Linux用户更简单Debian系执行apt install gitRedHat系执行yum install git装完验证一下版本git --version正常会输出类似git version 2.39.2的内容。装完Git之后第一件事是配置用户名和邮箱否则后续操作提交时会报错git config --global user.name yourname git config --global user.email youremailexample.com这两个配置看起来只是提交信息但在分析Git泄露仓库的时候有一个实际的用途如果你下载下来的仓库需要继续执行git reset、git checkout这类操作部分版本会校验用户信息配置好可以避免一些莫名其妙的报错。另外我要特别推荐Windows用户把Git Bash当成主力终端。当你以后要跑dirsearch、githack这类Python脚本时Git Bash里路径处理、权限表现和Linux环境更接近能少踩很多坑。2.2 dirsearch用字典爆破目录Git泄露的入口是发现.git目录而发现目录最通用的思路就是目录扫描。dirsearch是目前使用频率最高的Web目录扫描工具之一Python编写跨平台字典丰富支持多线程对CTF和授权测试都足够用。安装很简单git clone https://github.com/maurosoria/dirsearch.git cd dirsearch pip install -r requirements.txt基本用法python3 dirsearch.py -u http://目标地址/ -e html,php,txt,bak,tar -x 403,404 --random-agent参数含义-u目标URL注意带不带末尾斜杠会影响结果建议带上。-e要检测的扩展名CTF里常见的是php、html、txt、bak、zip、tar。-x排除的状态码比如403和404可以排除减少噪音。--random-agent随机User-Agent避免被WAF拦截。dirsearch扫描的原理说白了就是拿一批常见目录名和文件名去请求目标然后根据Content-Length、状态码、响应头判断是否存在。所以它的检出能力很大程度依赖字典质量。实际CTF里.git这种目录几乎每个扫描器都会测命中率极高。如果你用不惯dirsearchgobuster、ffuf、御剑一类工具也可以替代但方向一致Web目录爆破。2.3 githack把.git还原成源码发现.git目录之后最忌讳的操作是拿浏览器直接访问/.git/objects/xxx一个文件一个文件地下。原因有两点第一Git对象文件数量庞大手动下载不现实第二即使你把所有文件下载下来它们也是压缩过的二进制对象不是直接能看的源码。正确做法是用专门工具解析.git目录结构并重建项目。最经典的是githack项目地址是lijiejie/GitHackclone下来就能用git clone https://github.com/lijiejie/GitHack.git cd GitHack python3 githack.py http://目标地址/.git/它会自动遍历.git下所有可访问的文件下载并利用Git自身的逻辑重建工作区文件。重建完以后你会在当前目录下得到一个完整的项目文件夹里面就是还原出来的源码。后来还有一个增强工具叫GitHacker兼容性更好针对一些不完整、缺失对象的情况做了处理git clone https://github.com/WangYihang/GitHacker.git cd GitHacker python3 githacker.py --url http://目标地址/.git/ --output-folder ./result我个人建议两个工具都装上因为有些靶场或真实站点对某些工具的请求特征做了防护换着用能有效避免扫描行为被识别。2.4 需要注意工具不是万能的很多人第一次用githack会发现下载下来的文件夹里只有一部分文件或者干脆是空的。这种情况通常有三种原因一是目标.git目录不完整部分对象缺失二是服务器做了访问频率限制工具请求太快被拒绝三是Web服务器对.git目录做了部分拦截比如只拦截了config、HEAD这些关键文件。遇到这种情况先别急着换工具可以先手动访问/.git/config和/.git/HEAD看看是否正常返回再决定下一步。3. 实操在CTFHub上把Git泄露完整打一遍3.1 为什么选CTFHub来做实验练习Git泄露最怕的就是拿真实网站练手这既有法律风险也不符合安全测试的基本伦理。CTFHub是一个在线CTF靶场平台它的技能树里专门有一块“信息泄露”其中“Git泄露”分了三道题Log、Stash、Index。这三道题正好对应了Git泄露最常见的三种利用方式非常契合实战中会遇到的情况。靶场地址我就不贴了你搜索“ctfhub 技能树 信息泄露”就能找到。每道题打开后会给一个独立域名和端口答题环境是隔离的随便折腾不影响到别人。3.2 常规Git泄露Log提交历史才是宝库先打开“Git泄露-Log”这题题目环境会给你一个URL类似http://challenge-xxxxx.ctfhub.com:10080/。第一步用dirsearch确认.git目录是否存在python3 dirsearch.py -u http://challenge-xxxxx.ctfhub.com:10080/ -e html,php,txt,bak --random-agent跑完之后重点看状态码200且路径为/.git/的记录。dirsearch扫到目录后可能出现两种结果一种是直接列出.git下文件列表另一种是只显示目录存在但禁止列目录。后者也很正常因为很多站点会关闭目录列表功能。第二步手动验证访问http://challenge-xxxxx.ctfhub.com:10080/.git/HEAD如果返回ref: refs/heads/master基本确认Git泄露成立。第三步用githack下载完整仓库python3 githack.py http://challenge-xxxxx.ctfhub.com:10080/.git/命令跑完后同目录下会出现一个以域名命名的文件夹里面就是目标项目的全部源码。切进这个目录执行git log --oneline --all这时候能看到该仓库的完整提交记录。Log这道题的考点就在这开发者可能在某次提交里写了flag然后又把它改掉了但历史提交里仍然保留着原始内容。我们只需要找到包含可疑内容的提交git log --all -p --grepflag或者直接逐个查看提交差异git show commit_id通常情况下flag就藏在某次提交的代码注释、配置文件或者输出函数里。执行git show时如果提交信息里正好有flag{...}相关字样一眼就能看到。这道题的命名“Log”指的就是攻击面在git log学习的时候可以记一下提交历史是最好的信息藏身处。3.3 Git泄露Stash开发者的临时改动被留下了第二道题是“Git泄露-Stash”。Stash在Git里的含义是“储藏”开发者临时有别的任务但手头的改动还没做完又不想提交于是执行git stash把改动暂时收起来。问题在于很多开发者把东西stash之后就忘了这个“半成品”就永远留在了.git目录里。githack下载这个仓库后第一步先看stash列表git stash list如果输出类似stash{0}: WIP on master: xxxxxxxxx说明存在未被恢复的暂存改动。接着查看stash内容git stash show -p stash{0}-p参数会显示具体的diff内容flag往往就加在这个diff里。如果这个stash里没有可以把所有stash都看一遍git stash show -p stash{1}我在实际做这题的时候还试过git stash show stash{0} --name-only先看看涉及哪些文件再决定要不要看完整内容这样更高效。有一个细节要注意在某些版本的Git中花括号在shell里有特殊含义所以在bash里执行git stash show -p stash{0}时可能被解释成参数扩展报“bad substitution”之类的错。这时候用单引号包起来就行git stash show -p stash{0}3.4 Git泄露Index从暂存区里“捞”回被删除的文件第三道题是“Git泄露-Index”。Index是Git的暂存区记录了“已经add但尚未commit”的文件状态。有些时候开发者把flag文件git add到了暂存区但后来因为某种原因又把它从工作区删了而且没有重新提交。这时候这个文件的信息已经在Git对象库里了只是工作目录里没有。githack下载后第一步用git ls-files这个命令列出暂存区里所有的文件。如果看到一个类似flag.txt或flag.php的文件但当前工作目录里不存在那就说明flag被“藏”在index里。恢复方式有两种git checkout -- flag.txt或者git cat-file -p blob对象id第二种方式需要先通过git ls-files --stage查一下对应文件的blob对象ID然后直接读取对象内容。两种方式都能拿到flag。这三道题的递进关系很明显Log考的是提交历史Stash考的是储藏记录Index考的是暂存区。三者覆盖了Git本地仓库中几个最容易残留敏感信息的位置。有兴趣的话可以自己做个实验在本地仓库里分别执行git commit --amend、git stash、git add后删除文件再git reset然后看看.git目录里留下了什么这样能更直观地理解这些攻击面的来源。3.5 完整利用流程小结把这套流程固化下来以后遇到Git泄露无论是不是CTF题都按这个顺序走目录扫描用dirsearch或手工请求/.git/HEAD、/.git/config确认目标是否存在Git泄露。仓库下载用githack或GitHacker把.git目录下载到本地并重建。信息搜集依次执行git log --all --oneline、git stash list、git ls-files把历史提交、储藏区、暂存区的信息全部拉出来。内容审计用git show、git stash show -p、git cat-file -p定位敏感信息重点看配置文件、注释、密钥和flag关键词。扩展利用如果目标是真实站点还需要检查config文件里的远程仓库地址有没有泄露其它仓库的访问权限检查提交者邮箱是否暴露了内部账号信息。这套流程其实不复杂难的是每一步都做到位。很多人扫到.git目录就急着用工具一把梭下载完也不知道该看什么最后空手而归。按部就班做基本都能拿到结果。4. 常见问题与排查技巧实录4.1 命令提示“无法将git识别为cmdlet”Windows上装完Git后在PowerShell里敲git --version报错提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这个我在新环境里遇到过很多次。原因就一个Git可执行文件路径没有加入系统环境变量PATH。解决办法有两个一是重装Git在“Adjusting your PATH”那一步选择第一项或第二项。二是不重装手动添加环境变量。找到Git安装目录下的cmd文件夹比如C:\Program Files\Git\cmd然后“系统属性 - 环境变量 - Path - 编辑 - 新建”把这个路径加进去保存后重开终端。如果不想改环境变量也可以用Git Bash它自带完整环境不需要单独配置PATH。4.2 dirsearch扫不到.git目录排除目标本身没有Git泄露的情况扫不到.git目录多半是以下原因字典里没有.git这条记录。虽然大部分主流字典都有但个别精简字典可能漏掉。建议扫描时再手工请求一次/.git/HEAD确认。目标做了大小写敏感访问控制。Git目录正常是小写.git但有些站点会把/.Git/、/.GIT/的请求拦截掉这时候要具体看服务器配置。扫描线程开太高触发了WAF拦截。dirsearch默认会输出大量404噪音如果目标有安全设备你的扫描行为可能被识别并拦掉。讲到这里我建议扫描时加-x 403,404排除无效状态码同时降低线程数到10以内避免被视为攻击。验证.git是否存在最快的不是等扫描完而是直接访问这两条URL/.git/HEAD /.git/config这两个文件是Git仓库的必备文件如果返回内容符合预期哪怕dirsearch没扫到也基本可以确定目标存在Git泄露。4.3 githack下载失败、卡住或文件不完整这类问题在实战里最磨人。githack原理是逐文件请求目标服务器如果目标网络慢、文件多或者服务器限速很容易超时。处理方法换GitHacker工具再打一次它的断点续传和容错做得更好。手动下载关键文件掌握这个思路对理解Git原理也有帮助。.git目录里最重要的是objects/下的对象文件和refs/heads/下的分支引用如果工具下载不完整可以用脚本遍历objects/info/packs以及objects/xx/目录手工下载然后放到本地仓库对应的位置再用git fsck检查仓库完整性。缩小范围如果只是CTF里找flag可以先下载.git/logs/和.git/refs/这两个目录记录了分支指向和操作历史配合对象下载可以更快定位flag所在的提交。4.4 下载了源码但执行git命令没反应githack重建出来的仓库有可能不是一个“完整仓库”因为它重建的主要是工作区文件不是标准的Git裸仓库。如果你发现git log执行后没有任何输出先检查一下是否缺少了应有的目录结构。常见问题是git log默认从当前分支HEAD开始查找但如果仓库的HEAD内容被还原成了refs/heads/master而refs/heads/master指向的commit对象没有下载下来就会表现为“无提交记录”。这时候试试git fsck --lost-found它可以列出对象库里所有没有被引用的对象flag有可能藏在这些“孤儿对象”里。4.5 最容易忽视的两个细节第一个细节别忘了查看.git/config。这个文件里经常有远程仓库地址如果泄露的仓库是从内网Git服务器clone的地址本身就能暴露内网域名或IP。在一些渗透测试场景里这个信息比源码还值钱。第二个细节不是所有信息泄露都以.git/开头。有些站点把.git目录打包成了www.zip、backup.tar放在网站根目录或者用了git bundle、git archive导出了包。所以扫描的时候除了扫描.git目录也要关注zip、tar、bak、rar这些备份文件。ctfhub里还有“备份文件下载”这个分类思路是相通的。4.6 说不完的避坑心得我在线下带着新人做这道题的时候最常说的一句话是遇到Git泄露先看log再看stash最后看index顺序不要乱。因为这三类信息出现的频率和对解题的帮助是递减的Log最容易出结果Index最隐蔽。如果一上来就钻index很可能浪费时间。还有一个使用习惯拿到githack还原的源码后不要直接在“下载目录”里乱翻先执行git log --all --oneline看一遍提交时间线。很多flag不是写在当前代码里而是写在“某一次”历史提交里你要做的是对比差异不是看最终版本。最后再分享一个小技巧如果你以后在工作中遇到真实站点疑似Git泄露可以先试试请求/.git/objects/info/packs。如果这个文件存在且列出了pack文件名说明这是一个经过gc压缩的仓库对象可能都在一个pack文件里。这种情况下githack这种逐文件下载的工具大概率会失效因为pack文件体积很大而且通常是二进制流手动分析难度也高。这时候更好的选择是直接尝试用curl把pack文件拉下来然后在本地用git index-pack之类的命令去解析。当然这属于进阶玩法了CTF里很少遇到但真实环境里遇到两次就能体会到这个技巧的价值。我个人的体会是Git泄露之所以好玩是因为它考验的不是某个单一漏洞的利用而是你对Git这个工具本身机制的理解程度。把.git当成一本“开发流水账”去读比背一百条命令都管用。