Los ciberatacantes están explorando diversas vulnerabilidades, entre las que se destaca vulnerabilidad log4j: qué es y cómo protegerse.
Vulnerabilidad log4j: qué es y cómo protegerse
Para Martín Hoz, vicepresidente de ingeniería de Fortinet para América Latina y Caribe, hay muy pocos casos en los que una vulnerabilidad digital tiene un impacto tan severo que potencialmente puede hacer que se caigan los servicios de cualquier tipo y en todas partes.
En ese sentido, la vulnerabilidad etiquetada CVE-2021-44228 descubierta en una biblioteca de Java (un conjunto de código listo para ser utilizado, que ahorra tiempo de desarrollo) llamada Log4j, tiene este potencial.
Java es un lenguaje de programación y una plataforma que se creó con el objetivo de crear código (instrucciones para una computadora) una vez y luego ejecutar ese código en todas partes.
El concepto tuvo éxito y hoy se estima que más de 15 mil millones de dispositivos ejecutan Java: computadoras portátiles, tabletas, teléfonos celulares, robots y electrodomésticos. Esto significa que la página web de la compañía, el sistema de facturación, la nómina, los robots en la línea de producción, entre otros, pueden verse potencialmente afectados, considera el experto.
Cuáles son sus efectos y estragos
Según la unidad de investigación de Silikn, la vulnerabilidad conocida como Log4j está generando actualmente un caos en Internet, por lo que se está presentando una carrera contra el tiempo en donde los defensores intentan arreglar la falla, mientras que los cibercriminales intentan explotar sus debilidades y sustraer información.
Dicha vulnerabilidad fue aparentemente detectada el 2 de diciembre de 2021 y afecta a Apache Log4j, una biblioteca de código abierto ampliamente utilizada por los desarrolladores, cuyo objetivo es mantener un registro de actividades en diversas aplicaciones.
Aunque Apache, el fabricante de Log4j, publicó el viernes 10 de diciembre 2021 una corrección parcial de la vulnerabilidad, las empresas afectadas necesitarán tiempo para localizar el software vulnerable e implementar adecuadamente los parches.
¿Cómo funciona?
La vulnerabilidad descubierta es relevante porque puede afectar a muchos dispositivos en el mundo, pero también porque no se requieren muchos conocimientos técnicos para aprovecharla y se puede utilizar de forma remota.
En otras palabras, una persona técnica promedio podría potencialmente hacer lo que quiera con cualquier dispositivo desde una ubicación distante: cambiar instrucciones, ejecutar programas no deseados, alterar registros electrónicos, lanzar ataques adicionales o cerrar servicios.
Un atacante con mayores conocimientos podría automatizar los pasos y causar más daño. Un adversario hábil con más recursos (piense en el cibercrimen organizado) podría generar amenazas realmente dañinas con fines de lucro, como recopilar datos confidenciales de su organización y extorsionarlo (ciberextorsión) o mantener sus datos como rehenes y luego pedir un rescate (ransomware), detalla Hoz.
Cómo protegerse
Según el experto de Fortinet, la vulnerabilidad ya se solucionó y hay una actualización de software para remediarla. Pero realizar actualizaciones en todos los dispositivos afectados llevará algún tiempo. A veces, será necesario planificar períodos de mantenimiento para reducir el impacto comercial. Y el negocio no puede detenerse.
Por otra parte, la unidad de investigación de Silikn da a conocer algunas recomendaciones para mitigar esta vulnerabilidad a corto plazo para los sistemas afectados que aún no tienen actualizaciones disponibles.
Identificar la exposición
La superficie de ataque potencial es demasiado grande, por lo que se recomienda buscar la presencia de archivos JAR log4j-core — *. Jar para determinar si Log4j está en uso. La falla de seguridad (CVE 2021 44228) existe en versiones de Log4j anteriores a la 2.14.1, por lo que cualquier aplicación Java que use la versión vulnerable está en riesgo. Varias herramientas de Apache son vulnerables (Struts 2, Solr, Druid y Fink), pero el problema va mucho más allá de esa lista porque Java se usa mucho en la empresa.
El vector inicial también es difícil de detectar porque requiere buscar en los registros una cadena específica, por lo que también se recomienda revisar la entrada sin procesar al servidor Log4j y alertar sobre todas las conexiones externas LDAP, o buscar conexiones externas desde servidores de registro a archivos de clase Java. Los patrones en los campos de texto como User-Agent: /\$\{jndi:.*/ son “señales reveladoras de intentos de comprometer servidores. Las organizaciones deben identificar cuáles de sus aplicaciones están utilizando el componente vulnerable.
Una forma de hacerlo es con una herramienta de escaneo continuo. Se recomienda bloquear las aplicaciones externas que usan la biblioteca vulnerable, a menos que haya certeza de que esta vulnerabilidad no se puede explotar o se lance una versión actualizada.
Otra opción es buscar hosts que puedan ejecutar Log4j (Apache Tomcat y Struts, por ejemplo) y moverlos a un grupo para que sea más fácil monitorearlos y hacerles seguimiento.
Mitigar
Actualice a la última versión de Java, ya que evitará cargar una base de código remota usando LDAP. El mecanismo de explotación actual está bloqueado por la última versión de Java, que establece com.sun.jndi.object.trustURLCodebase en verdadero.
Si Log4j no se puede actualizar, establezca la propiedad del sistema log4j2.formatMsgNoLookups o la variable LOG4J_FORMAT_MSG_NO_LOOKUPS en verdadero al iniciar la máquina virtual Java que hace que la vulnerabilidad no sea explotable.
La opción de la línea de comandos es -Dlog4j2.formatMsgNoLookups = true. Establecer el distintivo JVM (log4j2.formatMsgNoLookups = true) en un archivo component.properties en la ruta de clase también evita búsquedas en mensajes de eventos de registro.
Apache también sugiere eliminar manualmente la clase JndiLookup del classpath (zip -q -d log4j-core — *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class) para protegerse contra la ejecución remota de código. Eliminar la clase Jndi Manager hará que JndiContextSelector y JMSAppender dejen de funcionar.
Especificar % m {nolookups} en la configuración de PatternLayout evita búsquedas en los mensajes de eventos de registro. Otra opción es que la organización controle el tráfico saliente en el perímetro y bloquee el tráfico LDAP y RMI, en la medida de lo posible.
Leíste: Vulnerabilidad log4j: qué es y cómo protegerse, te recomendamos: SHAREit: vulnerabilidades y cómo solucionarlas
Síguenos en nuestras redes sociales: