Gitea: Giteabot 账户被盗

创建于 2018-06-07  ·  75评论  ·  资料来源: go-gitea/gitea

我们目前正在调查一个对 go-gitea 组织具有写访问权限的帐户的可疑活动。 一个二进制文件被添加到多个 go-gitea 存储库的发布中。 我们清理了所有版本并暂时取消了帐户的访问权限。 我们将进一步调查以了解真正发生的事情,以防止将来发生这种情况,并在整个过程中对您保持透明。 同时,如果您发现任何可疑活动,请在此问题下报告。

更新:没有源代码或其他 Gitea 基础设施受到影响,包括https://dl.gitea.io/,因此使用它下载 Gitea 二进制文件是安全的。

被黑客入侵的 GitHub 帐户处于完全控制之下,并且还设置了 2FA,因此以后不会再发生这种情况。

做了什么:

  • 大多数go-gitea组织存储库的新版本和标签都是以0名称创建的,并将install.exe二进制文件(大小为 13KB)添加到恶意版本中(根据我们的分析包含加密货币矿工)。 所有这些版本和二进制文件都在添加后的 2-3 小时内被删除。
  • GitHub 上的 1.4.2 版 windows Gitea .exe 二进制文件也被替换为与上述相同的 13K 二进制文件。 因此,如果 Gitea 正在工作,您就安全了。
  • 以防万一我们重新标记 1.4.2 以触发 CI 重建二进制文件,因此 sha256 现在将与重新标记之前不同。

我们已经联系了 GitHub,但还没有收到他们的任何答复,但是

更新2:
没有实际的 gitea 二进制文件受到损害,因此下面评论中提到的所有哈希都是安全的。

恶意.exe文件的 SHA256:
bfc5a0358b1ad76ffbc1e1f4670bd3240536e2fbac88272cee3003322a15fffe

更新3:
v1.4.2 已于 2018-06-07 20:00:00 UTC+08 左右重新发布

kinsecurity prioritcritical

最有用的评论

@daviian也许那么有必要签署发行版?

所有75条评论

与此同时,下载我们发布的二进制文件时请小心,尤其是 Windows 的,直到另行通知。 例如,注意二进制文件的大小,或双.exe文件结尾。
我们发现 1.4.2 版中的 .exe 二进制文件也被更改了。

我们努力跟踪所有线索,清理并尽快恢复日常业务。

@daviian也许那么有必要签署发行版?

@Mauladen感谢您的投入。 我们肯定会讨论这个。

哎哟! 是的,签名的二进制文件是理想的。

default
1
2

@Mauladen我们已经为 1.4.2 版本重建了二进制文件,以确保我们提供安全的二进制文件。

或者你的意思是别的?

这是正常的。 我们重新发布 1.4.2 以重新触发 CI 以重建二进制文件,因为该版本的 Windows 二进制文件已被删除,并添加了新的恶意文件

@daviian ,也许@Mauladen意味着 1.4.2 发布提交没有 GPG 签名,但 1.4.1 是

仍然需要编辑更改列表

@axifive提交的地方不是由用户签名的 gpg,而是由 github 自动执行的(使用 github 密钥),当合并与 PR 作者相同时。 我不会认为它更安全,因为如果 github 帐户被盗用,我也会显示为“已验证”。 但是我们可以从现在开始签署标签(待讨论)。 对于我们的信息,我们正在对二进制文件进行签名,因为将 thzan 二进制文件作为 git 提交树更容易损坏。

您应该上传由git-archive创建的 tarball(除了 github 自动生成的那些),您使用signify签名。 您可以在此处了解其工作原理/外观:

Libressl 使用相同的技术。

还有这方面的信息吗? 二进制文件的有效载荷是什么? 用户是否会通过博客文章或其他任何方式获知此事? 是否有任何 Linux 二进制文件遭到破坏? 我很担心这些事情可能对我的服务器做了什么。 我很担心我只是偶然发现这个浏览问题页面而不是项目页面/博客上的官方通知

现在从源代码更新到 Gitea 1.4.2 版本是否安全?

在这一点上,我不清楚是否只有二进制文件受到影响。 你是如何验证这一点的? 您的分支机构受到保护吗?

