La vulnerabilidad tiene ciertas similitudes con el conocido y dramático Heartbleed, sobre todo en la manera en que los atacantes pueden realizar peticiones a los servidores para engañar al servidor Apache con el fin de obtener como respuesta más datos de los que les corresponde desde su posición.
Böck explica que Optionsbleed no es tan grave como Heartebleed porque solo filtra contenidos procesados por el servidor Apache y no contenidos de todo tipo alojados en la memoria de la máquina, incluyendo el sistema operativo y otros programas y aplicaciones. Esto significa que la filtración de datos está limitada a lo que Apache procesa, destacando las páginas web muy por encima del resto. Sin embargo, esto no significa que la vulnerabilidad sea inocua, ya que sí se podría filtrar contenidos de páginas reservadas solo a usuarios autenticados.
Básicamente, los servidores HTTP se dedican a servir datos que tienen alojados según las peticiones realizadas por los clientes, que principalmente son navegadores web. Los clientes suelen realizar peticiones de tipo GET o POST y esperan obtener una respuesta de los servidores. Sin embargo, Apache es capaz de procesar otros tipos de peticiones a través de sus “métodos”, pudiéndose mencionar PUT, PATCH, HEAD, etc. Estos métodos han sido añadidos a Apache con el paso de los años y no están soportados por todos sus competidores. Además, los administradores de servidores también bloquean el acceso a algunos de esos métodos.
Con el fin de no convertir las peticiones a los servidores en un agujero negro, Apache es capaz de soportar los métodos a modo de opción. Un cliente puede consultar al servidor con una petición de opciones y el servidor responde qué métodos tiene permitidos.
Böck ha llevado a cabo pruebas con los tipos de opciones manejados por los servidores de sitios web correspondientes al millón más visitado según el ránking Alexa, descubriendo que 466 nodos emitieron una respuesta distorsionada respondiendo a un formato similar al siguiente:
Allow: ,GET,,,POST,OPTIONS,HEAD,, Allow: POST,OPTIONS,,HEAD,:09:44 GMT Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Allow: GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE
En las opciones permitidas (Allow) se pueden ver porciones aleatorias que parecen pertenecientes a páginas web, lo que puede ser interpretado como una filtración de código. Böck no ha sido capaz de hallar el origen exacto del fallo, por lo que ha decidido reportar lo que tiene al equipo de seguridad de Apache.
Todo parece indicar que el origen está en ciertas configuraciones del servidor Apache que terminan provocando Optionsbleed, por lo que no estamos ante un problema generalizado ni especialmente extendido. De hecho, parece que el origen viene de una configuración errónea del fichero .htaccess:
< Limits PATCH PUT DELETE > Deny from all < /Limits >
Los ficheros .htaccess pueden ser colocados dentro de las carpetas de un servidor Apache para establecerles normas concretas. Esto permite a los administradores de los servidores limitar las opciones que pueden ser solicitadas por los clientes. Sin embargo, parece que el establecer normas contradictorias en un fichero .htaccess puede terminar confundiendo al servidor, provocando la vulnerabilidad Optionsbleed, que puede ser etiquetada como de usar después de liberar memoria.
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.
Los servidores Apache que están funcionando en entornos compartidos, en los cuales se pueden encontrar diferentes implementaciones del fichero .htaccess en una misma máquina, son los más afectados por Optionsbleed.
Fuente: BleepingComputer | muyseguridad
