Una vulnerabilidad bastante seria a la que nos estamos enfrentando desde el día de ayer, pero el destino ha querido que fuera de esta manera y no de otra. Hablo de la vulnerabilidad que ha sido bautizada como HTTPoxy y que deja potencialmente al descubierto a cualquier sitio web que utiliza CGI o mecanismos similares a CGI, tales como el ubicuo y nefasto PHP.
La vulnerabilidad consiste, como siempre, en una “tontería” (un hecho tonto) que, post factum, puede hacernos creer equivocadamente que los desarrolladores de las infraestructuras más importantes que constituyen la base de la red no saben lo que hacen y que nosotros lo haríamos mejor. Siempre es más fácil mirar desde la barrera. La seguridad en sistemas diseñados para comunicarse con otros sistemas es, sin lugar a dudas, el ámbito más difícil en la informática: es el ámbito donde todo debe funcionar perfectamente y el ámbito donde un mínimo error puede ser mortal. Si las infraestructuras libres que conocemos muestran vulnerabilidades –que, además, son rápidamente cubiertas por un parche– tan solo ocasionalmente, aunque en esas ocasiones suelan ser vulnerabilidades serias, la conclusión a la que hay que llegar forzosamente es que la comunidad del Software Libre se ocupa realmente bien de la seguridad, a pesar de las apariencias.
HTTPoxy es un ejemplo clásico de agujero producido por colisión de espacio de nombre (namespace collision): una variable que no debería poder ser modificable lo es porque existe un mecanismo que permite acceder a ella porque una segunda variable diferente que sí es modificable acaba siendo renombrada a la primera. Según la especificación de la interfaz CGI –que permite la ejecución de programas externos a un servidor web, a petición de este mismo–, si en una petición HTTP creamos una “variable” en forma de cabecera llamada Variable, esta variable será renombrada como HTTP_VARIABLE para ser pasada a cualquier aplicación mediante CGI o mecanismos similares a CGI (léase PHP). El problema es que si esa “variable” se llamase Proxy, CGI la renombrará en HTTP_PROXY, que es un nombre de variable global utilizada en CGI y especialmente en PHP para establecer un proxy HTTP para conexiones salientes. Esto quiere decir que bastaría con enviar una petición HTTP con una “variable” Proxy que apunte a un servidor malicioso para ganar control de todas las conexiones salientes que haga un servidor, por ejemplo, para consultar una base de datos o cualquier recurso que sea externo al propio servidor. A partir de ahí los ataques posibles son múltiples: desde poder conocer contraseñas de bases de datos porque se interviene la simple petición de acceso como devolver datos incorrectos para sabotear un servicio o, directamente, inyectar código ejecutable aprovechando alguna otra vulnerabilidad para poder tomar control total del servidor.
¿Cómo se resuelve esto? ¿Actualizando Apache y nada más? No es tan sencillo. Aquí quiero dirigirme al que posiblemente sea mi público mayoritario, esto es, al usuario de distribuciones Linux de escritorio que nunca ha tocado un servidor. No es que yo sea un experto –para eso tenemos a los verdaderos expertos como Linuxito o David Ochobits o Zagur–, pero he tenido que parchear el servidor contra esta vulnerabilidad en concreto. Y la poca experiencia que puedo tener al respecto ya me ha mostrado que la forma de administrar un sistema de escritorio poco tiene que ver con la forma de administrar un servidor que ofrece servicios a otros, incluso cuando esos pocos sean amigos y no el público en general.
Las vulnerabilidades de un sistema de escritorio pueden ser muy serias, por supuesto, pero si tenemos el cortafuegos bien configurado –que ignore toda conexión entrante– reducimos bastantelas probabilidades de un ataque remoto; solo quedaríamos vulnerables a ataques iniciados a través de aplicaciones concretas que se aprovechen de una conexión saliente ya establecida (un ejemplo: que un navegador tenga un agujero que permita a un script espiar la memoria utilizada por procesos del usuario). Y, en todo caso, un sistema de escritorio, normalmente, puede ser actualizado al minuto y con bastante seguridad de que no va a pasar nada especialmente malo… y que, si sucediera algo imprevisto, el único afectado sería uno mismo, finalmente, y nadie más.
Un servidor, en cambio, no puede ser intervenido en cualquier momento ni de cualquier manera. En primer lugar, y volviendo al caso concreto de HTTPoxy, la actualización que parchea Apache en Debian contra esta vulnerabilidad es la 2.4.10-10+deb8u5 –por cierto, a la fecha de publicación de la entrada testing aún no la tiene; así que espero que entendáis por qué siempre digo que no hay que tocar testing si uno no es beta tester de Debian–. Actualizar el servidor web implica tener que reiniciar Apache para que se cargue la nueva versión parcheada –el llamado hot patching solo existe en SUSE Enterprise Linux y solo para el núcleo–, cosa que interrumpe, aunque sea momentáneamente, el acceso a la web alojada y, por tanto, puede interrumpir sin previo aviso el trabajo de un visitante. En el caso de mi servidor una caída de cinco segundos no implicaría problema alguno a nadie, pero imaginaos, por ejemplo, si al administrador del servidor de la web de vuestro banco se le ocurre actualizar el servidor en medio de la jornada laboral mientras estáis haciendo una operación en vuestras cuentas y, para peor suerte, se le complicara el trabajo: os quedaríais sin poder realizar la operación por quién sabe uno cuánto tiempo (estoy acordándome de cierto banco del cual soy cliente que tuvo la web caída casi 48 horas).
Sin embargo, actualizar el servidor web no era suficiente en este caso. NextCloud no tardó ni 24 horas en lanzar una actualización de seguridad, antes incluso de que llegara la actualización de Apache en Debian. En el caso de NextCloud se trata de una aplicación PHP que, además, está pensada para alojar datos personales de usuarios, razón por la cual la actualización inmediata es forzosa para evitar la más mínima posibilidad de que dichos datos acaben en manos que no correspondan –aunque los datos estén cifrados en el servidor, pueden ser recuperados– o manipulados o, simplemente, inutilizados. Y en el caso del pequeño servidor que mantengo, debo decir que hay un par de cuentas que he cedido a amigos míos que confían en que el servidor funcione de forma correcta y segura. No tengo ni idea de lo que guardan o dejan de guardar allí, pero es una responsabilidad adquirida que obliga a que uno haga las actualizaciones pertinentes de forma meditada –haciendo todas las copias de seguridad necesarias– y correcta. Y si además las actualizaciones lo son de seguridad, además de meditadas y correctas, tienen que ser rápidas… ¡pero en un momento en el que no obstaculice el uso normal del servidor!
Relato todo esto con la perspectiva de un administrador de un pequeño servidor personal en el cual he cedido alguna cuenta de NextCloud a alguna persona cercana que siempre puede contactar conmigo directamente. Si mantener una infraestructura tan pequeña ya puede ser un dolor de cabeza, imaginad ahora lo que debe de ser tener que mantener un servidor de escala empresarial de forma profesional. Un servidor crítico y público no debe dejar de funcionar en ningún momento y tiene que garantizar seguridad total, por lo que para poder afrontar una actualización de este calado puede ser necesario, por ejemplo, mantener una réplica de un servidor que se active mientras se actualice el servidor principal de manera que el servicio no sufra ninguna interrupción. O, simplemente, programar la actualización en un horario que se sepa que es de tráfico mínimo que conlleve el menor impacto posible para el funcionamiento del servicio; esta suele ser la estrategia de los administradores de los servidores de mi universidad, por ejemplo. En resumen, sin importar el tamaño que tenga, administrar un sistema que está pensado para que terceros puedan usarlo de alguna u otra forma implica tener que pensar en esos usuarios en el momento de hacer cualquier cambio.
Esto explica por qué la propagación de actualizaciones de seguridad en servidores suele ser bastante lenta. Dejando de lado los servidores que quedan abandonados pero que, inexplicamente, siguen en línea, no es difícil encontrar noticias como que 300.000 sitios aún eran vulnerables a Heartbleed dos meses después de haberse descubierto la vulnerabilidad (artículo del 2014 de Errata Security). La dificultad que entraña “pilotar” un servidor puede tener este efecto adverso de retrasar la aplicación de parches críticos no solo de seguridad, sino de resolución de fallos –aunque en servidores un fallo suele tener asociado un problema de seguridad, aunque sea una “simple” denegación de servicio–, lo cual es garantizarse problemas aún más graves en un futuro. Si ya uno tiene que estar “rezando” por que aquellos que encuentren vulnerabilidades nuevas informen de ellas en vez de aprovecharse de ellas, lo único responsable, si uno se ha comprometido en mantener funcionando un servidor, es aplicar diligentemente toda actualización que redunde en protección y mejor funcionamiento. Entiendo, por otro lado, que uno retrase otro tipo de actualizaciones no críticas justamente para garantizar la estabilidad del sistema.
Es por esto que no todo el mundo puede mantener un servidor y no todo el mundo puede mantener cualquier clase de servidor. Un servidor web en que uno solo tenga su propio blog y nada más no implica casi ningún riesgo, porque no hay datos ajenos de los que uno se esté haciendo responsable, aunque aún así uno debería tener máximo cuidado en mantenerlo asegurado para evitarse disgustos. Una nube de alojamiento de archivos, aunque sea para uno mismo y un puñado de conocidos, ya es algo más serio. De ahí en adelante solo puede ser más difícil. La mentalidad “ermitaña” y “egoísta” del usuario de escritorio no sirve para nada en un contexto así: toda decisión se debe tomar pensando en aquellos que pueden potencialmente acceder al servidor. Y por supuesto, todo esto requiere tiempo y dedicación de la que, por ejemplo, yo puedo disponer ahora, pero quién sabe si podré en un futuro.
Por eso entiendo bastante a quienes se muestran reacios a alquilar un servidor o incluso dejaron de hacerlo. Estar pendientes del último fallo de OpenSSL y revisar bien si uno está protegido de este después de actualizar o aplicar un parche provisional, estar pendientes del estado del sistema, que las aplicaciones web están en orden y actualizadas, etc., todo eso requiere ganas y tiempo para estar alerta a incidentes de todo tipo. Eso sí, se aprende muchísimo, pero justamente porque nos muestra que casi todos los hábitos que adquirimos en el uso del escritorio son absolutamente inútiles en un servidor, por no decir que unos cuantos pueden ser incluso perjudiciales para ello.
Moraleja: actualizad vuestros servidores para protegerlos contra HTTPoxy. Hacedlo por vuestros usuarios, porque la amenaza es seria. Y usuarios, sed conscientes de las complicaciones de mantener un servidor: no es tan sencillo como ejecutar apt-get o pacman y olvidarse de todo. Ser usuario de un sistema Linux en el escritorio no tiene nada que ver con ser usuario de un sistema Linux en un servidor, incluso tratándose a veces de exactamente la misma distribución.
Imagen: Server, por dariorug, publicada bajo CC-BY 2.0
Fuente: etccrond
