Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Una guía de tecnologías de seguridad en Red Hat Enterprise Linux

Por Ana McTaggart , Vincent Danen



Crédito: Pexels

Red Hat tiene un largo historial de adopción y creación de tecnologías de seguridad para fortalecer nuestras plataformas centrales, como Red Hat Enterprise Linux (RHEL). Cuando se utilizan otras plataformas o productos en capas con RHEL, heredan muchas de estas protecciones debido a esa base.


Estas protecciones ayudan, pero requieren experiencia para saber cuándo deben aplicarse. Es importante distinguir entre las tecnologías de seguridad que están "siempre activas" y las que requieren activación o configuración. Por ejemplo, Security Enhanced Linux (o SELinux) es el último.







La cantidad de protección que SELinux brindará varía enormemente dependiendo de si SELinux está habilitado (el valor predeterminado de RHEL), en modo permisivo o deshabilitado por completo.


Por el contrario, un ejemplo de funciones de seguridad que no requieren ningún esfuerzo adicional por parte del usuario sería el uso de software que se ha creado con indicadores de refuerzo de compilación que crean binarios reforzados. Tocaremos cada uno de estos brevemente para describir el tipo de protección que ofrecen y proporcionar enlaces para aquellos que deseen obtener más información. Además, investigaremos los tipos de ataques que encontramos y cómo nuestros servicios protegen contra ellos, y si es posible protegerlos.


Entonces, ¿qué tipos de seguridad puede encontrar incorporada en un sistema Red Hat Enterprise Linux?


Seguridad configurable


Un tipo de característica de seguridad que proporciona RHEL es la seguridad configurable, ajustes que se pueden habilitar para una mayor seguridad. El kernel de Linux es notable en la capacidad de personalizarlo según las necesidades de cada uno, debido a su naturaleza de código abierto, y discutiremos varias características que contiene para hacerlo.


SELinux


SELinux es una implementación de MAC (control de acceso obligatorio) en el kernel de Linux, que proporciona una capa adicional de seguridad. SELinux está habilitado de forma predeterminada en todos los sistemas Red Hat Enterprise Linux desde Red Hat Enterprise Linux 4. Se ha demostrado que es capaz de mitigar varios tipos de fallas de ejecución remota de código cuando la aplicación vulnerable está limitada por las políticas de SELinux.


Un ejemplo reciente es CVE-2020-11100 , una falla de ejecución remota de código en HAProxy. En RHEL, cuando SELinux está habilitado y en modo de aplicación, el impacto de esta falla puede reducirse debido al aumento de la dificultad de explotación. Si bien SELinux puede no hacer que todos los defectos sean ineficaces, a menudo limita el riesgo y reduce la eficacia de una explotación exitosa.


Seccomp


El modo de computación segura (seccomp) es una función de filtrado de llamadas del sistema que se introdujo en el kernel de Linux en 2005. Después de mucho trabajo y evolución ascendente , agregamos soporte para seccomp en RHEL 7. Sin habilitar y configurar seccomp, las aplicaciones de espacio de usuario han acceso a una gran cantidad de llamadas al sistema que a menudo no se utilizan durante la vida útil de un proceso, lo que aumenta innecesariamente la superficie de ataque del kernel.


Es posible configurar seccomp para filtrar las llamadas al sistema a las que tiene acceso un proceso de acuerdo con un conjunto de reglas. Esto da como resultado la reducción de la exposición del kernel al espacio del usuario, mitigando posibles ataques de ejecución de código y fugas de datos, al tiempo que mejora el aislamiento de recursos. Cuando se detecta un intento de ejecutar una llamada al sistema que no está permitida, la función seccomp del kernel intercepta la llamada y mata al llamador. Esto es particularmente útil en escenarios donde un atacante logra desencadenar la ejecución de código arbitrario, convirtiéndolo en una denegación de servicio y un bloqueo resultante. Como SELinux, seccomp es otra amenaza.


técnica de reducción que reduce la gravedad de una vulnerabilidad. Seccomp es utilizado por OpenShift Container Platform en Red Hat para ayudar a proteger los contenedores.


