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

DragonJAR 336x280 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.

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

¿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ó)

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

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.

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

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.

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

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.

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

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

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

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.

8EslabonMasDebil 1 La cadena se rompe siempre por el eslabón más débilVerificamos 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.

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

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.


Si te ha gustado el post, compartelo y ayudanos a crecer.

Unete a nuestra Fanpage Siguenos en Twitter

Autor: DragoN

Ingeniero en Sistemas y Telecomunicaciones de la Universidad de Manizales. Information Security Researcher con más de 10 años de experiencias en Ethical Hacking, Pen Testing y Análisis Forense. Docente Universitario en Pre y Post-Grado, Speaker y Organizador de diferentes eventos de Seguridad Informática, Fundador del DragonJAR Security Conference y Fundador de DragonJAR SAS y de La Comunidad DragonJAR, una de las comunidades de seguridad informática mas grandes de habla hispana y referente en el sector.

Compartir este Artículo
  • Pingback: Bitacoras.com()

  • mister19

    Dragón muy buen post.. aun que la verdad no entendí muy bien la manera como suplantaste el sitio original lo podrías explicar un poco mejor???

    • http://www.dragonjar.org DragoN

      mister19 en los sistemas operativos modernos existe un archivo llamado “host” que almacena localmente las direcciones ip a las que apuntan ciertos dominios, este archivo es consultado siempre antes que los servidores DNS, por lo que añadiendo la siguiente linea a este archivo.

      127.0.0.1 http://www.dragonjar.org

      lograríamos que en ese computador, cuando consulten http://www.dragonjar.org en realidad envien a 127.0.0.1 y asi es como se logra engañar el software para que en vez de comunicarse con su casa matriz, se comunicara con nuestro servidor web local, donde estaba el archivo modificado.

  • tH!

    resección? por dios niño! recepción! recepción! recepción!

    • http://www.dragonjar.org DragoN

      corregido tH!, aveces el corrector de ortografía nos juega una mala pasada, y mas teniendo en cuenta la hora en que se publican las entradas ;-)

  • MannuDark

    Es una practica sencilla que utilizan muchos las empresas para bloquear paginas utilizando el archivo host en SS.OO de Microsoft, es mas yo pude solucionar un problema con el Assassin’s Creed (pirata obviamente) para evitar la actualizacion con los servidores de Ubsoft. Buen tema como siempre.

  • SystemRevolution

    Hola, Como puedo observar, utilizas WAMP, ¿Crees que haya problema si en ves de dicho servidor, utilizo “USB web server”?

    • http://www.dragonjar.org DragoN

      se usa cualquier servidor web, ese lo use por que no encontre una copia confiable del wos portable

  • Pingback: Lo mejor del 2012()