供应链老 6 投毒必学技能：Commit Stomping

我就不逐句翻译校对了，反正有些人也看不上。末尾有原文链接。可以直接看原文。我主要是提供最新的情报，告诉你有这件事值得关注。

Commit Stomping 是一种受 timestomping 启发的技巧，后者是一种在攻击行动中常用的方法，用于操纵文件元数据以隐藏操作的真实时间。在 Git 中，Commit Stomping 涉及更改提交时间戳，以误导观察者关于更改何时引入。

这不是Git 中的bug 或漏洞。这是一个特性，当被误用时，可以被利用来掩盖恶意或未经授权的更改，从而使在审计、调查或代码审查期间建立准确的时间线变得更加困难。

我之前写过/研究过这个话题，当时我写了 RepoMan 和相关的 博客文章 ，研究了受人工智能影响的提交代码的方法，但从未完全探索过独立技术的这个话题。

为什么这项技术很重要

Git 提交历史记录通常被用作以下方面的真相来源：

• 事件响应和取证时间线
• 代码审计和合规审查
• 团队或开源环境中的归属

当提交时间戳被伪造时，就更难确定更改的顺序及其来源。这在软件供应链安全、内部威胁和长期审计跟踪的背景下具有重大影响。

Git 如何追踪时间

Git 不仅仅存储更改的内容。它还存储有关谁进行了更改以及何时进行的元数据。每个提交都包含两个不同的时间戳：

• GIT_AUTHOR_DATE：内容最初编写的日期和时间
• GIT_COMMITTER_DATE：提交最终确定到存储库中的日期和时间

在大多数工作流程中，这些值是相同的。但是，当进行变基、修改提交或由原始作者以外的人执行提交时，就会出现差异。

变基和修改场景

使用 git rebase 或 git commit --amend 会重写提交。Git 保留 GIT_AUTHOR_DATE，但会更新 GIT_COMMITTER_DATE 以反映更改被重写的时间。

git commit --amend

这会调整提交元数据，但不会更改作者时间，除非显式覆盖。

多个提交者

在协作工作流程中：

• 开发人员可以创建补丁并将其通过电子邮件发送
• 维护者或审阅者随后可以提交它

在这些情况下，作者和提交者可能在身份和时区上有所不同。如果时间戳没有标准化，这种差异可能会使取证分析复杂化。

手动时间戳控制

Git 允许你通过环境变量控制时间戳：

GIT_AUTHOR_DATE="2025-05-01T10:00:00"GIT_COMMITTER_DATE="2025-01-15T15:30:00"git commit -m "Insert logic for token generation"

这使得合法的元数据保存成为可能，或者被滥用来伪造历史。

支持的时间戳格式

Git 支持这些环境变量和 --date 标志的各种格式：

<unix timestamp> <time zone offset>

示例：

GIT_AUTHOR_DATE="1700000000 +0100"

这代表 2024 年 11 月 14 日，欧洲中部时间 06:13:20。

GIT_AUTHOR_DATE="2024-11-14T06:13:20+01:00"GIT_AUTHOR_DATE="2024-11-14 06:13:20 +0100"

GIT_AUTHOR_DATE="Tue, 14 Nov 2024 06:13:20 +0100"

GIT_AUTHOR_DATE="2 weeks ago"GIT_COMMITTER_DATE="yesterday"

GIT_AUTHOR_DATE="@1700000000"

除非另有说明，否则等同于 "1700000000 +0000"。

使用自定义时间戳提交

Git 允许您在创建时为您的提交分配任意时间戳。这意味着您可以伪造提交日期，使其看起来好像工作发生在完全不同的时间点。这对于诸如将历史代码移植到新的存储库中并保留作者日期等合法原因可能很有用，但它也是恶意使用时提交踩踏的基础。

要使用回溯时间戳提交，您可以使用环境变量显式设置作者和提交者日期：

GIT_AUTHOR_DATE="2025-01-01T10:00:00"GIT_COMMITTER_DATE="2025-01-01T10:00:00"git commit -m "Backdated logic insert"

