Esta semana en ciberseguridad – Diciembre semana 3

Resumen de todos los CVE de Log4j

A continuación, les mostramos los CVE en el orden en que aparecieron así como las nuevas vulnerabilidades y actualizaciones, además del link de la fuente para conocer mas de cada una de estas vulnerabilidades.

  • CVE-2021-44228 [Crítico, 10.0]: la vulnerabilidad Log4Shell original es una falla de deserialización. Tiene un puntaje de 10 en la escala CVSS y otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados, lo que permite la toma de control completa del sistema.
  • CVE-2021-45046 [Crítico, anteriormente bajo, 9.0]: Este es un defecto de Denegación de Servicio (DoS) con un puntaje de 3.7 9.0. La falla surgió como resultado de una solución incompleta que entró en 2.15.0 para CVE-2021-44228. Si bien la corrección aplicada a 2.15.0 resolvió en gran medida la falla, ese no fue el caso para ciertas configuraciones no predeterminadas.
  • CVE-2021-4104 [Alto, 8.1]: Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. Aunque no es fácil, el ataque no es imposible en v1.x. Por lo tanto, tiene sentido protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando: zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
  • CVE-2021-42550 [Moderado, 6.6]: esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x.
  • CVE-2021-45105 [Alto, 7.5]: Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Desde entonces, Apache ha lanzado una versión log4j 2.17.0 que corrige el CVE.

Según Google: más de 35.000 paquetes de Java tienen defectos de Log4j

“Más de 35.000 paquetes de Java, que representan más del 8% del repositorio de Maven Central (el repositorio de paquetes de Java más importante), se han visto afectados por las vulnerabilidades Log4j reveladas recientemente.”

explican James Wetter y Nicky Ringland del Open Source Insights Team de Google


Según Google, la gran mayoría de los paquetes Java vulnerables en Maven Central toman prestado Log4j “indirectamente”, es decir, Log4j es una dependencia utilizada por el paquete, un concepto también conocido como dependencias transitivas.

De los 35.863 paquetes identificados por Google, solo alrededor de 7.000 tomaron prestado Log4j directamente, lo que indica que no todos los desarrolladores pueden tener una visibilidad adecuada de su software.

“La falta de visibilidad del usuario sobre sus dependencias y las dependencias transitivas ha dificultado la aplicación de parches; también ha dificultado la determinación del radio de alcance completo de esta vulnerabilidad”.

explica Google.

Al observar el historial de vulnerabilidades críticas reveladas públicamente que afectan a los paquetes de Maven, y el hecho de que menos del 48% de estos paquetes tenían una solución para estos, los investigadores de Google predicen “una larga espera, probablemente años” antes de que las fallas de Log4j se eliminen por completo de todo Java. paquetes.

FUENTE: https://blog.segu-info.com.ar/2021/12/resumen-de-todos-los-cve-de-log4j.html

Aumento en ciberataques y el daño ocasionado este 2021

Los últimos años se ha visto un número cada vez mayor de ataques cibernéticos, y aunque la frecuencia de tales ataques ha aumentado, también lo ha hecho el daño resultante. Uno solo necesita mirar La lista de incidentes cibernéticos significativos de CISA para apreciar la magnitud del problema.

En mayo de 2021, por ejemplo, un ataque de ransomware derribó el oleoducto colonial, causando una grave interrupción del combustible en gran parte de los Estados Unidos.
El mes pasado, un grupo de hackers obtuvo acceso a registros de llamadas y mensajes de texto de operadores de telecomunicaciones de todo el mundo. Estos son solo dos de las docenas de ataques cibernéticos que ocurren este año.

Debido a estos y otros incidentes de seguridad cibernética, el Departamento de Seguridad Nacional de EEUU emitió una directiva obligatoria a las agencias federales para proteger mejor los sistemas de información federales y los datos que contienen contra el ciberataque. Esta directiva se basa en Catálogo de vulnerabilidades de CISA que se sabe que representan un riesgo significativo. La directiva requiere que las entidades cubiertas actualicen sus procedimientos de seguridad cibernética y aborden las vulnerabilidades conocidas dentro de un período de tiempo específico.

Preparaciones de fin de año para CISA
El hecho de que el Gobierno Federal esté otorgando una prioridad tan alta a la seguridad cibernética es revelador, y vale la pena prestar atención a la directiva, incluso para las organizaciones del sector privado. Si las agencias federales apuntalan sus defensas cibernéticas de acuerdo con la nueva directiva, entonces al menos algunos ciberdelincuentes probablemente centrarán su atención en atacar objetivos del sector privado. Después de todo, es probable que algunas de las vulnerabilidades conocidas continúen existiendo en empresas privadas, incluso después de que esas vulnerabilidades se hayan abordado en sistemas pertenecientes al gobierno federal.

Al acercarse rápidamente el final del año, los profesionales de TI deberían poner la seguridad cibernética en la parte superior de sus resoluciones de Año Nuevo. Pero, ¿qué deberían hacer específicamente los profesionales de TI para prepararse para 2022??

