Como probador de penetración, esta redacción se incluye en la Declaración de trabajo, sin embargo, como probador, no recomiendo que haga que el probador simplemente detenga la prueba una vez que se obtenga acceso. El propósito de una prueba de penetración es obtener acceso muy similar a cómo un atacante obtendría acceso. Al detener la prueba, nunca se podría saber qué otra cosa es explotable. Veamos lo siguiente:
PENTEST
Yournetwork 172.16.1.0/24
Indiquemos que el comprobador comienza en 172.16.1.0 y obtiene acceso a 172.16.1.10, el comprobador se encuentra con una máquina altamente explotable, obtiene el control total y detiene la prueba. ¿De qué se ha beneficiado si hubieran 244 máquinas sin probar?
Uno de los mayores obstáculos a los que nos enfrentamos (evaluadores), es que a veces estamos limitados en lo que podemos probar y cómo podemos hacerlo. En general, mi objetivo es utilizar explotaciones confiables que no afecten a la red de un cliente (servicios fallidos, causan denegaciones de servicio). Muchas veces, las técnicas que un atacante de buena fe usaría son de la tabla para mí. Por ejemplo, encadenamiento de exploits, donde puedo encontrar un script de sitio cruzado de bajo nivel (XSS) pero la única forma de explotarlo es agregar un vector de ingeniería social (enviando un correo electrónico a su empleado un enlace).
Hay ventajas y desventajas con la realización de pruebas parciales y el estándar: "Apuntar una herramienta a este bloqueo de red, si no puede ingresar, estamos seguros" nunca funciona. Esto es porque la prueba es un arma cargada. Como evaluador profesional, sé que no puedo hacer algo para interrumpir sus operaciones, por lo que no lo arriesgaré. Un atacante de buena fe nunca va a decir: "bueno, si ejecuto este exploit, podría bloquear su sistema ... Mejor no" o "bueno, esto es solo un ataque XSS ... es mejor que no use esto en un correo electrónico elaborado , "o" encontré la primera máquina explotable ... debería dejar de explotar el resto de la red ". Por el contrario, un atacante ejecutará cualquier exploit que desee, no les importará que colisionen de algo y encadenarán exploits.
Prefiero realizar pruebas internas de blackbox (todo vale) desde dentro. Con y sin credenciales frente a pruebas remotas. Esta es una lógica simple: "Supongamos que llegaron a la puerta principal ... ¿Qué pueden hacer?" Esto me permite hacer que el cliente determine su postura de seguridad desde adentro hacia afuera, donde se realizan pruebas externas DESPUÉS. Encontré que este enfoque produce resultados mucho mejores que disparar a una IP externa.
Además, dependiendo de su estructura, me he encontrado con demasiados proveedores de alojamiento de terceros. Aquí es donde se dice la infraestructura web del cliente en Amazon, o algún otro proveedor de alojamiento, en el que no podemos realizar pruebas, ya que el proveedor de la nube evita las pruebas de penetración. Así que es probable que obtengas un informe sesgado.
Mi consejo es que, si vas a dejar que alguien lo pruebe, debería ser todo o nada. Los evaluadores más competentes son conscientes de las trampas que mencioné aquí. La mayoría ya debería saber: "nunca usarás hazañas que afectarán algo" para que sean responsables. Sin embargo, no dejaría de realizar las pruebas, y obtendría más por su dinero realizando primero las pruebas internas (a ciegas y con credenciales) seguidas de las pruebas externas.