tcstool/fireawayHerramienta de auditoría y evasión de cortafuegos de próxima generación
v0.2
FireAway es una herramienta para auditar, eludir y extraer datos contra reglas de inspección de capa 7/AppID en cortafuegos de nueva generación, así como otros mecanismos de defensa de inspección profunda de paquetes, como la prevención de pérdida de datos (DLP) y proxies conscientes de aplicaciones. Estas tácticas se basan en el principio de tener que permitir conexiones establecidas a través del NGFW para poder ver los datos de la capa 7 y filtrarlos, así como suplantar aplicaciones para ocultar canales de comunicación dentro de los registros del cortafuegos como tráfico normal de usuario, como la navegación por Internet. En el caso de eludir herramientas de prevención de pérdida de datos, FireAway envía datos en pequeños "fragmentos", que no coinciden con los activadores de expresiones regulares y otras reglas DLP, además de incrustar datos en cabeceras HTTP suplantadas de aplicaciones legítimas que la mayoría de las tecnologías de prevención de pérdida de datos no están diseñadas para inspeccionar. La herramienta también ha tenido éxito al derrotar motores de detección de anomalías y heurísticas gracias a su capacidad para suplantar cabeceras de aplicaciones y ocultar datos dentro de ellas.
Iniciando el Servidor FireAway: Normalmente, el servidor FireAway se iniciaría en el lado de salida del cortafuegos (como un servidor en Internet) y escucharía en un puerto que se cree cerrado para ver si alguna regla basada en aplicaciones permite el tráfico saliente en este puerto, o para recibir fragmentos de datos sin procesar y ver si DLP o proxies de aplicaciones pueden identificarlos:
python fa_server.py <puerto a escuchar> <número de modo>
El servidor puede iniciarse en cuatro modos:
Modo de prueba (modo 0): Recibe datos enviados secuencialmente o datos de prueba generados aleatoriamente. Los datos se escriben tal como se reciben y no se requiere reensamblaje.
Recepción secuencial de fragmentos (modo 1): Los datos se envían a uno o más servidores en tamaños de fragmento definidos por el cliente de forma secuencial. Fa_server registrará la marca de tiempo en que se recibió el fragmento en la salida y usará el tiempo de recepción como clave de orden durante el reensamblaje. También se generará una "clave de reensamblaje" por parte del servidor para usarse con fa_assembler.py. Esta es una clave de 4 caracteres generada aleatoriamente que se utiliza como delimitador entre fragmentos, con la idea de que estos caracteres no existan en los fragmentos de datos que se transmiten.
Recepción aleatoria de fragmentos (modo 2): Los datos se envían a uno o más servidores en orden aleatorio. Este modo depende de la transmisión de un mensaje de "clave de secuencia" desde el cliente a un servidor aleatorio del grupo. Al iniciar cada servidor, el servidor solicitará ingresar un "identificador de clave de secuencia". Este debe ser un patrón que no esté presente en el archivo que se está transmitiendo para que el servidor pueda identificar correctamente los datos recibidos a través de una conexión como la clave de secuencia. ¡ASEGÚRESE DE USAR EL MISMO IDENTIFICADOR DE CLAVE DE SECUENCIA EN TODOS LOS SERVIDORES! El cliente seleccionará aleatoriamente un servidor para transmitir la clave de secuencia, por lo que es importante que todos los servidores puedan localizar la clave de secuencia en sus datos recibidos. La clave de secuencia será registrada por el servidor receptor en un archivo llamado 'SequenceKey.txt'.
Recepción de fragmentos con aplicación suplantada (modo 3): Los datos codificados en Base64 se envían a uno o más servidores dentro de cabeceras HTTP que suplantan aplicaciones legítimas. Este modo también generará una "clave de reensamblaje" para usar con el script fa_assembler.
Todos los datos recibidos por los servidores en el puerto especificado se guardarán en el archivo ReceivedData.txt en el directorio desde el cual se inició el servidor. Si el servidor detecta tamaños diferentes en la cantidad de datos recibidos (lo que indica que el filtrado del cortafuegos ha intervenido), esta salida se mostrará en la consola del servidor:
Se obtuvo la misma cantidad o menor de datos en dos ejecuciones consecutivas. Si se envían datos de prueba, es posible que se haya alcanzado el tamaño máximo de fuga de datos.
Iniciando el Cliente FireAway / Suplantador de Aplicaciones: El cliente FireAway tiene tres modos:
Modo de prueba (modo 0): Enviar datos aleatorios en tamaños de fragmento crecientes para ver cuántos datos se pueden enviar antes de que los controles de capa 7 se activen y detengan el flujo de tráfico.
Modo de exfiltración secuencial (modo 1): Abrir un archivo y enviarlo en fragmentos de un tamaño especificado. Los datos se transmitirán secuencialmente.
Modo de exfiltración aleatorio (modo 2): Abrir un archivo y enviarlo en fragmentos de un tamaño especificado, pero en orden aleatorio. Al usar este modo, el cliente solicitará el identificador de la clave de secuencia. Este es el valor especificado en los servidores remotos, y el cliente etiquetará la clave de secuencia generada con el identificador, que se transmite a un servidor aleatorio si se proporciona una lista o a la IP del servidor especificada, antes de que se transmita el archivo.
Para iniciar el cliente básico:
python fa_client.py <IP del servidor FireAway o ruta del archivo de lista de servidores> <Puerto del servidor FireAway> <Modo del cliente>
La lista de servidores debe ser un archivo de texto simple que contenga una lista de direcciones IP, una por línea. Si solo se usa un servidor, se puede especificar una sola IP en su lugar.
El cliente de suplantación de aplicaciones tiene tres modos:
Modo de prueba (modo 0): Enviar datos de prueba aleatorios dentro de cabeceras HTTP en fragmentos cada vez más grandes para determinar cuántos datos se pueden enviar antes de que los controles de capa 7 se activen y detengan el flujo de tráfico.
Modo de exfiltración codificada en Base64 (modo 1): Codificar en Base64 un archivo de entrada y transmitir partes del archivo codificado dentro de cabeceras HTTP generadas aleatoriamente para eludir DLP y enmascarar la transmisión como una aplicación legítima.
Para iniciar el cliente de suplantación de aplicaciones:
python fa_spoof.py <IP del servidor FireAway o ruta del archivo de lista de servidores> <Puerto del servidor FireAway> <Modo del cliente>
La suplantación de aplicaciones insertará aleatoriamente cabeceras HTTP dentro de cabeceras de aplicaciones con apariencia legítima (por ejemplo, Facebook, LinkedIn, etc.) con los fragmentos de datos para contaminar los registros con varias aplicaciones y así enmascarar la exfiltración de datos.
Reensamblador Fireaway: El reensamblador FireAway (fa_assembler.py) se utiliza para reensamblar los datos recibidos por los servidores FireAway. El ensamblador tiene tres modos, que corresponden al modo de los servidores que recibieron los datos:
Modo 1: Reensamblar datos que fueron recibidos en orden secuencial por servidores en modo 1. El ensamblador solicitará especificar la clave de reensamblaje para el archivo que contiene los datos recibidos de cada servidor, que es el valor aleatorio que el servidor generó y mostró al iniciarse. Este valor también se puede encontrar examinando los archivos con los fragmentos recibidos y observando los primeros cuatro caracteres.
Modo 2: Reensamblar datos que fueron recibidos en orden aleatorio por servidores en modo 2. El ensamblador solicitará la ruta a la clave de secuencia, que fue recibida del cliente por un servidor aleatorio durante la transmisión. También solicitará las claves de reensamblaje para cada archivo.
Modo 3: Reensamblar datos codificados en Base64 que fueron recibidos en cabeceras HTTP de aplicaciones suplantadas. Estos datos, al igual que el Modo 1, también solicitarán la clave de reensamblaje.
Para iniciar el reensamblador:
python fa_assembler.py <modo de reensamblaje> <rutas separadas por comas a los archivos a reensamblar>
La salida se guardará en el nombre de archivo especificado.
Informe cualquier problema o pregunta a través de Github.