CISA diferencia entre vulnerabilidades conocidas y vulnerabilidades que se sabe que han sido explotadas. Del mismo modo, los profesionales de TI en el sector privado deben centrar sus esfuerzos y sus recursos de seguridad en abordar las vulnerabilidades que se han explotado en el mundo real. Tales hazañas están bien documentadas y representan una gran amenaza para las organizaciones que no abordan tales vulnerabilidades.

Implemente parches de inmediato
Lo más importante que las organizaciones pueden hacer para garantizar que aborden las vulnerabilidades de seguridad conocidas es aplicar parches de seguridad a medida que estén disponibles. Muchos parches de seguridad están diseñados específicamente para abordar vulnerabilidades conocidas, algunas de las cuales ya han sido explotadas. Por ejemplo, La actualización de Microsoft Exchange Server abordó la vulnerabilidad de ProxyShell a principios de este año. ProxyShell fue el nombre dado a una vulnerabilidad grave de Exchange Server que permitió la ejecución remota de código. Una vez que la vulnerabilidad se hizo pública, los atacantes comenzaron a buscar activamente servidores de Exchange no enviados, a menudo instalando ransomware en los servidores que se encontraban.

No lo olvides las vacaciones pueden aumentar el riesgo de ataque cibernético de su organización, por lo que aunque puede aparecer un parche en un momento inoportuno, es importante avanzar de inmediato ya que los hackers informáticos esperan fallas en su red de seguridad en esta época del año.

Por importante que sea la administración de parches, la instalación de los parches de seguridad disponibles es solo un ejemplo de los tipos de cosas que los profesionales de TI deben hacer para abordar las vulnerabilidades de seguridad conocidas.

Evite las contraseñas incumplidas en su red
Otra contramedida que es casi tan importante pero ampliamente pasada por alto es la de evitar que los usuarios usen contraseñas que se sabe que han sido comprometidas.

Los hackers mantienen bases de datos web oscuras masivas de contraseñas que se han descifrado como parte de varias hazañas. La razón por la cual esto es un problema es porque los usuarios a menudo usan sus contraseñas de trabajo en varios sitios web para minimizar la cantidad de contraseñas que deben recordar. Si se ha descifrado una contraseña, significa que hay una tabla que coincide con esa contraseña con su hash. Esto hace posible que un atacante reconozca cuándo se ha usado esa contraseña en otro lugar. Es por eso que es tan importante evitar que los usuarios usen cualquier contraseña que se sepa que está comprometida.

Emplear políticas de contraseña. Existen bases de datos que contienen miles de millones de contraseñas comprometidas para asegurar que esas contraseñas no se utilicen en su red.

Cree políticas de contraseña basadas en los estándares establecidos por NIST, SANS y otros. El uso de estas plantillas facilita garantizar que las contraseñas utilizadas en toda su organización se adhieran a los mismos estándares NIST a los que se adhiere el gobierno federal.

FUENTE: https://thehackernews.com/2021/12/how-to-see-if-cybersecurity-of-your.html

Avanzando a la Identidad Digital – ZTNA

Hoy comenzaremos a hablaremos de ZTNA (Zero Trust Network Access), que si bien habla de un modelo de seguridad de acceso a recursos, obviamente incluye la identificación de quien accede a dichos recursos. Por lo que, lo incluimos como parte íntegra de la identidad Digital.

Pero a que nos referimos cuando hablamos de ZTNA?
Netskope, nos comenta sobre la definición del Modelo de Seguridad basado en confianza cero.

La definición de confianza cero es un modelo de seguridad basado en la premisa de que no se confía ciegamente en nadie ni se le permite acceder a los activos de la empresa hasta que se haya validado como legítimo y autorizado. Es compatible con la implementación del acceso con menos privilegios, que se designa para conceder acceso de manera selectiva única y exclusivamente a aquellos recursos que necesitan los usuarios o grupos de usuarios. Además, las personas que obtienen acceso a la red, a los datos y a otros recursos deben autenticar continuamente su identidad.

La adopción del modelo de confianza cero se ha acelerado en respuesta al rápido aumento de los trabajadores móviles y teletrabajadores, la tendencia de usar dispositivos personales (BYOD), el Shadow IT y el auge de los servicios en la nube. Mientras que estas tendencias beneficiaban a los usuarios e incorporaban nuevos niveles de flexibilidad a las tecnologías informáticas, también reducían la capacidad de la organización de controlar y proteger el acceso a los datos y los recursos de red. El modelo de confianza cero devuelve este control y endurece las medidas de seguridad ante el proceso de disolución del perímetro de la red.

Piense en su infraestructura de red y datos como si fuese un edificio lleno de habitaciones con puertas cerradas y cada cerradura con su propia llave individual, donde solo se permite a los usuarios el acceso a la habitación donde se encuentran los recursos que necesitan y nada más. Eso es la confianza cero en pocas palabras.

En las referencias, les dejo un enlace donde pueden ver un poco mas de historia, principios y hacia donde nos dirigimos con este modelo.

REFERENCIAS: (1) https://www.netskope.com/es/security-defined/what-is-zero-trust