Backdoors en IDEs de desarrollo – Ponencia rootedcon 2015

Este artículo detalla el contenido de la ponencia «Bend the developers to your will» presentada en el congreso RootedCon 2015 por Miguel Tarascó.

1. ¿Porque los desarrolladores?

Los desarrolladores son un vector de infección y punto de entrada en las empresas muy interesante ya que suelen ser usuarios privilegiados, tienen acceso a credenciales o ficheros de configuración, en muchos casos acceso a los servidores de producción y como son humanos, necesitan buscar información o «inspiración» en internet.

2. Objetivos.

El objetivo de la charla no es hablar de cómo infectar código, sino que se dará un paso atrás para tener una visión más global de como es el día a día de un desarrollador, ver que herramientas usa, y analizar cuáles de estas herramientas se pueden forzar o abusar para que el desarrollador realice tareas no definidas o no esperadas que sirvan para desplegar backdoors desde el código y permitir la ejecución de comandos arbitrarios o la infección de su sistema con malware.

3. Estado del arte.

La troyanización de código y ocultación de backdoors no es algo nuevo, siempre se ha realizado a través del código fuente de la aplicación ocultando llamadas o mediante malware, que tras un acceso no autorizado, infecta los ficheros fuente, el caso más claro es el de malware que ataca servidores web para incrustar llamadas a un exploit kit o iframe para realizar los ataques a los clientes.

4. Backdoors en gestores de compilación

Los proyectos de desarrollo son complejos e intervienen un gran número de desarrolladores. Para simplificar la gestión de estos proyectos han aparecido los gestores de compilación, que son los encargados de gestionar desde cuales son los ficheros a compilar hasta el orden en el que se tiene que realizar el proceso para que no haya problemas de dependencias.

Para la ponencia se han analizado los ficheros de compilación del make, vemos cómo se realiza este proceso desde el Visual Studio mediante el uso de MsBuild y el Gradle, usado en el Android Studio, también se ve que ocurre con Xamarin, antiguamente llamado MonoDevelop, siendo un IDE de desarrollo multiplataforma para Windows, MacOsx y Linux compatible con .Net a través de Mono.

A continuación se incluyen los enlaces a las tres primeras demos de ejecución de backdoors en estos motores:

• Demo 1: MsBuild
• Demo2: Gradle para en Android Studio
• Demo3: Xamarin

Mostramos como se puede abusar de estos gestores y como con solo compilar el código, sin necesidad de ejecución del resultado, es posible insertar una backdoor en el sistema, hacer un “Man in the middle” al compilador de forma que se inserte una backdoor de código en el binario resultante así como la ejecución de comandos o escritura re ficheros, como malware o APTs

Se da un paso más hacia atrás para ver con más perspectiva el desarrollo de una aplicación, se analiza que ocurre durante el desarrollo de aplicaciones gráficas y de cómo estas hacen uso de los componentes gráficos en tiempo de diseño, Se ve en qué consisten y como estos se pueden diseñar por parte de un desarrollador para ajustar su forma y comportamiento a lo que necesite.

Desde el visual Studio se comprobará lo que ocurre al incluir un componente grafico a un formulario y que simplemente pasando el ratón por encima de este tendremos una ejecución de código permitiendo troyanizar el sistema o ejecutar comandos arbitrarios, esto se debe a la manera que tienen los IDEs de permitir que se dibujen los componentes en tiempo de diseño al igual que permiten que se puedan interactuar con ellos desde el diseñador, también se hara una prueba con el Android Studio para comprobar cómo se comporta a la hora de gestionar los componentes gráficos.

El vídeo de la demo se encuentra disponible aquí.

5. Conclusiones

Las conclusiones que extraemos es que no nos podemos fiar del código fuente publicado en internet, ni tan siquiera si no lo vamos a ejecutar, ya que puede incluir backdoors que se ejecuten en tiempo de diseño o de compilación.

Por esto no debemos confiar en código desarrollado por extraños, debemos revisar siempre el código fuente y también el resto de ficheros del proyecto y usar siempre este código desde máquinas virtuales o sandboxes para evitar que nos infecten los equipos de desarrollo con backdoors.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/