1 of 40

Detección Automatizada de Archivos Maliciosos en PyPI

Cristina Muñoz

2 of 40

Quien Soy Yo

Ingeniera
<3 seguridad cibernética
Desilusionada con BigTech

Pasé la mayoría de la última década desarrollando software y trabajando en seguridad cibernética en empresas de tecnología y consultorías en San Francisco y Nueva York. Me encanta diseñar sistemas y solucionar problemas humanos con herramientas de software. Mi ultimo trabajo fue en una empresa emergente tecnológica de Google X, llamado Chronicle Security. El producto estrella de Chronicle, llamado Backstory, fue un nuevo tipo de Sistema de información y gestión de eventos (SIEM) por sus siglas en inglés.

Backstory ingiere varios tipos de telemetría, y los escanea constantemente para buscar indicadores de sistemas comprometidos (IoC) por sus siglas en inglés. A los ingenieros de seguridad les encanta las abreviaciones, así es que les pido perdón por adelantado. ¿Cómo es que se encontraron los IoCs? Backstory está integrado con información sobre amenazas y escaneos de virus. El departamento de marketing lo imaginaron Backstory como un panel único de un centro de operaciones de seguridad (SOC) por sus siglas en inglés.

Chronicle fue oficialmente adquirido por Google Cloud en agosto 2019. Esto pasó tres meses después de que lanzamos Backstory al mercado. Después de la adquisición, nuestros nuevos “amos” corporativos me ofrecieron un lugar, pero su estrategia de negocio no estaba alineado con mis intereses personales, y decidí que no quería seguir con Chronicle y Google.

3 of 40

4 of 40

PyPI

Fuente canónico de paquetes de Python

5 of 40

pip install requests

PIP es el gestor de paquetes para Python. Si alguna vez has ejecutado este comando, usted ha utilizado PyPI. Cuando alguien instala paquetes de PyPI, ¿como sabe que estos archivos no son programas malignos? La respuesta a esta pregunta es, “desafortunadamente, no se sabe”. No hay una respuesta concreta porque los administradores de PyPI tampoco lo saben. Son aproximadamente 5,000 archivos subidos a diario a PyPI, y no tienen la capacidad de revisarlos todos manualmente. La Python Software Foundation es una organización sin fines de lucro. Cuenta con 7 empleados de tiempo completo, y solo uno ocupa una función técnica. También hay muchos voluntarios que dedican su tiempo para asegurar la seguridad de PyPI, pero la escala del problema es simplemente demasiada grande para resolverla manualmente.

Nos vemos en la necesidad de una solución automatizada, así que regresamos a los detalles de la solicitud de la propuesta. La solicitud tuvo dos metas con el propósito de fortalecer la seguridad de PyPI.

6 of 40

Solicitud de Propuesta

1. Firma criptográfica verificable de artefactos

2. Sistema para detección automatizada de malware en subidas

7 of 40

Requisitos del Sistema

Extensible
Infraestructura almacenamiento
Interfaz Administrativa
Documentación

8 of 40

Otra Perspectiva

Esto es simplemente un SIEM.

9 of 40

10 of 40

11 of 40

12 of 40

13 of 40

Typosquatting

pip install python3-dateutil

pip install jeIlyfish

14 of 40

pip install jeIlyfish

15 of 40

El paquete malware “python3-dateutil” en PyPI es particularmente engañosa debido a que existe un paquete legítimo en el repositorio Debian con este mismo nombre.

Estos dos proyectos maliciosos fueron creados por el mismo atacante. Un ingeniero de software alemán llamado Lukas Martini descubrió la verdad de estos paquetes el 1ro de diciembre del 2019. Se puso en contacto con el equipo de seguridad de PyPI, y los removieron del repositorio el mismo día. El proyecto “python3-dateutil” solo fue servido por PyPI por 2 días, pero el proyecto “jeIlyfish” permaneció en PyPI por casi un año.