Endurecimiento del compilador


RHEL utiliza varias funciones para mejorar el refuerzo del compilador , con el fin de mejorar la seguridad de los binarios enviados. Esto es importante para que los usuarios no necesiten volver a compilar el software, además de proporcionar coherencia entre los productos de Red Hat. Esto mitiga muchos ataques que se basan en desbordamientos de búfer u otras infracciones a nivel del compilador. A continuación, se muestran algunas de las formas en que intentamos optimizar RHEL para la seguridad mediante funciones del compilador al compilar el sistema operativo.


Reubicación de solo lectura (RELRO)


Relocation Read-Only (RELRO), es un mecanismo para fortalecer los binarios ELF en Linux. En esta tecnología, nos aseguramos de que el vinculador resuelva funciones vinculadas dinámicamente al comienzo de la ejecución y luego haga que el GOT sea de solo lectura. Esta técnica se llama RELRO y puede elevar significativamente el listón y los pasos necesarios para una sobrescritura GOT.


FORTIFY_SOURCE


FORTIFY_SOURCE es unmecanismo ligero de tiempo de compilación y ejecución que proporciona protecciones de desbordamiento de búfer para funciones que son muy utilizadas por los programadores. Según la investigación , más del 19% de las fallas informadas al CERT son desbordamientos de búfer. En Red Hat, ha sido una de las causas más comunes de fallas durante los últimos tres años, y el número ha disminuido debido al uso de lenguajes con seguridad de tipos, analizadores estáticos y el uso de FORTIFY_SOURCE.


Ejecutables independientes de posición (PIE)


Un binario PIE , así como todas sus dependencias, se cargan en ubicaciones aleatorias dentro de la memoria virtual cada vez que se ejecuta la aplicación. Este mecanismo de refuerzo basado en el compilador hace que los ataques de Programación orientada al retorno (ROP) sean mucho más difíciles de ejecutar de manera confiable. A partir de RHEL-7, la mayoría de los demonios de red se compilan como PIE y desde RHEL-8 en adelante, casi todos los binarios (97%) son PIE.


Protección contra aplastamiento de pilas (SSP)


SSP (también conocido como StackGuard) es una tecnología que dificulta la explotación de los desbordamientos de búfer basados ​​en la pila al insertar valores canarios aleatorios en el marco de la pila. Esto ha sido eficaz para bloquear técnicas de ataque como ret2libc , ret2gets y ret2plt .


Aleatorización del diseño del espacio de direcciones (ASLR)


ASLR es una tecnología que ha estado presente desde Red Hat Enterprise Linux 3. También se conoce como "Execshield" y protege contra la corrupción de la memoria. En particular, se defiende contra las vulnerabilidades presentes en la gestión de la memoria y lo hace aleatorizando las compensaciones a varios componentes clave como la pila, las ubicaciones de las bibliotecas compartidas en la memoria y el montón del programa.


Al aleatorizar estas ubicaciones de memoria, es mucho más difícil y costoso para un atacante realizar un ataque de desbordamiento del búfer, sin saber dónde se desborda el búfer. Puede leer más sobre cómo Execshield usa ASLR y NX (No eXecute) para lograr esto en Tecnologías de seguridad: ExecShield .


Estadísticas de CWE


Además, Red Hat analiza las vulnerabilidades que se nos informan para brindar un mejor servicio a nuestros usuarios. Red Hat ha estado utilizando CWE (Common Weakness Enumeration) para asignar tipos de debilidades a vulnerabilidades durante la última década. Con estos datos podemos ver qué tipos de debilidades están presentes en los productos Red Hat y determinar los tipos de protecciones que existen para ayudar a defendernos contra ellos o reducir la severidad de una explotación exitosa.


Por ejemplo, una vulnerabilidad de desbordamiento de búfer que podría permitir la ejecución de código arbitrario podría convertirse en una que bloquee solo una aplicación, a través de protecciones como FORTIFY_SOURCE. Analizamos las tres fuentes más comunes de vulnerabilidades, las principales vulnerabilidades explotadas y las principales vulnerabilidades críticas.


Desbordamientos de búfer


