La cadena se rompe siempre por el eslabón más débil

El titulo de esta entrada puede parecer cliché para algunos, pero el hecho que sea una frase ampliamente usada en nuestro medio, es por que encaja perfectamente en escenarios a los que nos encontramos diariamente como profesionales de seguridad informática, por ejemplo, si realizamos trabajos de seguridad ofensiva, constantemente estamos en la búsqueda de este eslabón débil que nos permita el ingreso a la organización/su información y si nuestro trabajo es la seguridad defensiva, debemos asegurarnos que todos los eslabones de nuestra cadena sean lo suficientemente fuertes como para garantizar un nivel aceptable de seguridad, teniendo en cuenta que la seguridad 100% no existe.

¿Pero a que viene el caso de la frase y esta entrada?, como algunos sabrán, por cuestiones de laborales he tenido que crackear analizar una serie de aplicaciones para conocer su contenido y funcionamiento, la mayoría de las aplicaciones que me encargaron analizar incluían un sistema de licenciamiento que representaban un obstáculo de complejidad media-baja/baja, nada que con un repaso a la documentación de Ricardo Narvaja no se pudiera solucionar, pero había una en especial que a simple vista aparentaba tener una dificultad mas elevada que las anteriores, ya que el desarrollador había tomado ciertas precauciones para evitar precisamente el análisis a su ejecutable.

La aplicación en cuestión, aparentemente era usada para hacer análisis de mercado y generar información estadística, estaba empaquetada con una herramienta desconocida, generaba un ID único para cada maquina en la que se ejecutaba y contaba con ciertas validaciones que me hacían pensar "analizar esta aplicación va a ser complicado", por tanto la deje de ultima para que no me retrasara el resto de trabajo (que en su mayoría tenían como mayor desafío identificar donde se debía mandar el salto para esquivar la validación).

Cuando llegó la hora de analizar la aplicación, me di cuenta que estaba totalmente equivocado en mi análisis preliminar y esta aplicación que aparentaba tener una mayor dificultad que las anteriores, en realidad fue la más fácil... Esta entrada y su titulo se deben a que pude encontrar y explotar el eslabón más débil en este programa y me pareció interesante documentar el proceso y hacer la analogia con la frase, por si le puede ser de utilidad a cualquiera de nuestros lectores.

Después de realizado el análisis previo con herramientas del sistema y aplicaciones como Exeinfo, PEiD, PeStudio, etc.. para tratar de identificar con que lenguaje fue hecha, si tenia empaquetadores de ejecutables y algún tipo de protección, como se había hecho anteriormente, decidí ejecutar la aplicación y analizar sus conexiones antes de pasarla por un debugger, de pronto encontraba algo y me evitaba el proceso (como efectivamente pasó)...

La pantalla nos mostraba un identificador único de la maquina y nos solicitaba un correo electrónico, pero no pedía ningún serial para validar la licencia, por lo que supuse que tendría que corroborar la información contra algún servidor en la red ya que si ingresaba cualquier correo electrónico entraba este mensaje.

Como no estaba en condiciones de pedir apoyo a soporte jejejej, ejecute wireshark para tratar de ver lo que la aplicación estaba pidiendo por debajo o con quien se estaba comunicando para saber que este computador con ese ID no estaba licenciado, descubriendo una petición HTTP sin cifrar bastante interesante.

Al parecer el programa se comunicaba con su casa matriz enviando al archivo verifyLicense.php el correo electrónico y el id del equipo para saber si este contaba con licencia o no y obtenía como respuesta un valor booleano del que dependería la acción a tomar (1 = mostrar el mensaje anterior, 0 = dejar entrar a la aplicación), conociendo esto los pasos a seguir eran muy simples.

Crear un archivo llamado verifyLicense.php cuyo contenido sea "0" y montarlo en nuestro servidor local o en uno remoto.

Modificar el archivo host del sistema para suplantar el sitio al que se conecta la aplicación por el servidor donde alojamos nuestro verifyLicense.php modificado.

Verificamos en un navegador que efectivamente se realizara el cambio...

Y si todo sale bien, la próxima vez que demos al botón Verify el software pensara que efectivamente esta licenciado y nos arroja su interface principal.

Como pueden ver el procedimiento realizado fue realmente simple, mas aún comparado con el trabajo de des-empaquetamiento, depurado, análisis y parcheo que el desarrollador pensaba obstaculizar con diferentes barreras, pero finalmente "La cadena se rompió por el eslabón más débil" y no fue necesario todo ese trabajo para poder acceder a las funciones del ejecutable.

La finalidad de esta entrada es mostrar con un ejemplo practico cómo un sistema de seguridad que se creía relativamente bueno, puede ser vulnerado aprovechando un vector descuidado, como lo fué el envío y recepción de información en texto plano.

Si te gustan estos temas te recomiendo leer Cracking con OllyDbg y Saltando y Asegurando los Periodos de prueba en el Software.