Es muy difícil detectar “typosquatting” porque hay miles de proyectos con nombres similares a proyectos bien conocidos por buena razón. Para combatir este problema, se requiere de heurísticas más avanzadas que la distancia de edición.

16 of 40

Ahora, hablaremos de versiones comprometidas. Esto es un relato de hechos que tomaron lugar en una comunidad de otro lenguaje de programación; Node. Considera este escenario no-tan-hipotético: Un desconocido se pone en contacto con a un ingeniero de software ocupadito, y le ofrece ayudar mantener su proyecto popular. Digamos que el proyecto se llama “event-stream”. Le concede el permiso para modificar y publicar nuevas versiones del proyecto al desconocido. El nuevo contribuidor crea una nueva versión que contiene malware. Cuando los usuarios desprevenidos actualizan su paquete, y se infectan con malware. Así, miles de proyectos son comprometidos.

Los detalles de estos eventos salieron a la luz en noviembre del 2018. El atacante, con el apodo de "right9control" le ofreció a “dominictarr” integrar una nueva dependencia a su proyecto “event-stream”. El nuevo contribuidor lanzó una nueva versión del proyecto, que agregó la dependencia maliciosa para robar Bitcoins. El resultado creo un caos y este issue GitHub.

Aunque esto no ha ocurrido en el ecosistema de Python (que nosotros sepamos), eso no quiere decir que no ocurrirá o que ya ocurrió.

Autores y responsable de proyectos de software open-source forman una gran superficie de ataque, que, en muchos casos, son más fácil explotar que sistemas técnicos. En este caso, el autor daba acceso al proyecto voluntariamente al atacante. Atacantes también tratan de conseguir acceso a cuentas de autores por otros medios: robo de credenciales o ataques de fuerza bruta contra las contraseñas. Autenticación multifactorial mitiga esto tipos de ataque. En PyPI solo existe la posibilidad de habilitar 2-factor autenticación desde hace un año, pero todavía no es requerido.

17 of 40

Ahora, hablaremos de versiones comprometidas. Esto es un relato de hechos que tomaron lugar en una comunidad de otro lenguaje de programación; Node. Considera este escenario no-tan-hipotético: Un desconocido se pone en contacto con a un ingeniero de software ocupadito, y le ofrece ayudar mantener su proyecto popular. Digamos que el proyecto se llama “event-stream”. Le concede el permiso para modificar y publicar nuevas versiones del proyecto al desconocido. El nuevo contribuidor crea una nueva versión que contiene malware. Cuando los usuarios desprevenidos actualizan su paquete, y se infectan con malware. Así, miles de proyectos son comprometidos.

Los detalles de estos eventos salieron a la luz en noviembre del 2018. El atacante, con el apodo de "right9control" le ofreció a “dominictarr” integrar una nueva dependencia a su proyecto “event-stream”. El nuevo contribuidor lanzó una nueva versión del proyecto, que agregó la dependencia maliciosa para robar Bitcoins. El resultado creo un caos y este issue GitHub.

Aunque esto no ha ocurrido en el ecosistema de Python (que nosotros sepamos), eso no quiere decir que no ocurrirá o que ya ocurrió.

Autores y responsable de proyectos de software open-source forman una gran superficie de ataque, que, en muchos casos, son más fácil explotar que sistemas técnicos. En este caso, el autor daba acceso al proyecto voluntariamente al atacante. Atacantes también tratan de conseguir acceso a cuentas de autores por otros medios: robo de credenciales o ataques de fuerza bruta contra las contraseñas. Autenticación multifactorial mitiga esto tipos de ataque. En PyPI solo existe la posibilidad de habilitar 2-factor autenticación desde hace un año, pero todavía no es requerido.

18 of 40

setup.py

from setuptools import setup

from setuptools.command.install import install

from my_evil_module import root_reverse_shell

class PostInstallCommand(install):

def run(self):

root_reverse_shell()

install.run(self)

setup(

name='0wned',

version='0.0.1',

description='Code execution via Python package installation.',

...

cmdclass={

'install': PostInstallCommand,

},

)

