Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Hijacking en Slashdot. Step by Step
En las últimas conferencia de Black Hat, una de las charlas hizo unas demostraciones sobre realizar Hijacking en las cuentas de Gmail. Para ello utilizó unas herramientas para analizar las cookies de las sesiones de cuentas de gmail y slashdot y realizó una demo en vivo. El contenido de las charlas de las últimas Blackhat no está en la web oficial aún, pero es un secreto a gritos que se encuentran en esta URL: BlackHat USA 2007.
El señor Knovas ha intentado replantear el método descrito en la sesión y no ha sido posible realizarlo en Gmail. ¿corregido?. Sin embargo sí ha sido posible realizarlo en Slashdot y aquí queda el Step-by-Step.
Hijacking en Slashdot. Step by Step by Knovas.
En este paso a paso partimos de la base de que tenemos las cookies de la cuenta víctima. Este paso es muy fácil de realizar simplemente esnifando la red, con la Wifi, con el cain....
Materiales necesarios…
- 2 cuentas en Slashdot.org (En el ejemplo tenemos dos para atacarnos a nosotros mismos). Nuestros usuarios son cancamusa y chipiwini
- 1 Herramienta para modificar las cookies. En este caso hemos elegido Firefox con el plugin “Edit cookies” que permite realizar este proceso de una forma sencilla.
Pasos a realizar.
Paso 1. La “víctima” entra en su cuenta.
La víctima en este caso será el usuario cancamusa:
login: cancamusa
pass: cancamusa
Marcamos la opción de “Public terminal” para que al cerrar el navegador nos desconecte la sesión
Paso 2. Cogemos la cookie.
Como hemos dicho antes, esta cookie se puede recuperar simplemente esnifando la red (Wireshark, Caín,…). En este caso utilizamos el plugin de Firefox para ver la cookie de la víctima.
Paso 3. Copiamos la cookie en el portapapeles.
Fácil, Ctrl+C. ;D
Paso 4. Cerramos el navegador.
Si pinchamos en el botón logout, se desconecta la sesión en el servidor y no se puede realizar el ataque. Pero cerrando el navegador no se avisa al servidor de la desconexión.
Paso 5. Entramos con el atacante.
Abrimos de nuevo el Firefox para entrar en la cuenta del atacante, que en este caso será el usuario chipiwini
login: chipiwini
pass: chipiwini
Paso 6. Editamos cookie del atacante.
Una vez logueados como chipiwini, abrimos el editor de cookies y cambiamos el valor de la cookie user por el que hemos recuperado de la víctima.
7. Cambio de usuario.
Pinchamos en cualquier enlace que nos mantenga dentro del sitio web… por ejemplo en el menú, y… voilá ya somos el usuario cancamusa
Fin.
Knovas.
13 comentarios:
Muy buena!
¿Te lo dije o no? Podíamos haber ido a las BH pero bueno, en cuanto tenga tiempo publico el artículo del Hijacking.
Muy buen post Maligno :). Probaré a hacerlo en un ratito hehe
Mmmm, no es por nada pero esto es lo lógico si cambias las cookies. El "hacking" está en conseguir una cookie que no sea tuya...
Perdón, ya he visto de que partes de que has obtenido las cookies por otros métodos :P
Hola anónimo,
con las cookies, si están bien, se puede evitar el hijacking pq autententica la máquina de conexión.
Muy interesante, claro ejemplo de que la seguridad de tu app no depende solamente de cuan fuerte sea tu cifrado, sino de que usen el maldito boton "salir", que pa eso lo hemos puesto ahi. :)
Quizas sea simple, pero como no soy muy listillo en esto de la securizacion... ¿Como lo a soluciando gmail? Seria interesante que los craneos malignos que visitan esta web esbozaran sus teorias. :D
Excelente post.
Uff... me parece muy triste que en esas empresas funcione el falseo de galletitas.
¿Que clase de administradores no piensan en un metodo que hasta un niño podria explotar?
No se estrujaron muxo el coco creo yo, ahora les toca corregir lo k podria ser seguro a stas alturas, debe ser que les mola trabajar de más xDD.
Un saludo. Kraden.
Si partimos de la base de que tenemos la cookie "simplemente esnifando la red, con la Wifi, con el cain...", para eso acabamos antes si esnifamos directamente los campos de usuario y contraseña, que según parece se envían siempre como texto en claro desde el formulario de autentificación, ¿o me equivoco?
La gracia estaría en encontrar además una vulnerabilidad XSS para robar la cookie y entonces la combinación de ambas debilidades ya sería como para preocuparse de verdad...
De todas formas, el método descrito parece perfectamente válido, aunque como se suele argumentar en temas de seguridad, si te pueden esnifar la red, el robo de esa cookie sería el menor de tus problemas, jeje ;-)
Saludos!
Como dijo kraden es increible como pueden equivocarse en un error tan tonto siendo una empresa tan grande..
Encima llama a la entrada "user" xD!!!
La solucion del error debe de haber sido cambiar el Id de la entrada por "estonoesunusersrhacker" 8-)
Saludos,!
El Hijacking es un problema si se consigue la cookie de cualquier manera, en este caso hasta accediendo a los archivos temporales. Si hay un XSS ya es todabía mejor pues la consigues en remoto.
En este caso las credenciales van en texto claro, con lo que si se snifa o se hace un arp-spoofing de la autenticación se engancha. Pero el hijacking se hace pillando cualquier petición. Vamos que es un cuadro esto.
mmm, usando un navegador del lado del bien....
Nota: Slashdot está hecho con Slash que es un gestor de blogs multiusuario, me huelo que todos tienen el mismo problemilla :P
Pues me temo que sí.
Publicar un comentario