Actualización de seguridad de Apache2 para Debian

El martes 27 de agosto la comunidad Debian amaneció con una actualización de seguridad en el servicio apache2 para solucionar varias vulnerabilidades que podrían causar una deneación de servicio en el servicio. Concretamente, se publicaron 6 CVEs donde se detallaban los fallos de seguridad.

En el Debian Security Advisory publicado, se dieron a conocer los 6 CVEs que afectan al servicio Apache2 httpd:

• CVE-2019-9517: Jonathan Looney (de Netflix) informó que un atacante podría realizar un ataque de denegación de servicio inundando una conexión con solicitudes. El fallo residía en que implementaciones HTTP/2 eran vulnerables al almacenamiento de datos en buffer sin restricciones, lo que posibilitaba la realización de denegaciones de servicio.

El atacante envía luego una secuencia de solicitudes para un objeto de respuesta grande y, dependiendo de cómo los servidores pongan en cola las respuestas, puede consumir la memoria, la CPU o ambos.

En la siguiente tabla se muestran las versiones que son aún vulnerables y cuáles han sido arregladas y ya no lo son:

• CVE-2019-10081: Craig Young informó que HTTP/2 PUSHes podría provocar una sobrescritura de memoria en el grupo de solicitudes de inserción, lo que provocaría bloqueos. HTTP/2 (2.4.20 a 2.4.39) con algunos «pushes«, por ejemplo configurados con «H2PushResource». Esto podrían provocar una sobreescritura de memoria en el grupo de solicitudes de empuje, lo que provocaría fallos. La memoria copiada es la de los valores del encabezado del enlace de inserción configurados, no los datos suministrados por el cliente.

En la siguiente tabla se muestran las versiones que son aún vulnerables y cuáles han sido arregladas y ya no lo son:

• CVE-2019-10082: Nuevamente Craig Young informó que el manejo de la sesión HTTP/2 podría permitir la lectura de memoria previamente liberada durante el cierre de la conexión.

En la siguiente tabla se muestran las versiones que son aún vulnerables y cuáles han sido arregladas y ya no lo son:

• CVE-2019-10092: Matei «Mal» Badanoiu informó de un problema de secuencias de comandos limitados entre sitios que afecta a la página de error mod_proxy. Un atacante podría provocar un error en el enlace de la página de error y, en su lugar, apuntar a una página de su elección engañando a los usuarios. Esto solo sería explotable si durante la configuración de un servidor con proxy esta se realizara de forma incorrecta, de tal manera que la página de error llegara a renderizarse.

Se ha aprovechado esta oportunidad para eliminar también los datos de solicitud de muchos otros mensajes de error incorporados. Sin embargo, este problema no afecta directamente y su salida ya se solucionó para evitar ataques de secuencias de comandos entre sitios. Se pueden observar los cambios realizados en los programas del módulo mod_proxy afectados, mod_proxy_balancer.c y proxy_util.c. Por ejemplo, el programa proxy_util.c estaba inicialmente:

@@ -1252,10 +1252,11 @@
     if (*balancer->s->nonce == PROXY_UNSET_NONCE) {
         char nonce[APR_UUID_FORMATTED_LENGTH + 1];
         apr_uuid_t uuid;
        /* Retrieve a UUID and store the nonce for the lifetime of
         * the process.
         */
        apr_uuid_get(&uuid);
        apr_uuid_format(nonce, &uuid);
         rv = PROXY_STRNCPY(balancer->s->nonce, nonce);
     }

y tras el patch, ha quedado de la siguiente forma:

@@ -1252,10 +1252,11 @@
     if (*balancer->s->nonce == PROXY_UNSET_NONCE) {
         char nonce[APR_UUID_FORMATTED_LENGTH + 1];
         apr_uuid_t uuid;   
 /* Generate a pseudo-UUID from the PRNG to use as a nonce for
     * the lifetime of the process. uuid.data is a char array so
     * this is an adequate substitute for apr_uuid_get(). */
    ap_random_insecure_bytes(uuid.data, sizeof uuid.data);
    apr_uuid_format(nonce, &uuid);
    rv = PROXY_STRNCPY(balancer->s->nonce, nonce);
 }

Se puede apreciar cómo apr_uuid_get(&uuid); se ha cambiado por ap_random_insecure_bytes(uuid.data, sizeof uuid.data). En otras palabras, se pasa de una función que genera un nuevo UUID (que es el causante del fallo que se expone) a una función que genera bytes pseudoaleatorios como es ap_random_insecure_bytes. Es la interfaz conveniente para apr_random, pero alertamos que, aunque sea conveniente y más barato, es también más inseguro que apr_generate_random_bytes(), pues mientras que apr_random_insecure_bytes genera valores pseudoaleatorios, apr_generate_random_bytes sí que los genera aleatoriamente. Decantarse por apr_random_insecure_bytes en lugar de apr_generate_random_bytes podría llevarnos a que en un tiempo se descubra otra vulnerabilidad similar a CVE-2019-10092.

