Luchando para demostrar / explotar un secuestro de sesión básico

Copiar la cookie de sesión es la forma más común de secuestrar una sesión. Puede haber varias razones por las que no funciona en su caso:

• La cookie de sesión que has secuestrado ya no es válida. Una aplicación web segura invalidaría una sesión tan pronto como el usuario cierre la sesión. ¿Está seguro de que la sesión de destino todavía está activa en el momento en que la secuestra?
• La aplicación puede vincular una sesión a atributos adicionales, como la dirección IP o las características del navegador. Eso no es terriblemente común pero complicaría tu ataque.
• No está aplicando correctamente la cookie secuestrada en su navegador. Puede ser complicado configurar las cookies manualmente. Asegúrese de haber cerrado todas las pestañas cuando cambie las cookies para que el sitio no pueda volver a agregarlas inmediatamente.

En cuanto al último punto, trataría de reproducirlo de la manera más simple posible utilizando herramientas de línea de comandos. Eso excluye la posibilidad de cualquier efecto secundario del navegador. Por ejemplo, podría usar curl(1) para emitir una solicitud (usando -b para configurar la cookie), similar a esto:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

Una respuesta autenticada indicaría que la configuración de la cookie es suficiente para controlar una sesión.

  

En lecturas adicionales, esto parece ser una cookie HttpOnly, entonces esto es una protección contra XSS, ¿verdad?

La bandera HttpOnly protege las cookies pero no contra XSS en general. Solo evita que las cookies sean expuestas al DOM. Por ejemplo, en Github, la cookie user_session está configurada en su navegador, pero permanece invisible a través de document.cookie . Hay muchas más formas para explote un defecto de XSS que simplemente robar cookies que funcionaría como una buena prueba de concepto.

Parece que la cookie de sesión tiene la opción HttpOnly . No puede extraerlo usando document.cookie , sin embargo, el sitio sigue siendo vulnerable.

Su carga útil XSS es JavaScript que se ejecuta en el contexto del sitio vulnerable. El JavaScript puede solicitar páginas en el sitio, y el navegador adjuntará automáticamente las cookies, incluidas las de HttpOnly. Debido a que usted está en el contexto del sitio, su JavaScript puede leer las respuestas. Es posible usar esto como un tipo de proxy para que usted, como atacante, pueda navegar por el sitio como si hubiera iniciado sesión como víctima.

Esto es un poco difícil de hacer, pero hay un par de herramientas para ayudarte:

• BeEF - El marco de explotación del navegador : es un marco de ataque bastante complejo con muchas características. Desafortunadamente, he encontrado que es un poco poco confiable.
• HttpPwnly : esta es una herramienta más sencilla escrita por un amigo mío. Solo intenta realizar el ataque proxy, no las otras cosas que hace BeEF, y lo hace de manera más confiable.

Si su servidor de destino tiene habilitado el método HTTP TRACE, puede omitir el indicador HTTPOnly. El ataque se llama Rastreo entre sitios (XST).

Cross-Site Tracing tiene una carga útil XSS que envía una solicitud HTTP TRACE al servidor web (proxy, reenvío o retroceso), que devolverá al cliente la solicitud completa, incluidas sus cookies, solo http o no. La carga útil XSS puede analizar la información devuelta y obtener las cookies.

Más información aquí:

Herramienta agradable para XST

Explicación XW de OWASP

Documento de investigación de XST

Si el servidor tiene el método de Rastreo HTTP deshabilitado, aún puede atacar la aplicación y explotar al lado del cliente / usuarios con muchos otros vectores de ataque como:

Secuestro del navegador.
Redirección.
Inyección de Keylogger.
Herramienta de explotación del marco XSS - BeEF
Recomiendo también seguir este blog sobre XSS - Brutelogic

Una vez tuve que hacer algo similar

En primer lugar, debe identificar las cookies de sesión, puede hacerlo simplemente iniciando sesión en la aplicación y eliminando las cookies una por una hasta que cierre la sesión

Después de eso, solo necesitas capturar las cookies del paso anterior. Lo hice usando bettercap + sslstrip para capturar la cookie, tuve algunos problemas con el analizador de cookies de bettercap en este punto, así que tuve que usarlo en modo de depuración, registrar todo y grep el registro para buscar las cookies correspondientes

Es posible que estés experimentando una aplicación web moderna. Las aplicaciones web modernas pasarán los datos del cliente a la interfaz en forma de cookies o datos de LocalStorage y mantendrán los identificadores de sesión solo HTTP. Trabajo con Django y esto es lo que hace fuera de la caja.