tcstool/fireawayFerramenta de Auditoria e Bypass de Firewall de Próxima Geração
v0.2
Fireaway é uma ferramenta para auditoria, bypass e exfiltração de dados contra regras de inspeção de camada 7/AppID em firewalls de próxima geração, bem como outros mecanismos de defesa de inspeção profunda de pacotes, como prevenção de perda de dados (DLP) e proxies com conhecimento de aplicativos. Essas táticas baseiam-se no princípio de ter que permitir que conexões sejam estabelecidas através do NGFW para visualizar os dados da camada 7 a serem filtrados, bem como falsificar aplicativos para ocultar canais de comunicação dentro dos logs do firewall como tráfego normal de usuário, como navegação na Internet. No caso de bypass de ferramentas de prevenção de perda de dados, o Fireaway envia dados em pequenos "chunks", que não correspondem a gatilhos de expressões regulares e outras regras de DLP, além de incorporar dados em cabeçalhos HTTP falsificados de aplicativos legítimos que a maioria das tecnologias de prevenção de perda de dados não foi projetada para inspecionar. A ferramenta também teve sucesso em derrotar mecanismos de detecção de anomalias e heurísticas através de sua capacidade de falsificar cabeçalhos de aplicativos e ocultar dados dentro deles.
Iniciando o Servidor FireAway: Normalmente, o servidor FireAway é iniciado no lado de saída do firewall (como um servidor na Internet) e escuta em uma porta que se acredita estar fechada para verificar se alguma regra baseada em aplicativo permite tráfego de saída nessa porta, ou para receber chunks de dados brutos para verificar se DLP ou proxies com conhecimento de aplicativos podem identificá-los:
python fa_server.py <porta para escutar> <número do modo>
O servidor pode ser iniciado em quatro modos:
Modo de teste (modo 0) - Receber dados enviados sequencialmente ou dados de teste gerados aleatoriamente. Os dados são escritos conforme recebidos e nenhuma remontagem é necessária.
Recepção sequencial de chunks (modo 1) - Os dados são enviados para um ou mais servidores em tamanhos de chunk definidos pelo cliente sequencialmente. O fa_server registrará o timestamp de quando o chunk foi recebido na saída e usará o tempo de recebimento como chave de ordem durante a remontagem. Haverá também uma "chave de remontagem" gerada pelo servidor para ser usada com o fa_assembler.py. Esta é uma chave de 4 caracteres gerada aleatoriamente usada como delimitador entre chunks, com a ideia de que esses caracteres não existiriam nos chunks de dados sendo transmitidos.
Recepção aleatória de chunks (modo 2) - Os dados são enviados para um ou mais servidores em ordem aleatória. Este modo depende da transmissão de uma mensagem de "chave de sequência" do cliente para um servidor aleatório no pool. Ao iniciar cada servidor, o servidor solicitará que seja inserido um "identificador de chave de sequência". Este deve ser um padrão não presente no arquivo que está sendo transmitido, para que o servidor possa identificar corretamente os dados recebidos através de uma conexão como a chave de sequência. CERTIFIQUE-SE DE QUE O MESMO IDENTIFICADOR DE CHAVE DE SEQUÊNCIA É USADO EM TODOS OS SERVIDORES! O cliente selecionará aleatoriamente um servidor para transmitir a chave de sequência, então é importante que todos os servidores possam localizar a chave de sequência em seus dados recebidos. A chave de sequência será registrada pelo servidor receptor em um arquivo chamado 'SequenceKey.txt'.
Recepção de chunks de aplicativo falsificado (modo 3) - Dados codificados em Base64 estão sendo enviados para um ou mais servidores dentro de cabeçalhos HTTP falsificando aplicativos legítimos. Este modo também gerará uma "chave de remontagem" para ser usada com o script fa_assembler.
Todos os dados recebidos pelos servidores na porta especificada serão salvos no arquivo ReceivedData.txt no diretório de onde o servidor foi iniciado. Se o servidor detectar tamanhos diferentes na quantidade de dados recebidos (indicando que a filtragem do firewall entrou em ação), esta saída será mostrada no console do servidor:
Got the same or lower amount of data on two consecutive runs. If sending test data, maximum data leak size may have been reached.
Iniciando o Cliente FireAway / Falsificador de Aplicativos: O cliente FireAway tem três modos:
Modo de teste (modo 0) - Enviar dados aleatórios em tamanhos de chunk crescentes para ver quantos dados podem ser enviados antes que os controles da camada 7 entrem em ação e parem o fluxo de tráfego.
Modo de exfiltração sequencial (modo 1) - Abrir um arquivo e enviá-lo em chunks de um tamanho especificado. Os dados serão transmitidos sequencialmente.
Modo de exfiltração aleatória (modo 2) - Abrir um arquivo e enviá-lo em chunks de um tamanho especificado, mas em ordem aleatória. Ao usar este modo, o cliente solicitará o identificador da chave de sequência. Este é o valor especificado nos servidores remotos, e o cliente marcará a chave de sequência gerada com o identificador, que é transmitido para um servidor aleatório, se uma lista for fornecida, ou para o IP do servidor especificado, antes que o arquivo seja transmitido.
Para iniciar o cliente básico:
python fa_client.py <IP do servidor FireAway ou caminho do arquivo de lista de servidores> <Porta do servidor FireAway> <Modo do cliente>
A lista de servidores deve ser um arquivo de texto simples contendo uma lista de endereços IP, um por linha. Se estiver usando apenas um servidor, um único IP pode ser especificado.
O cliente de falsificação de aplicativos tem três modos:
Modo de teste (modo 0) - Enviar dados de teste aleatórios dentro de cabeçalhos HTTP em chunks progressivamente maiores para determinar quantos dados podem ser enviados antes que os controles da camada 7 entrem em ação e parem o fluxo de tráfego.
Modo de exfiltração codificada em Base64 (modo 1) - Codificar em Base64 um arquivo de entrada e transmitir partes do arquivo codificado dentro de cabeçalhos HTTP gerados aleatoriamente para contornar o DLP e mascarar a transmissão como um aplicativo legítimo.
Para iniciar o cliente de falsificação de aplicativos:
python fa_spoof.py <IP do servidor FireAway ou caminho do arquivo de lista de servidores> <Porta do servidor FireAway> <Modo do cliente>
A falsificação de aplicativos irá inserir aleatoriamente cabeçalhos HTTP dentro de cabeçalhos de aplicativos de aparência legítima (por exemplo, Facebook, LinkedIn, etc.) com os chunks de dados para poluir os logs com vários aplicativos, a fim de mascarar a exfiltração de dados.
Remontador Fireaway: O remontador Fireaway (fa_assembler.py) é usado para remontar os dados recebidos pelos servidores Fireaway. O montador tem três modos, que correspondem ao modo dos servidores que receberam os dados:
Modo 1 - Remontar dados que foram recebidos em ordem sequencial por servidores no modo 1. O montador solicitará que seja especificada a chave de remontagem para o arquivo contendo os dados recebidos de cada servidor, que é o valor aleatório que o servidor gerou e exibiu ao ser iniciado. Esse valor também pode ser encontrado examinando os arquivos com os chunks recebidos e observando os primeiros quatro caracteres.
Modo 2 - Remontar dados que foram recebidos em ordem aleatória por servidores no modo 2. O montador solicitará o caminho para a chave de sequência, que foi recebida do cliente por um servidor aleatório durante a transmissão. Também solicitará as chaves de remontagem para cada arquivo.
Modo 3 - Remontar dados codificados em base64 que foram recebidos em cabeçalhos HTTP de aplicativos falsificados. Esses dados, assim como no Modo 1, também solicitarão a chave de remontagem.
Para iniciar o remontador:
python fa_assembler.py <modo de remontagem> <caminhos separados por vírgula para os arquivos a serem remontados>
A saída será salva no nome de arquivo especificado.
Por favor, relate quaisquer problemas ou perguntas através do Github.