Kit de inicio de pruebas de seguridad web

Hola a todos!

Me llamo Andrey Durante 10 a√Īos he estado buscando vulnerabilidades en varios servicios web. y listo para compartir mi conocimiento contigo. En mayo pasado, hice un informe sobre esto en la conferencia de Heisenbug , y ahora estoy listo para compartir mi conocimiento aqu√≠, tambi√©n, en los espacios abiertos de Habr. Entonces comencemos.

Una vez encontr√© una vulnerabilidad en los servidores de la famosa empresa Facebook. Los chicos olvidaron actualizar ImageMagick (la biblioteca de procesamiento de im√°genes) y lo pagaron :) Con este ejemplo, quer√≠a mostrar que todos somos humanos y que todos podemos cometer errores, sin importar en qu√© compa√Ī√≠as y en qu√© puestos trabajamos. El √ļnico problema es que estos errores pueden conducir a todo tipo de riesgos.
Cuanto más complicada sea su aplicación / sitio web / herramienta, más probable es que algo salga mal.
Debe verificar las vulnerabilidades. Es una tontería no hacer esto en absoluto.

Los siguientes elementos pueden ser etapas de verificación de aplicaciones web:
  • Preparaci√≥n:
    • Definir puntos de entrada, de hecho, de d√≥nde pueden venir los datos en la aplicaci√≥n;
    • Identificar stock de tecnolog√≠a;
    • Determine qu√© vulnerabilidades tiene sentido verificar;
  • Verificaci√≥n Debe verificar todas las vulnerabilidades que se aplican al alcance de la tecnolog√≠a de su aplicaci√≥n web;
  • An√°lisis de c√≥digo. No seas perezoso, no te saltes este art√≠culo. En algunos casos, sin acceso al c√≥digo, es dif√≠cil encontrar vulnerabilidades, y esto tambi√©n le permite omitir el filtrado que puede estar incrustado en su aplicaci√≥n.

Hablaré de todo esto en detalle.

Entonces, preparaci√≥n. No me enfocar√© en todos los tipos de vulnerabilidades, de lo contrario, la cantidad de texto en el art√≠culo exceder√° todos los tama√Īos imaginables e inconcebibles. Le aconsejo que comience a aprender de la lista de los 10 proyectos principales de OWASP . Cada pocos a√Īos, el consorcio OWASP forma una lista de las vulnerabilidades m√°s relevantes en este momento. Consideraremos algunos de ellos en detalle.

Xss


XSS (cross-site scripting) es un ataque a un usuario que permite a un atacante ejecutar un script arbitrario en el contexto del navegador de su víctima. Muy a menudo, implica la implementación de etiquetas HTML y scripts JS .
Ejemplo: en un momento existi√≥ dicho servicio Yahoo! Ad Exchange El formulario de recuperaci√≥n de contrase√Īa ten√≠a un par√°metro " URL de retorno ". Podr√≠a indicar a qu√© p√°gina volver despu√©s del proceso de restablecimiento de contrase√Īa. Si inserta uno u otro vector all√≠ que conduce a la ejecuci√≥n del c√≥digo JS , puede obtener todas las cookies del usuario. Analizaremos c√≥mo sucede esto y por qu√©.


Aquí está el vector en sí. Todo a la vez:

Para realizar una inyección, debe salir del contexto de la variable en la que estábamos por defecto (por defecto, esto es lo que asumió el programador cuando escribió el código).
A continuación se muestra el valor original. Este es un comportamiento válido.

Vemos que returnURL = / login.jsp
Esto cae dentro del valor de la etiqueta <input> .
Si agregamos una comilla después de jsp , veremos que se ha vertido la sintaxis HTML . Afortunadamente, el lenguaje HTML no es estricto, el analizador saltará y no habrá problemas:

Agrega otro personaje. Aquí estamos completamente fuera del contexto de la etiqueta <input> :

Ahora agregamos la apertura de la etiqueta <svg> y obtenemos dos etiquetas válidas en términos de sintaxis:

A continuación, agregue todo el vector de ataque:

En este caso, se dibuja la imagen svg . Usando el controlador JavaScript " onload ", ejecutamos una alerta con las cookies del documento. Eso es todo! El atacante recibió tus cookies .
Si en la prueba mostramos solo la alerta en sí, no será difícil para un atacante enviar cookies a un servidor controlado por él y, en el peor de los casos, incautar su cuenta. Veamos cómo se ve de nuevo:


También hay más vectores de ataque en el cliente. Daré algunos ejemplos con una breve descripción. Pero primero debe comprender cómo salir del contexto:
  • Fuera de contexto. Estos 6 caracteres ayudar√°n a salir no solo del contexto del valor del par√°metro HTML, sino tambi√©n de muchos otros:
    -> '">

Bueno, de hecho, los dos vectores de ataque m√°s simples:
  • Insertar enlaces en particular. Pero en el caso general: cambiar la apariencia de la p√°gina. Por ejemplo, pueden incrustar c√≥digo html en su p√°gina y mostrar una ventana falsa pidiendo datos:

    La cadena " aaaa " apunta a google.com . Puede ver que el enlace se representa en la página, pero es posible que no lo vea, pero esto no cancela su presencia en el código. En ambos casos, el caso puede considerarse completado;
  • Ejecuci√≥n de script, por ejemplo, interceptando cookies de usuario:



¬ŅD√≥nde y c√≥mo buscar XSS?


Primero, encuentre las funciones de salida de informaci√≥n / datos en la p√°gina. ¬ŅAnalizar qu√© datos llegan all√≠? Aqu√≠ viene el concepto de una fuente no confiable . Y tal, en primer lugar, es su usuario . Los vectores de ataque pueden estar contenidos en cualquier otra fuente: fuentes RSS, otros servicios, tanto externos como internos.
Aquí hay un ejemplo de la vida real: trabajo para SEMrush IT. Estamos desarrollando una plataforma en línea, que es una herramienta universal para los vendedores en línea. Entonces, un servicio guardó datos, el otro dedujo, cada uno de los equipos se basó el uno en el otro, resultó que en el segundo servicio XSS surgió debido a la falta de procesamiento adecuado de los datos de salida, y el primer comando no consideró necesario filtrar los datos entrantes. de ninguna manera y los mantuvo " tal cual ". Conclusión: si no sabe cómo se almacenan estos o esos datos, deben considerarse no confiables. O acuerde de antemano quién almacena y cómo, filtros, muestra datos.

Si ya tiene datos de fuentes no confiables, le recomiendo:
  • Para estudiar el filtrado de datos entrantes;
  • Examina el contexto de la salida. No en todos los casos, XSS puede ejecutarse, incluso en ausencia de filtrado. Por ejemplo, si el tipo de contenido de la respuesta es: text / plain;
  • No conf√≠e en el filtrado de marcos de sistemas de seguridad integrados.


Inyección SQL




Implementación de código SQL (inyección SQL en inglés) : la introducción en la consulta de la base de datos de instrucciones que no estaban implícitas allí.

Ejemplo (no de la vida, sino también bueno):
Vemos un script que muestra una tabla de usuario. En este caso, puede buscar por nombre de usuario.
A la derecha se muestra cómo se ve la consulta a la base de datos, y a la izquierda es el resultado de la secuencia de comandos en el navegador.

Adem√°s, para probar y obtener al menos alg√ļn resultado primario, insertamos dos comillas en el valor del par√°metro de nombre. Sencilla y doble:

Vemos que desde el punto de vista de la salida, todo se vino abajo, la tabla desapareció por completo. La solicitud también obtiene las 2 comillas adicionales. Se viola toda la sintaxis de la consulta SQL .
Si tomamos y agregamos dicha construcción al valor del parámetro ( ed .: Mire en el cuadro amarillo ), obtenemos una solicitud absolutamente válida. El resultado de la página es completamente idéntico a la primera solicitud, que no incluía una inyección:

Para verificar completamente que hay una vulnerabilidad, agregamos un deuce en lugar de la unidad:

