Los desarrolladores del repositorio de paquetes de Python, PyPI (Python Package Index), han anunciado la implementación de un mecanismo de certificación digital para autenticar los paquetes publicados, que reemplaza la verificación mediante firmas PGP. La clave de esta certificación es que la publicación de un paquete no la valida el propio desarrollador, sino una tercera parte (el catálogo de paquetes) tras verificar la autenticidad de la publicación a través de un proveedor externo de OpenID Connect (por ejemplo, después de comprobar que el paquete publicado está relacionado con su repositorio en GitHub o GitLab).
El sistema de certificación elimina las deficiencias propias del mecanismo de verificación mediante firmas PGP, que anteriormente fue declarado obsoleto en PyPI. Esta decisión se tomó debido a los problemas relacionados con la verificación de la propiedad de las claves PGP públicas utilizadas para autenticar las firmas digitales: de las 1069 claves PGP utilizadas desde 2020 para generar firmas en PyPI, el 29% de las claves públicas estaban ausentes en los principales directorios públicos. como en entornos de nube públicos o privados. Además, el 35% de las claves no pudieron ser validadas durante la auditoría. Al mismo tiempo, se confirmó que solo el 36% de las claves PGP abarcaba el 0.3% de todos los archivos firmados.
En el nuevo sistema, las firmas utilizadas para certificar paquetes se generan con claves efímeras de corta duración, que son creadas sobre la base de las credenciales validadas por proveedores de OpenID Connect. En el momento de la generación de las claves necesarias para crear la firma digital, el desarrollador se identifica a través del proveedor de OpenID, que valida su conexión con el proyecto principal. La infraestructura para la certificación digital se construyó utilizando el sistema Sigstore y el marco de trabajo in-toto Attestation Framework.
Entre las ventajas de la certificación se destaca la ausencia de dependencia de claves PGP permanentes: la pérdida o compromisión de la clave privada destruye la confianza en las firmas creadas con ella, mientras que en la certificación la firma se forma en relación con un token que confirma las credenciales en el momento de la publicación del paquete y la conexión del paquete con el repositorio principal del código. Por ejemplo, al publicar un paquete preparado a través de GitHub Action, la certificación establece una conexión verificable y confirmada entre el archivo que se sube a PyPI, el repositorio, el proceso de flujo de trabajo y el hash del commit en base al cual se generó el paquete.
Para rastrear la autenticidad de las claves y detectar posibles compromisos, se utiliza un registro centralizado público por parte de quienes generan los paquetes de proyectos y de PyPI mismo; para asegurar la integridad y proteger contra la alteración de datos en el pasado, se emplea la estructura de «árbol de Merkle» (Merkle Tree), donde cada rama verifica todas las ramas y nodos descendentes gracias al hashing en árbol.
Además, se puede señalar el descubrimiento en el catálogo de PyPI de un paquete malicioso llamado «fabrice», que mediante typosquatting (uso de nombres similares que difieren en símbolos individuales, por ejemplo, exampl en lugar de example, djangoo en lugar de django, pyhton en lugar de python, etc.) se disfrazaba de la popular biblioteca «fabric», que cuenta con 201 millones de descargas (7 millones de descargas el mes pasado). El paquete malicioso había permanecido sin ser detectado desde 2021 y desde entonces había sido descargado más de 37 mil veces.
El paquete «fabrice» replicaba la funcionalidad básica de la biblioteca original e incluía además código para detectar y enviar claves de acceso a AWS (Amazon Web Services) a un host externo, instalar un backdoor y ejecutar ciertos scripts. La activación de los componentes maliciosos se producía en Linux y Windows. En Linux, los archivos relacionados con la actividad maliciosa se cargaban en el directorio ~/.local/bin/vscode.
Fuente: opennet.ru
