Un sábado cualquiera: Jugando con un Applet Java

El sábado por la mañana, después de haberles hecho sudar a mis alumnos con el examen del Master, terminamos la sesión viendo algunos fallos más de seguridad. Entre los fallos que vimos estuvimos hablando de las sesiones rotas, y las partes que son accesibles de un panel web sin tener iniciada una sesión. Así, yo les conté la historia de cómo pasé una tarde en Buenos Aires jugando con un ActiveX para ver cuánto era capaz de sacar del panel interno.

Después de comer, me acordé de que tenía ganas de jugar realizar la misma jugada que con el ActiveX, pero con algún Applet Java, así que nada más levantarme de la siesta me puse a buscar algún lugar de pruebas. Tras tres consultas en Shodan [Cómprate el libro de hacking con buscadores... }:))], decidí quedarme con un bonito Applet de Java que invitaba a enredar con él... a ver qué salía.  Todavía no he terminado con él, pero os cuento la historia por si a alguien le viene bien conocer lo que fui haciendo desde el primer momento.

Incialmente el Applet no acababa de funcionar correctamente, así que el primer paso fue mirar los valores de llamada en la carga del componente en la página web. Aunque los he tachado, se puede ver que el nombre del servidor no era un FQDN ni una dirección IP, así que hubo que imaginarse que ese era el nombre de la dirección IP que me había devuelto Shodan para configurar el fichero /etc/hosts.

Figura 1: Parámetros de llamada del Applet

Una vez arreglado eso, el Applet arrancaba feliz y contento pidiendo un usuario y una contraseña, lo que me recordaba la famosa fase 2 del Reto Hacking de Boinas Negras - solucionarios RoMaNSoFt al aparato -. Era como volver al pasado y jugar de nuevo.

Figura 2: El Applet funcionando

Tirando de normas pre-establecidas mi paso natural fue configurarme Burp como Proxy Local y ver qué estaba enviando para ver si podía interceptar algo, pero no enviaba nada a través de HTTP. De hecho, en los parámetros de llamada se puede ver que usa el puerto 300 para la comunicación, con lo que tocaba pasar a nivel 2, a ver qué dice Wireshark.

Tras filtrar las peticiones capturadas por Wireshark por el puerto se puede obtener que el usuario y la password van en texto claro, lo que le hubiera costado ya un bonito negativo en un informe de auditoria de seguridad web que hacemos en Informática64.

Figura 3: Usuario y Password en texto claro

Sin embargo, al analizar el flujo TCP de la conexión parece que tiene un protocolo propio construido para comunicar información entre el cliente y el servidor, así que habrá que ver que son esos números de secuencia y esas cosas tan bonitas que se dicen.

Figura 4: Protocolo de negociación entre cliente y servidor

Para ello, volviendo a cómo se pasaba la fase 2 del Reto hacking de Boinas negras, descargué el Applet los descomprimí y descubrí que había muchos más ficheros de los que podía imaginarme, así que había que pensar en automatizar el método de análisis del Applet para ver si sacaba algo interesante.

Figura 5: Extracción de ficheros y decompilación con Jad

Para sacar el archivo fuente usé Jad, un decompilador Java que genera, como todos los de su clase, un archivo en texto claro con el código fuente extraído. A partir de ese momento el trabajo consistía en buscar los strings más interesantes a ver si era capaz de encontrar algo de información jugosa que me permitiera un atajo al destino final - fuera el destino que fuera, pues aún no tengo claro qué es lo que estaba buscado -.

Entre las cosas que aparecieron, que ya os contaré en otro artículo más, apareció que el sistema usaba cifrado para las comunicaciones, lo que complica mucho los ataques de man in the middle.

Figura 6: Análisis de strings con ficheros decompilados

Por suerte, parece que las claves, como se puede ver en la imagen anterior, se encuentran definidas en un fichero que está dentro del Applet, así que el siguiente paso era ir a ver si realmente las tenemos allí.

Figura 7: Claves de cifrado y descifrado en el código fuente

En este punto, me encuentro con un Applet que no pasa por HTTP,  que autentica en servidor, y que los datos los envía cifrados con su propio código, pero que por suerte no tiene el código ofuscado, lo que facilita la labor de hacer ingeniería inversa del protocolo. ¿Qué hacer ahora? Varias opciones con las que proseguí las pruebas:

- Conseguir hacer login en el servidor por medio de un fallo de inyección, por lo que será necesario  probar si es inyectable el componente en cliente o "meter los dedos en el enchufe".


- Conseguir hacer creer al Applet que nos hemos logado y que nos enseñe el resto de panel para ver si hay partes con sesión rota, igual que en el caso del ActiveX.


- Hacer análisis del código fuente para descubrir cuáles son sus orígenes de datos e intentar acceder a ellas directamente.

Y... ya os contaré como acaba mi juego con el dichoso Applet.

Saludos Malignos!