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.

Kaiten: ShellShock para distribuir malware en Mac OS X

Algunos delincuentes están explotando la vulnerabilidad de ShellShock para infectar numerosos sistemas, incluyendo a los OS X de Apple. Kaiten en un software que permite realizar denegación de servicio distribuida. Investigadores de la empresa Trend Micro han informado que descubrieron la campaña de distribución a través de un blog, advirtiendo que tiene el potencial para causar ataques DDoS a gran escala. Los investigadores indicaron que habían encontrado unos payloads que les llamaron la atención. Identificaron el fichero troj_bashkai.sm el cual es un código que permite descargar el malware Kaiten. Este malware no es nuevo y es controlado por IRC, pero ha llamado la atención los diferentes usos que se está haciendo de esta vulnerabilidad.

También indicaron que, por lo general, los sistemas infectados convierten a las máquinas infectadas en bots otorgando el control y permitiendo utilizar la potencia de la red para DDoS. El fichero encontrado está dirigido a sistemas operativos Mac OS X, por lo que queda claro que los atacantes están ampliando miras en lo que a plataformas se refiere. Para la gente de Trend Micro la amenaza es doble ya que Apple ha dicho a sus usuarios que ellos son seguros por defecto. 

Figura 1: Por ahora, Kaiten ha sido detectado solo en Mac OS X de Colombia

Es cierto que Apple ha lanzado parches de seguridad para solventar el problema de ShellShock para OS X Mavericks, OS X Lion y OS X Mountain Lion. Los investigadores añadieron que los administradores TI deben estar atentos para mitigar los posibles ataques que puedan sufrir sus usuarios.

El funcionamiento es sencillo, se conecta a http://www.computer-services.name/b.c. se descarga el código fuente de Kaiten, el cual es compilado con gcc. Esto significa que una vez que se accede a la dirección no se descarga un binario de inmediato y sí código fuente que posteriormente se compilará. Esta forma de actuar podría verse como una técnica de evasión de algunos sistemas de seguridad, tanto de red como antimalware.

VMWare Fusion vulnerable a ShellShock en tu OS X

Cuando vimos el exploit nos llamó mucho la atención y es que en el Github de Metasploit podemos encontrar un exploit que se aprovecha de ShellShocks para realizar una elevación de privilegios y ejecutar código con dicho  privilegio. Aunque se ha parcheado recientemente la vulnerabilidad en Bash para OS X, todavía existirán muchos usuarios que utilizan versiones vulnerables de esta shell. Cada día que pasa son más y más las aplicaciones que son utilizadas como fuente para aprovecharse de la vulnerabilidad de Bash. El nombre del módulo es vmware_bash_function_root.rb, se puede obtener desde el Github.

¿En qué consiste?

Cuando un usuario en OS X tiene instalado VMWare Fusion, durante su instalación se ha otorgado unos privilegios al usuario que lanza la virtualización. Esta versión del software tiene un binario con permiso SUID y que será el que utilice el payload para lanzarse con los permisos de root. Lo comentado anteriormente se puede ver en la siguiente imagen, dónde la descripción del módulo lo especifica. En la función initialize se proporciona más información sobre detalles informativos del módulo como son el nombre del módulo, que debe identificar la vulnerabilidad, la plataforma, la arquitectura, los targets, en este caso es totalmente válido con OS X Mavericks.

Figura 1: Inicialización del módulo

El módulo dispone de dos funciones check y exploit. La primera permite comprobar si la aplciación o servicio remoto o local es vulnerable sin necesidad de realizar la explotación contra la entidad vulnerable. La segunda permite llevar a cabo la explotación de la vulnerabilidad, y en el caso de Metasploit de ejecutar un payload.

Figura 2: Check y Exploit en el módulo

En el check se puede ver como se realiza una ejecución de código a través de la línea env x='() { :;}; echo...'. Para comprobar que se ha ejecutado correctamente, se comprueba mediante el método include?. Además, se realiza otra comprobación y es que no se pueda abrir como fichero el path seleccionado como ruta dónde se encuentra VMWare Fusion. La función exploit genera un binario dónde se dispone del payload para posteriormente ejecutarlo a través de la variable LANG. 

Está siendo muy curioso ver como cada vez más aplicaciones son utilizadas para explotar a Bash, y la criticidad que esta vulnerabilidad está teniendo a la altura sin duda de Heartbleed. Su fácil explotación hace que cualquiera pueda hoy en día aprovecharse de este grave error. En Github podemos encontrar un listado de aplicaciones o servicios que se piensan que pueden ser vulnerables, y otros tantos que han sido comprobados como vulnerables.

Parche de ShellShock en OS X Mavericks, Mountain Lion & Lion

ShellShock

Como es lógico Apple no ha tardado en parchear esta vulnerabilidad mediante una actualización de sus sistemas operativos OS X Mavericks, OS X Mountain Lion y OS X Lion. Esto había sido prometido por la empresa de Cupertino durante el fin de semana, y desde ayer lunes ya tenemos disponible el parche bajo el nombre OS X Bash Update 1.0  para los sistemas operativos mencionados anteriormente. 

Tras el análisis exhaustivo al que ShellShock está siendo sometido, Apple comentó que la mayoría de los consumidores son afectados por la vulnerabilidad y que estaban trabajando para arreglar el problema. Esta solución se dio a conocer ayer. ShellShock lleva con nosotros muchos años, por lo que si alguien conociera dicha vulnerabilidad habría podido tomar control remoto de infinidad de sistemas durante todos estos años. Esta información también nos trae que toda versión de Bash es vulnerable desde el comienzo. En nuestro servicio de pentesting persistente Faast nosotros estamos avisando a nuestros clientes desde el día que se hizo pública.

Figura 1: Actualización de Bash

Según Apple, OS X no te expone directamente a exploits remotos a menos que los usuarios configuren los servicios avanzados de UNIX. Cuando esta sentencia fue enunciada por un portavoz de Apple, también comentó que la empresa trabaja en proporcionar la ansiada actualización. Los usuarios de OS X Mavericks pueden descargar el parche a través del sitio de soporte de Apple, al igual que los usuarios que trabajan con OS X Mountain Lion y OS X Lion. También se puede conseguir el parche a través de Actualización de Software.

ShellShock afecta a todas las versiones de OS X

Bash 3.2.51 en OSX 10.9.5

Seguramente has oído hablar del bug de ShellShock que afecta a todas las versiones Bash desde 1994 hasta la versión 4.3 que ha sido actualizada esta semana. Por supuesto, también afecta a las versiones de OS X, concretamente a todas desde Mac OS X 10.1 hasta OS X Mavericks 10.9.5. Este fallo permite que, en la definición de variables se pueda introducir comandos de consola después de que ha terminado la definición de la misma, lo que permitiría a un atacante remoto ejecutar lo que quiera si se inyecta dentro de esa definición.

Esto es algo tan sencillo como lo que puedes ver en la siguiente captura en la que después de la definición de la variable se ejecuta otra bash para que se haga un echo. Podría haberse lanzado cualquier aplicación o script que se hubiera querido.

Figura 1: Cuando acaba la definición, se ejecuta el comando

Esto abre las puertas a ataques remotos vía web, tal y como se ha podido ver en el blog de Eleven Paths donde se han explicado con detalle todas las formas de sacar partido de esta vulnerabilidad en un servidor web. En el sistema de pentesting persistente Faast se introdujo un plugin de detección de este bug en las primeras horas de vida para que nuestros clientes pudieran estar informados de qué servidores se veían afectados por este fallo.

Figura 2: Inyección de una shell en una web vulnerable vía USER-Agent usando ShellShock

En los sistemas OS X, se podría explotar o bien vía servidor web con aplicaciones cgi corriendo sobre un OS X Server, o bien sobre un cliente que tenga habilitado el acceso de invitado. Por eso os recomendamos que deshabilitéis ese usuario. Lo peor es que Apple no va a sacar parches para los sistemas OS X anteriores, así  que un bug tan grande obligaría a los usuarios de Snow Leopard o anteriores a erradicar esta shell de su sistema... o atenerse a las consecuencias.

Activar y arrancar Mac OS X en modo "Verbose"

