- [6.20 Ataques de transferencia de zona (AXFR - Full Zone Transfer)](#620-ataques-de-transferencia-de-zona-axfr---full-zone-transfer)
## 6.17 Abuso de APIs
En caso de que veáis que tras desplegar el laboratorio, siguen habiendo errores en el despliegue de ciertos contenedores, probad a hacer un ‘docker rm $(docker ps -a -q) –force‘ y aplicad el último comando de los 3 mencionados anteriormente para volver a desplegar los contenedores. Llegará un momento en el que todos serán desplegados sin ningún problema.
Por otro lado, si de pronto véis que el comando ‘docker rm $(docker ps -a -q) –force‘ os da algún problema, esperad unos segundos y volved a probar el comando hasta que veáis que todos los contenedores han sido eliminados.
Cuando hablamos del abuso de APIs, a lo que nos referimos es a la explotación de vulnerabilidades en las interfaces de programación de aplicaciones (APIs) que se utilizan para permitir la comunicación y el intercambio de datos entre diferentes aplicaciones y servicios en una red.
Un ejemplo sencillo de API podría ser la integración de Google Maps en una aplicación de transporte. Imagina que una aplicación de transporte necesita mostrar el mapa y la ruta a seguir para que los usuarios puedan ver la ubicación del vehículo y el camino que se va a seguir para llegar a su destino. En lugar de crear su propio mapa, la aplicación podría utilizar la API de Google Maps para mostrar el mapa en su aplicación.
En este ejemplo, la API de Google Maps proporciona una serie de funciones y protocolos que permiten a la aplicación de transporte comunicarse con los servidores de Google y acceder a los datos necesarios para mostrar el mapa y la ruta. La API de Google Maps también maneja la complejidad de mostrar el mapa y la ruta en diferentes dispositivos y navegadores, lo que permite a la aplicación de transporte centrarse en su funcionalidad principal.
Adicionalmente, una de las utilidades que vemos en esta clase es Postman. Postman es una herramienta muy popular utilizada para probar y depurar APIs. Con Postman, los desarrolladores pueden enviar solicitudes a diferentes endpoints y ver las respuestas para verificar que la API está funcionando correctamente. Sin embargo, los atacantes también pueden utilizar Postman para explorar los endpoints de una API en busca de vulnerabilidades y debilidades de seguridad.
Algunos endpoints de una API pueden aceptar diferentes métodos de solicitud, como GET, POST, PUT, DELETE, etc. Los atacantes pueden utilizar herramientas de fuzzing para enviar una gran cantidad de solicitudes a un endpoint en busca de vulnerabilidades. Por ejemplo, un atacante podría enviar solicitudes GET a un endpoint para enumerar todos los recursos disponibles, o enviar solicitudes POST para agregar o modificar datos.
Algunas de las vulnerabilidades comunes que se pueden explotar a través del abuso de APIs incluyen:
- Inyección de SQL: los atacantes pueden enviar datos maliciosos en las solicitudes para intentar inyectar código SQL en la base de datos subyacente.
- Falsificación de solicitudes entre sitios (CSRF): los atacantes pueden enviar solicitudes maliciosas a una API en nombre de un usuario autenticado para realizar acciones no autorizadas.
- Exposición de información confidencial: los atacantes pueden explorar los endpoints de una API para obtener información confidencial, como claves de API, contraseñas y nombres de usuario.
Para evitar el abuso de APIs, los desarrolladores deben asegurarse de que la API esté diseñada de manera segura y que se validen y autentiquen adecuadamente todas las solicitudes entrantes. También es importante utilizar cifrado y autenticación fuertes para proteger los datos que se transmiten a través de la API.
Los desarrolladores pueden utilizar herramientas como Postman para probar la API y detectar posibles vulnerabilidades antes de que sean explotadas por los atacantes.
A continuación, se proporciona el enlace al proyecto de Github que utilizamos para desplegar con Docker el laboratorio vulnerable donde poder practicar la enumeración de APIs:
Si a la hora de desplegar el laboratorio con Docker, os encontráis con problemas y alguno de los contenedores que se despliegan véis que causan error, probad a desplegar como alternativa el laboratorio de desarrollo. Primero instalad la última versión de ‘docker-compose‘ y una vez hecho, ejecutad los siguientes comandos:
VERSION=develop docker-compose -f docker-compose.yml –compatibility up -d
```
Empecemos:
Descargamos el repo y nos vamos a la carpeta con el docker compose. Allí descargamos las imágenes Docker.
```
git clone https://github.com/OWASP/crAPI.git
cd crAPI/deploy/docker
docker-compose pull
```
Ahora desplegamos el laboratorio.
```
docker compose -f docker-compose.yml --compatibility up -d
```
A veces no funciona a la primera. El laboratoria es inestable, por lo que si no funciona a la primera, probad a ejecutar el comando varias veces empezando desde cero, borrando contenedores e imágenes. Merece la pena. La comunidad ha documentado algunos errores en su repositorio: https://github.com/OWASP/crAPI/blob/main/docs/troubleshooting.md
Ahora abrimos el inspector de elementos y vamos a la pestaña de Network. Vamos a la pestaña de XHR y nos logueamos. Tenemos que ver una petición a `http://localhost:8888/identity/api/auth/login`, que si la inspeccionamos veremos:
He detallado la request y el response porque es en lo que tendremos que fijarnos. Vemos que el token es un [JWT](https://es.wikipedia.org/wiki/JSON_Web_Token).
El abuso de subidas de archivos es un tipo de ataque que se produce cuando un atacante aprovecha las vulnerabilidades en las aplicaciones web que permiten a los usuarios cargar archivos en el servidor. Este tipo de ataque se conoce comúnmente como un ataque de “subida de archivos maliciosos“.
En un ataque de subida de archivos maliciosos, un atacante carga un archivo malicioso en una aplicación web, que luego se almacena en el servidor. Si por ejemplo el atacante consigue subir un archivo PHP y el servidor web lo almacena, podría conseguir ejecución remota de comandos y tomar el control del servidor.
Los atacantes también pueden utilizar técnicas de “falsificación de tipos de archivos” para engañar a una aplicación web con el objetivo de que acepte un archivo malicioso como si fuera un archivo legítimo.
En esta clase, exploraremos algunas de las técnicas más utilizadas para explotar la fase de subida de archivos en aplicaciones web. Aprenderás cómo los atacantes pueden cargar contenido malicioso, además de eludir diferentes restricciones implementadas para lograrlo.
A continuación, se os comparte el enlace al proyecto de Github el cual estaremos empleando para desplegar un laboratorio práctico en Docker con el que poder practicar estos conceptos:
El ataque Prototype Pollution es una técnica de ataque que aprovecha las vulnerabilidades en la implementación de objetos en JavaScript. Esta técnica de ataque se utiliza para modificar la propiedad “prototype” de un objeto en una aplicación web, lo que puede permitir al atacante ejecutar código malicioso o manipular los datos de la aplicación.
En JavaScript, la propiedad “prototype” se utiliza para definir las propiedades y métodos de un objeto. Los atacantes pueden explotar esta característica de JavaScript para modificar las propiedades y métodos de un objeto y tomar el control de la aplicación.
El ataque de Prototype Pollution se produce cuando un atacante modifica la propiedad “prototype” de un objeto en una aplicación web. Esto se puede lograr mediante la manipulación de datos que se envían a través de formularios o solicitudes AJAX, o mediante la inserción de código malicioso en el código JavaScript de la aplicación.
Una vez que el objeto ha sido manipulado, el atacante puede ejecutar código malicioso en la aplicación, manipular los datos de la aplicación o tomar el control de la sesión de un usuario. Por ejemplo, un atacante podría modificar la propiedad “prototype” de un objeto de autenticación de usuario para permitir el acceso a una cuenta sin la necesidad de una contraseña.
El impacto de la explotación del ataque Prototype Pollution puede ser significativo, ya que los atacantes pueden tomar el control de la aplicación o comprometer los datos de los usuarios. Además, dado que el ataque se basa en vulnerabilidades en la implementación de objetos en JavaScript, puede ser difícil de detectar y corregir.
A continuación, se proporciona el enlace directo al proyecto de Github que utilizamos en esta clase para desplegar un entorno vulnerable con el que poder practicar:
Los ataques de transferencia de zona, también conocidos como ataques AXFR, son un tipo de ataque que se dirige a los servidores DNS (Domain Name System) y que permite a los atacantes obtener información sensible sobre los dominios de una organización.
En términos simples, los servidores DNS se encargan de traducir los nombres de dominio legibles por humanos en direcciones IP utilizables por las máquinas. Los ataques AXFR permiten a los atacantes obtener información sobre los registros DNS almacenados en un servidor DNS.
El ataque AXFR se lleva a cabo enviando una solicitud de transferencia de zona desde un servidor DNS falso a un servidor DNS legítimo. Esta solicitud se realiza utilizando el protocolo de transferencia de zona DNS (AXFR), que es utilizado por los servidores DNS para transferir registros DNS de un servidor a otro.
Si el servidor DNS legítimo no está configurado correctamente, puede responder a la solicitud de transferencia de zona y proporcionar al atacante información detallada sobre los registros DNS almacenados en el servidor. Esto incluye información como los nombres de dominio, direcciones IP, servidores de correo electrónico y otra información sensible que puede ser utilizada en futuros ataques.
Una de las herramientas que utilizamos en esta clase para explotar el AXFR es dig. El comando dig es una herramienta de línea de comandos que se utiliza para realizar consultas DNS y obtener información sobre los registros DNS de un dominio específico.
La sintaxis para aplicar el AXFR en un servidor DNS es la siguiente:
➜ dig @<DNS-server><domain-name> AXFR
Donde:
-<DNS-server> es la dirección IP del servidor DNS que se desea consultar.
-<domain-name> es el nombre de dominio del cual se desea obtener la transferencia de zona.
- AXFR es el tipo de consulta que se desea realizar, que indica al servidor DNS que se desea una transferencia de zona completa.
Para prevenir los ataques AXFR, es importante que los administradores de red configuren adecuadamente los servidores DNS y limiten el acceso a la transferencia de zona solo a servidores autorizados. También es importante mantener actualizado el software del servidor DNS y utilizar técnicas de cifrado y autenticación fuertes para proteger los datos que se transmiten a través de la red. Los administradores también pueden utilizar herramientas de monitoreo de DNS para detectar y prevenir posibles ataques de transferencia de zona.
A continuación, se proporciona el enlace correspondiente al proyecto de Github que nos descargamos para desplegar un entorno en Docker vulnerable con el que poder practicar:
