Analizarea unui atac (Partea 3)

Analizarea unui atac (Partea 1)
Analiza unui atac (Partea a 2-a)

Don Parker

În partea 2 a acestei serii, am lăsat toate informațiile necesare pentru un atac asupra rețelei victimei. Având în vedere asta, să trecem la un atac real. Acest atac presupune transmiterea mai multor programe de solicitare pentru a putea merge mai departe in exploatarea unui atac.

Ar fi inutil să atacăm pur și simplu un computer și apoi să ne retragem, așa că vom face un atac puternic. De obicei, scopul unui atacator rău intenționat nu este doar de a-și crește prezența într-o rețea de computere, ci și de a o menține. Asta înseamnă că atacatorul dorește în continuare să-și ascundă prezența și să efectueze alte acțiuni.

Probleme interesante

Acum vom folosi Metasploit Framework pentru a facilita un atac real. Acest mecanism de lucru este cu adevărat interesant, deoarece vă oferă multe tipuri diferite de minerit, precum și multe opțiuni diferite atunci când vine vorba de alegerea sarcinilor utile. Poate că nu doriți un utilitar invers sau o injectare VNC. Sarcina utilă depinde adesea de ținta viitoare, arhitectura rețelei și obiectivul final. În acest caz, o vom face cu o utilitate inversă. Aceasta este adesea abordarea mai avantajoasă, mai ales în cazurile în care ținta noastră se află în spatele routerului și nu este direct accesibilă. De exemplu, „loviți” un server web, dar încărcarea este încă echilibrată. Nu există nicio garanție că va fi posibil să vă conectați la acesta cu un utilitar înainte, așa că veți dori ca computerul dvs. să genereze un utilitar invers. Nu vom acoperi cum să folosiți Metasploit Framework, deoarece este posibil să fi fost tratat într-un alt articol. Deci, să ne concentrăm doar pe lucruri precum nivelurile pachetelor.

De data aceasta, în loc să folosim metoda de introducere a fiecărui pas de atac cu imagini scurte și fragmente de cod, vom prezenta un atac diferit. Ceea ce se va face este să recreați atacul cu ajutorul lui Snort. Vom profita de jurnalul binar din atacul pe care l-am efectuat, apoi îl vom analiza prin Snort. Ideal ar arăta ca tot ce am făcut. De fapt, ceea ce va fi implementat este un pachet de probă. Scopul aici este să vedem cât de exact putem pune cap la cap ceea ce sa întâmplat. Având în vedere asta, vom folosi jurnalul de pachete binar care a înregistrat tot ce a fost executat și îl vom analiza prin Snort folosind unele dintre regulile sale implicite.

Ieșire Snort

Sintaxa folosită pentru a invoca Snort este următoarea:

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

Această sintaxă determină Snort să analizeze un pachet binar numit article_binary, rezultatul este afișat mai jos. Am trunchiat ieșirea Snort, astfel încât să putem privi fiecare secțiune în detaliu.

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

Această secțiune este interesantă deoarece au existat 63 de alerte declanșate de o acțiune de atac. Ne vom uita la fișierul alert.ids, care poate oferi o mulțime de detalii despre ceea ce s-a întâmplat. Acum, dacă vă amintiți că primul lucru pe care l-a făcut atacatorul a fost să folosească Nmap pentru a efectua o scanare a rețelei, aceasta a creat și prima alertă care a fost declanșată de 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]

În acest fel, atacatorul a folosit netcat pentru a enumera serverul web pentru a afla ce tip de server web este acesta. Această acțiune nu a declanșat nicio alertă Snort. De asemenea, vrem să aflăm ce s-a întâmplat, așa că haideți să aruncăm o privire mai atentă la jurnalul pentru pachet. După ce respectăm procedura obișnuită de strângere de mână TCP/IP, vom vedea pachetul de mai jos.

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.

Nu este nimic remarcabil la acest pachet, în afară de faptul că are o solicitare GET, cu unele probleme interne, cum ar fi slslsl, de exemplu. Deci, în realitate, Snort nu are nimic de făcut. Prin urmare, este foarte dificil să construiți o semnătură IDS (sau semnătură) eficientă pentru a declanșa acest tip de încercare de enumerare. De aceea nu există astfel de semnături. Următorul pachet de după acesta este locul în care se listează serverul web al rețelei victime.

Odată ce enumerarea este făcută, atacatorul trimite imediat un cod pentru a executa exploit-ul către serverul web. Acest cod va da apoi niște rezultate cu semnăturile Snort activate. În special pentru exploit-ul prezentat mai jos putem vedea această semnătură 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]

Odată ce atacatorul a obținut acces la serverul web, va începe să folosească clientul TFTP pentru a transfera 4 fișiere: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Odată ce aceste fișiere au fost transferate, atacatorul folosește netcat pentru a trimite un utilitar înapoi la computerul său. De acolo, el poate deconecta celălalt utilitar care a rezultat în urma atacului inițial și poate face toată munca rămasă în utilitarul netcat. Interesant este că niciuna dintre acțiunile efectuate de atacator prin intermediul utilitarului invers nu a fost înregistrată de Snort. Cu toate acestea, indiferent de asta, atacatorul a folosit un rootkit pe care l-a transmis prin TFTP pentru a ascunde informațiile de proces pentru netcat.

Concluzie

În partea a treia a acestei serii, am văzut un atac demonstrat folosind Snort. Putem recrea complet unul dintre lucrurile care au fost făcute, cu excepția utilizării rootkit-ului. Chiar dacă IDS este o tehnologie destul de utilă și o parte a sistemului dvs. de apărare a rețelei, nu este întotdeauna perfect. IDS-urile vă pot avertiza doar asupra traficului pe care îl poate detecta. Având în vedere acest lucru, vom învăța cum să construim semnături Snort în partea finală a acestei serii. Odată cu asta, vom învăța și cum să testăm o semnătură digitală (semnătură) pentru a-i evalua eficacitatea.