🔁 IPSpinner

IPSpinner es un proxy local que se puede utilizar para redirigir todas las solicitudes entrantes a través de diferentes proveedores elegidos. El propósito es crear un proxy de paso que rote la dirección IP de origen de cada solicitud. Por ejemplo, ejecutar una operación de fuerza bruta a través de IPSpinner ayudará a evitar ser detectado, ya que el servidor recibirá las solicitudes desde cientos de direcciones IP diferentes.

IPSpinner actualmente es compatible con AWS (API Gateway), Azure (Cloud Shell) y GitHub (GitHub Actions).

Tabla de contenidos

1. ¿Cómo funciona?
   1. General
   2. Por proveedor y lanzador
      1. AWS API Gateway
      2. Azure Cloud Shell
      3. GitHub Actions
   3. Comparación de lanzadores
2. ¿Cómo instalar?
   1. Instalar Go
   2. Clonar y compilar IPSpinner
   3. Limpiar compilaciones
3. ¿Cómo usar?
   1. General
      1. Argumentos de línea de comandos
      2. Archivo de configuración
   2. Por proveedor
      1. AWS
      2. Azure
      3. GitHub
4. ¿Cómo...?
   1. ¿Soporte HTTP/2?

I/ ¿Cómo funciona?

1) General

Figura 1: IPSpinner - Diagrama general

IPSpinner funciona como un proxy local que redirige las solicitudes a través de servicios externos. Para ello, IPSpinner utiliza proveedores y lanzadores (launchers).

Un proveedor corresponde a un proveedor de nube o a un proveedor de servicios en línea (AWS, Azure, GitHub, etc.) que ofrece diferentes servicios, denominados lanzadores, que pueden utilizarse para retransmitir las solicitudes del usuario (AWS API Gateway, GitHub Actions, Azure Cloud Shell, etc.).

Por lo tanto, para ejecutar IPSpinner, el usuario deberá proporcionar credenciales para los proveedores que quiera utilizar y configuraciones adicionales para los lanzadores. Se pueden usar varios tipos de lanzadores al mismo tiempo; IPSpinner elegirá aleatoriamente uno de los disponibles para cada solicitud.

Además, IPSpinner implementa una función de precarga. Algunos lanzadores pueden precargarse para evitar la demora de reconfiguración en caso de que el proxy vea un nuevo host. Para estos lanzadores, el procedimiento de precarga es recomendable pero no obligatorio. Para los demás, no es necesaria ninguna precarga.

2) Por proveedor y lanzador

i. AWS API Gateway

Introducción

IPSpinner puede utilizar AWS API Gateway para enviar solicitudes. Esta implementación se basa en FireProx, que crea una API Gateway REST para redirigir las solicitudes entrantes. FireProx se ha adaptado para manejar múltiples hosts por API Gateway e implementar nuevas funciones. En resumen, cuando IPSpinner recibe una solicitud, selecciona o crea la instancia de API Gateway adecuada y envía la solicitud hacia el destino. Luego, recopila la respuesta y la devuelve al usuario. De este modo, el servidor de destino recibe la solicitud desde la API Gateway y no directamente del usuario. Dado que API Gateway rota su IP de salida en cada solicitud, IPSpinner usa esta característica para rotar la dirección IP.

Figura 2: AWS API Gateway - Diagrama general

El siguiente gráfico, realizado en octubre de 2024, muestra el número de direcciones IP únicas disponibles por región de AWS según el número de solicitudes enviadas. La mayoría de las regiones ofrecen más de 100 direcciones IP y se pueden usar varias regiones al mismo tiempo, lo que permite al usuario enrutar sus solicitudes a través de miles de direcciones de todo el mundo.

Figura 3: AWS API Gateway - Direcciones IP disponibles por región

Finalmente, la Figura 4 muestra, con un nivel de color verde logarítmico, cuántas direcciones están disponibles por país. Esto demuestra que el usuario tiene la posibilidad de falsear su dirección IP de origen con direcciones de cualquier continente.

