¿Algún navegador no totalmente inseguro vulnerable a BEAST?

6

La gente todavía se preocupa por BEAST bastante al configurar los servidores web hasta el punto de preferir RC4 sobre AES-CBC. Pero la mayoría de los navegadores mitigan BEAST incluso mientras usan TLS 1.0.

¿Hay un navegador que:

  1. Es vulnerable a BEAST o a Lucky Thirteen
  2. No tiene vulnerabilidades conocidas que sean mucho peores, como la ejecución remota de código
  3. Tiene una base de usuarios no despreciables

¿BEAST sigue siendo una razón para evitar el CBC? ¿Qué hay de Lucky Thirteen?

    
pregunta CodesInChaos 10.09.2013 - 18:42
fuente

1 respuesta

3

Se debe tener en cuenta que BEAST requiere algún código hostil que se ejecute en el navegador de la víctima, código que puede enviar solicitudes arbitrarias al sitio web de destino, con suficiente "control" en los bytes enviados para llevar a cabo el CBC relacionado cálculos En particular, esto no puede ser "solo texto". Los autores de BEAST tenían para encontrar algún tipo de canal que evadiera la Política del mismo origen . Encontraron dos:

  • uno en Java, que se solucionó poco después (y los complementos de Java no arreglados tienen otros agujeros más grandes);
  • uno en una versión de borrador de WebSocket , que nunca fue generalizada (está en borrador) y se ha corregido; en realidad, fue ya arreglado cuando se publicó el ataque, aunque la solución fue inesperada (fue un cambio que estaba destinado a proteger contra otra cosa).

Podría decirse que BEAST no se puede explotar hoy en día a menos que se encuentre otro agujero SOP. Además, incluso si se encuentra un agujero SOP, los navegadores actuales de 1 / n-1 split que también impiden que BEAST sea aplicable. Este método se ha aplicado en los principales navegadores web hace más de un año (consulte this ) y no creo que no se haya encontrado ningún error de ejecución remota en estos navegadores en el último año. Esto significaría que, de hecho, ya no hay razón para preocuparse por BEAST . Sin embargo, cambiar a TLS 1.2 todavía sería bueno.

El ataque Lucky Thirteen no es un ataque contra el navegador pero en el servidor . Requiere que el navegador realice muchas solicitudes al servidor (en una configuración similar a BEAST), pero la fuga proviene del servidor: el servidor procesa un registro entrante y la verificación de MAC fallará, pero alguna medida de tiempo sutil puede revelar si el relleno PKCS # 5 fue correcto o no. Es reclamado que casi todos los proveedores (al menos los de código abierto) corrigieron su código a Evita la filtración en la que se basa Lucky Thirteen.

La marca y la versión del navegador web tienen poca relevancia para Lucky Thirteen. Teóricamente , uno podría revertir la configuración y atacar el procesamiento de los registros enviados por el servidor al cliente, pero requeriría que el atacante tenga suficiente control sobre las respuestas del servidor para Haz que el ataque funcione, y eso parece bastante difícil.

    
respondido por el Thomas Pornin 10.09.2013 - 19:13
fuente

Lea otras preguntas en las etiquetas