Resulta que la solicitud se vuelve falsa, desde el punto de vista de la lógica booleana y, como resultado, no contiene datos. Sin embargo, a diferencia del momento en que tuvimos un error, tenemos la salida de la tabla misma.

Para no enumerar todo lo que puede estar en diferentes motores de base de datos y consultas de diferentes tipos, he reducido todo a una línea:

Esto es algo que puede intentar ingresar en el par√°metro y luego, de acuerdo con las diferencias en las respuestas, intente comprender lo que est√° sucediendo, ¬Ņhay una vulnerabilidad o no? Alrededor del 80% de los casos que puede cubrir con esta manipulaci√≥n.
Queda un 20% de situaciones difíciles en las que no le dará ninguna información, por ejemplo: consultas / filtros anidados, etc. En mi práctica, me encontré con una persona similar solo una vez. Luego tuve que evitar el filtrado en el lado del servicio.

¬ŅCu√°l es el peligro en SQL?
  • De lo obvio: fuga de informaci√≥n . Si un atacante pudo generar consultas a sus bases de datos, de una forma u otra puede obtener valores que no estaban destinados a la salida (hashes de contrase√Īas, direcciones de clientes, etc.);
  • Cambio de datos . Ahora muchos desarrolladores usan bases de datos a trav√©s de sistemas ORM . Estos sistemas, por defecto, le permiten hacer m√ļltiples consultas a la vez, la sintaxis SQL tambi√©n le permite hacer esto. Si hay una vulnerabilidad, todo puede volverse no solo a la selecci√≥n de datos, sino tambi√©n a su cambio (hasta eliminar tablas, cambiar la estructura de la base de datos, etc.).
    En la misma situación, es posible un aumento de los privilegios del usuario. Cambie los campos en ciertas tablas (por ejemplo, coloque is_admins = true en la base de datos de usuarios ) y aumente sus derechos al administrador;
  • DoS . En algunos casos, una inyecci√≥n puede conducir a una denegaci√≥n de servicio. Se generan varias consultas pesadas a la base de datos, se inician en varios subprocesos y su servicio puede dejar de funcionar por alg√ļn tiempo;
  • Leer los archivos del sistema es otro desastre que la inyecci√≥n SQL puede traer. La aparici√≥n de este riesgo depende del sistema de base de datos que utilice, as√≠ como del usuario que trabaje con √©l (privilegiado o no);
  • RCE (Remote Code Execution) es ejecuci√≥n de c√≥digo. Depende directamente del tipo de base de datos que se use (anteriormente esto era posible de forma predeterminada, con la configuraci√≥n predeterminada de la base de datos, en MSSQL).

La siguiente tabla muestra las vulnerabilidades en la consulta SQL . Por supuesto, no necesitas memorizarlo. Además, estas no son todas las opciones posibles, sino simplemente ejemplos. Solo preste atención al hecho de que los lugares donde puede ocurrir la inyección en la consulta SQL si llegan datos sin procesar están resaltados en rojo. Un atacante experimentado puede encontrar una manera de explotar esto. Ten cuidado y atento.


SSRF (falsificación de solicitudes del lado del servidor)


Traducción literal: solicitudes falsas en el lado del servidor. Es decir, un ataque que le permite manipular los datos que envía a la aplicación, lo que le obliga a realizar la solicitud no a donde la lógica de negocios originalmente se planeó.
El funcionamiento de SSRF se muestra en la imagen a continuación:

Hay un atacante, est√° su servidor, que est√° cerrado por el cortafuegos , pero al mismo tiempo hay una funcionalidad que le permite realizar solicitudes en nombre del servidor.
Si esta funcionalidad no está debidamente protegida y / o de manera incorrecta, como suele suceder :), procesa los datos entrantes, el atacante puede recurrir a Memcached , Redis u obtener acceso a los recursos internos de la víctima.

Para un ejemplo más ilustrativo, considere el soporte que SEMrush utiliza para la capacitación interna de los empleados.
Es importante prestar atención al significado de la " URL de Avatar ":

Aquí prestamos atención a 2 puntos:
  • URL del avatar en s√≠
  • y la capacidad de descargarlo usando un archivo.

Tenga en cuenta que el campo " Avatar URL " es un campo de texto para la entrada, lo que significa que podemos manipular este valor. Intentemos poner el avatar, quiz√°s, la imagen m√°s famosa en Internet: Googlebot de la p√°gina de error 404 .
Hazlo una vez:

Haga dos veces, haga clic en " Guardar ". Tenemos un robot en lugar de mi foto:

Aquí vale la pena prestar atención al hecho de que el valor de la " URL del avatar " ha cambiado, a alguna ruta local; aparentemente, la aplicación solicitó una imagen, la guardó en el servidor y sustituyó un nuevo valor.

Seguimos adelante. En el campo " Avatar de URL ", ingrese el archivo de valor : /// etc / passwd . Este dise√Īo le permite acceder a la estructura del archivo. En algunas bibliotecas que sol√≠an trabajar con HTTP , de manera predeterminada, el trabajo con la estructura de archivos est√° activado y recibe datos de los servidores en los que se iniciaron:

¬ŅQu√© sucede despu√©s de hacer clic en el bot√≥n " Guardar "? ..
En primer lugar, la imagen se convirtió en " murciélago ", y en segundo lugar, la ruta del archivo cambió.

Si intentamos solicitar esta imagen en el navegador, no nos mostrarán nada (el archivo está " roto "). Pero no somos el primer día en seguridad de la información, sabemos qué hacer :) Mediante simples manipulaciones obtenemos el contenido del archivo en nuestra computadora:

Por lo tanto, con la ayuda de esta vulnerabilidad, yo, como atacante, puedo obtener todos los códigos fuente de su servicio y otros datos disponibles para leer al usuario que ejecuta el servicio web.
Veamos los peligros de la SSRF:
  • Escaneo de puertos. Para una red externa, su servicio es un punto de entrada y 2 puertos (http y https). Al escanear puertos desde el interior de su infraestructura, un atacante puede detectar puertos abiertos;
  • Omitir la autenticaci√≥n basada en host. Cual es el punto? Es posible que dentro de su estructura haya servicios que est√©n disponibles solo para ciertos recursos (lea: Lista blanca de IP). Por lo tanto, si su servidor vulnerable est√° en la lista blanca, obtiene acceso a los servicios que est√°n disponibles para √©l y, como resultado, puede manipularlos;
  • Continuando con el desarrollo del ataque antes mencionado, puede continuar explotando los programas vulnerables que se ejecutan en la intranet o en el servidor local. Muy a menudo hay situaciones en las que la infraestructura interna, inaccesible desde el exterior, est√° mal monitoreada (las versiones / parches de seguridad, etc. no siempre se actualizan). Esto tambi√©n puede conducir a ataques y robo de datos;
  • Lectura de datos locales. Lo mostr√© arriba con un ejemplo. Sus configuraciones se pueden leer y acceder, tokens y contrase√Īas.


¬ŅD√≥nde buscar SSRF?


Esta no es una vulnerabilidad estándar. Se puede encontrar en diferentes, a menudo en los lugares más inesperados. En esta situación, la técnica "mira aquí, pero quizás ni siquiera mires aquí" no funciona.
Se√Īales de un posible SSRF :
  • Webhook Si est√°n mal configurados, si Firewall est√° configurado incorrectamente en aquellos servidores desde los cuales Webhooks realiza solicitudes, se puede obtener una vulnerabilidad;
  • Conversi√≥n HTML Intente incrustar una construcci√≥n de URL <iframe> , <img> , <base> , <script> o CSS que apunte a un servicio interno;
  • Descargar archivos borrados . ¬ŅRecuerdas el ejemplo de avatar? Cuando un usuario tiene la oportunidad de cargar datos por URL al servidor, esto conlleva grandes problemas. Intente enviar la URL con el puerto y vea qu√© contenido se carga.


¬ŅC√≥mo buscar SSRF?


  • Levante el servidor y ejecute escucha :
    user$ nc -1 -n -vv -p 8080 -k 

    De esta manera, ver√° todas las solicitudes que llegan a su servidor en el puerto 8080 . Por un lado, es un puerto desocupado por sus servidores web y, por otro lado, es un puerto que Firewall no filtra a menudo. Se cree que se usa para el protocolo http y prohibirlo parece ser opcional;
  • En la aplicaci√≥n en estudio, encuentre el par√°metro al que puede pasar la ruta para solicitar datos de nuestro host (a nuestro oyente );
  • Examine la salida del enumerador o la respuesta devuelta.


XXE (entidad externa XML)


Comenzaré la historia, como siempre con un ejemplo, para que quede más claro:
En el servicio SEMrush mencionado anteriormente, existe una herramienta que se ocupa del análisis de contenido. El usuario conduce en la URL de su sitio o de un sitio de la competencia y, antes de analizarlo, el servicio descarga este mismo contenido. Mira cómo sucede esto en el video:



Para descargar, el servicio accede al sitio especificado y el rastreador descarga el archivo sitemap.xml . Y este es el mismo XML del que estamos hablando en este bloque.
En el video, podemos observar cómo el sitio atacante agregó una definición de la entidad externa XXE a sitemap.xml , que apunta a " file: /// etc / hosts ". En los sistemas Linux, este es un archivo que describe qué IP corresponde a los hosts si no hay registros DNS para ellos.
A continuación, el atacante indica en la etiqueta <loc> la expansión de esta variable. Después de analizar el XML, después de procesar todo el XML en el compartimento, insertará el valor que estaba en " archivo: /// etc / hosts " en la variable de ubicación (resaltada en rojo en el video).
El atacante inicia el lanzamiento de nuestro analizador, va a los registros y aquí aparece una línea resaltada en blanco en el video. Este es el contenido del archivo " archivo: /// etc / hosts " obtenido en la solicitud GET en los registros de un servidor controlado por él.
Que sigue El atacante verificará que tenía razón. Cambiará el nombre del archivo a " file: /// etc / fstab ", ejecutará el analizador nuevamente y obtendrá estadísticas sobre los procesos en ejecución.

Y finalmente: " file: /// etc / hostname ", inicie el analizador, vaya a los registros y obtenga el nombre de host de la m√°quina en la que estamos.
Este es un error real descubierto por una persona real que no est√° relacionada con nuestra empresa. Tuve que rociar ceniza en mi cabeza y pagar dinero :)

Otro ejemplo de XXE :

Supongamos que tenemos un cierto punto final , se llama: example.com/xxe .
Le enviamos la estructura XML ‚Üí en XML declaramos la entidad ‚Üí la entidad se refiere al archivo del sistema / etc / passwd y se abre m√°s en el cuerpo de la respuesta ‚Üí obtenemos el contenido de este archivo en respuesta.
Vale la pena se√Īalar que esto no ocurre tan a menudo como nos gustar√≠a.

Por que funciona


Los documentos XML son un formato de datos estructurados que, entre otras cosas, le permite describir los tipos de datos que pueden contener utilizando una etiqueta DOCTYPE especial.
Definición del tipo de datos (DTD) : la definición de los tipos de datos dentro de este documento XML . Hay tres opciones sobre cómo se puede hacer esto:
  • Si el documento es compatible con DTD . El siguiente ejemplo muestra algunos XML en los que hay una estructura de pedido, hay un elemento de producto y un elemento de conteo (presumiblemente: el n√ļmero de inventario del producto y el n√ļmero de art√≠culos en el pedido). El orden es el padre de estos dos elementos:
  • DTD externos en el servidor local.
    Hacemos lo mismo que en la primera realización, pero hacemos todas las definiciones en un archivo separado, que se encuentra en el servidor local:

  • DTD externos en un servidor de terceros:

Si es un lector atento, probablemente haya correlacionado el hecho de que la capacidad de hacer tales solicitudes en su servicio y solicitar esquemas de DTD externos es una vulnerabilidad en sí misma, de lo que hablamos anteriormente, es decir, la vulnerabilidad SSRF .
Una ocurrencia com√ļn: los desarrolladores corrigen la vulnerabilidad XXE , pero olvidan prohibir el procesamiento de DTD externos y obtener SSRF . De esto no se derivar√°n consecuencias fatales, pero no debe olvidarse de ello.

¬ŅQu√© son las entidades en XML?


Entidades en XML . Que es esto Esta es una oportunidad para definir ciertos valores y convertirlos en variables. Las entidades tienen tres tipos diferentes:

Predefinido : predefinido. De manera similar al código HTML , es posible utilizar aquellos caracteres que forman parte de la sintaxis del lenguaje, como una estructura de texto. Aquí se dan como ejemplo, para que entiendas de qué se trata. Sí, en la mayoría de los ataques no se usan, pero pueden ser necesarios en algunos casos excepcionales.
General y Parámetros . Este es uno y el mismo, solo cambia la sintaxis de su declaración y cómo pueden llamarse después de la declaración

¬ŅD√≥nde buscar XXE ?


Varias opciones:
  • Procesamiento de XML en cualquier manifestaci√≥n:
    • SVG;
    • mapa del sitio;
  • Convierte HTML a otros formatos;
  • Manejo de docx , xlsx y formatos similares.


¬ŅC√≥mo buscarlos?



La imagen muestra solo un ejemplo desde el cual comenzar. No es una clave universal. Debe optimizarse para los formatos que utiliza en el servicio en estudio.

Lo primero que hacemos: declarar una determinada entidad Z , que accede al host controlado por el host atacante, lo expande dentro del cuerpo del documento XML .
Aquí la segunda opción es posible: solo la esencia del parámetro . Difiere del primer anuncio (signo de % ). Y para volver a esta esencia, el cuerpo del documento ya no es necesario. Podemos acceder a él directamente en la estructura DOCTYPE y exponer esta entidad:

El tercer escenario es ver si la capacidad de solicitar DOCTYPE de servicios externos est√° activada o desactivada:

A continuación, observamos la salida de un servidor controlado por nosotros. Si vemos una llamada a URL / verificación desde varias direcciones IP , significa que con un alto grado de probabilidad la vulnerabilidad ha pasado, y luego solo tenemos que descubrir cómo obtener datos más interesantes para nosotros.

¬ŅCu√°l es el peligro de XXE ? Escribir√© brevemente y punto por punto:
  • Lectura de archivos locales;
  • Acceso a recursos locales;
  • Escaneo de puerto / host
  • Contenedores de texto sin formato . Esta es una oportunidad para acceder a sus servicios que operan en el protocolo de texto sin formato;
  • Ejecuci√≥n remota de c√≥digo (no es frecuente). Est√° desactivado por defecto;
  • DoS . Debido al hecho de que las entidades se pueden concatenar, es posible obtener f√°cilmente un aumento exponencial en la cantidad de memoria ocupada por estos par√°metros. El resultado es un ataque de mil millones de risas . En otras palabras, simplemente est√° sobrecargando la memoria del servidor atacado.

En conclusi√≥n, dir√© que todo esto (el art√≠culo y cualquier conocimiento que haya adquirido) no tiene sentido sin una aplicaci√≥n pr√°ctica. Por lo tanto, le preguntar√© acerca de una bagatela real: piense en la aplicaci√≥n que escribi√≥ / prob√≥ ayer e intente verificar si hay vulnerabilidades. ¬ŅHay formularios de entrada o procesamiento XML ? ¬ŅEsta aplicaci√≥n est√° protegida? ¬ŅSe ha agregado el filtrado y la DTD est√° deshabilitada?
Abra el manual de SQLmap y descubra cómo verificar su aplicación con él. Si no encuentra nada, tome otra herramienta y examínela, y luego pruebe su aplicación para detectar otras vulnerabilidades. Como dije al principio, el artículo examina solo algunas vulnerabilidades, pero miles de ellas .
No creo que puedas escribir un código absolutamente seguro. Siempre hay vulnerabilidades, todavía no las ha encontrado .

Source: https://habr.com/ru/post/441966/


All Articles