Proteger aplicaciones web con solo un proxy inverso

Según mi entendimiento, creo que ni siquiera necesitas entrar en la red interna para demostrar que es una idea terrible. Un atacante (que puede ser un ex empleado, un contratista externo o un empleado descontento existente) que tenga algún contexto sobre esta aplicación interna insegura, incluidos detalles como dirección interna del host donde se aloja la aplicación, < em> funcionalidades importantes de la aplicación, algunos conocimientos de aspecto general de la aplicación (esto obviamente ayudará a crear un sitio web de phising), y por supuesto, el hecho de que la aplicación es vulnerable a problemas comunes de aplicaciones web (especialmente falsificación de solicitudes entre sitios ).

Está bien. Sobre la base de las suposiciones anteriores, puedo pensar en los siguientes ataques posibles:

• Engañar a un usuario interno para hacer una solicitud de cambio de estado a la aplicación mediante la explotación de una vulnerabilidad CSRF . Esto se puede usar para explotar otras vulnerabilidades comunes en la aplicación engañando a un usuario autenticado para que visite su sitio web, donde su JavaScript estará esperando para realizar solicitudes a la aplicación con su carga útil , pero con < em> cookies de sesión de la víctima . Puede enviar cargas útiles de inyección para inyección de comando, inyección de SQL, XSS, etc. Dado que conoce su superficie de ataque, puede diseñar las solicitudes en consecuencia.

• Explotación de una implementación JSONP o CORS mal configurada en la aplicación . Nuevamente, para esto, utilizará la vulnerabilidad CSRF para realizar una solicitud a la aplicación interna con sus cookies de sesión. Pero esta vez, en lugar de realizar una solicitud de cambio de estado, su JavaScript malicioso leerá la respuesta confidencial de la aplicación (debido a JSONP y CORS). Puede leer más sobre esto aquí , here y aquí .

• Usuarios internos de phishing (a través de envenenamiento de caché de DNS, tal vez) . Ahora que ya sabe cómo se ve la aplicación intenal, puede crear un sitio web de suplantación de identidad (phishing) o simplemente la página de inicio de sesión de la aplicación y hospedarla en una dirección pública. Luego, puede envenenar el caché de DNS del servidor DNS de la empresa dentro de la red, o simplemente modificando el archivo de hosts de los sistemas internos (tal vez engañándolos para que descarguen un malware). Este último paso es un poco difícil de explotar desde fuera de la red, pero espero que se haga una idea. Más detalles sobre el envenenamiento de la memoria caché del DNS en caso de que esté interesado en leer más: DNS y envenenamiento de la caché de DNS . Una vez que haya configurado esto, no hay nada que le impida realizar una suplantación de identidad a los usuarios internos porque la aplicación no está sobre TLS (sin autenticación)!

Un usuario interno con un navegador que también se conecta al exterior proporciona rutas entre la intranet y la Internet pública. Constantemente estoy señalando esto a las personas que me dicen "no se preocupe, esta es una aplicación web interna".

HTTPS es necesario en su caso. Esto no solo protege contra la amenaza que usted menciona, alguien que ha irrumpido en la red, sino también contra intrusos malintencionados que no necesitan ingresar. Además de exponer los datos confidenciales en sí, sin https estaría exponiendo las credenciales en texto claro, credenciales que podría proporcionar aún más acceso a los recursos internos. El problema empeora si la conexión inalámbrica está en uso interno.

Parece que los usuarios internos de estas aplicaciones web no tendrían ningún control de acceso. Creo que el control de acceso debe estar integrado en las aplicaciones.

Si desean facilitar la depuración, tenga un entorno de prueba con los controles de seguridad desactivados.

Nuestro proxy inverso (libra) proporciona una característica de seguridad realmente buena: actúa como un intermediario entre los clientes externos y nuestros recursos web. Esto nos permite utilizarlo para establecer la política de acceso. Esta es una de sus capas de protección para las aplicaciones web internas sensibles que desea proteger, pero no creo que deba ser la única capa.

Así es como abordamos tu situación en general.

Habla con la empresa

Hay tres cosas con las que creo que los clientes realmente pueden relacionarse cuando hablan sobre la seguridad de sus aplicaciones. (el 90% del tiempo los usuarios son una nota al pie de página) .

1. IP (propiedad intelectual). Ningún cliente quiere que sus secretos estén disponibles para su competencia.
2. imagen. Se puede motivar amablemente a las empresas a adoptar mejores medidas de seguridad si la reputación y la imagen están en juego. Esto puede ser especialmente cierto si su cliente se encuentra en un entorno altamente competitivo donde una infracción podría enviar a los usuarios a la competencia.
3. dinero. Nada motiva a una empresa a actuar más que la amenaza de perder dinero. En seguridad, es el tiempo y el gasto de contratar ayuda externa adicional y, en situaciones de cumplimiento, son las multas las que se suman.

