Descargar ejecutables de Deep Web puede ser peligroso

El título bien podría ser "descargarse ejecutables desde cualquier red puede ser peligroso", pues permitir a un programa que realice acciones en tu equipo no es buena idea si no confías mucho en su procedencia, pero cuando conoces su procedencia pero lo descargas desde una red que puede tener un esquema de Man in the middle - uno de los ataques de red más comunes - esto puede ser aún más peligroso aún. En el caso de la Deep Web, en concreto en la Red TOR, tanto los nodos de entrada como los nodos de salida mantienen un esquema de Man in the middle entre el cliente y el servidor, por lo que si uno de ellos se vuelve malicioso, podría ser muy peligroso.

Figura 1: Descargar ficheros desde un nodo TOR malicioso es peligroso

Cuando estuvimos haciendo el trabajo de Owning Bad Guys {and Mafia} Using JavaScript Botnets utilizamos un servidor Proxy anónimo como esquema de Man in the middle, pero también montamos un nodo TOR de salida malicioso que manipulaba las respuestas DNS. En aquel entonces nos detectaron las medidas de seguridad y os lo dejé escrito en el artículo "Protección contra DNS Hijacking en la Red TOR".

Figura 2: Conferencia de Owning bad guys {and mafia} using JavaScript Botnets en Black Hat USA 2012

Al final, cuando nos conectamos a cualquier red siempre tenemos esquemas de Man in the middle, que pueden volverse peligros ya sea mediante un Access Point en la red WiFi que nos pueda hacer un ataque de Web Proxy AutoDiscovery, un router que nos haga un ataque SLAAC o el mismo servidor VPN que estés utilizando e infectando todos los ficheros JavaScript que descarguemos. Es por ello que autenticar y cifrar extremo a extremo es lo más deseable para garantizar que te estás conectando al elemento que quieras y que nadie en medio va a poder acceder a los datos que van en la comunicación.

Si el cifrado extremo a extremo no funciona, alguien podría meterte en una JavaScript Botnet, acceder a tus datos, o manipular los ficheros que descargas. En Hack Players hablaron hace tiempo de BDFProxy, una herramienta que en tiempo real infecta todos los archivos que pasan por un esquema de Man in the middle, lo que haría que cualquiera de esos que acabe ejecutándose en el cliente de la víctima quede comprometido.

Figura 3: Ejemplo de funcionamiento de BDFProxy para infectar binarios

Efectivamente, el manipular estos ficheros para meter el backdoor acabaría por romper cualquier firma digital del fichero que sea comprobada a posteriori. Esto, en los sistemas de actualizaciones es comprobado desde hace tiempo - o al menos debería - ya que desde que el investigador argentino Francisco Amato (@famato) publicó las técnicas de Evil Grade, se sabe que un atacante podría estar actualizando el software de su sistema operativo y alguien, con un ataque de Man in the middle, en lugar de entregar una actualización legítima entregue un backdoor para controlar el paquete.

Figura 4: Fin fisher uso un bug de Evil Grade en iTunes para infectar Mac OS X durante años

Si esto sucede, el software de actualización no funciona, y sale un error de firma incorrecta del binario, que es lo que llevó al creador de BDFProxy a investigar los nodos de la red TOR en busca de alguno que estuviera alterando los binarios.... y acabó por encontrarlo. El nodo malicioso en concreto estaba en Rusia, y estaba infectado con bots para controlar equipos que se conectan a través de la red TOR y enviándolos a paneles de control en servidores de Internet. De hecho, uno de los binarios infectados apunta a una web del pueblo de Alcoy, donde se puede ver que en Google han quedado indexados unos enlaces "extraños" con parámetros codificados.

Figura 5: Enlaces a un posible panel de control en una de las webs que aparecen en el binario

El riegos de utilizar esquemas de Man in the middle es que al final hay que confiar en los dispositivos de red que están en medio - por eso la NSA intentaba controlarlos en sus operaciones de espionaje - y en algunas redes como CJDNS conseguir acceder a ella exige un proceso de ganarncia de confianza. Sea como fuere, si vas a bajarte un binario ejecutable, hazlo desde la conexión más confiable posible.

Saludos Malignos!

Java: 4 años de actualizaciones inseguras

Hace tiempo que usar Java en una empresa da la impresión de que es para valientes. Desde que se levantó la libre de que los kits de explotación estaban haciendo más uso de vulnerabilidades en Java que de productos Adobe para distribuir malware, todo el mundo comenzó a preocuparse un poco más por esta plataforma tan popular y extendida de desarrollo de aplicaciones.

Entre los movimientos relativos a Java más llamativos estuvo el cambio de política de Apple que hasta la versión Mac OS X Snow Leopard había llevado Java como bandera y que con el lanzamiento de Mac OS X Lion este verano decidió convertirlo en un Opt-in, al mismo tiempo que discontinuó el soporte para Mac OS X Leopard - SO que se vendió hasta hace 2 años -, dejándolo también sin soporte para parches de seguridad Java. 

El uso de Java en una plataforma Mac OS X o Linux es usado también como base para el lanzamiento de exploits con metasploit contra estas tecnologías, ya que este trae un meterpreter escrito en Java que ayuda a unificar el proceso de explotación, que aunque no es igual que la versión de Windows, sí que trae un buen número de comandos.

Sin embargo, en el uso de esta plataforma dentro de la empresa, y dejando de lado que haya vuelto a quedar mal en un estudio centrado en análisis de vulnerabilidades en programas, la plataforma Java tiene un problema con las actualizaciones que conoce desde el año 2007 y que no ha solucionado: Es vulnerable a Evilgrade.

Las técnicas de evilgrade fueron publicadas por Francisco Amato en la Ekoparty del año 2007 en una charla a la que tuve el gusto de asistir. A grandes rasgos, la vulnerabilidad radica en que el actualizador del software de un programa que se tiene instalado en la máquina no comprueba correctamente el software a instalar, y un atacante puede ejecutar un troyano, o un meterpreter. Aquí, tenéis un ejemplo con MacPorts, que también es vulnerable a evilgrade.  Son muchos los programas vulnerables a evilgrade, y es por ello que unimos la técnica de DNS Cache Snooping a FOCA para mirar qué software era vulnerable a evilgrade en una empresa de forma remota.

Y a esto es vulnerable Java.

Supongamos una máquina con el actualizador de Java comprobando periodicamente si existe alguna nueva versión de Java. Para ello, este programa se conecta a un servidor web que le dice si existe o no, y qué fichero contiene la nueva versión. Así, cuando aparezca una nueva versión, el actualizador de Java se conecta a la URL indicada, se descarga el programa y lo ejecuta en la máquina cliente.

Ahora supongamos un entorno atacado con evilgrade en el que el atacante, mediante un esquema de man in the middle intercepta las peticiones del actualizador y le contesta indicándole que sí que existe una nueva versión, redirigiendo a la víctima hacia un servidor controlado desde el que se le va a entregar no una actualización sino un software malicioso que le permita tomar control de la máquina de la víctima (un ejecutable con una reverse shell, un meterpreter o un troyano).

Esto sucedía con Java allá por el año 2007 y Francisco Amato lo reportó a la entonces Sun Microsystems, que lo "intentó parchear" en Diciembre de 2008.

El intento de parche fue en comprobar que el programa que iba a ejecutar el actualizador viniese firmado por Sun, algo que Francisco Amato se saltó de la forma más sencilla posible: Utilizando el propio Java para ejecutar los programas maliciosos. De esta forma solo hay que ejecutar cualquier programa en Java en la actualización maliciosa, ya que la maquina virtual de Java siempre está firmada por Sun. Aquí el vídeo de la demostración.

Así se quedó la cosa. Sin embargo, tras la publicación de que FinFisher, el troyano que usaban algunos gobiernos, utilizaba como esquema de infección una vulnerabilidad de evilgrade en iTunes que el propio Francisco Amato reportó a Apple hace 3 años y que solo había sido parcheada en la última versión 10.5.1., decidó comprobar si Java todavía era vulnerable a lo que él reportó en el año 2007, para descubrir que sí.

