El panorama de la ciberseguridad se ha vuelto mucho más dinámico en la última década. Los atacantes son cada vez más sofisticados y recurren a técnicas complejas para infiltrar sistemas y robar datos sensibles. Mientras los equipos de defensa adquieren una variedad más amplia de productos, como escáneres de vulnerabilidades, la naturaleza personalizada de las aplicaciones hace que detener la explotación sea difícil sin una identificación adecuada.
En este artículo, exploramos ejemplos de cómo las pruebas manuales pueden emular métodos de ataque complejos comúnmente utilizados por atacantes sofisticados. Los ejemplos muestran vulnerabilidades que podrían haber permitido a un atacante ejecutar comandos y código en sistemas para obtener control de cuentas en aplicaciones web y que podrían haber causado daños financieros y reputacionales si no se hubieran identificado para su remediación a través de nuestras pruebas.
Encontrar vulnerabilidades de alta severidad utilizando el Análisis de Cadena de Ataque
Una de las formas en que las pruebas y análisis manuales superan a los escaneos automatizados es la capacidad de vincular diversas vulnerabilidades, algunas de las cuales no aparecerían en los resultados típicos de los escáneres de vulnerabilidades de aplicaciones web.
Ejecución de Código en la App Móvil de una Compañía de Energía
Una cadena de vulnerabilidades se encontró en una aplicación móvil para una compañía de energía. El pentester descubrió una función que permitía la carga de archivos con extensiones ejecutables y contenido como archivos Active Server Page Extended (ASPX) o Windows Executable (EXE). El pentester evadió los chequeos típicos utilizando solo la extensión del archivo (por ejemplo, “aspx”) como el nombre del archivo enviado, mostrando la ingeniosidad típica de nuestros pentesters.
Los escáneres de vulnerabilidades de aplicaciones pueden haber pasado por alto esta vulnerabilidad debido al caso de prueba único necesario para descubrirla. Típicamente, los escáneres de vulnerabilidades de aplicaciones probarían las vulnerabilidades de carga de archivos en el nombre del archivo enviado observando la respuesta de la aplicación a una presentación del nombre base del archivo (por ejemplo, “archivo1”) y la extensión del archivo (por ejemplo, “aspx”). El caso de prueba de enviar solo la extensión del archivo no es un caso de prueba típico y generalmente sería pasado por alto por la mayoría de los escáneres de vulnerabilidades.
El pentester luego encadenó esto con una vulnerabilidad de traversal de directorios para poder ejecutar código en el servidor web en funcionamiento. Tal vulnerabilidad también habría sido pasada por alto por un escáner de vulnerabilidades de aplicaciones web ya que la vulnerabilidad solo surgiría al realizar múltiples pasos en una secuencia particular: cargar un archivo, intentar cambiar dónde se cargó en el sistema de archivos y luego intentar acceder a él. Sin la comprensión contextual a través de pruebas manuales y la exploración de la funcionalidad de carga y acceso de archivos, esta cadena de vulnerabilidades no habría sido encontrada.
Ejecución de Comandos en la Aplicación Web de un Cliente Automotriz
Otro ejemplo para un cliente en el sector automotriz encontró una vulnerabilidad similar de carga de archivos. En este caso, las pruebas manuales encontraron que había un mensaje de error que divulgaba más información de la necesaria. Mientras que los escaneos automatizados habrían tratado ese problema como una vulnerabilidad de severidad “baja” o “informativa”, el pentester pudo usar la vulnerabilidad para identificar la ubicación donde se subió el archivo leyendo el código revelado, que estaba dentro del mensaje de error.
Con esa información, el pentester encontró una función que podía llamar, que eventualmente revelaría la ubicación del archivo cargado. Al acceder a un archivo creado que se subió, el pentester demostró que un atacante podría ejecutar cualquier código de su elección.
Deteniendo ataques de manipulación que permiten la toma de cuentas
Una vulnerabilidad o una serie de vulnerabilidades pueden llevar a la toma de cuentas, lo que proporciona a los atacantes acceso completo a una cuenta de usuario elegida y todos sus privilegios. Una forma sencilla para que los atacantes lo hagan es a través del credential stuffing, que utiliza scripts automatizados para adivinar los pares de nombre de usuario y contraseña (típicamente de contraseñas filtradas de una brecha de datos en otro sitio). La implementación de autenticación de dos factores en muchos de los sistemas de nuestros clientes ha reducido el riesgo de tales ataques de credential stuffing. Sin embargo, hemos identificado varios casos donde estas implementaciones de autenticación de dos factores están mal implementadas o configuradas y, por lo tanto, pueden ser evadidas.
Evadir la Autenticación de Segundo Factor
En nuestra prueba de una aplicación web de una firma de inversiones, nuestro pentester evadió una implementación de autenticación de dos factores como parte de nuestros casos de prueba realizados para verificar la eficacia de la función de autenticación multifactor.
Durante la prueba, nuestro pentester identificó el campo de correo electrónico enviado durante el proceso de autenticación de dos factores como un vector para la toma de cuentas. Se observó durante la prueba que una solicitud HTTP enviada contenía un parámetro de dirección de correo electrónico (ver captura de pantalla a continuación). Por diseño, la dirección de correo electrónico sería la dirección de correo electrónico del usuario válido. Sin embargo, el pentester observó que cambiar esta dirección de correo electrónico por la suya propia (simulando lo que haría un atacante) llevaría a la aplicación a enviar el código de autenticación de dos factores a su dirección de correo electrónico.
Los escáneres de vulnerabilidades de aplicaciones web típicos no podrían detectar esta vulnerabilidad debido a la necesidad de (1) tener acceso a un sistema de correo electrónico en funcionamiento y (2) comprender la lógica del mecanismo de autenticación de dos factores para identificar que la dirección de correo electrónico no debería usarse o solicitarse en este paso. La identificación y remediación de esta vulnerabilidad redujo el riesgo de toma de cuentas al eliminar este vector de la aplicación.
Para algunos de nuestros clientes que no tienen autenticación de dos factores, nuestros pentesters han encontrado métodos para evadir el requisito de autenticación por completo y tomar el control de la cuenta de otros usuarios. A continuación se proporciona una breve descripción de dos tales evasiones, una para un cliente en el sector Fintech y otra en el sector de energía.
Toma de Cuentas a través de Registro Sobrescrito
En el caso de una compañía Fintech, nuestro pentester descubrió una vulnerabilidad que permitiría a un actor malicioso tomar control de una cuenta. El pentester demostró que un atacante podría realizar un registro usando el mismo identificador que un usuario existente.
Las siguientes observaciones fueron hechas por el pentester durante la prueba de penetración de la aplicación:
- Durante el proceso de registro, la aplicación asignaba un nuevo identificador de registro para cada nuevo registro.
- Este identificador de registro podía cambiarse cuando se enviaba desde el navegador web.
- La aplicación aceptaba el identificador de registro cambiado y fusionaba la información de los dos registros juntos. Un atacante podría usar esto para crear un registro asociado con su propia dirección de correo electrónico.
- Había una verificación hecha por la aplicación para rechazar registros con el mismo número de teléfono móvil. Esta verificación podía abusarse para determinar si un número de teléfono móvil era válido.
- No había límites en el número de envíos (técnicamente una falta de limitación de tasa en las solicitudes HTTP y llamadas API) en cada etapa del proceso de registro.
El pentester pudo reunir múltiples prácticas de seguridad deficientes y vulnerabilidades para demostrar una falla crítica de toma de cuentas:
- El sistema no tenía restricciones sobre la tasa a la que se podían hacer intentos para determinar números de teléfono válidos, lo que facilitaba a un atacante identificar números válidos a través de múltiples intentos.
- La aplicación revelaba el identificador de registro a los usuarios innecesariamente.
- La aplicación no realizaba ninguna verificación o validación si el identificador de registro ya estaba en uso antes de crear el usuario.
- La base de datos no establecía el identificador de registro como una clave única en las tablas de la base de datos relevantes, por lo que era posible la creación de múltiples registros con el mismo identificador.
Toma de Cuentas a través de Parámetro Manipulado
En otro caso de toma de cuentas, el pentester observó que había un parámetro dentro de las solicitudes interceptadas que contenía el campo del nombre de usuario durante el proceso de inicio de sesión. Al cambiar selectivamente el parámetro al de otro usuario para algunas de las solicitudes, el pentester demostró que un atacante podría obtener acceso a una cuenta de mayores privilegios. Nuestro pentester de Bitdefender pudo hacer esto debido a sus experiencias previas con varias implementaciones de Single Sign-On y su capacidad para comprender qué solicitudes modificar y cuáles no.
Conclusión
Los ejemplos descritos anteriormente resaltan algunas de las debilidades de seguridad que pueden identificarse a través de pruebas de seguridad ofensivas. Los productos de defensa tradicionales, como los Web Application Firewalls, a menudo no pueden detener ataques intrincados que explotan tales debilidades, lo que subraya la importancia de realizar pruebas de seguridad ofensivas de manera integral. Además de descubrir vulnerabilidades ocultas para su remediación, las pruebas de seguridad ofensivas también demuestran diligencia debida a través de esfuerzos proactivos de seguridad y apoyan los esfuerzos de cumplimiento, como ISO 27001, SOC 2 Tipo 2, GDPR, PCI-DSS y HIPAA.
Adoptar una estrategia de ciberseguridad ofensiva no es solo una opción, sino una necesidad para las empresas y los líderes de TI que buscan mantenerse un paso adelante de los adversarios sofisticados. Por lo tanto, integrar medidas ofensivas es crucial para construir una defensa robusta y dinámica capaz de frustrar incluso las amenazas cibernéticas más avanzadas.
Fuente: Blog de Bitdefender
Autor: Joseph Zeng