Índice del contenido[Esconder][Espectáculo]
Log4Shell, una vulnerabilidad de Internet, afectó recientemente a millones de máquinas. Log4j, una pieza de software oscura pero casi omnipresente, lo causa.
Log4j se usa para registrar todas las acciones que ocurren detrás de escena en una variedad de sistemas informáticos.
Se basa en una biblioteca de registro de código abierto que utilizan las empresas e incluso las organizaciones gubernamentales en la mayoría de las aplicaciones.
Siendo uno de los peores agujeros de seguridad cibernética jamás descubiertos, es fundamental proteger sus sistemas de esta vulnerabilidad. ¿Pero cómo?
Exploremos la vulnerabilidad de Log4j en detalle y todas las posibles soluciones para solucionarla.
¿Qué es Log4j?
Log4j es un De código abierto Marco de registro que permite a los desarrolladores de software registrar diferentes datos dentro de sus aplicaciones. Es un componente del proyecto Apache Logging Services, que es ejecutado por el Apache Software Foundation.
Cientos de sitios web y aplicaciones utilizan Log4j para realizar operaciones críticas, como el registro de datos para la depuración y otros usos.
Cuando ingresa o hace clic en un enlace en línea deficiente y recibe un aviso de error 404, este es un ejemplo frecuente de Log4j en el trabajo. El servidor web que ejecuta el dominio del enlace web al que intentó acceder le informa que dicha página web no existe. También registra el evento en Log4j para los administradores del sistema del servidor.
A lo largo de los programas de software, se emplean señales de diagnóstico similares. En el juego en línea Minecraft, por ejemplo, el servidor usa Log4j para registrar actividades como la RAM total utilizada y las instrucciones del usuario enviadas a la consola.
¿Cómo se produce la vulnerabilidad?
Las búsquedas son una nueva característica introducida en Log4j 2.0, que ayuda a incorporar información adicional en las entradas de registro. Una de estas búsquedas es la búsqueda JNDI (Java Naming and Directory Interface), que es una API de Java para comunicarse con un servicio de directorio.
Con este enfoque, los ID de usuario internos se pueden asignar a nombres de usuario reales. Esta consulta expone la vulnerabilidad RCE recién descubierta, ya que uno de los tipos de datos proporcionados por el servidor LDAP es un URI que apunta a una clase Java, que luego se carga en la memoria y se ejecuta mediante la instancia de Log4j.
Debido a una debilidad en la validación de entrada de la biblioteca Log4j, es posible inyectar un servidor LDAP arbitrario desde una fuente no confiable. Debido a que los desarrolladores asumen que los datos enviados a los registros se manejarán como texto sin formato, no se realiza ninguna validación de entrada adicional y las entradas peligrosas del usuario ingresan a los registros.
Una declaración de registro podría verse así:
Un usuario malintencionado ahora insertaría una búsqueda JNDI que hace referencia a un servidor LDAP no autorizado en un parámetro de URL. La búsqueda JNDI sería la siguiente:
La biblioteca Log4j luego habla con este servidor LDAP en attacker.com para obtener información del directorio, incluidos los valores para Java Factory y Java Codebase.
Estos dos valores incluyen la clase Java del atacante, que luego se carga en la memoria y la instancia de Log4j la ejecuta, completando la ejecución del código.
¿Quién está en riesgo?
La vulnerabilidad de Log4j es increíblemente amplia y afecta a las aplicaciones empresariales, los dispositivos integrados y sus subsistemas. Las aplicaciones afectadas incluyen Cisco Webex, Minecraft y FileZilla FTP.
Sin embargo, esto no es de ninguna manera una lista completa. La falla incluso afecta la misión del helicóptero Ingenuity Mars 2020, que usa Apache Log4j para la grabación de eventos.
La comunidad de seguridad ha compilado una lista de sistemas vulnerables. Es crucial tener en cuenta que estas listas se actualizan continuamente, por lo que si un determinado programa o sistema no aparece, no asuma que no se ve afectado.
La exposición a esta vulnerabilidad es bastante probable, e incluso si una pila de tecnología no aplica Java, los ejecutivos de seguridad deben esperar que los sistemas de proveedores críticos, los proveedores de SaaS, los proveedores de alojamiento en la nube y los proveedores de servidores web lo hagan.
¿Cómo verificar la vulnerabilidad de Log4j?
El primer paso es determinar si ya se ha producido una agresión. Puede hacerlo comprobando los registros del sistema en busca de fragmentos de carga útil de RCE.
Si una búsqueda de términos como "jndi", "ldap" o "$::" arroja algún registro, los investigadores de seguridad deben explorar más a fondo para ver si fue un ataque legítimo o simplemente una huella digital.
Se descubrieron muchos asaltos en la naturaleza que no entregaron ninguna carga dañina. No obstante, fueron realizados por expertos en seguridad para determinar cuántas aplicaciones eran vulnerables a este ataque.
El siguiente paso es usar la biblioteca Log4j para identificar todos los proyectos. Si se utilizan versiones entre 2.0-beta9 y 2.14.1, el proyecto puede ser susceptible.
Dada la dificultad para determinar dónde existe esta vulnerabilidad, puede ser preferible suponer que el proyecto es susceptible y que actualizar la biblioteca es el mejor curso de acción para eliminar el peligro de ejecución de código.
El proyecto no es vulnerable si la versión utilizada es anterior a la 2.0-beta 9, aunque la biblioteca Log4j aún debe actualizarse porque las versiones en el rango 1.x son antiguas y ya no reciben actualizaciones.
Ya sea que se descubra un proyecto susceptible, se recomienda verificarlo para ver si alguna información registrada usando Log4j contiene información que el usuario puede cambiar. Las URL, los parámetros de solicitud, los encabezados y las cookies son ejemplos de estos datos. Si uno de estos se registra, el proyecto está en peligro.
Este conocimiento puede ayudarlo a profundizar en los registros del sistema y determinar si su aplicación web ya ha sido atacada.
Existen herramientas en línea gratuitas que pueden detectar si una aplicación web es vulnerable. Uno de estos programas es Log4Shell cazadora. Es de código abierto y está disponible en GitHub.
Si se descubre un área vulnerable de código en la aplicación en línea, la carga proporcionada por la herramienta revelada se puede usar para inyectarla en la aplicación web. La herramienta de prueba revelaría las conexiones realizadas entre su aplicación web y su servidor LDAP si se explotara la vulnerabilidad.
Soluciones para corregir la vulnerabilidad de Log4j
El primer paso es actualizar Log4j, lo que puede hacer usando los administradores de paquetes normales o descargándolo directamente de este página.
También es posible disminuir la capacidad de explotación de la vulnerabilidad configurando la variable de entorno FORMAT MSG NO LOOKUPS en verdadero. Esta contramedida, sin embargo, solo se aplica a las versiones de Log4j superiores o iguales a 2.10.
Consideremos ahora opciones alternativas.
1. Soluciones alternativas para Log4j versión 2.17.0
Definitivamente, se recomienda encarecidamente utilizar Log4j versión 2.15.0 para protegerse contra Log4Shell; sin embargo, si esto no es posible, hay otras soluciones disponibles.
Versiones 2.7.0 y posteriores de Log4j: Es factible protegerse contra cualquier ataque cambiando el formato de los eventos a registrar utilizando la sintaxis de percent m nolookups para los datos proporcionados por el usuario. Esta actualización requiere editar el archivo de configuración de Log4j para generar una nueva versión del programa. Por lo tanto, antes de implementar esta nueva versión, se deben repetir las etapas de validación técnica y funcional.
Log4j versiones 2.10.0 y posteriores: También es posible protegerse contra cualquier ataque configurando el parámetro de configuración log4j2.formatMsgNoLookups en verdadero, por ejemplo, al iniciar la máquina virtual Java con la opción -Dlog4j2”. formatMsgNoLookups = true, otra opción es eliminar la clase JndiLookup del argumento classpath, lo que eliminará el vector de ataque principal (los investigadores no descartan la posibilidad de otro vector de ataque).
Amazon Web Services proporciona un parche que "debe utilizarse bajo su propio riesgo". Se han publicado otras “técnicas”, como Logout4Shell, que “utiliza esta vulnerabilidad contra sí mismo”. El experto en seguridad cuestiona la legalidad de este movimiento, que implica “hackear una máquina para arreglarlo”.
2. El problema se resolvió en Log4j v2.17.0.
Para versiones posteriores a la 2.10: Log4j2.formatMsgNoLookups debe establecerse en verdadero.
Para las versiones 2.0 a 2.10.0: ejecute el siguiente comando para eliminar la clase LDAP de Log4j.
Log4j2.formatMsgNoLookups debe establecerse en verdadero en la configuración del sistema.
Mitigación en JVM
La mitigación con parámetros de JVM ya no es una opción. Otros métodos de mitigación continúan teniendo éxito. Actualice a Log4j versión 2.17.0 si es posible. Hay una guía de migración disponible para Log4j v1.
Si no es posible realizar una actualización, asegúrese de que los componentes del lado del cliente y del lado del servidor tengan establecida la propiedad del sistema -Dlog4j2.formatMsgNoLookups = true.
Tenga en cuenta que Log4j v1 ha llegado al final de su vida útil (EOL) y ya no recibirá correcciones de errores. Otros vectores RCE también son susceptibles a Log4j v1. Por lo tanto, le recomendamos que actualice a Log4j 2.17.0 lo antes posible.
3. Medidas de mitigación
Los exploits actuales no pueden funcionar incluso si Log4j es susceptible en algunos casos, como si la máquina host ejecuta una versión de Java superior a 6u212, 7u202, 8u192 o 11.0.2.
Esto se debe a una mejor protección de carga de clase remota de Java Naming and Directory Interface (JNDI) en las versiones actuales, que es necesaria para que el ataque funcione.
Además, con las versiones de Log4j superiores a la 2.10, el problema se puede evitar configurando el valor del sistema formatMsgNoLookups en verdadero, proporcionando el argumento JVM -Dlog4j2.formatMsgNoLookups = true, o eliminando la clase JndiLookup del classpath.
Mientras tanto, hasta que se reparen las instancias vulnerables, la vulnerabilidad se puede abordar utilizando las siguientes técnicas:
- Establezca la propiedad del sistema log4j2.formatMsgNoLookups en verdadero para >=2.10.
- Establezca la opción de entorno LOG4J FORMAT MSG NO LOOKUPS en verdadero para >=2.10.
- Elimine JndiLookup.class del classpath para 2.0-beta9 a 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Una mejor práctica recomendada es limitar el tráfico de salida a Internet solo a los puertos apropiados.
Aunque la mayoría de los ataques en el campo se entregan a través de HTTP, la vulnerabilidad podría explotarse a través de cualquier protocolo que registre los datos de entrada del usuario mediante Log4j.
Sin embargo, actualizar a log4j 2.17.0 es el mejor remedio porque alguien puede descubrir un enfoque adicional al problema. Además, muchos editores y fabricantes han anunciado mejoras en sus servicios o aplicaciones.
4. Parche de vulnerabilidad de Log4Shell
Log4j es omnipresente, especialmente ahora que se está explotando la vulnerabilidad. Para resumir, todo lo que necesita hacer es incluir los siguientes caracteres en los registros inspeccionados por Log4j.
Y esto descargará y ejecutará el archivo Java ubicado al final de la URL. Es tan directo como dramático.
Como sabe, es fundamental actualizar log4j a la versión >= 2.17.0 para remediar esta vulnerabilidad de Log4Shell (CVE-2021-44228).
Si esto no es posible:
Para las aplicaciones que utilizan las versiones 4 y posteriores de la biblioteca Log2.10.0j, también es posible protegerse contra cualquier ataque estableciendo el parámetro de configuración log4j2.formatMsgNoLookups en verdadero, por ejemplo, al iniciar la máquina virtual Java con -Dlog4j2.formatMsgNoLookups = true opción.
Otra opción es eliminar la clase JndiLookup del argumento classpath, lo que eliminará el vector de ataque principal (los investigadores no descartan la existencia de otro vector de ataque).
Note
Las organizaciones que dudan o no están dispuestas a realizar ajustes en los sistemas susceptibles (o que desean instalar protecciones adicionales) deben pensar en:
- Asegúrese de que todo el tráfico se enruta a través de un iSensor/WAF/IPS. Esto puede evitar que el asalto obtenga acceso al sistema.
- Limitación de la cantidad de tráfico que puede llegar al sistema susceptible Si el sistema no necesita estar conectado a Internet, restrinja el acceso solo a IPS y rangos esenciales y confiables.
- Reducir el tráfico saliente autorizado del host. Debido a que este ataque opera al conectarse a un servidor no autorizado, todas las direcciones IP y puertos superfluos deben bloquearse en un firewall.
- Si el servicio ya no es necesario, debe deshabilitarse hasta que esté lista una solución.
Conclusión
Las fallas de Log4j sorprendieron a nuestra comunidad y nos recordaron cuán dependientes somos del software de código abierto.
Log4j es único. No es un sistema operativo, ni es un navegador, ni es un software. Más bien, es lo que los programadores denominan biblioteca, paquete o módulo de código. Solo tiene un propósito, es decir, mantener un registro de lo que sucede en un servidor.
Las personas que escriben código prefieren concentrarse en lo que hace que su software sea distintivo. No les interesa reinventar la rueda. Como resultado, se basan en una gran cantidad de bibliotecas de códigos existentes, como Log4j.
El módulo Log4j se deriva de Apache, el software de servidor web más utilizado. Es por eso que se puede descubrir en millones de servidores. Por lo tanto, el aumento de las amenazas de seguridad.
Espero que las soluciones anteriores lo ayuden a mantener sus dispositivos seguros.
Estén atentos a HashDork para obtener más información útil del mundo de la tecnología.
Deje un comentario