packj
Rules and placeholder for more upcoming checks
Packj (произношенный пакет) - это инструмент, который помогает смягчить атаки цепочки программного обеспечения. Он может обнаружить вредоносные, уязвимые, заброшенные, опечатки и другие «рискованные» пакеты из популярных реестров с открытым исходным кодом, таких как NPM, Rubygems и PYPI. Его можно легко настроить, чтобы минимизировать шум. PackJ начинал как исследовательский проект PhD и в настоящее время разрабатывается под различными правительственными грантами.
Обратите внимание на самостоятельный веб-сервер Packj и несколько интеграций, которые появятся позже в этом месяце? Посмотрите, как это репо, чтобы оставаться в курсе.
Мы поддерживаем несколько моделей развертывания:
Используйте Packj для аудита зависимостей в запросах.
- name : Packj Security Audit
uses : ossillate-inc/[email protected]
with :
# TODO: replace with your dependency files in the repo
DEPENDENCY_FILES : pypi:requirements.txt,npm:package.json,rubygems:Gemfile
REPO_TOKEN : ${{ secrets.GITHUB_TOKEN }}Посмотреть на Github Marketplace. Пример PR Run.
Самый быстрый способ попробовать/тестировать Packj - это использование Docker. Podman также поддерживается для контейнерных (изолированных) прогонов.
docker run -v /tmp:/tmp/packj -it ossillate/packj:latest --help
Клонировать это репо,
git clone https://github.com/ossillate-inc/packj.git && cd packj
Установить зависимости
bundle install && pip3 install -r requirements.txt
Начните с помощью:
python3 main.py --help
PackJ может ветеринарный пакеты от NPM, PYPI, Rust, PHP и Rubygems Package. Rust и PHP -поддержка - WIP. Мы активно добавляем поддержку реестров. Он также поддерживает проверку местных (неопубликованных) пакетов NPM и PYPI.
| Реестр | Экосистема | Поддерживается |
|---|---|---|
| Npm | JavaScript | ✅ |
| Пипи | Питон | ✅ |
| Груз | Ржавчина | ✅ |
| Rubygems | Рубин | ✅ |
| ПАККАГИСТ | PHP | ✅ |
| Докер | Докер | |
| Nuget | .СЕТЬ | ✅ |
| Мавен | Ява | ✅ |
| Кокопод | Быстрый |
PackJ предлагает следующие инструменты:
PackJ аудит программных пакетов с открытым исходным кодом для «рискованных» атрибутов, которые делают их уязвимыми для атак цепочки поставок. Например, пакеты с истекшим срок службы электронной почты (отсутствие 2FA), большой разрыв с времени выпуска, чувствительные API или разрешения на доступ и т. Д., Оценки рискованны.
Аудит следующее поддерживается:
python3 main.py audit -p pypi:requests rubygems:overcommitpython3 main.py audit -f npm:package.json pypi:requirements.txt По умолчанию audit только выполняет анализ статического кода для выявления рискованного кода. Вы также --trace также провести анализ -t кода, который также может установить все запрашиваемые пакеты в рамках и мониторинга поведения пакетов времени установки. Пожалуйста, смотрите пример вывода ниже.
$ docker run -v /tmp:/tmp/packj -it ossillate/packj:latest audit --trace -p npm:browserify
[+] Fetching 'browserify' from npm..........PASS [ver 17.0.0]
[+] Checking package description.........PASS [browser-side require() the node way]
[+] Checking release history.............PASS [484 version(s)]
[+] Checking version........................RISK [702 days old]
[+] Checking release time gap............PASS [68 days since last release]
[+] Checking author.........................PASS [[email protected]]
[+] Checking email/domain validity.......RISK [expired author email domain]
[+] Checking readme.........................PASS [26838 bytes]
[+] Checking homepage.......................PASS [https://github.com/browserify/browserify#readme]
[+] Checking downloads......................PASS [2M weekly]
[+] Checking repo URL.......................PASS [https://github.com/browserify/browserify]
[+] Checking repo data...................PASS [stars: 14189, forks: 1244]
[+] Checking if repo is a forked copy....PASS [original, not forked]
[+] Checking repo description............PASS [browser-side require() the node.js way]
[+] Checking repo activity...............PASS [commits: 2290, contributors: 207, tags: 413]
[+] Checking for CVEs.......................PASS [none found]
[+] Checking dependencies...................RISK [48 found]
[+] Downloading package from npm............PASS [163.83 KB]
[+] Analyzing code..........................RISK [needs 3 perm(s): decode,codegen,file]
[+] Checking files/funcs....................PASS [429 files (383 .js), 744 funcs, LoC: 9.7K]
[+] Installing package and tracing code.....PASS [found 5 process,1130 files,22 network syscalls]
=============================================
[+] 5 risk(s) found, package is undesirable!
=> Complete report: /tmp/packj_54rbjhgm/report_npm-browserify-17.0.0_hlr1rhcz.json
{
"undesirable": [
"old package: 702 days old",
"invalid or no author email: expired author email domain",
"generates new code at runtime",
"reads files and dirs",
"forks or exits OS processes",
]
}
ПРЕДУПРЕЖДЕНИЕ: Поскольку пакеты могут выполнять вредоносную код во время установки, рекомендуется использовать
-tили--traceтолько при запуске внутри контейнера Docker или виртуальной машины.
Аудит также может быть проведен в контейнерах Docker/Podman. Пожалуйста, найдите подробную информацию о рискованных атрибутах и о том, как использовать в Audit Readme.
PackJ предлагает легкую песочницу для safe installation пакета. В частности, он предотвращает эксплуатирующие конфиденциальные данные, доступа к конфиденциальным файлам (например, клавиши SSH) и сохраняющуюся вредоносную программу.
Сценарии установки с песочницей ИТ, в том числе любое собственное соответствие. Он использует Strace (т.е. не требуется виртуальная/контейнер).
Пожалуйста, найдите подробную информацию о механизме песочницы и о том, как использовать в Sandbox Readme.
$ python3 main.py sandbox gem install overcommit
Fetching: overcommit-0.59.1.gem (100%)
Install hooks by running `overcommit --install` in your Git repository
Successfully installed overcommit-0.59.1
Parsing documentation for overcommit-0.59.1
Installing ri documentation for overcommit-0.59.1
#############################
# Review summarized activity
#############################
[+] Network connections
[+] DNS (1 IPv4 addresses) at port 53 [rule: ALLOW]
[+] rubygems.org (4 IPv6 addresses) at port 443 [rule: IPv6 rules not supported]
[+] rubygems.org (4 IPv4 addresses) at port 443 [rule: ALLOW]
[+] Filesystem changes
/
└── home
└── ubuntu
└── .ruby
├── gems
│ ├── iniparse-1.5.0 [new: DIR, 15 files, 46.6K bytes]
│ ├── rexml-3.2.5 [new: DIR, 77 files, 455.6K bytes]
│ ├── overcommit-0.59.1 [new: DIR, 252 files, 432.7K bytes]
│ └── childprocess-4.1.0 [new: DIR, 57 files, 141.2K bytes]
├── cache
│ ├── iniparse-1.5.0.gem [new: FILE, 16.4K bytes]
│ ├── rexml-3.2.5.gem [new: FILE, 93.2K bytes]
│ ├── childprocess-4.1.0.gem [new: FILE, 34.3K bytes]
│ └── overcommit-0.59.1.gem [new: FILE, 84K bytes]
├── specifications
│ ├── rexml-3.2.5.gemspec [new: FILE, 2.7K bytes]
│ ├── overcommit-0.59.1.gemspec [new: FILE, 1.7K bytes]
│ ├── childprocess-4.1.0.gemspec [new: FILE, 1.8K bytes]
│ └── iniparse-1.5.0.gemspec [new: FILE, 1.3K bytes]
├── bin
│ └── overcommit [new: FILE, 622 bytes]
└── doc
├── iniparse-1.5.0
│ └── ri [new: DIR, 119 files, 131.7K bytes]
├── rexml-3.2.5
│ └── ri [new: DIR, 836 files, 841K bytes]
├── overcommit-0.59.1
│ └── ri [new: DIR, 1046 files, 1.5M bytes]
└── childprocess-4.1.0
└── ri [new: DIR, 272 files, 297.8K bytes]
[C]ommit all changes, [Q|q]uit & discard changes, [L|l]ist details:
TL; Dr Packj начал как исследовательский проект PhD. Он подкреплен различными государственными грантами.
Packj начал как академический исследовательский проект. В частности, методы анализа статического кода, используемые PackJ, основаны на передовых исследованиях кибербезопасности: проект Maloss нашей исследовательской группы в Georgia Tech.
PackJ поддерживается щедрыми грантами от NSF, GRA и Alinnovate.
TL; DR Современные сканеры уязвимости предполагают, что сторонний код с открытым исходным кодом является доброкачественным. Следовательно, все такие инструменты рассматривают только угрозы от случайных ошибок программирования в доброкачественном коде (он же CVE, такие как log4j). Они не защищают от SolarWinds, подобных современным атакам цепочки поставок программного обеспечения от умышленно плохого (он же злонамеренного) кода, который распространяется плохими субъектами, использующими новые уязвимости в канале поставок, включая путаницу зависимости, опечатки, протестующую посуду (саботирование), бросание на счет и социальную инженерию. Недавний (Dec'22) примером является пакет Pytorch, который был скомпрометирован с использованием уязвимости путаницы зависимости (не назначен CVE).
PackJ не только аудиты для CVE, но также выполняет глубокий статический+динамический анализ кода, а также проверки метаданных для обнаружения какого -либо «рискованного» поведения и атрибутов, таких как нерестование оболочки, использование ключей SSH, несоответствие кода Github VS упакованного кода (Provenance), отсутствие 2FA и еще несколько. Такие небезопасные атрибуты не квалифицируются как CVE, поэтому ни один из существующих инструментов не может пометить их. PackJ может помечать злонамеренные, опечатки, заброшенные, уязвимые и другие небезопасные зависимости (слабые ссылки) в вашей цепочке поставок программного обеспечения.
Текущая модель угрозы цепочки поставок программного обеспечения предполагает , что сторонний код с открытым исходным кодом является доброкачественным, и, следовательно, уязвимости безопасности отслеживаются только для случайных ошибок программирования (он же CVES). Таким образом, все существующие сканеры уязвимости с открытым исходным кодом только сообщают только об общедоступных CVE и адресациях угрозы случайных ошибок в доброкачественном коде.
Типичным примером случайной ошибки программирования является отсутствующая проверка границ на пользовательском вводе, что делает код уязвимым для буферизации переполненных атак. Популярные примеры реального мира включают Log4J и Heartbleed. Злоумышленники должны разработать эксплойт для запуска CVES (например, созданный пакет TCP/IP в случае сердца или численно высокого ввода, вызванного переполнением буфера). CVES можно исправить путем исправления или обновления до более новой версии библиотеки (например, более новая версия log4j исправляет CVE).
Современная ландшафт угрозы цепочки поставок программного обеспечения изменился после атаки SolarWinds. Плохие актеры нашли новые уязвимости, но на этот раз в канале поставок, а не код. Эти новые уязвимости, такие как путаница зависимостей, опечатка, протестующая посуда (саботирование), угон учетной записи и социальная инженерия, используются для распространения вредоносных программ. Сообщалось о тысячах скомпрометированных пакетов NPM/PYPI/Ruby.
В отличие от CVE, вредоносное ПО намеренно плохим (он же злонамеренно) код. Более того, сам вредоносные программы являются эксплойтом и не могут быть исправлены или исправлены путем обновления до более новой версии. Например, атака путаницы зависимости была преднамеренно злонамеренной; Он не использовал какую -либо случайную ошибку программирования в коде. Точно так же автор популярного пакета саботирует свой собственный код для протеста против войны, очень преднамерен и не использует никаких CVE. Опечатка-это еще один вектор атаки, который плохие субъекты используют для распространения вредоносных программ в популярных реестров с открытым исходным кодом: он использует опечатки и неопытность разработчиков, а не случайных ошибок или CVES в коде.
Существующие сканеры не могут обнаружить эти атаки современной цепочки программного обеспечения, похожих на солнечные тиры, из преднамеренно уязвимого (вредоносного) кода. Эти инструменты просто отсканируют исходный код для зависимостей с открытым исходным кодом, составляют список всех используемых зависимостей и посмотрите каждую <зависимость-имени, зависимость-версии> в базе данных (например, NVD), чтобы сообщать о влиятельных версиях пакетов (например, уязвимая версия log4j, версия Libssl, затронутая Heartbleed).
PackJ не только аудиты для CVE, но также выполняет глубокий статический+динамический анализ кода, а также проверки метаданных для обнаружения какого -либо «рискованного» поведения и атрибутов, таких как нерестование оболочки, использование ключей SSH, несоответствие кода Github VS упакованного кода (Provenance), отсутствие 2FA и еще несколько. Такие небезопасные атрибуты не квалифицируются как CVE, поэтому ни один из существующих инструментов не может пометить их. PackJ может помечать злонамеренные, опечатки, заброшенные, уязвимые и другие небезопасные зависимости (слабые ссылки) в вашей цепочке поставок программного обеспечения. Пожалуйста, прочитайте больше на Audit Readme
PackJ можно легко настроить (нулевой шум) для вашей модели угроз. Просто добавьте файл .packj.yaml в верхний директор вашего репо/проекта и уменьшите усталость от предупреждения, комментируя нежелательные атрибуты.
Мы обнаружили более 40 и 20 вредоносных пакетов на PYPI и Rubygems, соответственно, используя этот инструмент. Некоторые из них были сняты. См. Пример ниже:
$ python3 main.py audit pypi:krisqian
[+] Fetching 'krisqian' from pypi...OK [ver 0.0.7]
[+] Checking version...OK [256 days old]
[+] Checking release history...OK [7 version(s)]
[+] Checking release time gap...OK [1 days since last release]
[+] Checking author...OK [[email protected]]
[+] Checking email/domain validity...OK [[email protected]]
[+] Checking readme...ALERT [no readme]
[+] Checking homepage...OK [https://www.bilibili.com/bangumi/media/md140632]
[+] Checking downloads...OK [13 weekly]
[+] Checking repo_url URL...OK [None]
[+] Checking for CVEs...OK [none found]
[+] Checking dependencies...OK [none found]
[+] Downloading package 'KrisQian' (ver 0.0.7) from pypi...OK [1.94 KB]
[+] Analyzing code...ALERT [needs 3 perms: process,network,file]
[+] Checking files/funcs...OK [9 files (2 .py), 6 funcs, LoC: 184]
=============================================
[+] 6 risk(s) found, package is undesirable!
{
"undesirable": [
"no readme",
"only 45 weekly downloads",
"no source repo found",
"generates new code at runtime",
"fetches data over the network: ['KrisQian-0.0.7/setup.py:40', 'KrisQian-0.0.7/setup.py:50']",
"reads files and dirs: ['KrisQian-0.0.7/setup.py:59', 'KrisQian-0.0.7/setup.py:70']"
]
}
=> Complete report: pypi-KrisQian-0.0.7.json
=> View pre-vetted package report at https://packj.dev/package/PyPi/KrisQian/0.0.7
PackJ отметил Krisqian (v0.0.7) как подозрительный из -за отсутствия исходного репо и использования конфиденциальных API (сеть, генерация кода) во время установки пакета (в setup.py). Мы решили глубже взглянуть и нашли пакет злоумышленником. Пожалуйста, найдите наш подробный анализ по адресу https://packj.dev/malware/krisqian.
Больше примеров вредоносных программ, которые мы нашли, перечислены по адресу https://packj.dev/malware, пожалуйста, обратитесь к нам по адресу [email protected] для полного списка.
Чтобы узнать больше о атаках Packj Tool или программного обеспечения с открытым исходным кодом, обратитесь к нашим
Смотреть ? Это репо, чтобы оставаться в курсе.
Есть функция или запрос на поддержку? Пожалуйста, посетите нашу страницу для обсуждения GitHub или присоединяйтесь к нашему сообществу Discord для обсуждения и запросов.
PackJ был разработан исследователями кибербезопасности в Ossillate Inc. и внешними сотрудниками, чтобы помочь разработчикам снижать риски атак цепочки поставок при поиске ненадлежащих сторонних зависимостей с открытым исходным кодом. Мы благодарим наших разработчиков и сотрудников. Покажите свою признательность, дав нам, если вам нравится наша работа.
Мы приветствуем кодовые взносы с распростертыми объятиями. См. Руководящие принципы Appling.md. Нашел ошибку? Пожалуйста, откройте проблему. Обратитесь к нашим руководящим принципам Security.md, чтобы сообщить о проблеме безопасности.
В настоящее время PackJ может проверять пакеты NPM, PYPI и Rubygems для «рискованных» атрибутов. Мы добавляем поддержку для ржавчины.
PackJ использует анализ статического кода, динамический отслеживание и анализ метаданных для комплексного аудита. Статического анализа недостаточно для того, чтобы пометить сложное вредоносное ПО, которое может лучше скрывать себя, используя запутывание кода. Динамический анализ выполняется путем установки пакета в strace и мониторинга его поведения времени выполнения. Пожалуйста, прочитайте больше на Audit Readme.
Это очень распространенное злонамеренное поведение. PackJ обнаруживает запутывание кода, а также нерестование команд оболочки (Exec System Call). Например, PackJ может помечать использование getattr() и eval() API, поскольку они указывают «генерация кода времени выполнения»; Разработчик может пойти и глубже взглянуть. Смотрите Main.py для деталей.