这将创建一个提交，看起来像是写于 2025 年初并提交的，无论它实际的创建日期是什么。从时间线分析的角度来看，这与真正在那时进行的提交无法区分，除非通过外部日志或镜像基础设施进行验证。

用 Commit Stomping 重写历史

如果提交已经使用当前或不想要的的时间戳完成，你仍然可以回去修改它。Git 强大的历史重写工具使得事后伪造时间戳变得微不足道。这就是 Commit Stomping 最有效的地方；重写现有的提交，以便在虚构的历史背景下植入或隐藏操作。

交互式变基

这种方法非常适合以受控方式更改最近的一两个提交：

git rebase -i HEAD~3

这将打开一个编辑器，显示最后三个提交。将 pick 更改为 edit，针对您想要更改的提交。然后：

GIT_COMMITTER_DATE="2025-01-01T10:00:00"git commit --amend --no-edit --date "2025-01-01T10:00:00"git rebase --continue

这会将原始时间戳替换为您选择的日期，同时保持提交内容和哈希值被更改（因为 Git 哈希值包含元数据）。这非常适合在清理或操作活动期间进行精确的“踩踏”。

使用 git filter-branch

Ps. 如果您要重写跨越更广泛提交集的的时间戳，或者您想针对历史深处的特定哈希，git filter-branch 允许进行脚本化的大规模重写。

git filter-branch --env-filter 'if [ "$GIT_COMMIT" = "abc123" ]; then    export GIT_AUTHOR_DATE="2025-01-01T10:00:00"    export GIT_COMMITTER_DATE="2025-01-01T10:00:00"fi' -- --all

这会选择性地更改提交 abc123 在所有分支上的时间戳。您可以扩展逻辑以匹配作者姓名、消息或范围。虽然功能强大，但 filter-branch 也很耗资源，并且在没有备份的情况下是不可逆的。

考虑使用 git filter-repo 替代。它更快、更灵活，并且对大型仓库更安全。

自动化提交合并

如果目标是隐藏更改的真实顺序，或者使存储库的时间线看起来混乱且随机，您可以在整个提交历史记录中自动执行 Commit Stomping。这会在时间线中引入熵，使得更难识别关键操作发生的时间。

这是一个使用 filter-branch 和随机 Unix 时间戳的简单示例：

git filter-branch --env-filter 'export GIT_AUTHOR_DATE="$(date -d @$((RANDOM % 1000000000 + 1000000000)))"export GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"' -- --all

这个脚本随机地将作者和提交者日期都设置为一个广泛的 epoch 范围内的值。你可以调整随机性或针对特定范围，以便将更改融入特定的时间框架（例如，将后门放置到旧的发布周期中）。

这种方法是嘈杂的、不可逆的，并且在无故进行时是篡改的明显迹象，但在对抗性模拟或攻击性行动中，它可以完全破坏基于时间线的调查。

检测提交踩踏

发现提交踩踏并不总是那么简单，尤其是在快速发展的存储库或那些没有一致提交规范的存储库中。然而，在取证审查、审计或一般的源代码控制规范检查期间，有一些明确的指标应该引起注意。

寻找以下内容：

• 多个提交之间的时间戳完全相同或过于相似提交具有完全相同的 GIT_AUTHOR_DATE 和 GIT_COMMITTER_DATE，尤其是在连续的情况下，表明存在自动化或手动回溯。当这些提交似乎反映了逻辑上独立的工作时，这一点尤其可疑。
• 作者和提交者日期不匹配如果作者日期明显早于提交者日期（例如，几个月或几年），则可能表明历史记录被重写或伪造。虽然在变基或补丁应用期间出现一些差异是正常的，但应调查较大的差距。
• 时间上的不一致提交记录的出现顺序不一致，即较新的提交记录却带有较早的时间戳，这可能是历史篡改的迹象。虽然 Git 并不强制执行严格的时间顺序，但这种提交记录的模式可以揭示篡改行为或潜在的恶意活动。
• 与外部日志的差异将提交时间戳与您的 CI/CD 管道、webhook 事件日志或镜像存储库进行比较。如果一个提交声称来自一月份，但构建系统在四月份才首次看到它，那将是一个危险信号。
• 历史回溯的不寻常集群如果一个贡献者突然开始提交大量代码，且时间戳来自遥远的过去，这可能是在试图插入或掩盖更改，而不会引起注意。