shasums 在我在 6/4 和 6/7 上下载的二进制文件上有所不同,尽管它们的字节数相同:

$ sha256sum gitea-1.4.2-linux-amd64*
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d  gitea-1.4.2-linux-amd64.1

$ ls --color=tty -l gitea-1.4.2-linux-amd64*
-rwxr-xr-x 1 matt matt 53674800 Jun  4 20:39 gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 matt matt 53674800 Jun  7 08:18 gitea-1.4.2-linux-amd64.1

想要在某个地方托管这些东西,以便人们可以将它们分开?

在此处上传二进制文件: https :

问题 - 只是网站上的二进制文件受到影响,还是存储库也受到影响? 我问是因为昨天我听说了 Gitea 并克隆并构建了 v1.4 分支。

如果源本身受到损害或只是二进制文件,我真的想了解更多信息。 我每晚都运行一个脚本来检查 git 中的更新/构建,并且很幸运因为时间原因错过了这个。

当前的 1.4.2 版本是否经过验证是干净的? 如果我们知道它被污染了,我们应该尽快把它拉出来放在其他地方进行分析,否则人们如果没有看到这个问题,仍然会下载它。 我同意@CountMurphy ,我们可以在自述文件中添加一些内容以便它真的可见吗?

我们可以获取哈希值以便检查我们的二进制文件是否受到影响吗? 我的 gitea 1.4.1 (linux amd64) 看起来像这样:
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

我刚刚下载了 gitea 1.4.1 linux-amd-64 并且我也得到了 d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 作为 sha256

@mikedilger见: https :

明确地说:没有人知道任何事情,唯一安全的哈希值是目前在这里找到的哈希值: https :

对于 amd64 上的 Gitea 1.4.2,这意味着:



抱歉,我误解了https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 意味着两个二进制文件都受到了威胁。


我编辑了这篇文章,以消除对我们实际了解的任何歧义。

搁置:根据此评论(https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229),有两个的SHA从6月7日6月4日和c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9。

我们是说这两个都受到了损害,还是只是其中之一? 作为记录,我服务器上的一个是从 6 月 5 日开始的 e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9。

@christianbundy ,请不要草率下结论,等待团队成员的回应

请不要草率下结论,等待团队成员的回应

对此很抱歉,我认为文件哈希值会立即由团队成员发布,但没有意识到信息来自其他人,他_也_处于黑暗中。 这是关注最新动态的正确渠道吗? 我已关闭服务器电源,需要更多信息来判断我是否已被感染。

我看到你的编辑划掉了我指向的条目。 但是,现在下结论是不是还为时过早? 我们如何确定 e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 没问题?

我们仍然缺少一些信息(可能不是详尽的):

  • [ ] 哪些二进制文件遭到破坏,它们的校验和是多少?
  • [ ] 机器人帐户何时遭到入侵?
  • [ ] 源存储库是否受到威胁(这可能很容易检查您是否有从前一段时间克隆的存储库版本,然后您可以检查差异或强制推送的证据)。

我有:

# ls -la gitea-1.4.1-linux-amd64
-rwxr-xr-x 1 gitea gitea 53663640 May  3 08:02 gitea-1.4.1-linux-amd64

使用 sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

刚刚下载了gitea-1.4.2-linux-amd64

# ls -la gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 root root 53674800 Jun  7 14:18 gitea-1.4.2-linux-amd64

使用 sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d匹配提供的 .sha256 文件: gitea-1.4.2-linux-amd64: OK应该是安全的。 (对?)

[...] 我们为 1.4.2 版本重建了二进制文件,以确保我们提供安全的二进制文件。 [...]


我上传gitea-1.4.2-linux-amd64分析在这里,但它并没有真正告诉任何明显。

将要观看此问题并暂时保持我的 gitea 安装离线。

我们如何确定 e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 没问题?

@shuhaowu我说c843d462很好,而不是e14e54f3 。 我们知道这一点,因为这是他们最近重建的 GitHub 上当前提供的文件。

如果 1.4.2 已重建,则应像其他有效版本一样对其进行签名和验证。 不这样做只会增加混乱。

@xcolor