• CVE-2019-10097: Daniel McCarney informó que cuando mod_remoteip se configura para usar un servidor proxy intermediario confiable usando el protocolo «PROXY«, un encabezado PROXY especialmente manipulado podría desencadenar un desbordamiento del buffer basado pila o una desferencia de puntero NULO. Esta vulnerabilidad solo puede ser activada por un proxy confiable y no por clientes HTTP no confiables.

Así es como estaba antes del patch el archivo mod_remoteip.c, donde se aprecia que no se trata de manera especial la función ap_get_brigade(), que es la que «juega» con lo que en Apache se denomina «bucket brigade«.

Tras el patch, ya se emplean salidas de log con ap_log_cerror(), autocompletando tal y como se recomienda en su documentación, con APLOG_MARK. Aunque lo más interesante es cómo se utiliza el if para obtener los bytes que se reservan en memoria para este módulo de remoteip y que, en caso de validarse, se emplea apr_brigade_destroy() para, destrozar el «bucket brigade» de «bb» que, según su documentación, es el que calcula su longitud.

bb –>The brigade to compute the length of
read_all –> Read unknown-length buckets to force a size
length –>Returns the length of the brigade (up to the end, or up to a bucket read error), or -1 if the brigade has buckets of indeterminate length and read_all is 0.

Documentación de la función apr_brigade_length

Como cabe esperar, de este CVE no hay muchas versiones afectadas tal y como muestra la propia Debian.

• CVE-2019-10098: Yukitsugu Sasaki reportó que los redireccionamientos configurados con mod_rewrite que estaban destinados a ser autorreferenciales podrían ser engañados por nuevas líneas codificadas y en su lugar redirigir a una URL inesperada dentro de la URL de solicitud. Aquí la solución pasó simplemente por modificar el valor de default_cflags, pasando de AP_REG_DOLLAR_ENDONLY a AP_REG_DOTALL | AP_REG_DOLLAR_ENDONLY;

Conclusiones y matices
—————————————————————————————

Hay una cuestión a tener en cuenta: qué versión de cada paquete viene con cada rama de Debian, algo muy importante a la hora de un pentest.

Tal y como hizo Dabo en la Qurtuba 2k17, tener un breve resumen de las versiones y sus distintas ramas es útil para realizar un pentest, pues suele existir confusión cuando se ve, por ejemplo, un Apache 2.4.10 en la salida de herramientas como Nmap y se piensa que es vulnerable al comprobar que la última versión de Apache disponible es la 2.4.38. Sin embargo, Apache 2.4.10 es la última versión de Debian 8, por lo que no es vulnerable. Es por esta razón que aunque muchos de los CVEs afecte a las versiones 2.4.38, la 2.4.25 en Debian 9 Jessie está solucionado.

Se recomienda tener muy en cuenta cuáles son los repositorios de nuestros sistemas y así saber si disponemos de la última versión de cada paquete de software. Además, se recomienda actualizar la versión de Apache a versiones que ya hayan sido arregladas o incluso, en servidores de desarrollo, comenzar a utilizar los repositorios de SID (Still in Development) de Debian bullseye. Esto es posible añadiendo los siguientes repositorios a nuestro /etc/apt/sources.list

deb http://deb.debian.org/debian bullseye main contrib non-free deb-src http://deb.debian.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian-security/ bullseye-security/updates main contrib non-free
deb-src http://deb.debian.org/debian-security/ bullseye-security/updates main contrib non-free

deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

Tras realizar un update y upgrade, podríamos instalar apache (de encontrarse previamente instalado simplemente, se actualizará)

$ lsb_release -a; apachectl -v
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Server version: Apache/2.4.41 (Debian)
Server built: 2019-08-14T04:42:29

Así se observa como, en un Debian 10 Buster (última versión de Apache es la 2.4.38), la salida de apachectl -v muestra la 2.4.41 al estar utilizando los repositorios de testing.

Tras todo lo comentado, desde Hispasec recomendamos que, si se está utilizando Apache2, se actualice a la versión arreglada lo antes posible para evitar todos estos posibles fallos, además de realizar las configuraciones necesarias del entorno GLAMP para optimizar el rendimiento del servidor.

Más información:

Apache2 Documentation
https://ci.apache.org/projects/httpd/trunk/doxygen/

Apache2 ap_random_insecure_bytes Documentation
https://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__DAEMON.html#ga08dcffcf71961b096bb25fa259e55f08

Apache2 apr_uuid_get Documentation
https://apr.apache.org/docs/apr-util/0.9/group__APR__UUID.html#g129830a7a3c6b77047d2e74e261a7364

Lo nuevo en Debian 7.0 Wheezy
https://www.debian.org/releases/wheezy/amd64/release-notes/ch-whats-new.en.html

Lo nuevo en Debian 8.0 Jessie
https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html

Lo nuevo en Debian 9.0 stretch
https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html

Lo nuevo en Debian 10 Buster
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html

Debian Security Advisory
https://www.debian.org/security/2019/dsa-4509

Documentación GitHub del CVE-2019-9517
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

Modificaciones en mod_proxy_balancer.c
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_balancer.c?r1=1864787&r2=1864786&pathrev=1864787

Modificaciones en proxy_util.c
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c?r1=1864787&r2=1864786&pathrev=1864787

Manu Alén