El caso de la autoprotección de aplicaciones en tiempo de ejecución (RASP) es que, si bien los firewalls de aplicaciones web (WAF) son una buena solución para algunos casos de uso, no son excelentes para ataques como el tipo que estamos viendo con Log4Shell. Como revisión rápida, RASP ayuda a proteger las aplicaciones al instrumentar la aplicación en tiempo de ejecución, lo que permite un contexto profundo e inteligencia sobre cómo funciona la aplicación para una mejor detección y bloqueo de ataques. Un WAF generalmente vive en el perímetro de la red y monitorea el tráfico HTTP en busca de ataques basados en las firmas proporcionadas. Ahora, profundicemos en el caso de RASP para combatir Log4Shell.
Por qué los WAF no son una solución
Hay tres razones principales por las que los WAF no nos ayudarán mucho aquí.
#1. Los WAF solo pueden firmar, y esta carga útil es bastante polimórfica.
Twitter es activo Varios codificaciones del ataque para eludir los WAF. La comunidad se dio cuenta al instante de que es bastante difícil firmar. He aquí un ejemplo llamativo:
Incluso si hay una manera de firmar el ataque, será atrapar irremediablemente tráfico legítimo e interrumpir su sistema. Esta es la razón por la que creemos que, como máximo, los WAF ayudan con la visibilidad con los atacantes poco calificados, pero no brindan una protección real.
#2.WAF no ven los elementos fuera de banda del ataque.
Uno de los elementos de este ataque que se pasa por alto es el hecho de que el exploit implica engañar a la aplicación para que se comunique con otro servicio (DNS, LDAP, RMI, CORBA) - y ninguna de estas transacciones de salida pasará por WAF.
Por lo tanto, el WAF no puede conocer el éxito del exploit. - el WAF solo te dice si los script kiddies te están golpeando con ataques de vainilla. Y sabes que la respuesta a eso es "sí" incluso antes de tener el WAF - entonces… ¿para qué estamos haciendo esto otra vez?
#3. El mundo ya no es solo HTTP.
Un porcentaje cada vez más grande de nuestro código es asincrónico, impulsado por eventos, desencadenado por colas de mensajes, serializado con protobuf, etc. Este error puede desencadenarse arbitrariamente en lo más profundo de la empresa a través de caminos ridículamente tortuosos.
Internamente, vimos una cadena en la que la aplicación de un cliente fue atacada con una carga simple de Log4Shell, y luego los datos de la carga útil se capturaron como un análisis en nuestro agente, que se envió a nuestro servidor de ingesta de agentes, que registró algunos datos, que a su vez fueron ingeridos. por nuestro agregador de registros, que terminó canalizado a un canal de Slack. Es un pensamiento vertiginoso que todos estos lugares tengan que ser endurecidos contra ataques. Simplemente no hay escasez de formas en que una pequeña cadena puede llegar a su empresa y luego propagarse a muchos sistemas en ella.
No podemos poner una cámara de seguridad cerca de la puerta principal de un estadio de fútbol y declarar que estamos protegiendo a todos los fanáticos que están adentro.
Proteja sus aplicaciones
Equipar sus aplicaciones con protección en el interior ayudará a protegerse contra Log4Shell ahora y ataques similares inevitables en el futuro. Aprende más de Seguridad de contraste.
Sobre la autora
Arshan Dabirsiaghi es un consumado investigador de seguridad con más de 10 años de experiencia asesorando a grandes organizaciones sobre seguridad de aplicaciones. Arshan ha lanzado herramientas de seguridad de aplicaciones populares, incluidas AntiSamy y JavaSnoop.
- Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
- Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
- CriptoHawk. Radar de altcoins. Prueba gratis.
- Fuente: https://www.darkreading.com/application-security/log4shell-makes-the-case-for-runtime-application-self-protection