定期审计提交元数据，尤其是在受监管或高信任环境中，是供应链完整性中宝贵的一部分。

防御提交篡改

Git 是一个围绕灵活性和离线工作流程设计的分布式系统。这种灵活性包括允许用户为提交分配任意时间戳，这也意味着 Git 不会验证所提供的日期是否真实。如果您希望加强存储库以防止时间线被篡改，以下措施将有所帮助：

• 强制要求并验证签名提交GPG 或 SSH 签名的提交提供了一种验证提交者身份的方法。虽然这并不能直接防止时间戳篡改，但它增加了问责性，并有助于检测未经授权的重写尝试。将签名检查集成到您的 CI 管道中，并在受保护的分支上拒绝未签名的提交。
• 摄取时捕获元数据在提交进入您的生态系统时记录提交事件，这可以是 CI/CD 管道中的时间戳记录、Git 服务器中的审计跟踪，或存储在日志聚合器中的 webhook 负载。这些摄取日志为实际发生更改时创建了一个外部参考点。
• 使用带有不可变存储的镜像仓库将提交推送到托管在安全位置的只读镜像。此镜像充当时间线的独立副本。如果有人在主仓库中重写历史记录，您可以与镜像进行比较以识别差异。
• 锁定历史重写禁用对主分支或受保护分支的强制推送。这并不能阻止某人在 fork 或个人分支中重写历史记录，但它可以防止未经授权的时间线更改在未经通知的情况下进入您的关键分支。
• 监控异常模式使用提交分析工具或基本脚本来监视时间戳异常，例如大的日期间隙、提交历史中的向后跳跃，或旧日期提交的突发。将其与发布或合规周期内的定期手动审查结合起来。

最终，防御“提交踩踏”在于围绕您的开发流程建立信任和验证层。Git 给了你绳索，团队是安全地使用它还是把自己吊死，取决于如何实施这些控制措施。

最后的想法

“提交踩踏” 并非传统意义上的漏洞，没有漏洞利用，没有 CVE，也没有补丁即将到来。 这是一个真实的案例，它不是一个错误，而是 Git 分布式和基于信任的设计的一个特性，可以转化为一种欺骗技术。 问题不在于 Git 坏了，而在于它隐含地信任用户。 这种信任可能会被滥用。

手动设置或重写提交时间戳的能力本身并不坏。它经常用于实际原因，例如在导入旧项目时保留日期、将贡献与外部系统对齐或整理混乱的提交历史。但在错误的人手中，它可能被滥用来重写过去，掩盖更改的真正时间、隐藏恶意编辑，或扰乱任何试图追踪发生了什么以及何时发生的人。

在源代码控制是安全边界一部分的世界中，假设 Git 日志的完整性已经不够好了。重要的是将版本历史视为可变的，除非另有证明，并用提供外部验证的控件包围 Git：CI/CD 日志记录、签名提交、不可变镜像和行为监控。

如果你正在模拟高级攻击者、应对内部威胁、在事件期间审查代码历史记录，或者构建强化的开发管道，那么操纵时间戳的能力必须成为你的威胁模型的一部分，并且了解现有攻击类型的含义至关重要。如果你不去寻找它，你就不会看到它；如果你不防御它，你就会在你的取证追踪中留下一个隐蔽的漏洞。

归根结底，Git 讲述了一个故事。Commit Stomping 让你能够改写这个故事的时间线，并在此过程中更改一些关键细节。

Git Link: https://github.com/ZephrFish/CommitStomping-Info

文章原文地址：https://blog.zsec.uk/commit-stomping/