El panorama de la ciberseguridad se ha convertido en un campo 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 infiltrarse en los sistemas y robar datos confidenciales. Si bien los equipos defensivos compran una variedad más amplia de productos para tratar de detener el flujo de fallas de seguridad, incluidos escáneres de vulnerabilidades, la naturaleza personalizada de las aplicaciones dificulta detener la explotación 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 llevado a que un atacante obtuviera la capacidad de ejecutar comandos y códigos en sistemas para obtener el control de cuentas en aplicaciones web y podrían haber causado daños financieros y de reputación si no se hubieran identificado para su reparación mediante nuestras pruebas.

Encontrar vulnerabilidades de alta gravedad mediante el análisis de la cadena de ataques

Una de las formas en que las pruebas y el análisis manuales superan a los del escaneo automatizado es la capacidad de vincular varias 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 para la aplicación móvil de la empresa de energía

Una de esas cadenas de vulnerabilidades se encontró en una aplicación móvil de una empresa de energía. El evaluador descubrió una función que permitía cargar archivos con extensiones ejecutables y contenido como archivos Active Server Page Extended (ASPX) o archivos ejecutables de Windows (EXE). El evaluador eludió las comprobaciones típicas utilizando solo la extensión del archivo (por ejemplo, “aspx”) como nombre del archivo enviado, lo que demuestra el ingenio típico de nuestros evaluadores.

 

Carga exitosa de un archivo ASPX, que no estaba previsto que se permitiera.

Es posible que los escáneres de vulnerabilidades de aplicaciones hayan pasado por alto esta vulnerabilidad debido al caso de prueba único necesario para descubrirla. Normalmente, 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 al enviar tanto el nombre base del archivo (por ejemplo, "archivo1") como 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, por lo general, la mayoría de los escáneres de vulnerabilidades lo pasarían por alto.

 

La lista de vulnerabilidades encontradas por el escáner no tiene la vulnerabilidad mencionada anteriormente.

Luego, el evaluador se encadena a esto con una vulnerabilidad de recorrido de ruta para poder ejecutar código en el servidor web en ejecución. Un escáner de vulnerabilidades de aplicaciones web habría pasado por alto tal vulnerabilidad y la vulnerabilidad solo saldría a la luz al realizar múltiples pasos en una secuencia particular: cargar un archivo, intentar cambiar el lugar donde se cargó en el sistema de archivos y luego intentar acceder. él. Sin la comprensión contextual mediante la prueba y exploración manual de la funcionalidad de carga y acceso a archivos, no se habría encontrado esta cadena de vulnerabilidad.

 

La carga fuera de la carpeta deseada se podría realizar a través de una vulnerabilidad de recorrido de ruta.

 

Ejecución de comandos para la aplicación web del cliente automotriz

Otro ejemplo para un cliente del sector automotriz encontró una vulnerabilidad de carga de archivos similar. En este caso, las pruebas manuales encontraron que había un mensaje de error que revelaba más información de la requerida. Si bien los análisis automatizados habrían tratado ese problema como una vulnerabilidad de gravedad "baja" o "informativa", el evaluador pudo utilizar la vulnerabilidad para identificar la ubicación donde se cargó el archivo leyendo el código revelado, que estaba dentro del error. mensaje.

 

 

El mensaje de error revela la ubicación de una página que contiene el código fuente.

Con esa información, el evaluador encontró una función a la que podía llamar y que eventualmente revelaría la ubicación del archivo cargado. Al acceder a un archivo manipulado que se cargó, el evaluador demostró que un atacante podía ejecutar cualquier código de su elección.

 

 

Ubicación del archivo cargado encontrado mediante la función descubierta al acceder al código divulgado.

 

El evaluador demostró que los comandos del sistema operativo (OS) se podían ejecutar en el servidor web.

Detener los ataques de manipulación que permiten la apropiación de cuentas

Una vulnerabilidad o una serie de vulnerabilidades pueden llevar a la apropiación de cuentas, lo que proporciona a los atacantes acceso completo a una cuenta de usuario elegida y a todos sus privilegios. Una forma sencilla para que los atacantes lo hagan es mediante el relleno de credenciales, que consiste en utilizar scripts automatizados para adivinar los pares de nombre de usuario y contraseña (normalmente a partir de contraseñas filtradas a partir de una filtración de datos de otro sitio). La implementación de la autenticación de dos factores en muchos de los sistemas de nuestros clientes ha reducido el riesgo de este tipo de ataques de relleno de credenciales. Sin embargo, hemos identificado varios casos en los que estas implementaciones de autenticación de dos factores están mal implementadas o configuradas y, por lo tanto, pueden omitirse.

