Analisando um Ataque (Parte 3)

Analisando um Ataque (Parte 1)
Analisando um Ataque (Parte 2)

Dom Parker

Na parte 2 desta série, apresentamos todas as informações necessárias para um ataque à rede da vítima. Com isso em mente, vamos passar para um ataque real. Este ataque envolve a transmissão de alguns dos programas necessários para que possamos explorar o ataque com mais profundidade.

Seria inútil simplesmente atacar um computador e depois recuar, então faremos um ataque forte. Normalmente, o objetivo de um invasor malicioso não é apenas aumentar sua presença em uma rede de computadores, mas mantê-la. Isso significa que eles querem continuar a ocultar sua presença e realizar outras ações.

Coisas

interessantes : Agora, usaremos o Metasploit Framework para facilitar o ataque em si. Isso é realmente interessante porque oferece muitos tipos diferentes de exploits e muitas opções diferentes na hora de escolher um payload. Talvez você não queira um utilitário reverso ou uma injeção VNC. O payload geralmente depende do seu próximo alvo, da sua arquitetura de rede e do seu objetivo final. Nesse caso, usaremos um utilitário reverso. Essa costuma ser a melhor abordagem, especialmente se o nosso alvo estiver atrás de um roteador e não for diretamente acessível. Por exemplo, você acessa um servidor web, mas ele está com balanceamento de carga. Não há garantia de que você conseguirá se conectar a ele com um utilitário de encaminhamento, então você precisará que seu computador gere um utilitário reverso. Não abordaremos como usar o Metasploit Framework, pois isso pode ser abordado em outro artigo. Então, vamos nos concentrar em coisas como o nível do pacote.

Desta vez, em vez de passar pelo processo de mostrar cada etapa do ataque com capturas de tela e trechos rápidos, mostraremos um ataque diferente. O que faremos é recriar o ataque com a ajuda do Snort. Pegaremos o log binário do ataque que realizamos e o analisaremos pelo Snort. Idealmente, ele verá tudo como nós vimos. Na verdade, o que executaremos é um pacote de demonstração. O objetivo aqui é ver como podemos juntar exatamente o que aconteceu. Com isso em mente, pegaremos o log do pacote binário que capturou tudo o que aconteceu e o analisaremos pelo Snort usando algumas de suas regras padrão.

Saída do Snort

A sintaxe usada para invocar o Snort é a seguinte:

C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full

Essa sintaxe faz com que o Snort analise um pacote binário chamado article_binary, cuja saída é mostrada abaixo. Truncamos a saída do Snort para que possamos examinar cada parte em detalhes.

==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

Esta parte é interessante porque há 63 alertas que foram disparados por um ataque. Analisaremos o arquivo alert.ids, que pode nos dar muitos detalhes sobre o que aconteceu. Agora, se você se lembra, a primeira coisa que o invasor fez foi usar o Nmap para escanear a rede, o que também gerou o primeiro alerta disparado pelo Snort.

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]

Dessa forma, o invasor usou o netcat para listar o servidor web e descobrir qual era o seu tipo. Essa ação não acionou nenhum alerta do Snort. Também queremos descobrir o que aconteceu, então vamos analisar o log de pacotes mais detalhadamente. Após observar o handshake TCP/IP usual, vemos o seguinte pacote.

15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%t@...u...o.
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

Não há nada de extraordinário neste pacote, exceto o fato de conter uma requisição GET seguida por algo como slslsl. Portanto, na realidade, não há nada que o Snort possa fazer. Seria muito difícil construir uma assinatura IDS eficaz para acionar esse tipo de tentativa de enumeração. É por isso que não existem tais assinaturas. O próximo pacote é onde o servidor web da rede da vítima se enumera.

Após a enumeração, o invasor envia imediatamente um código para executar o exploit no servidor web. Esse código retornará uma saída com as assinaturas do Snort habilitadas. Especificamente para o exploit mostrado abaixo, podemos ver esta assinatura do Snort.

[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

Assim que o invasor obtiver acesso ao servidor web, ele começará a usar o cliente TFTP para transferir quatro arquivos: nc.exe, ipeye.exe, fu.exe e msdirectx.exe. Após a transferência desses arquivos, o invasor usa o netcat para enviar um utilitário reverso de volta ao seu computador. A partir daí, ele pode desconectar outro utilitário, o utilitário resultante do ataque inicial, e executar todo o trabalho restante no utilitário netcat. Curiosamente, nenhuma das ações executadas pelo invasor por meio do utilitário reverso foi registrada pelo Snort. No entanto, independentemente disso, o invasor usou o rootkit que transferiu via TFTP para ocultar as informações do processo para o netcat.

Conclusão

Na parte três desta série, vimos o ataque demonstrado usando o Snort. Podemos recriar completamente uma das coisas que foram feitas, exceto pelo uso do rootkit. Embora um IDS seja uma peça de tecnologia bastante útil e parte das defesas da sua rede, ele nem sempre é perfeito. Os IDSs só podem alertá-lo sobre o tráfego que eles podem detectar. Com isso em mente, veremos como criar assinaturas Snort na parte final desta série. Ao longo do caminho, também veremos como testar uma assinatura para verificar sua eficácia.