Каталогът PyPI внедри нова система за удостоверяване на пакети.

Разработчиците на хранилището за Python-пакети PyPI (Python Package Index) обявиха внедряването на поддръжка за механизма за цифрова атестация, който ще се използва за проверка на автентичността на публикуваните пакети, заменяйки верификацията с PGP подписи. Основната разлика при атестацията е, че публикуването на пакета се заверява не от разработчика, а от трета страна (каталог на пакети) след потвърждение на валидността на публикацията чрез външен доставчик OpenID Connect (например, след проверка, че публикуваният пакет съответства на свързаното с него хранилище в GitHub или GitLab).

Системата за атестация преодолява недостатъците на механизма на верификация с PGP подписи, който преди това беше обявен за остарял в PyPI. Това решение беше взето поради проблеми с проверката на принадлежността на разработчиците към публичните PGP ключове, използвани за проверка на цифровите подписи — от 1069 PGP ключа, използвани от 2020 година за генериране на подписи в PyPI, 29% от публичните ключове липсваха на големи публични сървъри ключове, а 35% от ключовете не можаха да бъдат потвърдени по време на одит. В същото време потвърдените 36% PGP ключове обхващаха само 0.3% от всички подписани файлове.

В новата система, използваните за заверяване на пакети подписи се създават с помощта на краткотрайни ефимерни ключове, генерирани на базата на пълномощия, потвърдени от доставчиците на OpenID Connect. В момента на генериране на ключовете, необходими за създаване на цифрова подпис, разработчикът се идентифицира чрез доставчик на OpenID, потвърдващ връзката му с основния проект. Инфраструктурата за цифрова атестация е изградена с помощта на системата Sigstore и инструментария in-toto Attestation Framework.

Сред предимствата на атестирането е отсъствието на връзка с постоянни PGP-ключове — загубата или компрометацията на частния ключ разрушава доверието в подписите, създадени на негова основа, докато при атестацията подписът се формира във връзка с токен, който потвърждава правомощията в момента на публикуване на пакета и свързва пакета с основния хранилище с кода. Например, при публикуване на пакет, подготвен чрез GitHub Action, атестацията определя верифицируема и потвърдена връзка между поставяния в PyPI файл, хранилището, работния процес и хеша на комита, на база на който е формиран пакетът.

За проследяване на автентичността на ключовете и разкриване на възможни компрометации, за формиращите пакети на проектите и самия PyPI се използва публичен централен лог, за осигуряване на целостта и защита от изкривяване на данните задним числом, в който е внедрена структурата «дърво на Меркъл» (Merkle Tree, всяка клонка верифицира всички подлежащи клонки и възли благодарение на дървовидното хеширане).

Допълнително, можем да отбележим открития в каталога PyPI на злонамерения пакет «fabrice», който чрез тайпсквотинг (присвояване на подобни наименования, различаващи се с отделни символи, например, exampl вместо example, djangoo вместо django, pyhton вместо python и т.н.) се маскирал като популярна библиотека «fabric», която има 201 милиона изтегляния (7 милиона изтегляния за миналия месец). Злонамереният пакет остава незабелязан от 2021 година и оттогава е изтеглен повече от 37 хиляди пъти.

Пакетът «fabrice» повторял основната функционалност на изходната библиотека и допълнително включвал код за разкриване и изпращане на външни хостове на ключове за достъп до AWS (Amazon Web Services), инсталиране на бекдор и изпълнение на определени скриптове. Активацията на злонамерените компоненти ставаше на Linux и Windows. В Linux, свързаните със злонамерената активност файлове се качвали в каталога ~/ .local/ bin/ vscode.

Източник: opennet.ru