tinyopsec/gitward

   

**gitward** 是一款专为 OSINT、取证和供应链审计设计的命令行 git 仓库扫描工具。将其指向任何本地仓库，它就能提取出深藏在历史记录中的一切：密钥、作者身份、IP 地址、可疑 hooks、悬空提交、时区变化等。随后，它会对仓库的整体风险进行评分。 它完全通过 `git` 子进程运行。没有库，没有运行时依赖，没有网络调用。只需一个二进制文件和一份 git 副本。 ## 目录 - [为什么选择 gitward](#why-gitward) - [它能发现什么](#what-it-finds) - [风险评分](#risk-scoring) - [安装说明](#installation) - [使用方法](#usage) - [命令](#commands) - [输出格式](#output-format) - [密钥模式](#secret-patterns) - [可疑模式](#suspicious-patterns) - [贡献指南](#contributing) - [许可证](#license) ## 为什么选择 gitward Git 历史是永久且诚实的。开发人员在工作树中轮换密钥，却忘记了三个月前引入它们的提交。作者在工作机器上使用个人电子邮件。内部主机名通过 CI 配置泄露。Hooks 在无人审查的情况下被添加。 gitward 纵观全局：跨所有 ref 的每一次提交、reflog、stashes、notes、submodules、不可达的 blobs 以及 hook 脚本。然后，它会呈现出真正重要的内容。 它适用于： - 审计目标泄露或公开仓库的**红队** - 对内部仓库进行事后事件取证的**蓝队** - 希望添加 pre-push 或 CI 门禁以在密钥泄露前将其拦截的**安全工程师** - 想要知道自己在项目生命周期内究竟提交了什么的**开发人员** ## 它能发现什么 gitward 会收集 15 种线索类型： | 类型 | 描述 | |---|---| | `email` | 所有提交中的作者、提交者、配置和 Signed-off-by 电子邮件 | | `username` | 从电子邮件、`.git/config`、GPG 密钥和 Signed-off-by 尾部提取的用户名 | | `author` | 完整日志中唯一的作者和提交者姓名 | | `commit` | 每个带有主题和时间戳的可达提交哈希 | | `refname` | 分支、远程仓库、标签、reflog 条目和 notes | | `tag` | 附注标签和轻量级标签 | | `stash` | 所有 stash 条目 | | `url` | Remote URL、配置 URL 以及在 diff 内容中发现的 URL | | `domain` | 从 URL 提取的域名，以及内部的 `.corp`/`.local`/`.internal` 主机名 | | `ip` | 在 diff 历史记录中发现的 IPv4 和 IPv6 地址 | | `filepath` | 已跟踪的文件，并对敏感文件名（如 `.env`、`id_rsa`、`.npmrc`）发出警报 | | `secret` | 匹配 30 多条 regex 规则的凭据模式（见下文） | | `suspicious` | 危险的 shell 模式、强制推送指标、悬空提交、hook 风险、异常时间提交、时区偏移、高频变动删除、Docker 指令、VS Code 自动运行配置 | | `relation` | Submodule 路径和 GPG 签名的提交元数据 | | `timestamp` | 用于行为分析的提交时间戳 | 除了收集之外，gitward 还会检查： - 位于 `.git/hooks`、`.githooks` 和 `.husky` 中的 **Git hooks**：会对每一个 hook 进行网络调用、`base64 -d`、pipe-to-shell 模式及其他恶意意图迹象的评分 - **CI 配置**：标记 `.github/workflows`、`.gitlab-ci.yml`、`.travis.yml` 和 `Jenkinsfile` - **悬空 blobs**：运行 `git fsck` 并扫描不可达对象，以查找正常 `git log` 永远不会显示的凭据模式 - **VS Code 工作区配置**：捕获在打开仓库时立即执行代码的 `runOn: folderOpen` 和 `allowAutomaticTasks` 设置 - **时区偏移**：当具名作者在历史记录中跨多个时区进行提交时发出标记 - **异常时间提交**：标记在当地时间午夜至早上 6 点之间进行的提交 ## 风险评分 每次扫描都会生成一个数字风险评分： | 评分 | 含义 | |---|---| | 0–29 | 低风险 | | 30–99 | 值得审查 | | 100+ | 高风险，采取行动 | 评分是累加的。重点如下： - 可达提交中的密钥：**+20** - 不可达 blob（已删除，认为已经消失）中的密钥：**+80** - reflog 中的强制推送指标：**+30** - 悬空提交：**+10** - 评分 ≥ 50 的 hook（pipe-to-shell、`base64 -d`、网络调用）：**+100** - 评分 ≥ 30 的 hook：**+30** - 高频变动删除提交：**+15** - 文件被删除后又重新添加：**+20** - 每次异常时间提交都会累加评分 - 同一作者发生三次或更多次时区偏移：**+10** ## 安装说明 **环境要求：** C99 编译器、`make`，并且 `$PATH` 中需要包含 `git`。 ``` git clone https://github.com/tinyopsec/gitward cd gitward make sudo make clean install ``` 或者在不安装的情况下进行构建： ``` make ./gitward help ``` 使用显式标志进行构建： ``` cc -std=c99 -Wall -Wextra -pedantic -O2 -o gitward main.c scan.c clue.c ``` 不需要任何外部库。该二进制文件仅链接 C 标准库。 ## 使用方法 ``` gitward [args] ``` 所有命令都接受全名或单字母别名。 ``` gitward scan [path] scan a local git repository (default: .) gitward inspect [path] scan and print full report gitward search search clues by keyword gitward save [outfile] save results to file gitward version print version gitward help print help aliases: s=scan i=inspect f=search o=save ``` 快速示例： ``` # 扫描当前目录 gitward scan # 扫描特定 repo gitward scan /path/to/repo # 搜索 domain 或 string gitward search /path/to/repo corp.internal # 将结果保存为 plain text gitward save /path/to/repo results.txt # 将结果保存为 JSON（通过 .json extension 检测） gitward save /path/to/repo results.json ``` ## 命令 ### `scan` / `s` 扫描位于 `path`（默认为 `.`）的仓库，并将完整的检查报告打印到 stdout。运行所有收集器：提交、作者、refs、标签、stashes、reflog、notes、文件、远程仓库、git 配置、URL、IP、内部域名、submodules、GPG 签名、hooks、VS Code 配置、CI 配置、Docker 指令、悬空提交和 blobs、时区异常、异常时间提交、变动分析、signed-off-by 尾部和强制推送指标。 ### `inspect` / `i` 与 `scan` 相同。这两个命令都会扫描仓库并打印报告；`inspect` 的存在是为了方便您在脚本中明确表达读取意图的场合。 ### `search` / `f` 扫描仓库，然后根据 `query`（对值、作者、路径和额外字段进行不区分大小写的子字符串匹配）过滤所有收集到的线索。适用于进行信息追踪：查找涉及特定电子邮件、主机名或提交哈希的每一条线索。 ``` gitward search . alice@example.com gitward search /repos/target sk_live_ ``` ### `save` / `o` 扫描仓库并将结果写入 `outfile`（默认为 `gitward.out`）。如果 `outfile` 以 `.json` 结尾，结果将以 JSON 格式写入，并包含完整的字段元数据。否则，gitward 将使用扁平的 key=value 文本格式，适用于 grep 管道。 JSON 输出包括：`gitward_version`、`repo`、`scanned`（UTC 时间戳）、`risk_score`、`clue_count`，以及一个 `clues` 数组，其中每条记录都包含 `type`、`value`、`commit`、`author`、`path`、`extra` 和 `utc`。 ## 输出格式 当 stdout 是 TTY 时，终端报告会使用颜色（绿色代表干净，黄色代表警告，红色代表密钥和高风险）。各个部分： ``` ── REPOSITORY ───────────────────────────────────────────── path: /path/to/repo scanned: 2025-04-12T14:23:01Z git-size: 42M pack-size: 38M commits: 1847 authors: 12 refs: 34 ... secrets: 2 suspicious: 7 risk-score: 145 ── SECRETS ───────────────────────────────────────────────── [CRIT] AKIA... commit=a3f9c1 path=config/deploy.sh utc=2024-11-03T02:14:00Z ── SUSPICIOUS ────────────────────────────────────────────── [WARN] hook:.git/hooks/post-checkout score=75 [WARN] force-push-indicator:refs/heads/main reset: moving... ``` ## 密钥模式 gitward 可匹配当前工作文件和不可达历史记录中的 30 多种模式： - AWS 访问密钥（`AKIA…`、`ASIA…`） - GitHub token（`ghp_`、`ghs_`、`github_pat_`，classic 和 fine-grained） - GitLab token（`glpat-`） - Slack token（`xox[baprs]-`） - 私钥（RSA、EC、DSA、OpenSSH、PGP） - Google API 密钥（`AIza…`）和 OAuth token（`ya29.`） - JWT（`eyJ…`） - MongoDB 连接字符串 - Stripe live 密钥（`sk_live_`、`rk_live_`） - SendGrid API 密钥（`SG.`） - Twilio 凭据（`AC…`、`SK…`） - Square token（`sq0atp-`、`sq0csp-`） - 常见的 64 字符十六进制字符串 - 密码/密钥/token/API 密钥分配模式（单引号和双引号） - 数据库密码环境变量 - NPM token - Docker 和 Heroku 环境变量分配 - AWS 元数据端点（`169.254.169.254`） ## 可疑模式 除了凭据模式外，gitward 还会标记 shell 和行为指标： - `curl … | sh`, `wget … | sh` - `base64 -d` 或 `base64 --decode` - `eval $(base64 …)` - 访问 `/etc/passwd`、`/etc/shadow`、`/etc/cron` - `chmod 777` / `chmod 666` - `rm -rf /` - `.onion` 地址 - VS Code `runOn: folderOpen` / `allowAutomaticTasks` Hook 脚本会使用更细粒度的模型单独评分，该模型会检查 `curl`、`wget`、`base64`、`/dev/tcp`、`nc`、`netcat`、`bash -i`、`python -c`、`perl -e`、`ruby -e`、`ncat`、`socat`、`exec`、pipe-to-shell 以及注释密度。 ## 贡献指南 欢迎提交 Bug 报告和补丁。请确保更改保持在纯 C99、兼容 POSIX 且无依赖的状态。提交前请运行 `make`；在使用 `-Wall -Wextra -pedantic` 进行构建时，应该产生零警告。

标签：Bing搜索, ESC4, Git, OSINT, StruQ, 安全取证, 客户端加密, 敏感信息扫描, 网络安全研究