Entradas etiquetadas con Hijacking

En el congreso de la URJC Tech Fest, en el que Flu Project volvió a casa, se demostró una prueba de concepto de lo fácil que es realizar un Hijacking a una sesión de, un alumno, profesor, o miembro laboral de la Universidad, los cuales dispongan de cuenta en el portal de servicios. En primer lugar abarcaremos cual es el problema y como se logra acceder a la cookie y la posible suplantación, para después ver como uno se puede proteger de las andanzas de los jóvenes e inquietos estudiantes de la URJC y lo que pueden llevar a cabo en la biblioteca.

Ah… ¿Pero qué no solo se va a estudiar a la biblioteca?

Por lo que se vió en el congreso no sólo de estudio vive el estudiante, en la biblioteca de la URJC se hace de todo, relaciones personales, importantes en la vida, y sobretodo mucho cesped… y luego hay jóvenes que pueden ver la WiFi como un campo de batalla sobre el que experimentar, siempre sobre sus recursos y máquinas y nunca sobre los demás… nunca…

Cogiendo la Cookie

Si fuéramos argentinos la frase ‘cogiendo la cookie’ significaría… ‘foll… la cookie’ pero este no es el ámbito, a lo que nos referimos es como capturar una cookie de sesión del portal de la URJC. Para ello se demostró que utilizando un arp-spoofing o más conocido como Man In The Middle o MITM, el cual ha sido tratado en Flu Project en diversas ocasiones, se consigue que el tráfico de la víctima pase por nosotros. Este artículo no pretende volver a explicar el MITM, ni incluso la suplantación de cookie, pero si enseñar que fácil puede llegar a ser, y la pregunta es ¿Por qué no lo corrigen? Les ayudaremos a ello, y sobretodo al usuario de la biblioteca a protegerse un poco más.

En primer lugar, ¿Cómo me protejo del MITM? Bueno, pues podemos utilizar un script que detecte cambios en la tabla arp. De esto también hemos hablado con anterioridad, por lo que enlace al canto sobre la detección de MITM. Pero, si no tenemos maña con los scripts, que me lo den hecho, y para ello disponemos de la Marmita, si no la has probado… ¡pruebala!

Una vez hago el MITM…

Una vez hecho el MITM y se consigue que el tráfico de la víctima, que claramente somos nosotros mismos, porque esto es una PoC, que nadie se enoje… :O abrimos el Wireshark, el paratodo de redes, el analizador por excelencia. El filtro que le aplicamos es http contains “Cookie” && http contains “miportal.urjc.es”. El filtro es importante que se entienda, se filtra tráfico http y que, en primer lugar, contenga la palabra Cookie, importante la C en mayúscula, y en segundo lugar, que ese tráfico a la vez contenga la palabra miportal…blabla.

Una vez se localiza la Cookie, hay que tener en cuenta que la IP debe ser la víctima, es decir nosotros recordarlo siemrpe eh! ajajaja. El caso, que copiamos el valor de la cookie y la llevamos a un bloc de notas. Toca estudiar que cosas más bonitas esos parámetros que nos identifican de cara a un servidor. Bueno, habrá que ir probando a ver qué parámetros son los necesarios para suplantar la cookie… tras un largo estudio, el joven inquieto se da cuenta de que, ORA_WX_no se qué y algo de un portal son necesarios, bueno, lo único necesario…

Aplicando cambios en un plugin como Cookies Manager+

Bueno, pues el plugin elegido es Cookies Manager+, un plugin que permite crear cookies y configurarlas… por lo que si se tienen los parámetros, solo hay que crear la cookie… y listo. Una vez creada la cookie, hay que proporcionar el recurso al que se quiere entrar. En el navegador simplemente, hay que indicar a la web que se quiere entrar. El recurso no será la web pública, si no la privada de inicio, es decir, la URL a la que accede un usuario tras loguearse.

¿Así de fácil? Como se pudo ver en la PoC del congreso si… ¡Pero bueno! ¿algo se podrá hacer no? Em… si, bueno, anteriormente hemos comentado como intentar evitar el MITM, pero y si no nos damos cuenta del MITM, disponemos de varios plugin que lo que intentan es forzar la conexión HTTPS. El problema está en que se fortalece el login del portal de usuarios de la Universidad, pero una vez logueado, la conexión baja a HTTP, por lo que el contenido va sin cifrar… Entonces, la cookie puede ser capturada. ¿Por qué no dejan la conexión siempre bajo HTTPS? Eso arreglaría bastante el problema, aunque cuidado que hay otro tipo de ataques, como por ejemplo, SSL Strip que también nos podría dar un quebradero de cabeza…

Plugin: ForceTLS

Ayuda a proteger siempre conectándose por HTTPS, pero claro si el servidor no da servicio por HTTPS no obra el milagro, por lo que sólo si se puede acceder por HTTPS se accederá si no… NO! Lo que parece que ForceTLS logra parcialmente, o al menos lo intenta… pero viendo la información que proporciona el navegador, no parece que haya una conexión segura, aunque intentemos conseguirla… podréis utilizar ForceTLS correctamente con facebook por ejemplo… tuenti tampoco aporta el HTTPS en su sesión una vez logueado.

Y por último vemos como no… no conseguimos el HTTPS dentro de la sesión…

¿Entonces qué?

Protegeros en las tierras de batalla que es la WiFI, ¡protegeros! y usad el sentido común. Recordad que no está bien utilizar dichas técnicas para sacar algún teléfono de la chica que te gusta, y ni mucho menos, para espiar sus conversaciones, en este blog sólo hablamos de pruebas de concepto y no hay nada más lejos de la realidad. Sed buenos, y con vuestros compañeros también… Todos somos Laura, todos somos Carlos…