Los identificadores de CWE relacionados con los desbordamientos de búfer son CWE-119 , CWE-120 , CWE-121 , CWE-122 y CWE-680 .


Las vulnerabilidades en los productos Red Hat, para el año 2020 a partir del 12 de octubre, con estos CWE asociados representaron el 8% del total de vulnerabilidades manejadas. Para 2019, fue superior al 11% y para 2018 incluso superior al 13%. Estos están por encima del error estándar relativo del 1,5% y se puede suponer que reflejan una disminución significativa en la ocurrencia de desbordamientos de búfer.


Creemos que esto se debe al mayor uso de lenguajes de programación con seguridad de tipos como Python y al declive de C y otros lenguajes que no imponen la verificación enlazada. Aunque Python y otros lenguajes con seguridad de tipos no son perfectamente inmunes a los desbordamientos de búfer, es menos probable que ocurran. Además, el uso de herramientas de análisis de código estático está descubriendo posibles desbordamientos de búfer que se pueden solucionar antes de que se publique el código. Finalmente, Red Hat tiene protecciones integradas contra desbordamientos de búfer, como FORTIFY_SOURCE.


Errores de búfer de memoria


CWE identifica una categoría de debilidades llamadas Errores de búfer de memoria que incluye nueve debilidades diferentes. Estas son debilidades que se relacionan principalmente con el correcto direccionamiento de los búferes de memoria. Las tecnologías que aleatorizan el diseño de la memoria, agregan verificación de integridad adicional a las estructuras de control o cambian las protecciones de mapeo de páginas para que sean lo más estrictas posible son todas tecnologías que pueden ayudar a mitigar los ataques contra estas fallas, especialmente cuando se usan junto con otras.


Las vulnerabilidades en los productos Red Hat, para el año 2020 a partir del 12 de octubre, con estos CWE asociados representaron el 13% del total de vulnerabilidades manejadas. Para 2019, fue menor al 11% y para 2018, menor al 12%. Estas diferencias están por encima del error estándar relativo del 0,5% y esta fluctuación no tiene una causa aparente. Estos pueden protegerse mediante la aleatorización de ubicaciones de direcciones, lo que Red Hat hace con ASLR y otras técnicas.


Errores de neutralización de datos


CWE identifica una categoría de debilidades denominadas errores de neutralización de datos que incluye 22 debilidades diferentes. Estas son debilidades relacionadas con cómo se ingresan los datos en los protocolos. Por ejemplo, los ataques XSS y las inyecciones SQL se encuentran en esta categoría.


Las vulnerabilidades en los productos Red Hat, para el año 2020 a partir del 12 de octubre, con estos CWE asociados representaron el 1.6% del total de vulnerabilidades manejadas. Para 2019, fue menor al 1% que 2020, y para 2018, mayor que 2019 al 1.2%, pero aún menor que 2020. Estas diferencias están por encima del error estándar relativo de 0.7%, y esta fluctuación no tiene una causa aparente


Las 10 principales vulnerabilidades explotadas


El CERT / CC emitió un informe que detalla las 10 principales vulnerabilidades explotadas de forma rutinaria en el período 2016-2019. De estos, solo dos tuvieron un impacto en los productos Red Hat; el primero fue en Apache Struts 2 ( CVE-2017-5638 ) que se incluyó en Red Hat JBoss Fuse Service Works 6, pero nunca se usó en la aplicación.


Además, la otra vulnerabilidad aplicable estaba en Adobe Flash Plugin, que se envía como un paquete adicional para Red Hat Enterprise Linux ( CVE-2018-4878 ), que se debió a una debilidad de "uso después de gratis" ( CWE-416 ). Si bien, en teoría, esto podría mitigarse con tecnologías diseñadas para proteger contra la explotación de la corrupción de la memoria, Red Hat no vuelve a compilar el complemento Adobe Flash y el proveedor tendría que aplicar cualquier refuerzo, ya que Adobe Flash no es de código abierto. Por lo tanto, Red Hat no está en condiciones de prevenir esta vulnerabilidad.


Vulnerabilidades comúnmente explotadas en Red Hat