Mac OS X tiene muchas opciones adicionales que podemos activar para depurar mejor un determinado problema en el sistema. Una de ellas es el llamado modo “Verbose”, que puede ser activado durante el proceso de inicio y permite ver toda la información de lo que ocurre en el sistema operativo cuando está arrancando. Este modo esta pensando para usuarios avanzados y para desarrolladores que quieran ver los pasos por los que va iterando el sistema cuando se esta iniciando, para poder ver detectar problemas tanto en el hardware o como en el software del sistema.

El modo “Verbose” sustituye la pantalla de inicio por defecto de Apple, por una pantalla que muestra en modo texto toda la información de lo que esta pasando en nuestro sistema, pudiendo verse mejor el proceso de arranque del sistema.

Figura 1: Equipo Mac OS X arrancando en modo Verbose

La forma de activar este modo es muy sencillo. Podemos hacerlo de dos formas, o bien a través del comando “command + V” mientras se esta iniciando el sistema, lo que nos permitirá acceder al modo "Verbose", o bien activarlo mediante una orden de terminal para que cada vez que iniciemos nuestro sistema operativo iniciemos en este modo. El comando debe ejecutarse como administrador y es el siguiente: sudo nvram boot-argvs=”-v”

Una vez hecho los cambios se reinicia el equipo y podremos ver el modo verbose de nuestra nueva splash screen mostrando toda la información del proceso de arranque de Mac OS X.  Y si quieres volver a desactivarlo, puedes usar el siguiente comando: sudo nvram boot-argvs= . Reiniciar el sistema, y todo volverá a la forma normal de arrancar.

Saber qué tiene un fichero en Mac OS X: head, xxd y file

A veces llega a nuestro sistema Mac OS X - algunas veces sin saber cómo pudo suceder esto - un archivo del que no sabemos qué hay dentro de él. En esos casos, por si es peligroso, una de las cosas que podemos hacer es subirlo a Virus Total y ver qué nos dicen los antivirus. Sin embargo, para revisar su contenido podemos echar mano de algunos comandos sencillos en la consola bash de nuestro sistema operativo Mac OS X. Aquí van unos sencillos por si no los conoces, que pueden serte útiles.

- Filtros de ficheros: En la consola del sistemas tenemos comandos que nos hacen un volcado ASCII del contenido del fichero. Ejemplos como cat que lo muestra completo, more que muestra el contenido completo paginado y que permite que podamos cancelar en cada página pulsando la tecla "q", head que muestra las primeras líneas del fichero o tail, que muestra las últimas.

Figura 1: El comando head muestra la cabecera de un fichero. Por defecto 10 líneas.

Seguro que cada uno de ellos te puede venir bien en diferentes casos, pero head es una opción muy buena ya que nos deja ver las cabeceras del fichero - por defecto las 10 primeras líneas -. Por supuesto, si por algo se precia la consola de los sistemas *NIX* es por tener una cantidad brutal de filtros de ficheros, como cut o wc, además de poderosos lenguajes de script, como el clásico y poderoso awk.  Si necesitas un filtro para un archivo, busca en la ayuda, seguro que existe o hay uno similar.

- Volcado hexadecimal de un fichero: En la consola de Mac OS X está disponible un filtro de fichero que realiza un volcado en formato hexadecimal del fichero. Este comando es xxd y tiene opciones para formatear la salida en configuraciones distintas. No es muy conocido, pero sí útil y rápido para no abrir el editor hexadecial completo en un vistazo rápido o para poder hacer determinados scripts.

Figura 2: Volcado hexadecimal del fichero filtrado con head.

- Análisis de tipo de fichero: El último comando que os traemos hoy es file. Esta sencilla utilidad tiene una base de datos que hace fingerprinting al tipo de ficheros que lleva. Tiene una opción por defecto que busca el magic number - la secuencia inicial que identifica a un tipo de fichero - pero tiene un modo más exhaustivo con -k que permite determinar más formatos contenidos dentro del mismo fichero. Esto es ideal para detectar intentos de engaños en ficheros camuflados. Además, tiene opciones para analizar el contenido de archivos comprimidos, facilitando la generación de scripts de revisión de ficheros.

Figura 3: Tipo de archivo detectado con el comando file.

Si eres una persona experta con el uso del terminal de comandos seguro que los conocías todos, y si no lo eres, que sea el comienzo de un bonito idilio entre tú y la consola bash de tu Mac OS X.