Figura 4: AWS API Gateway - Direcciones IP por país

Detalles a tener en cuenta

IPSpinner implementa una función de rotación que elimina y renueva periódicamente las instancias FireProx creadas. Como muestra el siguiente gráfico, rotar una instancia de FireProx puede entregar un nuevo subconjunto de IP. Sin embargo, cada región de AWS tiene un conjunto limitado de IP y, por lo tanto, en algún momento las rotaciones no entregarán IP nuevas.

Figura 5: AWS API Gateway - Proceso de rotación

Este lanzador implementa un procedimiento de precarga. Como se ha dicho antes, no es obligatorio, pero puede evitar demoras de reconfiguración o errores de sincronización durante los primeros segundos después de ser reconfigurado.

Además, las API Gateway establecen por defecto una cabecera X-Forwarded-For, que no se puede eliminar pero sí sobrescribir. Así, el usuario puede especificar en la configuración de IPSpinner un rango de direcciones IP del cual se elegirá una IP aleatoria para cada solicitud (rango IPv4 o IPv6).

ii. Azure Cloud Shell

Introducción

IPSpinner utiliza Azure Cloud Shell para enviar solicitudes. Azure Cloud Shell es una terminal interactiva, autenticada y accesible desde el navegador para administrar recursos de Azure. Cloud Shell se ejecuta en un host temporal proporcionado por sesión y por usuario.

De este modo, IPSpinner utiliza varios usuarios de Azure para los cuales se prepara una sesión de Cloud Shell. Luego, cada solicitud se redirige a un Cloud Shell inicializado, antes de que este se renueve para restablecer su dirección IP.

Figura 6: Azure Cloud Shell - Diagrama general

Como muestra el siguiente gráfico, las diferentes regiones disponibles para desplegar sesiones de Cloud Shell ofrecen cada una decenas de direcciones IP. El usuario puede configurar varias regiones al mismo tiempo para aumentar su pool de IP.

Figura 7: Azure Cloud Shell - Direcciones IP disponibles por región

Sin embargo, las direcciones IP están más concentradas que en AWS API Gateway. Como ilustra el siguiente mapa, la mayoría se encuentran en EE. UU., Europa e India.

Figura 8: Azure Cloud Shell - Direcciones IP por país

Detalles a tener en cuenta

Debido a la demora del proceso de renovación de Cloud Shell, recomendamos limitar la tasa de solicitudes. Más información en la subsección comparación de lanzadores.

iii. GitHub Actions

Introducción

IPSpinner también puede aprovechar GitHub Actions para enviar solicitudes. Esta implementación está inspirada en git-rotate, pero ha sido completamente modificada y adaptada para eliminar el servidor de captura.

Crea un repositorio con una plantilla de flujo de trabajo predefinida. Luego, para cada solicitud, ejecuta el flujo de trabajo proporcionando la información de la solicitud a través de las variables de entorno. Todos los datos están cifrados para que un usuario externo no pueda leerlos. Finalmente, IPSpinner recopila los datos de respuesta de los registros del flujo de trabajo.

Figura 9: GitHub Actions - Diagrama general

La siguiente figura muestra que GitHub Actions ofrece miles de direcciones IP diferentes.

Figura 10: GitHub Actions - Direcciones IP disponibles por región

Sin embargo, el siguiente mapa ilustra que GitHub Actions solo ofrece direcciones IP americanas. Tras el análisis, parece que sus workers están desplegados en una infraestructura de Azure.

Figura 11: GitHub Actions - Direcciones IP por país

Detalles a tener en cuenta

⚠️ Además, "GitHub se toma muy en serio el abuso y el spam de Actions, y cuenta con un equipo dedicado a rastrear a los “usuarios spammer”.". Por lo tanto, el usuario NO DEBE utilizar este proveedor con su cuenta personal ni con la cuenta de la empresa para evitar problemas de cierre de cuenta.

Debido al límite por hora de la API REST de GitHub, se debe limitar la tasa máxima de solicitudes para evitar cualquier interrupción. Más información en la subsección comparación de lanzadores.

3) Comparación de lanzadores

II/ ¿Cómo instalar?

1) Instalar Go

Este proyecto se ha probado con una versión de Go >= 1.21, pero puede funcionar con versiones anteriores de Go.

Consulte la documentación de instalación de Go

Después de la instalación, asegúrese de que el binario de Go predeterminado sea el correcto:

$ go version
go version go1.21.1 linux/amd64

2) Clonar y compilar IPSpinner

$ git clone https://github.com/synacktiv/IPSpinner.git
$ cd IPSpinner
$ go mod tidy

$ make build-linux # For Linux AMD64 arch
$ make build-windows # For Windows AMD64 arch

El ejecutable se llamará por defecto "ipspinner" en Linux o "ipspinner.exe" en Windows.

3) Limpiar compilaciones

Al finalizar su uso, puede limpiar las compilaciones ejecutando

$ make clean

III/ ¿Cómo usar?

1) General

Para obtener ayuda sobre el uso de IPSpinner, puede ejecutar el comando sin argumentos:

$ ./ipspinner -h
    Help will be displayed

Toda la información (excluyendo las redirecciones de solicitudes) se registra en el archivo ipspinner.log.

Algunas opciones comunes están disponibles como argumentos, y el resto de la información de configuración debe proporcionarse en un archivo de configuración INI.

i. Argumentos de línea de comandos

El usuario puede especificar algunos argumentos de línea de comandos:

Algunos parámetros globales y de proveedores deben especificarse en un archivo de configuración INI. El archivo de configuración debe prepararse antes de ejecutar IPSpinner. Su contenido se explicará en las siguientes subsecciones. Por defecto, IPSpinner busca un archivo de configuración llamado config.ini.

Para gestionar solicitudes https, IPSpinner necesita un certificado de Autoridad de Certificación (CA) y una clave. Si el usuario no proporciona un certificado, IPSpinner generará su propio certificado autofirmado y clave. El usuario puede solicitar recuperar el certificado generado con --export-ca-cert (p. ej., para importarlo en el navegador). De lo contrario, el usuario puede proporcionar su propio certificado CA y clave en el archivo de configuración (consulte las siguientes secciones).

El usuario puede especificar el host y el puerto de escucha con --host y --port.

Por último, hay tres modos verbose disponibles:

• --v: imprime los registros de creación
• --vv: igual que --v e imprime las redirecciones de solicitudes
• --vvv: igual que --vv e imprime información detallada de las solicitudes

ii. Archivo de configuración

Además, hay una plantilla para el archivo de configuración INI disponible en el repositorio del proyecto.

En la sección proxy, el usuario puede especificar algunos parámetros:

Todas las demás secciones se describirán en el capítulo correspondiente al proveedor.

Es importante tener en cuenta que el usuario puede habilitar varios proveedores y lanzadores al mismo tiempo. IPSpinner elegirá entonces un lanzador aleatorio entre todos los disponibles para cada solicitud.

2) Por proveedor

i. AWS

Parámetros de configuración para AWS, en la sección aws:

Parámetros de configuración para las API Gateway, en la sección aws:

ii. Azure

Parámetros de configuración para Azure, en la sección azure:

Parámetros de configuración para Azure Cloud Shell, en la sección azure:

iii. GitHub

Parámetros de configuración para GitHub, en la sección github:

Parámetros de configuración para GitHub Actions, en la sección github:

IV/ ¿Cómo...?

1) ¿Soporte HTTP/2?

IPSpinner no soporta el protocolo HTTP/2. Dado que el proxy termina la primera conexión TLS, las ventajas del protocolo se pierden y la conexión aparece como una conexión HTTP/1.1 básica.

Por lo tanto, para evitar problemas con HTTP/2 al usar IPSpinner con Burp Suite, elimine el soporte de cliente HTTP/2: Settings > Network > HTTP > HTTP/2 > Desmarque la casilla HTTP/2.