在此处上传二进制文件: https :

这两个二进制文件之间的唯一区别是movabsq $63663754793, %rcx大约 2000 个实例被替换为movabsq $63663969431, %rcx 。 我不能确切地说这在行为上发生了什么变化,但我认为它不太可能是恶意的。

也许推出具有已知安全代码的新(已签名?)1.4.3 版本,或者这是否会使事情更加混乱?

@justinclift我喜欢这个想法,还有一篇博客文章和自述文件中关于这种情况的一些内容将有助于澄清问题。

@spaghetti2514

一方面,您是对的 - _那些_ 两个二进制文件之间的差异很容易看出。

另一方面,Gitea 团队实际上并没有发布哪些二进制文件受到影响,发布了任何 SHA256 哈希值,或者真的说任何可以帮助我们理解妥协的东西 正如其他人指出的那样,我们几乎没有足够的信息来确定发生了什么以及谁受到了影响。

我很沮丧地指出,我们可能应该假设最坏的情况,然后等待核心团队的诊断步骤。 话虽如此,我感谢您发布反汇编的差异。

感谢您更新@lafriks

我已经用附加信息更新了问题描述。 情况并没有想象中的那么糟糕。 我们希望尽可能透明,因此在我们清理并修复所有内容后立即创建了这个问题,因为这是第一次发生这样的事情,所以可能我们应该更快地提供更多信息,抱歉造成混乱。

@lafriks感谢您的更新! 您能否发布我们可以用来验证提交的 PGP 密钥?

@4oo4标签由合并者自己的 GPG 密钥之一签名,因为 PR 都是使用 Squash&Merge 合并的,它们没有签名(或者可能由 GitHub 的魔法签名 :) )

发行版将由 1.5.0 发行版之前创建的 GPG 密钥签名,我们将在 README.md、gitea 文档和博客文章中发布它。

作为 386 用户,我可以确认 Releases 页面上当前可用的gitea-1.4.1-linux-386二进制文件与我在 6 月 4 日下载的版本 ( cf6344b4 ) 匹配。

由于 PR 全部使用 Squash&Merge 合并,因此它们没有签名(或者可能由 GitHub 的魔法签名 :) )

不要使用合并按钮,这基本上是不安全的,而且是一个随机的 gpg 密钥。 本地合并并推送合并。

@mappu gitea v1.4.1 没有受到影响,现在 v1.4.2 已经重新发布。

您应该上传由 git-archive 创建的 tarball(除了 github 自动生成的那些),并使用 signify 签名。

实际上,您甚至不必构建档案并再次上传。 您可以对创建的 GitHub 进行签名,因为它可以重复完成。

这是一个小脚本: https :

@rugk很有用的脚本。 :微笑:

在发现漏洞之前,是否有任何有贡献的团队成员获得了 1.4.2 的存档?

对于任何 Linux 版本是否已更改此二进制文件,您似乎让很多人一无所知,考虑到这是一个非常重要的信息:

1) 大多数部署将针对 Linux 堆栈

2) Linux 堆栈不习惯二进制木马,通常不适合以编程方式检测系统上已运行的可疑代码的最佳工具。

虽然我愿意相信这是一次简单的以 Windows 为目标的攻击,仅此而已,但事实上,他们在用户群急剧增长的几天后才瞄准了这个特定的存储库,这似乎表明了更精心策划的努力。 我非常怀疑任何知道他们的目标是什么以及如何实现这种事情的人都会错过这样一个感染尽可能多主机的成熟机会。

@stanier dl.gitea.io 没有受到影响,我们已经验证没有其他二进制文件被篡改

所以这就解释了为什么我们的 webproxy 拒绝从 hub.docker.com 下载最新的 gitea 镜像......

@lafriks那么你能确认c843d462e14e54f3都是安全的吗? 如果 CI 提供了具有不同签名的构建,那么源代码或编译器用于构建的参数中的某些内容肯定发生了变化。 这本身就是一个次要的技术问题,但这里从未直接说明对手是否更改了 1.4.2 Linux 二进制文件,只有@daviian 在评论中提到的相应 .exe 二进制文件。

