Analisi di un attacco (parte 3)

Analisi di un attacco (Parte 1)
Analisi di un attacco (Parte 2)

Don Parker

Nella seconda parte di questa serie abbiamo lasciato tutte le informazioni necessarie per un attacco alla rete della vittima. Con questo in mente, passiamo all'attacco vero e proprio. Questo attacco comporta la trasmissione di più programmi di richiesta per poter proseguire nello sfruttamento di un attacco.

Non avrebbe senso attaccare semplicemente un computer e poi ritirarsi, quindi sferreremo un attacco più forte. Solitamente l'obiettivo di un aggressore malintenzionato non è solo quello di aumentare la propria presenza su una rete informatica, ma anche di mantenerla. Ciò significa che l'aggressore vuole continuare a nascondere la sua presenza ed eseguire altre azioni.

Questioni interessanti

Ora useremo Metasploit Framework per facilitare un attacco reale. Questo meccanismo di funzionamento è davvero interessante perché offre molti tipi diversi di mining e molte opzioni diverse quando si tratta di scegliere i carichi utili. Forse non vuoi un'utilità inversa o un'iniezione VNC. Il carico utile spesso dipende dal bersaglio imminente, dall'architettura della rete e dall'obiettivo finale. In questo caso lo faremo con un'utilità inversa. Spesso questo è l'approccio più vantaggioso, soprattutto nei casi in cui il nostro obiettivo si trova dietro il router e non è direttamente accessibile. Ad esempio, si "colpisce" un server web ma il carico è ancora bilanciato. Non c'è alcuna garanzia che sarà possibile connettersi ad esso tramite un'utilità di inoltro, quindi sarà opportuno che il computer generi un'utilità di inversione. Non spiegheremo come utilizzare Metasploit Framework, poiché questo argomento potrebbe essere trattato in un altro articolo. Quindi concentriamoci solo su aspetti come i livelli dei pacchetti.

Questa volta, invece di utilizzare il metodo che prevede di introdurre ogni fase dell'attacco con brevi immagini e frammenti di codice, presenteremo un attacco diverso. Ciò che verrà fatto sarà ricreare l'attacco con l'aiuto di Snort. Utilizzeremo il log binario dell'attacco che abbiamo eseguito, quindi lo analizzeremo tramite Snort. L'ideale sarebbe che assomigliasse a tutto quello che abbiamo fatto. Infatti, ciò che verrà implementato è un pacchetto di prova. L'obiettivo qui è vedere con quanta accuratezza possiamo ricostruire quanto accaduto. Tenendo presente ciò, utilizzeremo il registro dei pacchetti binari che registra tutto ciò che è stato eseguito e lo analizzeremo tramite Snort utilizzando alcune delle sue regole predefinite.

Output di Snort

La sintassi utilizzata per richiamare Snort è la seguente:

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

Questa sintassi fa sì che Snort analizzi un pacchetto binario denominato article_binary; il risultato è mostrato di seguito. Abbiamo troncato l'output di Snort in modo da poter esaminare ogni sezione in dettaglio.

==============================================================
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

Questa sezione è interessante perché sono stati attivati ​​63 avvisi a seguito di un'azione di attacco. Esamineremo il file alert.ids, che può fornire molti dettagli su quanto accaduto. Ora, se ricordate, la prima cosa che ha fatto l'attaccante è stata usare Nmap per eseguire una scansione di rete, che ha anche creato il primo avviso attivato da 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]

In questo modo, l'attaccante ha utilizzato netcat per enumerare il webserver e scoprire di che tipo di webserver si tratta. Questa azione non ha attivato alcun avviso Snort. Vogliamo anche scoprire cosa è successo, quindi diamo un'occhiata più da vicino al registro del pacchetto. Dopo aver osservato la consueta procedura di handshake TCP/IP, vedremo il pacchetto qui sotto.

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%[email protected].
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.

Non c'è nulla di notevole in questo pacchetto, a parte il fatto che ha una richiesta GET con alcuni problemi interni che la seguono, come ad esempio slslsl. Quindi in realtà Snort non ha nulla da fare. È quindi molto difficile costruire una firma IDS efficace (o una firma) per attivare questo tipo di tentativo di enumerazione. Ecco perché non esistono firme di questo tipo. Il pacchetto successivo è quello in cui si elenca il server web della rete vittima.

Una volta completata l'enumerazione, l'aggressore invia immediatamente al webserver un codice per eseguire l'exploit. Questo codice fornirà quindi alcuni risultati con le firme Snort abilitate. Nello specifico, per l'exploit mostrato di seguito, possiamo vedere questa firma 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]

Una volta che l'aggressore ha ottenuto l'accesso al server web, inizierà a utilizzare il client TFTP per trasferire 4 file: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Una volta trasferiti i file, l'aggressore utilizza netcat per inviare un'utilità al suo computer. Da lì, può disconnettere l'altra utilità risultante dall'attacco iniziale e svolgere tutto il lavoro rimanente nell'utilità netcat. È interessante notare che nessuna delle azioni eseguite dall'aggressore tramite l'utilità inversa è stata registrata da Snort. Tuttavia, nonostante ciò, l'aggressore ha utilizzato un rootkit trasmesso tramite TFTP per nascondere le informazioni sui processi a netcat.

Conclusione

Nella terza parte di questa serie abbiamo visto un attacco dimostrato utilizzando Snort. Possiamo ricreare completamente una delle cose che sono state fatte, fatta eccezione per l'utilizzo del rootkit. Anche se l'IDS è una tecnologia piuttosto utile e fa parte del sistema di difesa della rete, non è sempre perfetto. Gli IDS possono avvisarti solo del traffico che riescono a rilevare. Con questo in mente, impareremo come creare firme Snort nell'ultima parte di questa serie. Oltre a ciò, impareremo anche come testare una firma digitale per valutarne l'efficacia.