Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Por qué sus servidores aún pueden sufrir (a) Heartbleed - y qué hacer
22 de marzo de 2023 - Equipo de RRPP de TuxCare
Ha pasado casi una década desde el descubrimiento de Heartbleed, un peligroso exploit de OpenSSL que afectó a millones de sistemas, y una vulnerabilidad que saltó a los medios de comunicación.
Historia, ¿verdad? La tecnología avanza rápido... diez años es mucho tiempo... y esa vulnerabilidad hace tiempo que desapareció, ¿verdad?
Equivocada.
Publicamos otro artículo sobre Heartbleed porque, adivina qué, sigue entre nosotros. Sí, dada la rapidez con la que se publicó un parche, y teniendo en cuenta el rápido ritmo de desarrollo de la tecnología, Heartbleed ya debería haber pasado a un segundo plano.
Y, si ha parcheado sus sistemas a tiempo, siempre, no tiene nada de qué preocuparse.
Pero, ¿y si te has saltado un parche en algún sitio? ¿Y si su empresa se ha fusionado recientemente con otra en la que los parches no estaban al día? ¿Y si esa nueva solución tecnológica contiene un trozo de código obsoleto?
Resulta que sigue siendo habitual que los sistemas sean vulnerables a Heartbleed. En este artículo, ofrecemos una rápida visión general de Heartbleed y su historia. También le indicaremos investigaciones recientes que demuestran que innumerables sistemas siguen corriendo el riesgo de sufrir un ataque habilitado por un exploit de Heartbleed.
También describimos cómo puede comprobar fácilmente si tiene bibliotecas OpenSSL vulnerables a Heartbleed, y qué puede hacer para asegurarse de que tiene una protección hermética contra esta peligrosa vulnerabilidad.
¿Qué es exactamente el "fallo Heartbleed"? Un breve resumen
En 2014, los investigadores descubrieron que las versiones 1.0.1 a 1.0.1f de OpenSSL incluían un tipo de error de gestión de memoria denominado comprobación de límites omitida. En otras palabras, el código de OpenSSL no comprobaba que los datos introducidos en la memoria no superaran el tamaño del búfer asignado.
Un atacante puede, por tanto, engañar al servicio OpenSSL para que asigne un búfer de 64 KB, sólo para enviar datos que excedan el tamaño del búfer. De este modo, el atacante puede filtrar (o sangrar) datos de la máquina de la víctima en incrementos de 64 KB. Esto es sólo una breve descripción - para más detalles sobre el exploit puedes leer el artículo en profundidad de CSO Magazine de CSO Magazine aquí.
El fallo se denominó Heartbleed debido a la necesidad de "sangrar" los datos bit a bit, y porque el ataque se produce durante lo que se denomina un "latido", el mensaje de pulso que se envía entre dos servidores para confirmar que el servidor conectado sigue vivo.
Las posibilidades de explotar la vulnerabilidad Heartbleed eran amplias y graves. Los atacantes pueden robar desde claves criptográficas y credenciales de usuario hasta documentos y comunicaciones privadas. Un atacante puede conseguir todo eso sin estar en posesión de las credenciales de acceso y sin dejar rastro.
Aunque 64 KB no parecen mucho, abren la puerta a grandes brechas. En un sorprendente ejemplo de pirateo de Heartbleed, un atacante consiguió robar 4,5 millones de historiales de pacientes de Community Health Systems en 2014.
Heartbleed sigue al descubierto
Vale, eso fue en 2014. Por qué sigue mereciendo la pena escribir sobre Heartbleed? Simplemente por el gran número de aplicaciones y servidores que dependen de OpenSSL que, mezclado con la tendencia a parchear de forma inconsistente, nos deja con un gran número de servicios que siguen siendo vulnerables.
Cuando se descubrió Heartbeat, Netcraft informó de que alrededor del 17% de los servidores web seguros eran vulnerablesincluyendo algunos de los servicios más populares del mundo. Es un número enorme de servidores.
Los parches para OpenSSL se publicaron en cuanto se anunció la vulnerabilidad, pero eso no significa que Heartbleed haya pasado a la historia.
Los investigadores de seguridad siguen señalando riesgos en torno a Heartbleed. Recientemente, el gigante tecnológico japonés NTT señaló en un informe de investigación que Heartbleed es una de las principales razones por las que OpenSSL sigue siendo uno de los servicios más atacados por los piratas informáticos.
Asimismo, en noviembre de 2020, un investigador del SANS Internet Storm Center utilizó el motor de búsqueda Shodan para descubrir que más de 200.000 máquinas siguen siendo vulnerables a CVE-2014-0160el identificador oficial de la vulnerabilidad Heartbleed. Mediante un proceso de validación, el investigador descubrió que Shodan estaba en su mayoría en lo cierto en sus evaluaciones.
Está claro que, aunque existen medidas de mitigación, Heartbleed sigue siendo un problema. Si utiliza el servicio de parcheo de bibliotecas de TuxCare, LibraryCarede TuxCare, no tienes de qué preocuparte, ya que tus bibliotecas estarán siempre actualizadas. Pero, a falta de una solución de parcheo de bibliotecas automatizada y sin reinicios, debe revisar cómo sus operaciones pueden seguir siendo vulnerables a Heartbleed debido a una vulnerabilidad de las bibliotecas OpenSSL.
Los parches son la solución... pero también el problema
La razón por la que Heartbleed sigue ahí fuera no es en absoluto la falta de parches. La mayoría de los servicios que dependen de OpenSSL tendrán un parche disponible para eliminar la amenaza Heartbleed. Aplique el parche y la amenaza Heartbleed habrá desaparecido, tan simple como eso, dice la teoría.
Pero no es tan sencillo por varias razones. En el entorno empresarial, la aplicación de parches no consiste simplemente en activar un parche y reiniciar un servicio o dispositivo. La aplicación de parches requiere un tiempo de inactividad planificado y recursos significativos, que implican el tiempo de una serie de expertos, como administradores de sistemas, administradores de bases de datos y administradores de Linux. En el proceso surgen muchos problemas:
- Incertidumbre sobre las bibliotecas actualizadas: En la ejecución de un proceso de parcheo, a menudo interviene un cierto grado de automatización que puede dejar a los administradores de sistemas inseguros sobre qué bibliotecas se parchearon durante el proceso. Esto puede dar lugar a reinicios extensos e innecesarios y a tiempos de inactividad adicionales, lo que puede suponer un freno a la aplicación de parches exhaustivos.
- No parchear consistentemente: Otro peligro es que algunas bibliotecas no se parcheen simplemente porque los administradores no son conscientes de que es necesario parchearlas. Un catálogo completo y exhaustivo de bibliotecas puede ser difícil de establecer y todo lo que se necesita para una brecha es una sola biblioteca sin parchear. La aplicación manual de parches también puede hacer que se pasen por alto bibliotecas.
- Ventana de vulnerabilidad: A menudo, los parches se publican rápidamente, pero se aplican con menos rapidez. La razón de ello es la dificultad de planificar el tiempo de inactividad, y los retos de conseguir todos los patos técnicos en una fila para aplicar un parche. Esto deja un margen de tiempo entre el momento en que se informa de una vulnerabilidad y el momento en que el usuario final la parchea. Durante este periodo, los sistemas de su organización serán vulnerables a los ataques.
Está claro que la aplicación de parches puede convertirse rápidamente en un asunto de aciertos y errores. Años después de que se descubriera Heartbleed, no es en absoluto imposible que su organización haya descuidado la aplicación de parches para protegerse contra él.
También es posible que, entretanto, hayas adquirido tecnología que aún sea portadora del fallo crítico de OpenSSL.
Comprobación de bibliotecas sin parches con Uchecker
Si eres un administrador de sistemas y te preguntas si tus bibliotecas están parcheadas de forma consistente, una de las herramientas que deberías considerar es uChecker - una herramienta gratuita, con licencia GNU desarrollada por el equipo detrás de TuxCare.
uChecker le ayuda a comprobar si sus bibliotecas están parcheadas contra la vulnerabilidad Heartbleed, generando un informe fácil de leer que detalla qué bibliotecas no están actualizadas. uChecker puede escanear bibliotecas en memoria, así como bibliotecas almacenadas en disco.
Esto supone una ventaja frente a otros escáneres que no detectan las bibliotecas no parcheadas en memoria. Es fácil instalar uChecker - simplemente consulte la página de GitHub aquí.
$ curl -s -L https://kernelcare.com/uchecker | sudo python
Una vez que haya realizado un análisis con uChecker, puede proceder a parchear cualquier servicio OpenSSL que siga siendo vulnerable a Heartbleed.
Como cuestión de seguridad, deberías comprobar a fondo el código que descargas de Internet antes de ejecutarlo en tus sistemas. El comando anterior puede, y debe, dividirse en dos: uno para descargar el código que desea comprobar y otro para ejecutarlo. Lo anterior es sólo una forma conveniente de ejecutar uChecker, no la mejor práctica de seguridad.
Merece la pena volver a comprobar Heartbleed
Años después de la aparición de Heartbleed, no cabe duda de que merece la pena comprobar que sus servidores están completamente protegidos contra esta peligrosa amenaza. Hemos señalado dos ejemplos de cómo investigaciones recientes subrayan que las organizaciones aún tienen lagunas en su respuesta a Heartbleed.
Si actualmente no utiliza una herramienta automatizada de aplicación de parches en tiempo real, le recomendamos que ejecute uChecker, una herramienta gratuita y sencilla que le indicará rápidamente si sus servidores siguen siendo vulnerables a Heartbleed.
En cualquier caso, es fundamental vigilar de cerca OpenSSL. Es una capa de seguridad importante y, al mismo tiempo, una de las piezas de software más expuestas, con 202 vulnerabilidades descubiertas desde su lanzamiento hasta el momento de escribir estas líneas, de las cuales Heartbleed es sólo una.
Y no lo olvides: LibCare de TuxCare mantendrá actualizadas tus bibliotecas, incluida OpenSSL, sin complicaciones. Más información sobre LibCare aquí.
