Menú principal

viernes, 26 de diciembre de 2014

El iPhone del jefe explota ShellSock en la DMZ de tu red

En la pasada NocONName celebrada en Barcelona, el Dr. Alfonso Muñoz y Ricardo Martín, compañeros de Eleven Paths, presentaron lo que denominaron Shellshock Client-Side Scripting Attack, el cual permite explotar bugs del famoso Shellshock en sistemas no publicados en Internet. El escenario es el siguiente un atacante que se encuentra fuera de la red empresarial prepara un entorno el cual es vulnerable, por ejemplo a un ataque de Cross-Site Scripting.

Cuando la víctima ejecuta código Javascript malicioso se ejecutan varias instrucciones con las que se puede enumerar los recursos de una red interna, tal y como puede verse en la presentación. La idea es que se puede localizar servidores web y otros recursos internos, los cuales pueden ser vulnerables a la vulnerabilidad de Shellshock. En la prueba de concepto que hemos montado simulamos que el dispositivo víctima es un iPhone, como ya se ha visto con otros ejemplos anteriores en los que se abusaba de un iPhone:
- Cómo explotar un SQL Injection en la DMZ a través de un iPhone
- Cómo explotar un CSRF en un router a través de un iPhone
Cuando el dispositivo iOS visita un sitio web malicioso y, por ejemplo, rellena un formulario en el cual tiene que pinchar sobre tres botones, se estará explotando la vulnerabilidad por detrás contra un tercer equipo de la organización.


Figura 1: Presentación de explotación de Shellshock en servidores no publicados

En la prueba de concepto, se preparara con Metasploit un handler con el que se recogerá la sesión en el equipo remoto. Una vez que el dispositivo iPhone accede al sitio web se le presenta un sitio web con el esquema del ataque, pero en un caso real estaríamos hablando de un formulario de registro, encuesta o, simplemente un sitio web con alguna vulnerabilidad client-side, como puede ser un Cross-Site Scripting. La preparación del handler es sencilla indicamos qué tipo de payload esperamos gestionar y qué dirección IP es la nuestra, la del atacante.

Figura 2: Configuración de exploit/multi/handler

La idea ahora es que cuando el dispositivo iOS visite la página realice tres peticiones contra algún activo interno de la organización. Esto es un claro ejemplo de los peligros que puede tener lo que se conoce como BYOD, y el estar conectado a la red corporativa de la organización. Cuando el dispositivo carga el sitio web ejecutará varias peticiones, aunque por simplicidad se ha decidido incluir tres botones en la prueba de concepto para ejemplificar lo que sucede con cada uno de ellos.

Figura 3: Generación de binario con payload

El esquema básico es el siguiente:
  1. Ejecución de comandos en la máquina interna de la organización, petición realizada por el propio iPhone. En esta petición se enviará a la máquina remota un echo con un payload codificado en base64 y se almacenará en /tmp. Para ello se genera el binario y se codifica en base64. 
  2. Una vez se dispone del binario codificado y subido a una máquina vulnerable a Shellshock en la organización, se realizará una segunda petición para decodificar y aplicarle permisos de ejecución al binario. 
  3. Por último, se realizará una tercera petición dónde se ejecutar el binario con el payload, el cual devolverá el control remoto de dicha máquina hacia el exterior de la organización. De este modo queda comprometida una máquina vulnerable a Shellshock que se encuentra en una red interna.
Una vez visto el esquema básico accedemos desde el iPhone al sitio web malicioso. El esquema es bastante claro y refleja el entorno corporativo y las posibilidades del ataque.

Figura 4: Sitio web malicioso

Por simplificación se han colocado tres botones, que ejecutarán cada uno las acciones expuestas anteriormente. En la siguiente imagen se puede ver como cuando el usuario pulsa sobre el botón 1, se ejecuta la primera petición maliciosa que explota la vulnerabilidad de Shellshock y sube un binario codificado en base64.

Figura 5: Subida de fichero a máquina interna de la organización

Cuando el usuario pulsa sobre el botón número dos, se ejecuta otra petición con explotación de Shellshock con la que se decodifica el binario y se le aplican permisos de ejecución mediante la instrucción chmod u+x.

Figura 6: Ejecución de chmod u+x

Por último, cuando el usuario pulsa el botón tres se ejecuta el binario ya preparado para devolver el control al atacante. Estamos ante un payload de tipo inverso, ya que la petición se genera desde la víctima hacia el atacante.

Figura 7: Ejecución de shellcode

Hay que tener en cuenta que en función de los permisos con los que se ejecute el CGI vulnerable, podríamos llegar a ser hasta administrador. Es probable también que no tengamos todos los privilegios, por lo que en ese caso deberíamos realizar una elevación de privilegios, aunque teniendo una sesión el equipo siempre será más sencillo.

Figura 8: Obtención de sesión con Metasploit

Debemos tener mucho cuidado con los distintos ataques, o combinación de ataques como se produce en este caso, y fortificar nuestros navegadores y nuestros entornos internos, aunque pensemos que por estar en una red interna estamos más seguros. Desde hace algunos años existen ciertos riesgos reales de que simplemente por visitar un sitio web con cualquier navegador, la red corporativa esté en riesgo, por lo que cuantas más capas de seguridad mejor.

No hay comentarios:

Publicar un comentario

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares