Los posibles ataques de tiempo siempre se mencionan en un contexto u otro, pero no creo que haya leído un caso en el que alguien haya ejecutado un ataque de ese tipo en Internet.
Los posibles ataques de tiempo siempre se mencionan en un contexto u otro, pero no creo que haya leído un caso en el que alguien haya ejecutado un ataque de ese tipo en Internet.
Puede ser tentador suponer que la latencia de la red (jitter) hace que estos ataques sean poco prácticos. Este no es el caso porque las máquinas vulnerables utilizan a menudo marcas de tiempo de TCP , donde el tiempo exacto en que se generó el paquete se codifica en la Encabezado TCP No importa cuánto demore el tráfico en llegar, la hora exacta en que se creó sigue presente. Incluso en sistemas con marcas de tiempo deshabilitadas, es posible obtener una idea precisa de la sincronización del paquete al repetir la prueba varias veces y promediar el resultado para tener en cuenta la fluctuación de la red. Entonces, con eso en mente ...
Sí, los ataques de tiempo se pueden realizar a través de una red. El ejemplo más destacado fue una vulnerabilidad de larga duración en OpenSSH que enumeración de usuario trivial permitida . El problema se debió al hecho de que un usuario no válido activaría la comparación de contraseñas utilizando Blowfish, el valor predeterminado. Cuando se usó un usuario válido, se usaría SHA-2 en su lugar. Mientras que normalmente la diferencia de tiempo es mínima, enviar una contraseña grande (varios kilobytes) causaría que la diferencia sea notable.
Del error original divulgación :
Cuando SSHD intenta autenticar a un usuario no existente, recogerá una estructura de contraseña falsa codificada en el SSHD. código fuente. En esta estructura de contraseña codificada, el hash de contraseña se basa en el algoritmo BLOWFISH ($ 2). Si las contraseñas de los usuarios reales se procesan con SHA256 / SHA512, el envío de contraseñas grandes (10KB) resultará en más corto Tiempo de respuesta del servidor para usuarios no existentes.
Los ataques contra estos tipos de errores a menudo explotan el hecho de que se toma una ruta de código diferente dependiendo de la entrada que proporcione, causando una diferencia de tiempo significativamente mayor que la que se suele observar con los ataques de tiempo de arquitectura de bajo nivel donde las diferencias se miden en nanosegundos y provienen de instrucciones que no se ejecutan en tiempo constante (flush + flush, etc.).
Como se explica en la discusión sobre esta pregunta sobre una amenaza de enumeración de usuarios basada en un ataque de tiempo ... las vulnerabilidades pueden surgir en cualquier momento en que se necesite una cantidad diferente de trabajo para devolver un resultado, incluso si la página renderizada no está diseñada para revelar la información que se utilizó para procesar la solicitud.
La pregunta vinculada se refiere específicamente a una vulnerabilidad de enumeración de usuarios, pero pueden ocurrir diferencias de tiempo similares en cualquier esquema de autorización que requiera la búsqueda de un recurso y la verificación de permisos antes de que se pueda determinar si el usuario autenticado tiene permiso. Podría ser posible discernir, por ejemplo, si un usuario tiene cierta función habilitada en su cuenta, porque la lógica de autorización es más compleja y demora más en ejecutarse.
La gravedad de dicha vulnerabilidad dependería completamente de la sensibilidad de la información que revelaría el ataque.
Sí, por supuesto, porque uno de esos ataques es Spectre ! El ataque contra el tiempo de caché de la CPU es conocido por su potencial de llevarse a cabo con Javascript , revelando datos críticos del usuario, almacenados en un navegador, a un sitio web arbitrario.
(Por cierto, esto ilustra la idea: los ataques de tiempo remotos a veces pueden verse como algo casi inofensivo, pero pueden desempeñar el papel de una base sólida para ataques más sofisticados, construir sobre otras vulnerabilidades y demasiado difícil de rastrear. Por ejemplo, si en algún momento habrá incluso una vulnerabilidad aparentemente inofensiva en el lado del cliente, un ataque de sincronización puede fácilmente evolucionar hacia un problema grave.)
La razón por la que siempre se creía que los ataques de temporización no eran viables en Internet era, básicamente, el tiempo de ida y vuelta que agrega un margen de error considerable, que a su vez se supone que hace que los problemas de tiempo sean muy oscuros para una parte remota. Sin embargo, en general, la RTT es algo que, en la mayoría de los casos, dada una buena conectividad tanto del lado de la víctima como del lado del atacante (que es algo demasiado fácil de lograr), estadísticamente, es lo suficientemente estable. Los problemas de tiempo también son estables en este sentido.
Si un atacante puede hacer muchos intentos de recopilar datos suficientes para realizar mediciones estadísticas, generalmente puede realizar un ajuste para RTT, eliminando esta vaga confusión de las mediciones del tiempo de ejecución. Aquí hay otro ejemplo práctico de cómo se puede hacer.
Los problemas de tiempo no son algo que deba subestimarse.
Lea otras preguntas en las etiquetas timing-attack