 |
| Imagen tomada de The Fuzzing Project |
Precisamente por este parecido la vulnerabilidad ha sido bautizada como OptionsBleed, también en honor al método OPTIONS de HTTP. Este es utilizado por un cliente web para recibir información sobre los métodos soportados por el servidor. Una petición OPTIONS normal debería devolver una respuesta de la forma:
 |
| Respuesta de una petición OPTIONS. |
Pero, durante una investigación sobre los sitios con mayor posición de Alexa, Böck descubrió algunas respuestas a OPTIONS bastante peculiares. Los métodos se repetían, aparecían vacíos, y en algunas cabeceras se devolvía algo parecido a una fuga de memoria:
 |
| Respuesta OPTIONS de un servidor vulnerable. |
Este comportamiento le hizo sospechar. Aunque no conocía el software especifico que devolvía estas respuestas, encontró fugas con fragmentos de configuraciones que parecían pertenecer a servidores Apache, y se puso en contacto con el equipo de desarrollo, que finalmente confirmaron la vulnerabilidad.
Este error ha sido identificado como CVE-2017-9798 y ya existen parches para la mayoría de las versiones de Apache Web Server en Linux.
Teoría y práctica
Explotar OptionsBleed en teoría es sencillo: solo hay que realizar una petición OPTIONS al servidor para disparar la vulnerabilidad. En la práctica, la vulnerabilidad no es determinista, es decir, no devuelve siempre el mismo resultado dados los mismos datos de entrada. Por ello su reproducción es difícil.
Se sabe con seguridad que la vulnerabilidad es causada por un fallo en la implementación de la directiva Limit. Los métodos disponibles en el servidor (aquellos que la respuesta de OPTIONS comunica) se pueden establecer a nivel global en la configuración. Usando Limit, además, se puede limitar su uso por recurso, usando un fichero .htaccess.
 |
| Sintaxis de una directiva Limit. |
El problema ocurre cuando establecemos una directiva Limit sobre un método que no hemos registrado en la configuración global. Es más, en general cualquier método no valido sobre el que se define esta directiva directiva en un fichero .htaccess provoca la fuga de información.
Aun localizado el problema, se deben dar ciertas condiciones para su explotación, y los detalles son bastante vagos. Según Böck en el FAQ de la vulnerabilidad:
Debido a su naturaleza, el fallo no aparece de forma determinista. Parece que solo se da en servidores ocupados. A veces aparece tras varias peticiones.
OptionsBleed no es HeartBleed
Más allá del parecido en el comportamiento, hay varias diferencias que hacen a OptionsBleed bastante menos peligroso que HeartBleed, la famosa vulnerabilidad en OpenSSL aparecida en 2014 con la que se le está comparando.
Por un lado, la superficie de exposición es menor. OptionsBleed solo afecta a servidores Apache Web Server. Por su parte HeartBleed afectaba a todo servidor con versiones de OpenSSL vulnerables, sin distinción entre web, email, o VPN.
Además, es necesario tener una cierta configuración y que el servidor se encuentre en condiciones específicas para la explotación. Hay que tener en cuenta que en el estudio se ha conseguido explotar la vulnerabilidad en solo 466 servidores entre el Top 1 millón de Alexa. Además, de ser explotada, OptionsBleed devuelve un fragmento de menor longitud que HeartBleed.
Sin embargo, tiene un riesgo añadido: en servidores Apache compartidos, un usuario puede incluir un fichero .htaccess manipulado para facilitar deliberadamente la explotación y descubrir secretos del resto de usuarios.
Pero hay algo que sí tiene en común: pasaron desapercibidos durante bastante tiempo.
Deja una respuesta