Reveláronse os detalles do ataque á infraestrutura utilizada no desenvolvemento do marco de aprendizaxe automática PyTorch, o que permitiu extraer claves de acceso suficientes para colocar datos arbitrarios no repositorio con versións do proxecto en GitHub e AWS, así como para substituír código. na rama principal do repositorio e engadir unha porta traseira a través de dependencias. A suplantación de versión de PyTorch podería usarse para atacar a grandes empresas como Google, Meta, Boeing e Lockheed Martin que usan PyTorch nos seus proxectos. Como parte do programa Bug Bounty, Meta pagou aos investigadores 16250 dólares para obter información sobre o problema.
A esencia do ataque é a capacidade de executar o seu código en servidores de integración continua que realizan reconstrucións e executan traballos para probar os novos cambios enviados ao repositorio. O problema afecta a proxectos que usan os seus propios controladores externos "Self-Hosted Runner" con accións de GitHub. A diferenza das accións tradicionais de GitHub, os controladores autoaloxados non se executan na infraestrutura de GitHub, senón nos seus propios servidores ou en máquinas virtuais mantidas polo desenvolvedor.
Executar tarefas de montaxe nos seus servidores permítelle organizar o lanzamento de código que pode escanear a rede interna dunha empresa, buscar no FS local claves de cifrado e tokens de acceso e analizar variables ambientais con parámetros para acceder a servizos de almacenamento externo ou na nube. A falta dun illamento adecuado do ambiente de montaxe, os datos confidenciais atopados pódense enviar externamente aos atacantes, por exemplo, mediante o acceso a API externas. Para determinar o uso de Self-Hosted Runner por proxectos, o kit de ferramentas Gato pódese usar para analizar ficheiros de fluxo de traballo accesibles publicamente e rexistros de inicio de tarefas de CI.
En PyTorch e en moitos outros proxectos que usan Self-Hosted Runner, só os desenvolvedores cuxos cambios foron previamente revisados por pares e incluídos na base de código do proxecto poden executar traballos de compilación. Ter o estado de "colaborador" cando se usa a configuración predeterminada no repositorio fai posible iniciar os manejadores de GitHub Actions cando se envían solicitudes de extracción e, en consecuencia, executar o seu código en calquera ambiente GitHub Actions Runner asociado co repositorio ou coa organización que supervisa o proxecto.
A ligazón ao estado de "colaborador" resultou fácil de ignorar: é suficiente con enviar primeiro un cambio menor e esperar a que se acepte na base de código, despois de que o desenvolvedor recibiu automaticamente o estado de participante activo. cuxas solicitudes de extracción poden ser probadas na infraestrutura de CI sen verificación separada. Para acadar o estado de desenvolvedor activo, o experimento incluíu pequenos cambios cosméticos para corrixir erros tipográficos na documentación. Para acceder ao repositorio e ao almacenamento das versións de PyTorch, o ataque ao executar código no Self-Hosted Runner interceptou o token de GitHub utilizado para acceder ao repositorio desde os procesos de compilación, así como as claves de AWS utilizadas para gardar os resultados da compilación.
O problema non é específico de PyTorch e afecta a moitos outros proxectos grandes que usan a configuración predeterminada para "Self-Hosted Runner" en GitHub Actions. Por exemplo, mencionouse a implementación de ataques similares para instalar unha porta traseira nalgunhas grandes carteiras de criptomonedas e proxectos de blockchain cunha capitalización de miles de millóns de dólares, facer cambios nas versións de Microsoft Deepspeed e TensorFlow, comprometer unha das aplicacións CloudFlare e tamén executar código nun ordenador da rede de Microsoft. Os detalles destes incidentes aínda non foron revelados. Baixo os programas de recompensa de erros existentes, os investigadores enviaron máis de 20 solicitudes de recompensas por valor de varios centos de miles de dólares.
Fonte: opennet.ru