澄清一下,我问的是 GH 存储库的发布页面二进制文件,而不是 dl.gitea.io,我知道在 GH 存储库之外没有任何内容被篡改。

Linux 堆栈不习惯二进制木马,通常不适合用于以编程方式检测系统上已运行的可疑代码的最佳工具。

嗯,大多数包管理器(和类似的)不是有至少验证 sha* 校验和的规定吗? 不一定只是为了检测恶意软件,而是作为“让我们验证下载没有损坏”。

@justinclift是的,但这仅适用于通过包管理器安装的二进制文件。 这里的问题与从 GitHub 直接下载有关,据我所知,它没有任何嵌入式恶意软件检测。

啊。 “Linux 堆栈”这个词让我感到厌烦,因为我更习惯于将下载作为简单的一次性事情(例如,在原型设计时),而不是自动化解决方案会做的事情。 不用担心。 :微笑:

@stanier构建是由无人机重做以清除所有内容。 Go 不会在您每次构建二进制文件时提供相同的二进制文件,因为某些变量可能会发生变化(例如构建时间),因此散列不同是正常的。
我在调查期间获得了所有二进制文件,并且可以在我到达我的个人计算机后立即提供哈希值。

对于所有人,请停止对谣言的争论,并提供建设性的意见。
我知道您担心您的安全,我们非常关心它(因为我们也作为 gitea 的用户在您的位置)。 目前访问权限已更改,我们再也没有看到任何可疑活动。 我们已经完成了这个问题,以尽快通知透明,并能够从任何有用的数据中接收输入,以进行调查或遗漏点,因为没有人是完美的。
我们将进行事后分析以解释发生的情况,并且我们已经明确地考虑采取行动来防止将来发生这种情况。
如果这个问题变得疯狂,我认为我们将需要关闭以只保留有用和简洁的信息,并将辩论发送到应该去的地方。

为避免将来出现类似情况,我们将在下一个版本中开始对所有二进制文件进行签名。 我为 Drone 构建了一个插件,您可以在https://github.com/drone-plugins/drone-gpgsign (必须完成此插件的文档)中找到该插件,该插件将对所有二进制文件进行签名,公钥将被上传下载服务器和密钥服务器,您将始终能够以可信赖的方式验证二进制文件。

只是为了向您展示它的外观以及结果是什么,您可以查看https://github.dronehippie.de/webhippie/ldap-proxy/49/18https://dl.webhippie.de /misc/ldap-proxy/master/ ,类似的文件将上传到 Gitea 下载页面和 GitHub 版本。

如果您认为这个插件缺少一些非常重要的东西,请随时在插件存储库中打开一个问题,我可以解决它。

@sapk感谢您的澄清。 我很抱歉,我完全忘记了该项目是基于 Golang 的——像这样的大多数问题都与旧软件有关,所以我认为我的想法跳到了错误的关系上。 我的错。

我开始查看上传的install.exe二进制文件: https :

似乎不仅仅是 Gitea 受到了打击,还有https://github.com/opencompany/www.opencompany.org/releases

谢谢你的清楚解释。

我认为这个问题是通过发行版特定包装的主要原因。 它引起了对打包和潜在恶意代码/二进制文件的更多关注(特别是在这种粗暴尝试的情况下)。 Gitea 至少有 Debian/RedHat/Archlinux 软件包会很棒:这将阻止许多人在他们的生产服务器上运行任意二进制文件:)

PGP 签署发行版就足够了吗? 大概。 只需确保在许多不同的平台上宣传您的公钥,这样例如您的网站就不会让每个人都下载错误的密钥。 (但是反向移植中的 Debian 软件包将 <3)

(此外,可重复的构建?)

既然您将开始对二进制版本进行签名,您是否也可以考虑对推送到注册表的 Docker 镜像进行签名?

似乎不仅仅是 Gitea 受到了打击,还有https://github.com/opencompany/www.opencompany.org/releases

直接给他们的联系人发电子邮件,以防他们还没有查看他们的 GitHub 问题。

@graystevens是否应该联系 pastebin 工作人员以

谢谢大家..会重新下载并备份我的服务器

@justinclift我现在将粘贴报告给 PasteBin - 我有一份内容副本,因此我们可以在需要时重新创建恶意软件的输出。 好喊

