OptionsBleed, bug similar a Heartbleed (PARCHEA!)
Heartbleed es una de las peores vulnerabilidades a las que se ha enfrentado Internet. Descubierto en abril de 2014, este fallo de seguridad en OpenSSL permitía a cualquier usuario conseguir volcados de memoria de cualquier servidor, volcados en los que podía haber todo tipo de información personal, como, por ejemplo, contraseñas. La magnitud de este fallo de seguridad fue tal que, a día de hoy, aunque está más o menos controlado, sigue habiendo miles de servidores vulnerables conectados a Internet. Ahora, una nueva vulnerabilidad similar (en cierto modo), llamada OptionsBleed, vuelve a amenazar Internet, esta vez, por culpa del servidor web Apache.
Las conexiones HTTP pueden hacer llamadas a varios métodos (como GET y POST, los métodos más utilizados), pudiendo recurrir al método OPTIONS para ver una lista completa con los métodos que tenemos disponibles y podemos utilizar.
Tal como dice Hanno Bock en The Fuzzing Project, al enviar una petición OPTIONS a las webs más visitadas a nivel mundial según el ranking Alexa, la respuesta, en la mayoría de los casos, viene con un parámetro "Allow" y repetición de "HEAD". Esto puede ser fruto de un desbordamiento de búfer, igual a como ocurría en una primera instancia con OpenSSL y que, finalmente, dio lugar a Heartbleed.
Aunque de momento no hay un exploit ni una prueba de concepto de este fallo de seguridad, todo apunta a una especie de nuevo Heartbleed, esta vez de la mano del servidor web Apache. De conseguirse explotar, esta vulnerabilidad podría permitir a cualquier atacante conseguir piezas arbitrarias de memoria que podrían contener información sensible, tanto del propio servidor (contraseñas, por ejemplo), como de los usuarios que lo visitan.
El experto de seguridad que ha dado con esta vulnerabilidad, se ha puesto en contacto con la mayoría de las compañías potencialmente vulnerables a este fallo, y tan solo una ha devuelto el correo, siendo, además, bastante reacia a colaborar en la investigación
Dentro del Alexa Top 1 Million, tan solo 466 webs se han encontrado como vulnerables a este fallo, aunque al no ser un fallo determinista, puede haber muchos más servidores vulnerables en la lista.
La vulnerabilidad ya ha sido registrada con el código CVE-2017-9798, aunque, de momento, se encuentra en fase de análisis por parte del NIST.
Si utilizamos Apache 2.2, este experto de seguridad nos facilita un parche temporal hasta que se analice la vulnerabilidad, se acepte y llegue un parche oficial de la mano de Apache.
Aunque la vulnerabilidad es similar en la técnica a Heartbleed, en realidad no es tan grave como esta, y es que, además de afectar a un pequeño número de hosts en todo el mundo, los volcados de memoria que devuelve son mucho menores a los que devolvía Heartbleed. Pero es un fallo real, un fallo del que hay que preocuparse e intentar solucionar cuanto antes, y es que, al final, los grandes ataques informáticos siempre vienen a través de estas pequeñas vulnerabilidades.
Esto debería devolver UN solo "Allow: HEAD".
Otro ejemplo:
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.
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.
OptionsBleed no es HeartBleed. Es necesario tener una cierta configuración y que el servidor se encuentre en condiciones específicas para la explotación. 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.
Actualización: Optionsbleed no fue descubierto por Böck, sino que ha tomado como referencia un informe que lo describía en 2014 publicado por investigadores Old Dominion University, en Estados Unidos. Después de tres años, desde Apache solo han lanzado parches para las ramas 2.4.X y 2.2.X.
Las conexiones HTTP pueden hacer llamadas a varios métodos (como GET y POST, los métodos más utilizados), pudiendo recurrir al método OPTIONS para ver una lista completa con los métodos que tenemos disponibles y podemos utilizar.
Tal como dice Hanno Bock en The Fuzzing Project, al enviar una petición OPTIONS a las webs más visitadas a nivel mundial según el ranking Alexa, la respuesta, en la mayoría de los casos, viene con un parámetro "Allow" y repetición de "HEAD". Esto puede ser fruto de un desbordamiento de búfer, igual a como ocurría en una primera instancia con OpenSSL y que, finalmente, dio lugar a Heartbleed.
El experto de seguridad que ha dado con esta vulnerabilidad, se ha puesto en contacto con la mayoría de las compañías potencialmente vulnerables a este fallo, y tan solo una ha devuelto el correo, siendo, además, bastante reacia a colaborar en la investigación
Dentro del Alexa Top 1 Million, tan solo 466 webs se han encontrado como vulnerables a este fallo, aunque al no ser un fallo determinista, puede haber muchos más servidores vulnerables en la lista.
La vulnerabilidad ya ha sido registrada con el código CVE-2017-9798, aunque, de momento, se encuentra en fase de análisis por parte del NIST.
Si utilizamos Apache 2.2, este experto de seguridad nos facilita un parche temporal hasta que se analice la vulnerabilidad, se acepte y llegue un parche oficial de la mano de Apache.
Aunque la vulnerabilidad es similar en la técnica a Heartbleed, en realidad no es tan grave como esta, y es que, además de afectar a un pequeño número de hosts en todo el mundo, los volcados de memoria que devuelve son mucho menores a los que devolvía Heartbleed. Pero es un fallo real, un fallo del que hay que preocuparse e intentar solucionar cuanto antes, y es que, al final, los grandes ataques informáticos siempre vienen a través de estas pequeñas vulnerabilidades.
¿Cómo probarlo?
Simplemente con...curl -D - -X OPTIONS http://localhost
Returns:
HTTP/1.1 200 OK
Date: Thu, 22 Jun 2017 08:40:07 GMT
Server: Apache
Allow: GET,HEAD,POST,OPTIONS,HEAD,HEAD
Content-Length: 0
Content-Type: httpd/unix-directoryEsto debería devolver UN solo "Allow: HEAD".
Otro ejemplo:
for i in {1..100};
do curl -sI -X OPTIONS https://www.google.com/ | grep -i "allow:";
doneTeorí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.
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.
OptionsBleed no es HeartBleed. Es necesario tener una cierta configuración y que el servidor se encuentre en condiciones específicas para la explotación. 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.
Actualización: Optionsbleed no fue descubierto por Böck, sino que ha tomado como referencia un informe que lo describía en 2014 publicado por investigadores Old Dominion University, en Estados Unidos. Después de tres años, desde Apache solo han lanzado parches para las ramas 2.4.X y 2.2.X.
Actualizaciones de productos
- Gentoo: Commit (2.2.34 / 2.4.27-r1 fixed), Bug
- NetBSD/pkgsrc: Commit
- Guix: Commit
- Arch Linux: Commit (2.4.27-2 fixed)
- Slackware: Advisory
- NixOS: Commit
- Debian: unfixed, Security Tracker
- NIST
- MITRE
- ExploitDB
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!