Portal Zarządzających Bezpieczeństwem

Teraz przejdźmy do samego włamania. Po nim nastąpi przekazanie niektórych programów wymaganych, aby haker mógł ponownie uzyskać dostęp do komputera ofiary. Nie byłoby sensu włamać się do komputera, a potem się wycofać. Zazwyczaj celem jakiegokolwiek złośliwego hakera jest nie tylko wejście do sieci komputera, ale także utrzymanie się w niej. Oznacza to próbę ukrycia swojej obecności.

Czas na zabawę

Teraz skorzystam z Metasploit Framework, aby ułatwić samo włamanie. To narzędzie jest naprawdę piękną sprawą, oferującą wielką różnorodność exploitów i – co jest tak samo ważne – wielu różnych opcji „payload” do wyboru. Pewnie nie zawsze będziesz chciał mieć zwrotną powłokę albo wprowadzać VNC. Payload będzie często zależeć od najbliższego celu, architektury sieci i Twojego celu końcowego. W naszym przypadku posłużymy się powłoką zwrotną. Jest to zawsze korzystne, a szczególnie w przypadku, gdy Twój cel jest za routerem i nie jest bezpośrednio dostępny. Na przykład: uderzasz w serwer sieciowy, ale jest on jednym z kilku, które mają wyrównane obciążenie. Nie ma gwarancji, że będziesz w stanie się z nim połączyć za pomocą powłoki typu „forward” i dlatego chcesz, aby komputer przerzucił powłokę z powrotem do Ciebie. Nie będę omawiał rzeczywistego użycia Metasploit Framework do tego celu, ponieważ jest to coś, co omawiałem już kilka razy w innych artykułach. Skupimy się na tym, jak to wszystko wygląda na poziomie pakietu.

Teraz zamiast omawiania każdego kroku włamania za pomocą zrzutów ekranu i fragmentów kodu, przyjmiemy inną taktykę. To co zrobimy, to odtworzenie włamania za pomocą systemu Snort. Przyjmiemy binarny rejestr włamania, którego dokonałem, a następnie sparsuję go do systemu Snort, aby zobaczyć to, co on zobaczył. Idealnie: zobaczył to wszystko, co i ja zobaczyłem. W rzeczywistości to, co zrobimy będzie analizą pakietu. Celem będzie zobaczenie tego, jak precyzyjnie możemy przejść do złożenia dokładnie tego, co się stało. Przyjmę tutaj binarny rejestr pakietu, który nagrał wszystko co zrobiłem i sparsuję to do systemu Snort ze swoim domyślnym zestawem reguł na właściwym miejscu.

Dane wyjściowe systemu Snort

Składnia użyta do wywołania snortu jest następująca:

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

To z kolei spowodowało, że Snort sparsował pakiet binarny nazwany article_binary, czego wynikiem były poniższe dane wyjściowe. Skróciłem dane wyjściowe systemu Snort do istotnych części, aby się nie rozpisywać.

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

Interesującą nas częścią jest fakt, że 63 alerty były spowodowane czynnością włamania. Teraz przyjrzymy się plikowi alert.ids, który da nam bardziej szczegółowe informacje na temat tego, co się wydarzyło. Teraz, jeśli pamiętasz, pierwszą rzeczą, jaką zrobił haker było użycie Nmap do skanowania sieci. Tak się składa, że jest to pierwszy alert wywołany przez 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]

Następnie haker użył narzędzia netcat do określenia serwera sieciowego, aby dowiedzieć się jakiego był typu. Ta próba określenia nie wywołała żadnych alertów Snort. Z ciekawości dlaczego tak się stało przyglądniemy się rejestrowi pakietu. Zaraz po zobaczeniu normalnego porozumienia TCP/IP typu „three way handshake”, widoczny był następujący pakiet:

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% Ten adres email jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
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.

Nie ma nic zadziwiającego w tym pakiecie ponad fakt, że wystąpiła prośba GET z paroma bezużytecznymi danymi jak potwierdza slslsl. Tak więc w rzeczywistości Snort nie miał czego wywołać. Raczej trudno byłoby zbudować skuteczny podpis IDS do wywołania tej próby określenia systemu. I prawdopodobnie dlatego nie ma takich podpisów. Kolejnym pakietem po tym jest ten, gdzie serwer sieciowy ofiary określa sam siebie.

Po wyliczeniu haker natychmiast wysłał kod „exploit” do serwera sieciowego. Kod ten powoduje, że wywołanych zostaje kilka podpisów Snort. Zobaczyłem taki podpis Snort dla konkretnego exploitu pokazanego poniżej.

[**] [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]

Następnie po tej serii alertów, Snort uruchamia serię alertów TFTP. W momencie gdy haker zdobył dostęp do serwera sieciowego, rozpoczął stosowanie wbudowanego klienta TFTP do przesłania czterech plików: nc.exe, ipeyes.exe, fu.exe, msdirectx.exe. Po przetransportowaniu tych plików, haker zastosował netcat, aby wysłać powłokę z powrotem do swojego komputera. Od tego momentu rozłączył poprzednią powłokę, której użył do zapoczątkowania ataku, a całą pozostałą pracę wykonał w powłoce netcat. Interesującym jest fakt, że żadna z postępujących aktywności dokonanych przez hakera poprzez powłokę zwrotną nie została odnotowana przez Snort. Nie została odnotowana, chociaż haker zastosował rootkit, przetransportowany przy użyciu TFTP, w celu ukrycia informacji procesowej dla netcat. Może to być rozczarowaniem dla kogoś, kto oczekiwał, że wystarczy użyć rootkita fu.exe do uruchomienia podpisu IDS.

W trzeciej części tej serii artykułów zobaczyliśmy włamanie, które zostało dokonane przez hakera jak to widział Snort. Byliśmy w stanie odtworzyć prawie wszystko, co zostało zrobione z wyjątkiem użycia rootkita. I chociaż IDS jest całkiem pomocną technologią i powinna być częścią zabezpieczenia Twoich sieci, nie jest ona idealna. Będzie Cię powiadamiać tylko o ruchu w sieci, dla których posiada podpisy. Mając to na uwadze, powinniśmy się nauczyć, jak budować podpisy Snort i to będzie tematem ostatniej części tej serii artykułów. Ponadto zobaczymy także jak sprawdzić te podpisy, aby zweryfikować ich efektywność. Do zobaczenia.