Analiza ataku (część 3)

Analiza ataku (część 1)
Analiza ataku (część 2)

Don Parker

W części 2 tej serii zostawiliśmy wszystkie niezbędne informacje potrzebne do przeprowadzenia ataku na sieć ofiary. Mając to na uwadze, przejdźmy do właściwego ataku. Atak ten polega na przesłaniu kilku programów żądających, aby móc przeprowadzić atak dalej.

Nie ma sensu po prostu zaatakować komputera, a następnie się wycofać, więc przeprowadzimy silny atak. Zazwyczaj celem złośliwego ataku jest nie tylko zwiększenie swojej obecności w sieci komputerowej, lecz także jej utrzymanie. Oznacza to, że atakujący nadal chce ukrywać swoją obecność i wykonywać inne działania.

Interesujące kwestie

Teraz wykorzystamy Metasploit Framework do przeprowadzenia prawdziwego ataku. Ten mechanizm działania jest naprawdę interesujący, ponieważ umożliwia prowadzenie wielu różnych typów wydobycia, a także oferuje wiele różnych opcji przy wyborze ładunków. Być może nie potrzebujesz narzędzia odwrotnego ani wstrzykiwania VNC. Ładunek często zależy od przyszłego celu, architektury sieci i efektu końcowego. W tym przypadku zrobimy to za pomocą narzędzia odwrotnego. Często jest to korzystniejsze podejście, szczególnie w przypadkach, gdy nasz cel znajduje się za routerem i nie ma do niego bezpośredniego dostępu. Na przykład, „trafiasz” na serwer WWW, ale obciążenie jest nadal zrównoważone. Nie ma gwarancji, że będzie można się z nim połączyć za pomocą narzędzia do przekazywania, dlatego należy uruchomić na komputerze narzędzie do przekazywania. Nie będziemy omawiać sposobu korzystania z Metasploit Framework, ponieważ być może zostanie to omówione w innym artykule. Skupmy się więc na takich kwestiach jak poziomy pakietów.

Tym razem zamiast stosować metodę wprowadzania każdego kroku ataku za pomocą krótkich obrazów i fragmentów kodu, zaprezentujemy inny atak. Atak zostanie odtworzony przy pomocy Snort. Wykorzystamy binarny dziennik przeprowadzonego ataku, a następnie przeanalizujemy go za pomocą Snort. W idealnym świecie wyglądałoby to tak, jak wszystko, co zrobiliśmy. W rzeczywistości zostanie wdrożony pakiet dowodowy. Celem jest sprawdzenie, jak dokładnie możemy odtworzyć to, co się wydarzyło. Mając to na uwadze, wykorzystamy binarny dziennik pakietów, który rejestruje wszystko, co zostało wykonane, i przeanalizujemy go za pomocą Snort, stosując niektóre z jego domyślnych reguł.

Dane wyjściowe narzędzia Snort

Składnia używana do wywołania narzędzia Snort jest następująca:

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

Ta składnia powoduje, że Snort analizuje pakiet binarny o nazwie article_binary. Wynik pokazano poniżej. Skróciliśmy dane wyjściowe Snort, aby móc szczegółowo przeanalizować każdą sekcję.

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

Ta sekcja jest interesująca, ponieważ w wyniku jednego ataku wygenerowano 63 alerty. Przyjrzymy się plikowi alert.ids, który może dostarczyć wielu szczegółów na temat tego, co się wydarzyło. Teraz, jeśli pamiętasz, pierwszą rzeczą, jaką zrobił atakujący, było użycie narzędzia Nmap do przeprowadzenia skanowania sieci, co spowodowało również wygenerowanie pierwszego alertu wyzwolonego 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]

W ten sposób atakujący użył programu netcat do enumeracji serwera WWW i ustalenia jego typu. Ta czynność nie spowodowała żadnych alertów Snort. Chcemy się również dowiedzieć, co się stało, więc przyjrzyjmy się bliżej dziennikowi pakietu. Po zaobserwowaniu standardowej procedury nawiązania połączenia TCP/IP naszym oczom ukaże się poniższy 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%[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.

Nie ma w tym pakiecie niczego niezwykłego poza faktem, że ma żądanie GET, po którym następują pewne problemy wewnętrzne, takie jak na przykład slslsl. Tak więc w rzeczywistości Snort nie ma nic do roboty. W związku z tym skonstruowanie skutecznego podpisu (lub podpisu) systemu IDS w celu wywołania próby enumeracji tego typu jest bardzo trudne. Dlatego nie ma takich podpisów. Kolejny pakiet zawiera listę serwerów WWW ofiary.

Po zakończeniu wyliczania atakujący natychmiast wysyła do serwera WWW kod uruchamiający exploit. Ten kod zwróci pewne wyniki po włączeniu podpisów Snort. Konkretnie w przypadku exploita pokazanego poniżej możemy zaobserwować ten podpis 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]

Gdy atakujący uzyska dostęp do serwera WWW, zacznie używać klienta TFTP do przesyłania 4 plików: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Po przesłaniu plików atakujący używa programu netcat, aby wysłać narzędzie z powrotem na swój komputer. Stamtąd może odłączyć inne narzędzie, które powstało w wyniku pierwotnego ataku, i wykonać całą pozostałą pracę w narzędziu netcat. Co ciekawe, Snort nie zarejestrował żadnej z czynności wykonanych przez atakującego za pomocą narzędzia odwrotnego. Jednak niezależnie od tego, atakujący użył rootkita, którego przesłał poprzez TFTP, aby ukryć informacje o procesach netcata.

Podsumowanie

W części trzeciej tego cyklu pokazaliśmy atak z wykorzystaniem narzędzia Snort. Możemy całkowicie odtworzyć jedną z rzeczy, które zostały zrobione, za wyjątkiem wykorzystania rootkita. Mimo że IDS to bardzo przydatna technologia i element systemu obrony sieci, nie zawsze działa idealnie. System IDS może Cię ostrzegać tylko o ruchu, który wykryje. Mając to na uwadze, w ostatniej części tej serii nauczymy się, jak budować podpisy Snort. Przy okazji nauczymy się testować podpis cyfrowy (podpis) aby ocenić jego skuteczność.