99% de servidores web vulnerables

Alexander Klink y Julian Zeri han mostrado en esta charla una vulnerabilidad del uso de funciones “hash” que está presente en un 99% de las plataformas de servidor web actuales. La lista es impresionante, parecía que nunca iban a acabar de encontrar sitios vulnerables: PHP, ASP.NET, Java, Python, Ruby, Node.js. Con esta lista y sumando según W3Techs, parece totalmente creíble que el 99% de los servidores web estén afectados.

La verdad es que es mucho más fácil decir dónde no existen problemas: en Perl (que tiene este problema solucionado desde que en 2003 se descubrió que era vulnerable -- la historia se repite a sí misma) y CRuby 1.9 (y para 1.8 parece que hay ya un parche), que ha sido el equipo que han puesto como ejemplo de colaboración.

¿De qué se trata la vulnerabilidad? Enviando una petición POST a un servidor web con una lista de parámetros adecuadamente configurada, la CPU del servidor sube al 99% durante un largo rato (por cada petición). Las cifras de efectividad del ataque en cuanto a ancho de banda son impresionantes: de 1 a 100 kb/s para subir un núcleo al 100% de CPU.  

¿Y por qué sucede? Básicamente todas las plataformas afectadas utilizan un “hash” para guardar los parámetros de la petición web. Y el problema está en que utilizan funciones hash que son conocidas, no son resistentes a las colisiones y son fáciles de invertir. Los nombres de los parámetros que se van a meter en el “hash” se pueden elegir de modo que todos tengan el mismo valor de “hash” (construyéndolos a base de cadenas de dos o tres caracteres que todas producen hashes equivalentes), de modo que una operación que normalmente es lineal con el número de parámetros se vuelve cuadrática. Y en cuanto se añaden miles de parámetros en una petición… tu servidor web está perdido.

Pero no todo está perdido: hay mitigaciones rápidas (limitar el número de parámetros de la petición web), que es lo que están haciendo la mayoría, porque la solución buena (que es la que ha adoptado Perl) requiere aleatorizar el hash de modo que no sea posible encontrar las cadenas equivalentes (básicamente con aleatorizar la semilla de una manera diferente para cada estructura es suficiente, no es muy complicado pero es una pieza tan crítica de cada plataforma que el cambio hay que hacerlo con unas buenas pruebas).