GitLab 帐户被黑,回购被擦除

信息安全 账户安全 勒索软件 入侵 github
2021-08-15 23:16:26

我正在做一个项目,一个私人仓库,突然间所有的提交都消失了,取而代之的是一个文本文件,上面写着

要恢复丢失的代码并避免泄漏:将 0.1 比特币 (BTC) 发送到我们的比特币地址 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA 并通过电子邮件与我们联系 admin@gitsbackup.com 并提供您的 Git 登录名和付款证明。如果您不确定我们是否有您的数据,请联系我们,我们将向您发送证明。您的代码已下载并备份在我们的服务器上。如果我们在接下来的 10 天内没有收到您的付款,我们将公开您的代码或以其他方式使用它们。

发生这种情况时,谷歌搜索没有显示任何内容,但大约一个小时后,开始出现。

我正在使用 SourceTree(始终是最新的),但不知何故我怀疑 SourceTree 是问题所在,或者我的系统(Windows 10)受到了损害。我不是说不是这样,只是我对此表示怀疑。

这仅发生在我的一个存储库(它们都是私有的)中,而其他所有存储库都没有受到影响。我更改了密码,启用了 2 因素身份验证,删除了一个我多年未使用的访问令牌,并给 GitLab 写了一封电子邮件,希望他们能告诉我有关攻击者在哪里/谁进入的信息。

我的密码很弱,可以通过暴力破解相对容易(它不是一个常见的密码,但以“a”开头,并且只有 az 字符)并且可能是他们只是自动检查是否可以访问该帐户,然后运行一些 git 命令。我的电子邮件地址和该特定密码也可能在泄露的帐户列表中。有人可能会争辩说,如果他们是这样进入的,他们会简单地更改帐户凭据,但搜索 Internet 发现在这些情况下 GitLab/GitHub 只会为您恢复凭据,所以我认为这就是他们没有这样做的原因不要这样做。

也可能是那个旧的访问令牌,我不记得我过去用它做什么和在哪里使用它 - 很可能是为在我以前拥有的计算机上使用而生成的,所以我怀疑这是问题所在。

还有 4 名开发人员正在开发它,他们都拥有对存储库的完全访问权限,因此他们的帐户也有可能被盗用。

我已经用 BitDefender 扫描了我的计算机,但我没有在互联网上做任何可疑的事情,所以我不认为我感染了恶意软件/木马是造成这种情况的原因。

我正在等待 GitLab 的回答,也许他们可以对此有所了解。我在本地 Git 上有代码库,所以这不是问题,但我还没有将代码推回存储库。此外,以防万一代码在某处发布,我将更改要在源(数据库、IMAP 帐户)中找到的所有密码

更新

我发现代码没有消失。我尝试访问提交的哈希并且它有效。所以代码在那里,但 HEAD 有问题。我对此的了解非常有限,但

git reflog

显示我所有的提交。

对我来说意味着攻击者很可能没有克隆存储库(无论如何,这对所有受害者来说都是一场后勤噩梦),而且他们有机会通过源代码寻找敏感数据,或者公开代码的比例很低。对我来说,这也意味着这不是有针对性的攻击,而是由脚本执行的随机批量攻击。我真的希望这是为了我们自己的利益!

更新 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

会解决一切。彼得的评论

因此,问题是假设您在本地没有 repo,哪些命令将使我的存储库恢复到以前的工作状态,至于被攻击者是如何进入的,我希望 GitLab 的答案(如果有的话)能帮助我们更多的。

这里正在进行讨论

该攻击针对 GitHub、BitBucket 和 GitLab 帐户。是 GitHub 公共存储库的规模

4个回答

您可以git reflog在克隆中使用并签出发生此情况之前的最后一次提交。

发生这种情况是因为.git/config在您的网络服务器上(在克隆存储库的目录中)包含远程 URL,并且人们在其中添加了用户名:密码,这绝不应该是这种情况 - 人们应该使用 SSH、部署密钥或在每次拉取时进行身份验证。切勿将您的凭据存储在配置文件中。使用凭证助手。

来源:https ://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg

你好,是我,你备份的那个人..

我会揭露你的罪过

这是 2015 年的一篇文章,更详细,https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas -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

--separate-git-dir=<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 dir>
不要将克隆的存储库放在它应该在的位置,而是将克隆的存储库放在指定的目录中,然后创建一个与文件系统无关的 Git 符号链接到那里。结果是 Git 存储库可以与工作树分离。

https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---separate-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从您的本地克隆将所有对 master、tags 等的引用推送到远程,然后在您的帐户中启用 2FA。

如果更多分支受到影响,请使用 git push -u --all -f

另外请启用 2FA 以减少此类攻击的可能性。

请不要忘记更改所有受损的登录名/密码并撤销任何未知会话。

我怀疑黑客是否推送了“全部删除”提交,否则您可以简单地还原最后一次提交。相反,他们将带有注释的不同提交强制推送到主分支的 HEAD,从而看起来您的整个提交历史都消失了。

正如其他人指出的那样,您可以轻松地使用本地存储库将正确的代码强制推送到服务器。由于 Git 的分布式特性,无论服务器是否被擦除,这始终有效,因为每个本地 repo 都有服务器的完整克隆,包括提交和代码。当然,在尝试恢复之前,您应该首先确保服务器已得到保护。:-)

如果您没有包含最近提交的本地存储库,则提交历史记录(和所有关联文件)仍将在服务器上存在一段时间。但是,服务器最终会运行git gc,这将清除那些无法访问的提交。截至 2013 年,GitHub 表示它们每天git gc最多运行一次,但也可以手动触发,而 BitBucket 将根据需要运行,或者可能在每次推送之后运行。GitLab默认在 200 次推送后运行,也可以手动触发。

但是,即使所有提交和文件仍在服务器上,您也需要找到提交的哈希值,以便恢复它。如果没有带有 reflog 的本地 repo,就很难找到正确的提交来恢复。您可以尝试的一些想法:

  • 如果您使用的是 GitHub,请检查您的存储库的事件APIhttps://api.github.com/repos/:user/:repo/events ,看看您是否可以找到正确的提交。我不知道其他服务是否提供类似的功能。
  • 拉取请求通常会永久保留,因此您应该能够查看合并到主分支中的最新拉取请求。只要确保选择合并提交的哈希,而不是分支的哈希。(GitHub 在合并提交哈希旁边有一个绿色复选标记,GitLab 显示“merged into master with”,不确定 BitBucket)。
  • 如果您有构建服务器,请查看 master 分支的最新构建是什么(可能在构建日志中?)
  • 您可能还想检查您的 repo 的分叉。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

如果更多分支受到影响,您可能需要先使用以下命令检查所有分支,然后再执行 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

我想你已经知道更明显的了,但是:

  1. 展望未来,设置 SSH以与 GitLab(以及任何其他支持它的远程)进行通信,而不是像@Daniel Ruf所建议的那样使用用户名+密码。

  2. 为您的 GitLab 帐户配置一个非常强的密码(大约 16 个以上随机生成的字符),并使用密码管理器来管理它。

  3. 确保您的计算机没有受到威胁为了以防万一,我会更进一步,更改我所有在线帐户的密码。

现在来解决另一个紧迫的问题:

这对我来说意味着攻击者很可能没有克隆存储库(无论如何,这对所有受害者来说都是一场后勤噩梦)(假设#1)
(......)
他们的机会在源代码上寻找敏感数据,或公开代码是低的(...)(假设#2)

对我来说,这也意味着这不是有针对性的攻击,而是随机的批量攻击,由脚本执行 (...) (假设 #3)

假设 #1 和 #3 可能正确,也可能不正确(我个人认为,当您的计划是为了赎金而破坏回购协议时,克隆回购协议根本不是一场后勤噩梦——攻击者很可能拥有一台专门用于该任务的服务器,通过 VPN 或排序配置。它可能是你目标)。但它们不是很关键。

但是,假设 #2 是您现在无法承担的假设

如果代码或回购历史包含私人信息或任何类型的商业机密,请立即开始采取应急措施。

引用他们的部分信息:

如果我们在接下来的 10 天内没有收到您的付款,我们将公开您的代码或以其他方式使用它们。

恐怕无论你是否支付赎金,他们都会这样做是安全的。特别是“以其他方式使用它们”位。