Problemas del “pentesting real” según Marek Zmysłowski (II)- Se Cuidadoso, es nuestro sistema en producción

La selección del entorno correcto es fundamental para garantizar una prueba de penetración (pentesting) exitosa. A pesar de ello, como plantea Marek Zmysłowski en la conferencia Penetration Testing 7 Deadly Sins, este es el primer problema o “pecado capital” con el que tropiezan los especialistas de seguridad,  afectando negativamente los resultados del proceso.

Antes de continuar, te recomiendo que leas la introducción de esta serie si aún no lo has hecho. Allí se explica, entre otras cosas, que estamos haciendo una traducción literal del contenido de la conferencia. Si leíste la introducción, te propongo entonces continuar con la sección dedicada al primer problema capital referenciado como “Se Cuidadoso, es nuestro sistema en producción“:

Según Marek, este problema se caracteriza con tres factores básicamente:

  • Entorno inadecuado
  • Restricciones de escaneos
  • Restricciones de entradas de usuarios

Entorno inadecuado

Solamente un entorno adecuado puede permitir que se realice una Prueba de Penetración realmente efectiva. Los entornos puedes ser de Desarrollo, de Pre-producción y de Producción.

Características del Entorno de Desarrollo:

  • A veces todas las funcionalidades que deben probarse en la aplicación no están presentes
  • A veces todas las funcionalidades no están parcheadas.
  • A veces no están presentes los datos apropiados.
  • El código está cambiando continuamente.
  • Cualquier pequeño cambio en el código puede crear una nueva vulnerabilidad

Evaluación: Entorno no adecuado.

Características del Entorno de Pre-producción

  • El código de la aplicación es el mismo que el código del entorno de producción.
  • La aplicación tiene datos que son reales o cercanos a los reales.
  • Pueden realizarse pruebas y escaneos automáticos de vulnerabilidades.

Evaluación: Entorno ideal.

Características del Entorno de Producción

  • A veces las modificaciones no están permitidas. ¿Qué pasarías si realizas un defacement tratando de explotar una vulnerabilidad?
  • A veces la utilización de algunas funcionalidades no está permitida. ¿Las funcionalidades de eliminar datos pueden comprobarse?
  • A veces no es posible desarrollar pruebas y escaneos automatizados. ¿Qué podría pasar cuando un escaneador comienza ciegamente a comprobar todas las funcionalidades de la aplicación, con la consiguiente modificación de los datos reales existentes?

Evaluación: Entorno no adecuado.

Restricciones de escaneos

Usualmente el especialista de seguridad no tiene permisos para utilizar escáner o cualquier otras herramientas automáticas, en un entorno de producción, porque:

  • Envían muchas peticiones simultáneamente con la consiguiente sobrecarga de los servidores, provocando en ocasiones ataques no intencionales de Denegación de Servicios.
  • Estos pueden crear/modificar/eliminar una inmensa cantidad de datos sin control que pueden producir daños de importancia.
  • La falta de escáner puede disminuir el valor de las pruebas de seguridad y puede esconder el descubrimiento de algunas vulnerabilidades.

Algunos ejemplos:

  • La aplicación dejó de trabajar bien después que el escaner fue utilizado.
  • El análisis de configuración reveló que solamente 16 conexiones pueden realizarse a la base de datos.
  • El jefe de proyecto explica que esas restricciones existen porque son pocas las personas que utilizan esa aplicación.

 A un atacante no le interesa esas restricciones. El usa el modo más simple de romper, explotar o destrozar la aplicación objetivo.

Restricciones de entradas de usuarios

A veces los administradores crean restricciones a la entrada de datos pues no quieren que las Pruebas de Penetración interfieran con los procesos normales porque:

  • Tales restricciones interrumpen la correcta ejecución de la prueba de seguridad
  • Las restricciones no se aplican al ciberatacante real.

Ejemplos:

  • La prueba de penetración se refiere a la aplicación de producción que fue utilizada por los usuarios normales
  • La restricción no permitía la prueba de las vulnerabilidades de XSS almacenadas.
  • Cuando los datos fueron insertados para probar vulnerabilidades XSS reflejadas, accidentalmente causaron la creación de XSS almacenado.

Análisis y conclusiones

Coincido con los planteamientos de Marek 100%. El entorno ideal para la realización de las pruebas de penetración es un entorno de pre-producción o en otras palabras, un entorno que simule lo mejor posible las condiciones reales de producción de la aplicación web objetivo. Poner restricciones a las pruebas de escaneos automáticos y entradas de datos no hace la aplicación más segura, todo lo contrario: crea la falsa sensación de que todo está bien hasta que la aplicación es atacada mediante un vector que pudo haberse detectado en una prueba de penetración sin impedimentos.

Que no quepa duda, todos queremos vivir en el mundo donde los informes de pruebas de seguridad dicen que todo está bien y donde no hay ciberatacantes merodeando a través de selvas de bits disfrazados con códigos fuentes ofuscados. Sin embargo, ¿así es la realidad actual?

Los vectores de ataque, por otra parte, no son lineales, dependen en ocasiones de ejecutar una secuencia de exploits que debiliten progresivamente las defensas de la aplicación. Si alguno de los ataques intermedios no se pueden realizar, ¿que sentido tendría entonces comprobar su ejecución?

Por último: hay un proceso informatizado A->B->C, donde en cada fase, los formularios que se acceden depende de la entrada de datos en los formularios del paso anterior. La pregunta que debemos hacernos es: ¿De qué forma un escaneador automático y/o un especialista de seguridad podrán investigar los formularios de C si no pueden entrar o modificar datos en los formularios precedentes?

Como decía Marek en su conferencia, las opiniones expresadas son personales. Por tanto, creo que mas allá de tomar al pie de la letra cada palabra, lo importante es la reflexión y la construcción de un conocimiento propio al respecto, pero, y siempre hay un “pero”, recuerda que seremos capaces de ver más lejos si nos apoyamos en la experiencia de los que llevan más tiempo en esta actividad. Al menos esa es mi opinión (y la de Bernardo de Chartres).

La próxima entrada de esta serie estará dedicada al “pecado capital” del pentesting: Mi Nessus es mejor que el tuyo. ¿Interesante verdad?

!S4lud0s y h4st4 el próx1m0 p0st¡

Anuncios

Un comentario en “Problemas del “pentesting real” según Marek Zmysłowski (II)- Se Cuidadoso, es nuestro sistema en producción

  1. Pingback: Problemas del “pentesting real” según Marek Zmysłowski (I)- Introducción | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s