要恢复丢失的代码并避免泄漏：发送给我们0.1比特币（BTC）到我们的比特币地址1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA，并且
通过admin@gitsbackup.com通过电子邮件与我们联系，并提供您的Git登录名和付款证明。如果您不确定我们是否有您的数据，请与我们联系
，我们将向您发送证明。您的代码已下载并备份在我们的服务器上。如果我们在接下来的10天内没有收到您的付款，我们将
公开您的代码或将其用于其他用途。
在这种情况发生时，Google搜索没有不会显示任何东西，但是一个小时左右就开始出现。
我正在使用SourceTree（始终是最新的），但不知何故我怀疑SourceTree是问题所在，或者我的系统（Windows 10）受到了损害。我并不是说这不是，只是我对此表示怀疑。
这仅发生在我的一个存储库（所有存储库都是私有的）上，而其他存储库则保持不变。我更改了密码，启用了2因素身份验证，删除了我多年未使用的一个访问令牌，并给GitLab写了一封电子邮件，希望他们可以告诉我一些有关攻击者进入何处/谁的信息。
我的密码是一个很弱的密码，可以通过蛮力相对容易地破解（这不是很常见的密码，但以“ a”开头并且只包含z字符），并且可能是他们只是自动检查了是否可以访问该帐户，然后运行一些git命令。我的电子邮件地址和特定密码也可能在泄露的帐户列表中。有人可能会争辩说，如果这是他们的入门方式，他们只是更改了帐户凭据，但在Internet上搜索发现，在这种情况下，GitLab / GitHub只会为您恢复凭据，所以我认为这就是为什么他们没有不能这样做。
也可能是那个旧的访问令牌，我不记得过去使用它的目的和位置-很可能是为在我的计算机上使用而生成的
还有4位开发人员正在开发它，他们都拥有对存储库的完全访问权限，因此也有可能破坏他们的帐户。
我已经用BitDefender扫描了计算机，却找不到任何东西，但是我没有在互联网上做任何可疑的事情，所以我不认为这是导致我感染了恶意软件/特洛伊木马的原因。 br />
我正在等待GitLab的答复，也许他们可以对此有所启发。我的代码基于我本地的Git，所以这不是问题，但是我还没有将代码推回到存储库中。另外，以防万一代码被发布到某个地方，我将更改在源（数据库，IMAP帐户）中可以找到的所有密码。
UPDATE
我发现了代码没有消失。我尝试访问一个提交的哈希，它起作用了。因此代码已经存在，但是HEAD出问题了。我对此的知识非常有限，但是
git reflog 显示了我的所有提交。
对我而言，这意味着攻击者很可能没有克隆存储库（无论如何，这将是所有受害者的后勤噩梦），并且他们有机会遍历源代码以查找敏感数据，或者公开代码的难度很低。在我看来，这也不是针对性攻击，而是由脚本执行的随机，批量攻击。我真的希望是这样，为了我们自己！
UPDATE 2
因此，如果您这样做
git checkout origin/master
您将看到攻击者的提交
git checkout master
您将看到所有文件
git checkout origin/master
git reflog # take the SHA of the last commit of yours
git reset [SHA]
将修复您的出身/主人...但是
git status
现在会说
HEAD detached from origin/master
仍在寻找解决方案在此
更新3
如果本地有文件，运行
git push origin HEAD:master --force
将解决所有问题。请参阅Peter的评论
所以，问题是，假设您没有本地存储库，哪些命令将使我的存储库恢复到以前的工作状态，关于被攻击者是如何进入的，我希望来自GitLab的答案（如果有的话）将为我们提供更多帮助。
此处正在进行讨论
攻击针对GitHub，BitBucket和GitLab帐户。这是GitHub的公共存储库的数量级
#1 楼
您可以在克隆中使用git reflog并在此之前检出最后一次提交。发生这种情况是因为您的网络服务器上的
.git/config（在克隆存储库的目录中）包含远程URL，并且添加了用户名：password在这种情况下，永远都不会发生这种情况-人们应该在每次拉动时使用SSH，部署密钥或进行身份验证。切勿将您的凭据存储在配置文件中。使用凭据帮助器。来源：https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg
你好，是我，有你的后援的人..
我会揭露你的罪过
这是2015年的一篇文章，其内容更加详细，https：// zh.internetwache.org/dont-publicly-expose-git-or-how-download-your-websites-sourcecode-an-analysis-ofalexas-1m-28-07-2015/
Internetwache的相关文章：https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of- alexas-1m-28-07-2015 /
要防止这种情况阻止访问以点开头的目录，请参阅https://github.com/h5bp/html5-boilerplate/blob/master/ dist / .htaccess＃L528-L551
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Block access to all hidden files and directories with the exception of
# the visible content from within the `/.well-known/` hidden directory.
#
# These types of files usually contain user preferences or the preserved
# state of an utility, and can include rather private places like, for
# example, the `.git` or `.svn` directories.
#
# The `/.well-known/` directory represents the standard (RFC 5785) path
# prefix for "well-known locations" (e.g.: `/.well-known/manifest.json`,
# `/.well-known/keybase.txt`), and therefore, access to its visible
# content should not be blocked.
#
# https://www.mnot.net/blog/2010/04/07/well-known
# https://tools.ietf.org/html/rfc5785
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} "!(^|/)\.well-known/([^./]+./?)+$" [NC]
RewriteCond %{SCRIPT_FILENAME} -d [OR]
RewriteCond %{SCRIPT_FILENAME} -f
RewriteRule "(^|/)\." - [F]
</IfModule>
，或使用
.git分隔--separate-git-dir目录和数据。- split-git-dir =
而不是将存储库初始化为$ GIT的目录_DIR或./.git/，在其中创建一个文本文件，其中包含实际存储库的路径。此文件充当到存储库的与文件系统无关的Git符号链接。
如果重新初始化，则存储库将移动到指定的路径。
但是最好是在部署后进行
rm -rf .git-只需使用rsync将构建工件复制到目标即可。https://git-scm.com/docs/git-init#Documentation/git- init.txt --- separate-git-dirltgitdirgt
--separate-git-dir =
与其将克隆的存储库放置在指定的目录中，还不如将其放置在指定的目录中，然后在此处建立与文件系统无关的Git符号链接。结果是Git存储库可以与工作树分离。
https://git-scm.com/docs/git-clone#Documentation/git-clone.txt--独立的git-dirltgitdirgt
https://stackoverflow.com/a/8603156/753676
有关部署密钥和凭据助手的信息：
https://developer.github.com/v3/guides/managing-deploy-keys/
默认情况下，部署密钥为只读，但是您可以在以下情况下为它们提供写访问权限将它们添加到存储库中。
https://gist.github.com/zhujunsan/a0becf82ade50ed06115
https://help.github.com/en / articles / caching-your-github-password-in-git
使用本地克隆中的
git push -u origin master -f && git push --tags -f将所有主，标记等参考推送到远程，然后在您的帐户中启用2FA。 如果更多分支受到影响，请使用
git push -u --all -f 还请启用2FA来减少此类攻击的可能性。
请不要忘记更改所有入侵的登录/密码并撤消所有未知会话。
评论
您有此要求的来源吗？攻击者如何访问.git / config？如果他们可以访问该文件，则他们大概仍可以访问整个.git文件夹，对于私有仓库来说，能够访问整个源代码和历史记录的攻击者仍然是一个重要问题。
–约瑟夫·H
19年5月5日在8:35
有用于扫描.git目录的工具。通常应禁止访问dotfile和目录，有关所需规则，请参见html5boilerplate .htaccess文件。使用Git，您也可以将数据的位置和.git目录分开。无论如何，部署到服务器应该是一种单向任务（rsync等），并且应该使用部署密钥。
–丹尼尔·鲁夫（Daniel Ruf）
19年5月5日，9：45
这是常识，但是请添加到答案的最后一步-重新获得对存储库的访问权限后，请更改源代码中可能包含的所有密码和用户名。或任何其他可以用来对付您的东西，尽管我无法提出任何形式的建议
– Stefan Gabos
19年5月6日在6:24
应该提到的是，.git / config发现发生在已安装的服务器上，而不是在github上，以防万一您想知道为什么需要修复GH设置（您不知道）
–eckes
19年5月6日在6:59
这再次表明：Git不是部署工具。每当有人提到他们只是使用git push来部署他们的网站时，我都会发抖...
–sleske
19年5月6日，11：45
#2 楼
我怀疑黑客是否推送了“全部删除”提交，否则您可以简单地还原上一次提交。相反，他们使用对master分支的HEAD的注释强制推送了一个不同的提交，看起来您的整个提交历史都已消失。正如其他人指出的那样，您可以轻松地使用本地回购来强制执行将正确的代码推送到服务器。由于Git的分布式特性，无论是否擦除服务器，这始终有效，因为每个本地存储库都具有服务器的完整克隆，包括提交和代码。当然，在尝试恢复工作之前，应确保首先确保服务器的安全。 :-)
如果您没有包含最新提交的本地存储库，则提交历史记录（以及所有相关文件）将在服务器上保留一段时间。但是，服务器最终将运行
git gc，它将清理那些无法访问的提交。截至2013年，GitHub表示他们每天最多运行一次git gc，但也可以手动触发，而BitBucket将根据需要运行它，或者可能在每次推送后运行。 GitLab默认会在200次推送后运行它，或者可以手动触发它。但是，即使所有提交和文件仍在服务器上，您也需要找到提交的哈希值才能恢复它。如果没有带有reflog的本地存储库，则很难找到要还原的正确提交。您可以尝试一些想法：
如果您使用的是GitHub，请在
https://api.github.com/repos/:user/:repo/events上查看事件API的存储库，以查看是否可以找到正确的提交。我不知道其他服务是否提供类似功能。拉取请求通常会永久保留，因此您应该能够查看合并到master分支中的最新拉取请求。只要确保选择合并提交的哈希，而不是分支的哈希即可。 （GitHub在合并提交哈希旁边有一个绿色的复选标记，GitLab显示“与...合并为主”，不确定BitBucket是否正确）。
如果您有构建服务器，请查看master分支的最新构建是什么（也许在构建日志中？）
您可能还需要检查存储库的派生。 GitHub允许您在Forks或Network视图中查看它们。
找到正确的master哈希后，可以使用以下命令还原服务器（假设您有一个名为“ origin”的Git远程服务器） ）。
git fetch origin <hash>
git checkout master
git reset --hard <hash>
git push --force origin master:master
请注意，除非打算覆盖某人的工作，否则切勿使用
git push --force。评论
如果OP的本地存储库中不再有最新数据，那么他们如何安全地从服务器中提取并合并更改？我认为提交历史记录可能已经在服务器上被恶意重写了。 （欢迎来到Security.SE，Matt！）
– ComFreek
19年5月4日在9:20
如果有叉子，请使用最新的叉子。或最近根据master分支改组的PR。否则，如果平台没有自己的引用日志或所有（过去）对象的备份，则数据可能会丢失。
–丹尼尔·鲁夫（Daniel Ruf）
19年5月4日15:55
但是，克隆的存储库并不总是包含所有引用（标签+未跟踪的分支）。
–丹尼尔·鲁夫（Daniel Ruf）
19年5月4日15:57
@ComFreek我的答案的后半部分解决了本地存储库不存在或不是最新的情况。当Git执行哈希时，它将同时哈希文件和该分支的提交历史记录。一旦找到了最新的提交哈希，就可以恢复文件和提交历史记录，并假设它们尚未被垃圾回收。 （Git使用SHA-1哈希，因此设计散列冲突将非常困难。）一旦恢复了服务器，所有本地存储库都应该能够正常拉/合并。
–马特
19年5月6日在17:11
#3 楼
如果更多分支受到影响，则可能需要先使用以下命令检出所有分支，然后再执行git push -u --all -f for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master `; do
git branch --track ${branch#remotes/origin/} $branch
done
https://gist.github.com/octasimo/ 66f3cc230725d1cf1421
#4 楼
我想您已经知道了更明显的内容，但仍然如此：继续，设置SSH与GitLab（以及支持该功能的任何其他远程设备）进行通讯，而不是与用户名进行通讯+密码，如@Daniel Ruf所建议。
为您的GitLab帐户配置一个非常强的密码（大约16个随机生成的字符），并使用密码管理器进行管理。
确保您的计算机没有受到损害。我会更进一步，以防万一我更改所有在线帐户的密码。以防万一。现在解决另一个紧迫的问题：
这意味着什么？我的意思是，攻击者很可能没有克隆
（无论如何，这将是对所有受害者
的后勤噩梦）（假设＃1）
（... ）
，并且他们遍历源代码以查找敏感数据或将代码公开的机会很小（...）（假设2）
>对我来说，这还不是针对性攻击，而是由脚本（...）（假设＃3）实施的随机，批量
攻击
假设＃1和＃3可能是正确的，也可能不是正确的（我个人认为，当您的计划是为了破坏赎金而克隆存储库时，克隆存储库根本不是后勤梦night-攻击者很可能拥有专用于该任务的服务器，通过VPN或排序进行配置。可能是您被锁定了）。但是它们并不是很关键。
但是，假设＃2是您现在无法承担的。
如果代码或回购记录中包含私人信息或任何类型的商业机密，请立即开始采取应急措施。
如果引用他们的部分消息，则：
如果我们在接下来的10天未收到您的付款天，我们将公开您的
代码，否则将其使用。
恐怕您可以肯定，不管您是否支付赎金，他们都会这样做。特别是“否则使用它们”位。
评论
对。我严格地谈论我的案子，这对我意味着什么。绝对，如果有人拥有敏感数据（例如用户名和密码），则应立即进行更改
– Stefan Gabos
19年5月6日在6:22
对于应用程序的密码/凭据，请使用.env文件-有PHP软件包和其他可使用的文件-绝不应在任何Git历史记录中包含机密信息。
–丹尼尔·鲁夫（Daniel Ruf）
19年5月6日在6:46
谢谢！我不知道这个！会马上调查
– Stefan Gabos
19年5月6日在11:46
评论
评论不作进一步讨论；此对话已移至聊天。更新：我向NameCheap（电子邮件的域名注册商）发送了滥用投诉，他们只是回信给我，指出他们已暂停该域名。
没有某种形式的授权来追踪骗子/黑客吗？