Ataque persistente de denegación de servicio basado en HPKP en sitios web

4

Fijación de clave pública HTTP (HPKP) es un estándar que permite que un sitio web HTTPS especifique en qué certificados confía, y indique al navegador que no permita ninguna conexión a ese sitio que esté protegido por cualquier otro certificado.

¿Se puede usar esto para facilitar un ataque persistente de denegación de servicio en un sitio web? Supongamos que un atacante compromete un sitio web como cnn.com (por ejemplo). Parece que el adversario podría configurar el servidor web para habilitar HSTS y HPKP, con una política de anclaje que especifica un certificado controlado por agresor. El ataque puede ser descubierto y los administradores legítimos recuperan el control, pero todos los que visitan cnn.com mientras tanto recibirán una política de HSTS y HPKP y su navegador la almacenará en caché. Como resultado, su navegador no permitirá ninguna conexión HTTP a cnn.com (debido a la política de HSTS) y solo permitirá conexiones HTTPS si el servidor utiliza el certificado anclado y la clave pública. Pero dado que el atacante especificó el certificado anclado, podría estar usando una clave privada controlada por el atacante y que cnn.com no conoce. En consecuencia, después de que el atacante es expulsado, cnn.com no tiene forma de terminar una sesión SSL utilizando la clave privada elegida por el atacante. Por lo tanto, todas las conexiones futuras de esos navegadores a cnn.com fallarán.

El estándar HPKP sugiere que los navegadores deben establecer una edad máxima para estas políticas, pero también suggests que establece la edad máxima en 60 días. Entonces, si estoy entendiendo esto correctamente, significa que si un atacante compromete temporalmente un sitio web, entonces el atacante puede asegurarse de que el sitio web será absolutamente inaccesible durante los próximos 60 días para todos los usuarios que visiten el sitio web durante el breve período en que El sitio web está comprometido. Básicamente, cualquier usuario que visite el sitio web en un momento en que esté controlado por el atacante está "envenenado" durante los próximos 60 días, y el sitio web parece simplemente inalcanzable.

Como las infracciones del sitio web no son desconocidas, parece que sería un resultado bastante grave. Este es un tipo de ataque de denegación de servicio bastante inusual: permite el vandalismo irreversible de un sitio del que los administradores del sitio web no pueden hacer nada, excepto esperar. También parece que este ataque podría ser explotado contra el sitio web cualquier , incluso uno que no esté utilizando actualmente HPKP, HSTS o incluso HTTPS.

¿He entendido esto correctamente? ¿Hay alguna mitigación que pueda tomar un sitio web para evitar que se haga de esta manera? ¿Existe un argumento de que HPKP no presenta ningún nuevo riesgo de DoS que sea más grave que el que ya existía antes de HPKP? ¿Se ha observado este tipo de ataque DoS persistente en la naturaleza?

He leído RFC 7469, el estándar que describe HPKP, y parece que no tiene ninguna mitigación. Parece que el ataque que describí calificaría como una instancia de 'pining hostil' , pero el estándar no lo hace ' Parece que menciona alguna mitigación útil para la fijación hostil (aparte de la edad máxima).

    
pregunta D.W. 06.07.2015 - 07:26
fuente

1 respuesta

1

Al leer esta nota , se proporciona un enlace a la pin draft de Perrin aquí . Veo dos contramedidas contra el escenario que describe en este borrador:

Comencemos con el primero, que se puede interpretar de diferentes maneras:

  

Cada vez que un cliente que realiza una "activación de pin" ve una combinación de nombre de host y TSK no representada en el almacén de pin de "activación de pin", se crea un pin inactivo. Cada vez que el cliente ve el mismo pin, el pin se "activa" durante un período igual al período de tiempo entre la primera vez que se vio el pin y el tiempo más reciente, hasta un período máximo de 30 días.

En mi interpretación, la implementación del párrafo anterior significaría que un atacante solo puede activar nuevos pines por un tiempo muy limitado. Sin embargo, el atacante todavía podría revocar los pines más viejos, parece. Por lo tanto, pasamos a la segunda contramedida descrita:

  

Tachuelas no revocables:   Una tachuela con generación 255 no puede ser revocada. Tales tachas PUEDEN usarse para minimizar el riesgo de que una clave privada de TSK comprometida pueda usarse para afectar la disponibilidad del sitio.

Por lo tanto, un servidor que ha emitido una táctica no revocable, de hecho podría seguir utilizando esta táctica para siempre. Lo que he leído es que un servidor podría crear un par de claves que NO se usa, pero para el que crea una táctica no revocable. (En la implementación de Perrin, esto se convertiría en uno de los dos PIN máximos que no se pueden eliminar). En caso de que el servidor esté comprometido, esta clave se puede recuperar y usar para deshacer los cambios del atacante.

Si esto se implementa o no en los navegadores actuales, no lo sé.

Editar : Como @StackzOfZtuff señaló en uno de los comentarios, en realidad hay una transcripción de una conversación por correo electrónico entre IETF: WEBSEC y Perrin, señalando la implementación de un mecanismo tipo TACK para HSTS.

    
respondido por el Michael 06.07.2015 - 11:12
fuente

Lea otras preguntas en las etiquetas