El marco PyTorch ML se vio comprometido en un ataque a la cadena de suministro

31 de diciembre de 2022 Marco de aprendizaje automático de PyTorch Anunciado informó en su sitio web que uno de sus paquetes se rompió a través del repositorio PyPI. PyTorch es un marco para la computación de tensor con una poderosa aceleración de GPU y redes neuronales profundas construidas en sistemas de autograduación basados ​​en cintas.

Según la empresa, cualquier instalación de la versión nocturna de PyTorch entre el 25 de diciembre de 2022 y el 30 de diciembre de 2022 está en riesgo. A diferencia de las versiones estables, que se benefician de más pruebas para evitar errores o vulnerabilidades, el software nocturno se actualiza diariamente. La versión estable de PyTorch no se ve afectada por este ataque.

El problema en la versión nocturna afectó a una dependencia de software llamada torchtriton instalada a través de pip de PyPI, que estaba comprometida y ejecutaba un binario malicioso cuando se importaba torchtriton.

¿Qué es el repositorio de código PyPI?

PyPI, también conocido como Python Package Index, mantiene más de 400 000 proyectos que representan más de 7 millones de archivos. Este administrador de paquetes ayuda a los desarrolladores a mantener y distribuir actualizaciones para su código. Es muy utilizado en empresas que necesitan varios softwares escritos en Python.

VER: Kit de reclutamiento: desarrollador de Python (Premium de TechRepublic)

PyPI se puede consultar fácilmente a través de la línea de comandos para instalar y actualizar el software de Python, por ejemplo, usando el comando pip. Si bien dichos repositorios de código facilitan que los usuarios y administradores trabajen con el software, también pueden atraer a los actores de amenazas en demanda. forma de propagar malware.

¿Cómo sucedió el compromiso de PyTorch?

Según el equipo de PyTorch, el viernes 30 de diciembre de 2022, alrededor de las 16:40, se cargó un paquete de dependencia de torchtriton malicioso en el repositorio de PyPI. índice.

PyTorch explica que “Este paquete malicioso se instaló en lugar de la versión de nuestro repositorio oficial porque se prefiere el índice PyPI. Este diseño permite que alguien registre un paquete con el mismo nombre que uno que existe en un índice de terceros, y pip instalará su propia versión de manera predeterminada”.

Henrik Pleit, investigador de seguridad y CISSP en Endor Labs, dijo a TechRepublic que “la técnica utilizada en el ataque es similar a la confusión de dependencias conocida y utiliza instalaciones donde se utilizan múltiples repositorios de paquetes para descargar dependencias de proyectos. Según el algoritmo de resolución del administrador de paquetes, como el orden en que se contacta con los repositorios, un atacante puede obligar al administrador de paquetes a descargar su paquete malicioso en lugar de un paquete legítimo”.

Carga dañada

En este ataque a la cadena de suministro, el código malicioso tenía como objetivo recopilar datos del sistema, como:

• Servidores de nombres utilizados por el sistema
• nombre de host
• Nombre de usuario registrado actual
• El nombre del directorio de trabajo actual
• Variables ambientales

También está diseñado para leer varios archivos:

• /etc/hosts
• /etc/contraseña
• Los primeros 1000 archivos del directorio de inicio del usuario tienen un límite de tamaño de 99 999 bytes
• Archivo Gitconfig
• Cualquier clave Secure Shell almacenada en la máquina

Una vez recopilados, todos los datos se cargaron en el dominio h4ck(.)cfd utilizando un servidor DNS en wheezy(.)io a través de consultas cifradas del sistema de nombres de dominio.

Un usuario de Twitter reclama la propiedad del ataque

En un giro sorprendente de los acontecimientos, un usuario de Twitter apodado BadRequests tuvo lugar posesión para ataque y se disculpó. BadRequests dijo que la intención no era maliciosa y que se eliminaron todos los datos recopilados.

El supuesto ingeniero de seguridad señala que esto está relacionado con la investigación de problemas de confusión de dependencias y que el problema se informó a Facebook el 29 de diciembre. Aparentemente, BadRequests no sabía que PyTorch ya no está a cargo de Facebook/Meta, sino de la Fundación Linux.

VER: Descifrado de contraseñas: por qué la cultura pop y las contraseñas no se mezclan (PDF gratuito) (República Tecnológica)

En el caso de una recompensa por error simple, es posible que se pregunte por qué esta persona recopiló todas las claves SSH del directorio SSH de los usuarios comprometidos y por qué todos los datos se enviaron encriptados a través de consultas de DNS. Además, el incidente podría generar problemas legales para BadRequests, ya que es posible que el atacante haya recopilado datos personales de manera ilegal, y las empresas o personas afectadas pueden querer demandarlos.

¿Cómo detectar compromisos?

PyTorch proporciona una línea de comando que busca el paquete torchtriton e imprime si afecta el entorno de Python:

python3 -c "import pathlib;import importlib.util;s=importlib.util.find_spec('triton'); affected=any(x.name == 'triton' for x in (pathlib.Path(s.submodule_search_locations[0] if s is not None else '/' ) / 'runtime').glob('*'));print('You are {}affected'.format('' if affected else 'not '))"

Si el sistema está comprometido, PyTorch y torchtriton deben desinstalarse y reinstalarse utilizando los archivos binarios más recientes.

Además, se recomienda a los usuarios afectados que reemplacen todas las claves SSH, ya que han sido comprometidas y enviadas al atacante.

Cómo proteger a su organización de estos ataques

El equipo de PyTorch escribió que la dependencia de torchtriton para los paquetes nocturnos se eliminó y reemplazó con pytorch-triton, y se registró un paquete ficticio en PyPI. Esto asegurará que el mismo problema no vuelva a ocurrir. PyTorch también contactó a PyPI para obtener la propiedad adecuada del paquete torchtriton y eliminar la versión maliciosa.

Cuando se le preguntó acerca de esto, Henrik Plate le dijo a TechRepublic que “este vector de ataque puede abordarse mediante el uso de repositorios privados para recibir paquetes internos y reflejar paquetes externos, p. devpi En el caso del ecosistema Python. Por lo general, estas soluciones permiten un mayor control sobre la resolución de dependencias y los procesos de descarga de paquetes. Sin embargo, requieren poco esfuerzo para configurarse y operarse, y solo son efectivos cuando los clientes de desarrolladores nativos están configurados correctamente”.

Divulgar: Trabajo para Trend Micro, pero las opiniones expresadas en este artículo son mías.