Hay tres cosas de las que puede estar seguro en la vida: muerte, impuestos y nuevos CVE. Para las organizaciones que confían en CentOS 8, ahora sucedió lo inevitable, y no tomó mucho tiempo. Apenas dos semanas después de llegar al final oficial de la vida, algo se rompió espectacularmente, dejando CentOS 8 usuarios con mayor riesgo de un ataque severo, y sin soporte de CentOS.
Uno pensaría que este problema ya no afecta a una cantidad significativa de organizaciones porque, a estas alturas, las empresas ya habrían migrado de CentOS 8 a un sistema operativo que cuenta con el soporte activo de los proveedores. Después de todo, el soporte del proveedor es fundamental para la seguridad y el cumplimiento.
Pero como siempre sucede con estas cosas, puede contar con el hecho de que una gran parte de los usuarios de CentOS 8 continúan con un sistema operativo no compatible, a pesar de ser conscientes de los riesgos. Con ese riesgo ahora cristalizándose, estamos usando este artículo para examinar CVE-2021-4122la vulnerabilidad recién descubierta en el cifrado LUKS y analizar sus opciones para mitigarla.
Espera, ¿qué es LUKS?
Entonces que es lucas? LUKS significa Configuración de clave unificada de Linux y es un mecanismo que se utiliza en los sistemas basados en Linux para admitir, entre otras cosas, el cifrado de disco completo. Se recomienda en muchas guías de «mejores prácticas» como una opción esencial de fortalecimiento del sistema para los equipos de TI preocupados por la seguridad.
¿Cómo funciona LUKS? Bueno, durante la implementación del sistema, puede crear una partición que solo sea legible, es decir, los datos que contiene solo sean comprensibles, con una contraseña proporcionada por el usuario. LUKS es bastante complejo y muchos sistemas de seguridad interactúan con LUKS, pero el objetivo de este artículo no es una guía completa de LUKS.
Tener un disco completamente encriptado (dispositivo de bloque en Linux «habla») garantiza que los datos estén a salvo de miradas indiscretas incluso cuando están en reposo, lo que significa que un atacante que roba una computadora portátil, por ejemplo, aún no puede ver los datos confidenciales contenidos en eso.
Puede aumentar aún más la seguridad vinculando un dispositivo de bloque específico a una computadora específica a través de TPM (Módulo de plataforma confiable). Eso agrega otro obstáculo para un atacante, lo que dificulta extraer físicamente los datos cifrados de una máquina y conectarlos a un sistema de alto rendimiento con el objetivo de acceder a los datos por fuerza bruta. Aunque, como siempre, la probabilidad de éxito depende de la potencia informática, el algoritmo de cifrado seleccionado y la pura suerte.
En general, LUKS proporciona una protección excelente y, por ese motivo, se confía con frecuencia en él para proteger los sistemas en una variedad de organizaciones.
Entendiendo la falla de LUKS
CVE-2021-4122 se asignó a fines del año pasado, pero solo recientemente surgió una comprensión completa de los riesgos de seguridad en torno a LUKS. Resulta que es posible, al menos parcialmente, descifrar un disco cifrado con LUKS y acceder a los datos que contiene sin poseer la contraseña utilizada para configurar el cifrado.
Una característica clave de LUKS es la capacidad de cambiar, sobre la marcha, la clave que se utiliza para cifrar un dispositivo determinado. Haría esto, por ejemplo, para rotaciones de claves programadas en entornos de alta seguridad.
Esta función de recifrado sobre la marcha significa que el dispositivo permanece disponible durante el proceso de cambio de clave. Se llama «reencriptación en línea», que se refiere a la capacidad de volver a encriptar un disco con una clave diferente mientras está en línea y en uso activo.
Es dentro de este proceso que se identificó una vulnerabilidad. Resulta que si sabe lo que está haciendo, puede realizar esta operación sin tener la contraseña original y actual. Incluso sin una contraseña, puede solicitar un nuevo cifrado.
Explotando la falla, este proceso parecería abortado y algunos de los datos estarían disponibles sin cifrar. En ningún momento el dispositivo experimenta ningún comportamiento anómalo, por lo que sería difícil detectar a un atacante realizando la operación con solo mirar el estado del dispositivo de bloqueo.
Se recomienda encarecidamente a los administradores de sistemas que actualicen cryptsetup, el paquete compatible con LUKS, en todos los sistemas bajo su control, ya que la vulnerabilidad puede conducir a la divulgación de información.
Ok, entonces solo parchearé y seguiré adelante…?
Exactamente. Eso es lo que todo administrador de sistemas debe hacer en sus sistemas: reemplazar el paquete afectado. Pero para algunos administradores de sistemas esto será más fácil decirlo que hacerlo. ¿Qué administradores de sistemas tendrán dificultades? Ha acertado: aquellos que aún dependen de CentOS 8.
La mayoría de los proveedores recibieron una advertencia temprana del error y ya están proporcionando paquetes actualizados para sus distribuciones. Y lo mismo con Red Hat, que respalda a CentOS. Pero, dado que CentOS 8 ya no es oficialmente compatible, no aparecerá un parche de CentOS 8 para la falla de LUKS.
Para los usuarios de CentOS 8, las cosas son bastante sombrías. Los sistemas sin parches son vulnerables al robo de datos debido a una falla publicada y ampliamente conocida. Es una situación grave y, de una forma u otra, debe implementar versiones parcheadas actualizadas del paquete afectado.
No hacer nada no es una opción cuando los datos confidenciales están en riesgo. Y, esencialmente, todos sus datos son confidenciales y no para divulgación pública (de lo contrario, ya se habrían hecho públicos), y confía en una solución de cifrado de disco completo como LUKS precisamente para evitar la divulgación.
Sus opciones de parcheo si todavía está en CentOS 8
Hay dos caminos disponibles para los administradores de sistemas que confían en los sistemas Linux afectados que funcionan más allá del final de su vida útil. Una opción es descargar la fuente del proyecto aguas arriba y compilarla localmente, creando un paquete de sistema de reemplazo. La otra opción es firmar con un proveedor de soporte extendido que proporcionará los parches que el proveedor original ya no publica.
El enfoque de construcción local tiene inconvenientes. Primero, el código fuente del proyecto original no hace concesiones especiales para una distribución específica. Cada distribución o familia de distribuciones tiene sus propias peculiaridades. La familia RHEL, que incluye CentOS, también tendrá estas peculiaridades.
Eso incluye cosas como ubicaciones binarias, configuraciones de inicio de servicio, configuraciones, etc. Su equipo local tendrá que ajustarlos manualmente. Si su equipo de TI local tiene la experiencia necesaria es otra cuestión. Del mismo modo, con los equipos de tecnología generalmente bajo presión para hacer las cosas, existe el riesgo de que su esfuerzo de parcheo de bricolaje se retrase. Además, en la página del proyecto LUKS sí mismoexiste este siniestro «Por favor, prefiera siempre las herramientas de compilación específicas de la distribución a la configuración manual de cryptsetup».
Su alternativa es pensar en los proveedores de soporte extendido como un enfoque confiable, rentable y más fácil para abordar este problema. Soporte de ciclo de vida extendido de TuxCare el servicio hace exactamente eso. TuxCare ofrece parches de alta calidad para distribuciones al final de su ciclo de vida, como CentOS 8, y lo hace a tiempo.
Además, también obtiene soporte completo para los parches. La implementación es simple, los parches de TuxCare se implementan con la misma facilidad que los parches compatibles con el proveedor.
Debes actuar – ahora
Si decide no buscar soporte externo, debe hacer algo ahora mismo para proteger sus sistemas contra la nueva vulnerabilidad. Podría decidir morder la bala y compilar cryptsetup y sus dependencias localmente, y realizar la implementación en todos sus sistemas.
Pero definitivamente no es el último CVE que sale que afecta a CentOS 8. Para que os hagáis una idea del alcance de lo que estamos hablando: aún hoy siguen surgiendo vulnerabilidades que afectan a los sistemas CentOS 6. ¿Qué tan viable es a largo plazo seguir lidiando con un flujo continuo de CVE que afectan a CentOS 8?
Es posible que esté ejecutando CentOS 8 en este momento porque se le impidió migrar a una alternativa por un motivo u otro. Podría ser compatibilidad, soporte o cualquiera de múltiples razones.
Las vulnerabilidades no se detendrán en la fecha de EOL, por lo tanto, haga la vida más fácil para sus equipos de TI, más segura para sus profesionales de seguridad y cumpla con los requisitos de cumplimiento en cuanto a la aplicación de parches para su negocio: consulte Familia de servicios de TuxCare, y específicamente Soporte de ciclo de vida extendido. Es una forma sólida de obtener protección continua contra nuevos CVE que afectan CentOS 8 – comprándole tiempo para migrar a otro sistema operativo.