Así que, mucho cuidado con las actualizaciones de Java de tus equipos. Deshabilita el Java Updater y hazlo manualmente en tu casa desde una red de confianza y en tu empresa utilizando algún software de distribución de paquetes, como System Center Configuration Manager, por ejemplo. Por supuesto, ten cuidado con los equipos "perdidos" en tu red, y evita que un usuario fuera del control de tu System Center actualice Java y se metan en tus sistemas de red.

Saludos Malignos!

Hacking FOCA [1 de 3]

*********************************************************************************************
- Hacking FOCA [1 de 3]
- Hacking FOCA [2 de 3]
- Hacking FOCA [3 de 3]
*********************************************************************************************

A parte de la forma pensada para trabajar con FOCA que está siendo descrita en el Manual de usuario de la FOCA 2.5, muchas de las nuevas funcionalidades de la FOCA van apareciendo a partir de usar la herramienta de una manera “tricky”, es decir, de “hackear” su funcionamiento para conseguir algunos resultados mejorados. En esta serie os voy a poner tres usos que hemos pensado y utilizado de la herramienta en su versión actual y que acabarán por convertirse en parte del funcionamiento normal de la misma en próximas versiones.

FOCA & Evilgrade

Evilgrade es un framework que creó inicialmente Francisco Amato, la herramienta está pensada para, una vez realizado un ataque de DNS Poisoing, suplantar a los servidores que son comprobados por los clientes para buscar actualizaciones y troyanizar la máquina mediante una actualización maliciosa.

La idea es genial y, en la versión que liberará la próxima semana y que presentó en Defcon 18 y Black Hat 2010, tendrá 53 módulos distintos para hacer ataques de este tipo. En la mayoría de los módulos se consigue ejecución directa, en otros es necesaria una pequeña intervención del usuario haciendo clic en algún mensaje de alerta y en otros, como en el caso de Windows Update, es mediante la suplantación de la página web original para hacer un phishing.

Como FOCA incorpora un módulo de DNS Caché Snooping, una de las ideas para sacarle más partido a la información extraída es generar un fichero con todos los servidores para los cuales Evilgrade tiene un módulo de ataque. De esta manera, FOCA puede descubrir cuáles son los módulos a preparar en un ataque con Evilgrade en un pentesting de una empresa.

Francisco Amato nos ha pasado un fichero con los nombres de dominio, y éste es el resultado al pasarlo por algunas organizaciones con el módulo de DNS Caché Snooping de FOCA 2.5

En la Renfe, como se puede ver, además de tener máquinas con Windows que visitan sitios con Google Analytics, para los cuales tiene un módulo de ataque preparado Evilgrade, tiene como curiosidad que los usuarios navegan a winscp.com, que es la página de un cliente FTP que tiene activada la búsqueda de actualizaciones y al menos alguno de ellos tiene instalado el Antimalware de ClamAV.


Figura 1: DNS Caché Snooping de Evilgrade a Renfe.es
En la UNED, además de Windows y Google Analytics, se podría hacer un ataque al sistema de actualizaciones de Cygwin.com.


Figura 2: DNS Caché Snooping de Evilgrade a la UNED
Por último, en el ayuntamiento de Getafe, que compite con nuestro Móstoles - en vano }:) - por ser la capital del sur, se podría hacer uso también de los módulos para el sistema de actualizaciones de autoitscript.com y vmware.com.


Figura 3: DNS Caché Snooping de Evilgrade al ayuntamiento de Getafe
El fichero de Evilgrade.txt se puede generar desde el framework con un simple show vhosts, pero para la próxima mini-release de la FOCA que saldrá a finales de la semana que viene con algunos arreglos a pequeños fallos, ya vendrá incorporado. Además, en el futuro incorporaremos esta búsqueda de forma automatizada en FOCA.

*********************************************************************************************
- Hacking FOCA [1 de 3]
- Hacking FOCA [2 de 3]
- Hacking FOCA [3 de 3]
*********************************************************************************************