Evaluaciones de las aplicaciones web

Este ABC de reconocimiento en evaluaciones de seguridad de aplicaciones web antes de realizar un ataque (sqli, xss, lfi) es algo que no veo en los cursos de Pentester, Hacking Ético comunes y definitivamente muy poco en los proyectos.

Creo que es porque ahora la mayoría se limita a “tirar” de herramientas cada vez más.

En este artículo les comento un poco mi forma de hacerlo y de muchos otros (antaño), para tomar verdaderamente el rol de un atacante o adversario es necesario actuar como tal, definitivamente hacer uso de un escáner es de lo último.

¿Que es MITRE ATT&CK Navigator? y como podemos usarlo

Instituciones/Instructores ¿Formar profesionales reales en ciberseguridad o script kiddies profesionales?

Recordemos que: los shinobis (ninjas) podían pasar días, semanas, incluso años en reconocimiento e ideando una estrategia de ataque, con un único propósito: Misión exitosa, es lo mismo en una simulación de Adversarios y la base de todo, es el reconocimiento, además la que más tiempo lleva.

No hablo del Fingerprinting, Enumeration, etc. por eso es lo que se muestra en todos lados. Daré una visión general de cómo se comporta un Adversario ante una aplicación. Whois, DIG, DNS, reconocimiento de HOSTS se da por hecho.

La Ciberseguridad en México ya es un tema de todos los días.

El ABC de evaluación de seguridad en las aplicaciones

• Proffiling phase (fase de perfilamiento)
• Attack surface analysis (análisis de la superficie de ataque)
• Input/test Validation – NOT ATTACK (Validación de entrada)

1. Proffiling phase (fase de perfilamiento)
   Aquí es cuando le pones un nombre, descripción y complejidad al proyecto.

   Consiste en un análisis de profundo que se realiza al objetivo u objetivos de forma manual. El objetivo es recabar toda la información posible.

   ¿Quién es tu Adversario en ciberseguridad?

   Por ejemplo: servidor en ejecución, framework utilizado, tipo de software de aplicación, sistema operativo, librerías de terceros).

   Passive proffiling: Navegar por el target, conocer su lógica (del programador y de la aplicación), entender el flujo de los datos como usuario común.

   Active proffiling: Es un camino más arriesgado, comienzas a ser un usuario con un comportamiento extraño, tipo tester (que no es un security tester) de aplicación, por lo que puede generar alertas y mensajes de error o de algún otro tipo. También son útiles

   En esta etapa, con el tiempo Incluso podrás detectar honeypots

   ¿Ya lo tienes?, ve al siguiente paso

2.- Attack surface analysis

Quizás esta sea la fase más interesante, al menos para mí, por qué es el punto en donde te metes en la lógica del administrador/programador/arquitecto/diseñador de la aplicación o arquitectura sin información previa. Algunas preguntas que deberás hacerte son:

• ¿Qué tipo de validaciones existen?
• ¿Por qué utilizo este componente?
• ¿Qué tipo de conexiones tiene la aplicación (db, Webservices, accesos remotos)?
• ¿Cuál es el backend al que te enfrentas?
• ¿Cuál es la lógica del negocio?

Consiste en diseñar una estrategia de ataque (en nuestro caso evaluación), y debe realizarse para cualquier objetivo.

Esta estrategia se puede realizar en evaluaciones de tipo Blackbox, Greybox o Whitebox. Si tienes la oportunidad de echarle un ojo a la arquitectura, diseño de la aplicación o infraestructura (comúnmente en pruebas de tipo greybox), perfecto, tan solo no olvides que debes analizar desde la perspectiva de un atacante.

¿Como armar la estrategia?

Aquí te dejamos un listado básico… mientras vayas avanzando crecerá tu lista.

• Identificar todos los formularios web
• Identificar HEADERS enviados y recibidos
• ¿Qué métodos HTTP soportados por la aplicación?
• ¿La aplicación fue hecha para funcionar en un navegador en particular?
• Estudia las sesiones (principalmente headers y cookies)
• Identifica y estudia las cookies generadas en la aplicación. Sobre todo, las que se generan
• una vez logeado en la aplicación
• Busca, encuentra y analiza APIs/Webservices
• Base de datos utilizada
• Identifica módulos de manejo de archivos: descarga y subida
• Correos electrónicos, nombres de contacto
• Variables o parámetros que se pasean por la URL en métodos POST y GET (clasifícalos)
• Puntos de almacenamiento: Cache, archivos temporales (local), archivos temporales (servidor)
  ¿Servicios públicos?

Reglas de ORO:

Programador/Defensor: NO CONFIES EN EL USUARIO, válida todo lo que venga del lado del usuario

PT/Tester: IDENTIFICA y PRUEBA TODOS LOS PUNTOS DE ENTRADA

3.- Input/test Validation – NOT ATTACK (Validación de entrada)