Por fin, hablaremos de archivos. En Python, existen dos formatos de distribución para paquetes: “Built” y “Source”. Las distribuciones “Built” son pre-compiladas. Cuando alguien descargue el paquete, los archivos se colocan en el lugar correcto para ejecutar, pero no ejecutan código adicional para instalarse. “Wheel” es un ejemplo de una distribución “Built”, y el formato recomendado actualmente para desarrolladores de paquetes.

Distribuciones “source” son un formato más antiguo de empaquetamiento, y requieren un paso adicional de pre-compilación en el sistema de usuarios de los descarguen. Las instrucciones para esto pasos se contienen en el archivo requerido “setup.py”. Los desarrolladores de paquetes controlan el contenido de “setup.py”, y pueden aprovecharse de esta función para ejecutar código malicioso en el momento de descargue automáticamente. En la industria de seguridad cibernética, llamamos esto: Remote Code Execution (RCE) o Ejecución de Código por via Remota.

Aquí tenemos un ejemplo de ello. El autor puede enganchar al comando “install” para iniciar una “Shell” inversa, y ganar acceso al sistema del usuario. Esto es el método utilizado por el atacante en el primer ejemplo, de los paquetes “python3-dateutil” y “jellyfish”.

19 of 40

20 of 40

Tipos de chequeos

Enganches de eventos: Creación de proyectos, versiones, archivos
Enganches prevista: Investigar patrones y comportamientos

21 of 40

Chequeos de enganche de evento

Enviar subidas a VirusTotal
Hacer analisis estatico o dinamico
Utilizar reglas YARA

22 of 40

SetupPatternCheck

Reglas YARA que avisen cuando encuentren:

Generación de procesos
Conexiones de red
Deserialización
Metaprogramación

De hecho, esto es lo que hicimos. Este escanea el archivo setup.py de cada subida con reglas YARA, para buscar firmas digitales que señala código malicioso.

Las reglas YARA avisan cuando encuentren generaciones de nuevos procesos (por ejemplo, coincidente de la cadena sobre funciones como exec, eval, o el módulo subprocess). Activamos una alerta para conexiones de red porque esto es lo que hace malware para comunicar con servidores de comando y control.

De-serializar se refiere a código serializado u ofuscado que podría contener una carga útil maliciosa. Metaprogramming es otra estrategia de ofuscación que detectamos.

Lo malo de las reglas YARA es que siempre serán una carrera de armamentos. No puedes escribir una regla para un vector de ataque nuevo o desconocido. También, hay muchas razones legítimas que alguien necesita iniciar un nuevo proceso o hacer un a conexión de red en el archivo setup.py.

23 of 40

24 of 40

Chequeos de enganche previstos

Cambios de propiedad
Cambios del nivel de seguridad de cuentas usuarios
Reputación de usuarios
Direcciones IP asociados con VPNs

25 of 40

PackageTurnoverCheck

Vector de amenaza: Un mantenedor cambia o baja el nivel de seguridad de su cuenta, y transfiere propiedad de su proyecto a otro usuario

26 of 40

Warehouse

27 of 40

Warehouse

28 of 40

Warehouse

29 of 40

Warehouse

30 of 40

Warehouse

31 of 40

Warehouse

32 of 40

33 of 40

34 of 40

Interfaz Administrativa

https://test.pypi.org/admin/

35 of 40

36 of 40

El Desarrollo de Chequeos Nuevos

Descargar Warehouse
Heredar la clase MalwareCheckBase y escribir el chequeo
Cambiar una variable de entorno
Implementar con un script
Activarlo en la interfaz administrativa
¡Ejecutarlo!

37 of 40

Documentación

https://warehouse.pypa.io/development/malware-checks/

38 of 40

39 of 40

Agradecimientos

Marco Palacios, Christian Navarrete, Ernest W. Durbin, William Woodruff

40 of 40

Preguntas? Comentarios?

Pongase en contacto: hi@xmunoz.com