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


Ahora detallamos las vulnerabilidades reportadas con más frecuencia para Red Hat por año. Vemos que las mismas vulnerabilidades son en gran medida las mismas en la parte superior para 2020, y aparecen nuevas en diferentes años. Esto refleja el cambio en la tecnología y los métodos de seguridad más modernos implementados a lo largo del tiempo. También refleja el desafío de resolver CWE particulares. Cabe destacar CWE-125 , CWE-120 , CWE-20 y CWE 400 con más de 100 CVE cada año. CWE-120, CWE-125 son desbordamientos de búfer, CWE-20 es una desinfección de entrada incorrecta y CWE 400 es un consumo de recursos incontrolado. Estos son defectos difíciles de proteger.


La desinfección de la entrada es muy difícil de hacer a la perfección y requiere una base teórica importante para evitar posibles ataques. El consumo incontrolado de recursos puede ser ventajoso para utilizar completamente una pieza de hardware. Los desbordamientos de búfer son un error común en los lenguajes que no son seguros para la memoria, sin embargo, la buena noticia es que los desbordamientos de búfer en general están disminuyendo. En general, los CVE se distribuyen en una variedad más amplia de CWE que en el pasado. Esto hace que sea más difícil para los analistas de seguridad descubrir y corregir vulnerabilidades, pero subraya la posición única de Red Hat para brindar este servicio de seguridad de valor agregado con su modelo basado en suscripción. Podemos abordar los defectos a medida que se descubren, sin importar lo difícil que sea prevenirlos.



Vulnerabilidades críticas comúnmente reportadas en Red Hat


A continuación, examinamos los principales CVE críticos, a diferencia del patrón general de CVE. Como antes, vemos el aumento de la propagación de los CVE entre los CWE y una disminución general de los CVE críticos. Las mismas categorías siguen siendo las principales culpables, pero Red Hat protege cada vez más de forma preventiva el software contra ataques. CWE-120 puede ser un desbordamiento de búfer, pero como los desbordamientos de búfer están en general en declive, podemos esperar ver menos CVE críticos. Además, Red Hat mantiene el software a lo largo del tiempo. Corregimos los defectos existentes cuando se descubren y somos selectivos en la actualización a nuevas versiones de software para evitar que se introduzcan nuevos defectos. Esto da como resultado que el software que mantenemos tenga menos vulnerabilidades a lo largo del tiempo




Conclusión


En conclusión, una suscripción a Red Hat proporciona un servicio de valor agregado para la seguridad. Red Hat proporciona numerosas herramientas para la seguridad de nuestros productos y un ciclo de vida constante con soporte. También hemos documentado una reducción en los tipos de ataques más comunes, que atribuimos a nuestras medidas preventivas de seguridad por diseño.


A pesar del aumento de los ataques, no hay indicios de que Red Hat se vea afectado en 2020 más que en años anteriores y hay alguna evidencia de que nos afecte menos. Esto se debe a nuestro soporte de seguridad y correcciones de fallas. Para aplicaciones de alta seguridad, el software de código abierto compatible ofrece los beneficios de un modelo de desarrollo de código abierto y el soporte de software empresarial. Red Hat Enterprise Linux permite que las tecnologías de seguridad de la comunidad de código abierto estén habilitadas de forma predeterminada y que las vulnerabilidades se investiguen a medida que se descubren.


Fuente: Blog Red Hat


8 vistas0 comentarios

Entradas Recientes

Ver todo
D&S colores.png

Un Servidor en Quien Confiar

CONTACTO

contactodirecto@datayservice.com

PBX + 57 6 8812277

Calle 54 # 26-60

ZIP 170004

Manizales, Colombia

REDES

logo-facebook.png
linkedin_circle-512.webp
logo-instagram-1.png

 © Data&Service, todos los derechos reservados.