Omisión de autenticación de segundo factor

En nuestra prueba de la aplicación web de una empresa de inversión, nuestro evaluador omitió 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 evaluador identificó el campo de correo electrónico enviado durante el proceso de autenticación de dos factores como un vector para la apropiación de la cuenta. Durante la prueba se observó 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 evaluador observó que cambiar esta dirección de correo electrónico a su propia dirección de correo electrónico (simulando lo que haría un atacante) llevaría a que la aplicación enviara el código de autenticación de dos factores a su dirección de correo electrónico.

 

El mecanismo de verificación 2FA (autenticación de 2 factores) tomó una decisión basada en la dirección de correo electrónico enviada por el usuario.

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 que funcione 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 debe ser utilizado o solicitado en este paso. La identificación y corrección de esta vulnerabilidad redujo el riesgo de apropiación de cuentas al eliminar este vector de la aplicación.

Para algunos de nuestros clientes que no tienen autenticación de dos factores, nuestros evaluadores han encontrado métodos para evitar por completo el requisito de autenticación y hacerse cargo de la cuenta de otros usuarios. A continuación, se proporciona una breve descripción de dos de estos bypass, uno para un cliente del sector Fintech y el otro del sector energético.

Adquisición de cuenta mediante registro sobrescrito

En el caso de una empresa de tecnología financiera, nuestro evaluador descubrió una vulnerabilidad que permitiría a un actor malintencionado obtener el control de una cuenta. El evaluador demostró que un atacante podría realizar un registro utilizando el mismo identificador que un usuario existente.

El evaluador realizó las siguientes observaciones durante la prueba de penetración de la aplicación:

1. Durante el proceso de registro, la aplicación asignó un nuevo identificador de registro para cada nuevo registro.
2. Este identificador de registro podría cambiarse cuando se envió desde el navegador web.
3. La aplicación aceptó el identificador de registro modificado y fusionó la información de los dos registros. Un atacante podría utilizar esto para crear un registro asociado con su propia dirección de correo electrónico.
4. La aplicación realizó una verificación para rechazar registros con el mismo número de teléfono móvil. Se podría abusar de esta verificación para determinar si un número de teléfono móvil era válido.
5. No había límites en la cantidad de envíos (técnicamente, una falta de limitación de velocidad en solicitudes HTTP y llamadas API) en cada etapa del proceso de registro.

El evaluador pudo reunir múltiples prácticas de seguridad deficientes y vulnerabilidades para demostrar una falla crítica de apropiación de cuentas:

• El sistema no tenía restricciones sobre la velocidad a la que se podían realizar los intentos de determinar números de teléfono válidos, lo que facilitaba que un atacante identificara números válidos mediante múltiples intentos.
• La aplicación reveló el identificador del registrante a los usuarios innecesariamente.
• La aplicación no realizó ninguna comprobación o verificación si el identificador del registrante ya estaba en uso antes de crear el usuario.
• La base de datos no estableció el identificador del registrante como una clave única en las tablas relevantes de la base de datos, por lo que fue posible la creación de múltiples registros con el mismo identificador.

Adquisición de cuenta mediante parámetro manipulado

En otro caso de apropiación de cuentas, el evaluador observó que había un parámetro dentro de las solicitudes interceptadas que contenía el campo de 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 evaluador demostró que un atacante podría obtener acceso a una cuenta con mayores privilegios. Nuestro evaluador de Bitdefender pudo hacer esto gracias a sus experiencias previas con varias implementaciones de inicio de sesión único 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 mediante pruebas de seguridad ofensivas. Los productos defensivos tradicionales, como los firewalls de aplicaciones web, por sí solos a menudo no pueden detener ataques complejos que explotan dichas debilidades, lo que enfatiza la importancia de realizar pruebas de seguridad ofensivas integrales. Además de descubrir vulnerabilidades ocultas para su reparación, las pruebas de seguridad ofensivas también muestran la debida diligencia a través de esfuerzos de seguridad proactivos y respaldan los esfuerzos de cumplimiento como ISO 27001, SOC 2 Tipo 2, GDPR, PCI-DSS e HIPAA.

Adoptar una estrategia ofensiva de ciberseguridad no es solo una opción, sino una necesidad para las empresas y los líderes de TI que buscan estar un paso por delante de adversarios sofisticados. Por lo tanto, integrar medidas ofensivas es crucial para construir una defensa sólida y dinámica capaz de frustrar incluso las amenazas cibernéticas más avanzadas.

 

 

 

Fuente: Bitdefender Central