Ahora que tienes información puedes comenzar a realizar pruebas de entrada y de salida.
Sugerencia: prueba todo, comienza manualmente, después utiliza scripts semi automatizados y si no hay mecanismos de seguridad o sospechas que algo está deteniendo o proporcionando información falsa (¡con ese del Threat Deception, ya no se sabe).

Identifica todos los errores que puedes, sin ser intrusivo.

go to basic, sé que suena trillado, ¡Pero hombre, es lo básico! aunque no quieras.

Debes Hacer uso de las propias utilerías (bondades) que nos proporcionan los sistemas operativos (Windows-linux). No siempre se tiene una distribución de “pentester/hacker/ya saben quién” a la mano, no todas las instituciones permiten conectar este tipo de sistemas en su red. En algunos casos si se toman en serio la seguridad y cuando se detectan sistemas operativos no permitidos o que no cumplen con las políticas de la institución, simplemente no tendrás acceso a la red. Pentester millenial, ¿Qué harías?

Por lo tanto, acostúmbrate a utilizar al menos algunas de las siguientes opciones:

• Curl
• Netcat
• Wget
• Telnet
• Invoke-WebRequest
• GnuWin32

BONUS

Sabías que: herramientas como NMAP, SQLMAP por default envían un User-Agent que los delata y facilita la detección o el bloqueo de estas herramientas a nivel de código o por cualquier tecnología de seguridad de tipo firewall, IPS/IDS, SIEM, Threat Intelligence, etc. claro siempre y cuando estas se configuren de forma adecuada.

User-Agent por default de NMAP

/Users/marco/Documents/Natasec/Armada/Articulo 1/Default-HeaderSQLmap.png

User-Agent por default de SQLMap

/Users/marco/Documents/Natasec/Armada/Articulo 1/Default-HeaderSQLmap.png

User-Agent, de CURL

/Users/marco/Documents/Natasec/Armada/Articulo 1/Curl-RecongHTTP.png

Por cierto, es muy probable que puedas modificar el User-Agent de mayoría de las herramientas que hoy en día utilizas.

¿Como defenderse contra este ABC?

Registrar y monitorea la actividad de los usuarios.
Configurar las bitácoras de servicios o aplicaciones, principalmente Web, SSH, FTP, RDP, DB, historial de comandos.
Crear reglas para el bloque de las utilerías más conocidas/usadas para la detección de vulnerabilidades.
Habilita la bandera httpOnly, eso evitará que la cookie sea revelada a terceras partes, por ejemplo, en un ataque de tipo XSS que intenta robar las credenciales del usuario, debido a que la cookie no puede ser accedida por el cliente.

Habilitar la bandera secure.
Personalizar los códigos de Error http.
Quitar los comentarios de programadores del código que se muestra del lado del usuario, no solamente en el código HTML, en todo el código que se puede ver del lado del cliente.
Procurar que la conexión hacía DB, Webservices o integraciones se realicen a través de TLS o canales seguros.

Procurar, borrar los metadatos de todos los archivos publicados en internet, principalmente documentos PDF, Imágenes y archivos de ofimática.

Por ningún motivo dejes habilitado los directorios del servidor web.

Procurar mantener actualizados todos los componentes de tu aplicación, servicios e instalados todos los parches de seguridad.

Implementa un honeypot y si te lo puedes permitir alguna tecnología de tipo Threat Deception.

Ejecuta escaneos periódicos de seguridad, al menos una vez al mes. Esto te ayudara a tener visibilidad al menos de las vulnerabilidades más fáciles de explotar. Generalmente identificadas como de riesgo “alto, crítico”. Así podrás comenzar a preparar el camino para la implementación de un proceso de administración de vulnerabilidades.

Realizar simulaciones de adversarios sorpresa, cada vez vemos más solicitudes de pruebas de penetración del tipo: Ejecutar un pentest a estas 5, 10, 50 ip’s… eso no es un pentest, eso es una auditoría, un análisis de vulnerabilidades.

Finalmente, el cumplimiento de estándares internaciones. Pasar un cumplimiento no es seguridad. Si tu seguridad es robusta, pasarás cualquier cumplimiento. De otro modo tecnología/procesos/gente puestos ahí solo por el cumplimiento.

Serán evadidos, ¿por quién? Por el siguiente Adversario

Es nuestro deber reducir el GAP de comunicación entre Equipo de desarrollo , seguridad y negocio.

Información adicional.

OWASP Testing Guide (https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet)

RFC es

https://www.rfc-es.org/

La Armada

armada.natasec.com

Disclaimer

El contenido mostrado en este artículo y en todos los anteriores expresa únicamente mi opinión personal y no representa la opinión de Natasec o de alguna otra institución/proyecto/empresa en la que este colaborando.

Recuerda: La fase más importante de toda misión, es el reconocimiento.