Habla con el equipo

En el mundo de la seguridad, el riesgo es el juego que jugamos y nuestro trabajo es convencer a las empresas para que se adapten. Desde un punto de vista técnico, en el equipo de seguridad consideramos este tipo de escenario como "ESTO ES TAL COSA BÁSICA". Desde la perspectiva de las empresas, su pensamiento es "¿Cuál es la posibilidad REAL de que me comprometan?"

Obviamente, no conozco a su cliente ni a su red, pero aquí están los conceptos básicos sobre cómo debería comenzar (un intento de no sonar crítico al hacer preguntas):

• ¿Cuál es su "red segura como"? ¿Hacen las mejores prácticas? ¿Las cosas se mantienen al día?
• ¿Por qué no quieren aplicar la seguridad? ¿Base de conocimientos? ¿Dinero? En su caso de depuración.
• ¿Se puede resolver su razón para no hacer algo de una manera más segura? La depuración en un entorno de prueba viene a la mente.

Por último, habla en ese nivel

¿La pequeña empresa no es una corporación mediana que no es una gran corporación que no es un Fortune 500? Hay deseos, necesidades y capacidades en todos los niveles y si tuviera que decirle a un cliente que necesita otros 50K en dispositivos de seguridad, tendría un negocio muy reacio para trabajar.

Las tres cosas en las que me concentraría:

• Habla con su industria. Saber cómo la industria médica hace algo es bueno, pero si trabajan en controles industriales, no les importa.
• Speck en su margen de beneficio. Esto se remonta a mis declaraciones anteriores sobre el tamaño de una empresa. Una hamburguesa King no tiene los recursos de Apple.
• Habla sobre sus experiencias. Si su industria o competencia ha tenido un incumplimiento, hable con él. Por lo general, sabrán (se corre la voz), si no han escuchado, refuerza los conceptos que pueden y probablemente están siendo identificados.

Sé que esto no habla exactamente del problema de proxy en cuestión, pero no puedo ser específico en una situación detallada del cliente sin saber sobre el cliente.

Yo personalmente haría 3 cosas en esta situación:

1. Mostrar al cliente los datos sobre el porcentaje de infracciones importantes que son el resultado de la suplantación de identidad (algo así como 95-97%)

2. Además, muestre que el phishing puede llevar directamente a un atacante a rastrear el tráfico en la red y puede ver cada bit de los datos que pasan hacia y desde esos servicios.

3. Identifique la cantidad y calidad de los datos que pasan estos servicios web y preséntelos al cliente junto con un modelo de riesgo que intente cuantificar el costo potencial en relación con el tráfico de rastreo del tiempo del atacante.

Esto se relaciona principalmente con la falta de SSL, pero dada su situación, parece ser el problema más urgente.

Buena suerte con tus esfuerzos. Entiendo lo difícil que es enfatizar la seguridad para un cliente reacio. Sin embargo, siempre debe tener en cuenta que su trabajo es aumentar el valor comercial, mostrarles cómo puede hacerlo y comenzarán a ver su perspectiva.

Los ataques cibernéticos más comunes se resumen muy bien en el informe anual de incumplimiento de Verizon: enlace

Como se puede leer aquí, los ataques de phishing y robo de credenciales son dos de las amenazas más comunes. Por lo tanto, si un sistema interno se ve comprometido por alguien que accidentalmente hace clic en un enlace malicioso, un atacante ahora está dentro de la red, posiblemente puede ver todo el tráfico no TLS en la subred de ese sistema. Luego, ese atacante puede capturar las credenciales y acceder al servidor web internamente sin necesidad de utilizar el proxy inverso.

Además, si las personas reutilizan las credenciales (comunes), es posible que no sepan que sus contraseñas se envían de forma clara. Un atacante podría usar esas credenciales en los sistemas OTROS , quizás con éxito en algunos casos. Esto no solo abre el negocio a posibles incumplimientos, sino también a la responsabilidad si se descubre esto (no soy un abogado; consulte con el abogado corporativo y / o las compañías de seguros).

Espero que esto ayude a hacer su caso.

Eventualmente habrá un caso en el que una acción que esté perfectamente autorizada en el nivel de proxy podrá causar un comportamiento inesperado en un componente de back-end. Es una cuestión de cuándo , no si . Esta es una idea terrible. Tus instintos sobre esto son correctos. Haga todo lo que pueda para convencer a su cliente de que no debe continuar por este camino.