公平地说,go 现在具有可重现的构建: https :
这可能是 sqlite 的 cgo 和一些使它们无法重现的构建环境。

仅供参考,以前的重建和未触及的哈希列表。 如果您有这些哈希,则意味着您在我们为重置 1.4.2 版本所做的重建之前以及在攻击之前拥有二进制文件。 如果是这样,你可以和他们在一起。

156655506d373241fea6b8955acbe6fdc148f06b49b4f6e46d11cadcd00d7316  gitea-1.4.2-darwin-10.6-386
5730c1a471dfc2c055442360d431c950b3a4f266403c5f327c94a68b88e67a10  gitea-1.4.2-darwin-10.6-amd64
8c3cc2127161695dea512176cd4282711e8c57972f333253cc89597dfab002ef  gitea-1.4.2-linux-386
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
bca75d81c52b9aa57fd05b8f7ce0572abae3e1a008d8ab77840ca08c53975867  gitea-1.4.2-linux-arm-5
3aa791afce2e3450461038e09622fe04f34b891c47db641be50b6cc3f772645e  gitea-1.4.2-linux-arm64
fc73d06621fc23a944a2a8ee3b19fbd8edb972b0cdaefa67248eb885aa4d6240  gitea-1.4.2-linux-arm-6
5b76cd9b84846c09ba3627219a6cad99542a53d8eec71a427a433ab82eaabacf  gitea-1.4.2-linux-arm-7
4fafeabfa069066fd624364b47b5729f8f068545d4cd8a3620774a982937ac16  gitea-1.4.2-linux-mips64le
7d9e0afcd315f0efbfb26cab303b3fee3939fa0e081b0d3f4f480f950d0a9870  gitea-1.4.2-linux-mips64
7f2e3c1163823889bec1fdd34b4135149c83d53b6dc86f186821e51e0f839e53  gitea-1.4.2-linux-mipsle
a1b8338113d4fdb0360582ba18f6fce97722c779493e7d7e07594d78c7c3f003  gitea-1.4.2-linux-mips
82ad50932bd927ead2e7da4e4c575d94f88e0105a82eda4cce1df7c9fc5ba0dc  gitea-1.4.2-windows-4.0-386.exe
86d7332894390ccaedd39be891044d829f54d4cd71fa21fce5dbd9bc3abbce44  gitea-1.4.2-windows-4.0-amd64.exe

install.exe 清理通行证似乎漏掉了很多存储库:

其中大部分都是旧的,并不完全相关,但保留恶意软件可能不是一个好主意。

@伦尼


去-xorm


探戈


去-xweb


goftp


手游


探戈


去构建

嗯,谢谢。 你用来定位这些的方法是什么? GitHub 员工使用的任何方法似乎都不是 100% 有效。 :皱眉:

@jvanraaij @yaggytter谢谢。

在我们的调查之后,没有其他任何事情受到影响,GitHub 也没有提供更多信息,我认为这个问题可以关闭。 有没有人写过关于这个的博客文章?

@lafriks我在这一切开始后的几天内发布了

我想他想在 gitea 博客上写一篇验尸博客文章:)

@graystevens顺便说一句,您的网站通知链接是 404

在我们的调查之后,没有其他任何事情受到影响,GitHub 也没有提供更多信息......

作为一个数据点,虽然 GitHub 没有在公开场合对此发表任何评论,但他们私下已经回复(通过电子邮件)有效地说“谢谢,我们正在调查”。

@jvanraaij@yasuokav的上述评论似乎也有帮助,因为(奇怪的是,来自我的 PoV)GitHub 在此之前似乎没有找到恶意软件的那些特定实例。

例如, @yasuokav列出的所有 repo 仍然存在恶意软件: https :

我会再次给 GitHub 员工发邮件指出这一点。 当直接联系要查看的确切列表时,他们似乎会在几天内处理好事情。

这对所有其他项目来说都是可悲的,但至少对于 Gitea 我们已经正确地解决了问题,希望...... :)

关闭此问题,因为现在已签署二进制文件,并实施了 2FA。

此页面是否有帮助?
0 / 5 - 0 等级