XTP???

Jeden z monitorowanych przeze mnie IDSów "złapał" bardzo ciekawy pakiet. Nie powinien dotrzeć (przy dobrze skonfigurowanym firewallu), ale przyroda płata figle;)

ff ff ff ff ff ff 00 1a 64 27 57 03 08 00 45 00 ........ d'W...E.
00 00 00 00 ff 0c 08 36 34 32 37 35 37 30 ff ff .......6 427570..
ff ff 00 44 00 43 01 1e 2b 72 01 01 06 00 64 27 ...D.C.. +r....d'
57 19 00 00 80 00 00 00 00 00 00 00 00 00 00 00 W....... ........
00 00 00 00 00 00 00 1a 64 27 57 03 00 00 00 00 ........ d'W.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00 00 00 00 00 00 63 82 53 63 35 01 01 33 04 ff ......c. Sc5..3..
ff ff ff 0c 08 36 34 32 37 35 37 30 33 37 03 01 .....642 757037..
03 06 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

Czy to XTP? (IP proto = 36)

Whois mówi o amerykańskich serwerach:

NetRange: 55.0.0.0 - 55.255.255.255
CIDR: 55.0.0.0/8
NetName: ARMY-RCAS
NetHandle: NET-55-0-0-0-1
Parent:
NetType: Direct Allocation
NameServer: NS01.ARMY.MIL
NameServer: NS02.ARMY.MIL
NameServer: NS03.ARMY.MIL
Comment:
RegDate: 1996-10-26
Updated: 2007-04-06

A co na to wikipedia?

Xpress Transport Protocol (XTP) is a transport layer protocol for high-speed networks promoted by the XTP Forum developed to replace TCP. XTP provides protocol options for error control, flow control, and rate control. Instead of separate protocols for each type of communication, XTP controls packet exchange patterns to produce different models, e.g. reliable datagrams, transactions, unreliable streams, and reliable multicast connections.
XTP does not employ congestion avoidance algorithms. XTP is a real-time option at Layer 4 for the US Navy SAFENET LAN Profile.

Tak czy siak, mam okazję żeby nauczyć się czegoś nowego - z XTP wcześniej się nie spotkałem. Ba! Nawet nie słyszałem;)

Defragmentacja, reasemblacja i oszukiwanie IDSów - cz. III

Po długiej przerwie czas na przedstawienie kilku przykładów związanych z fragmentacją pakietów i wykorzystaniem Snorta. Aby móc przetestować nasz próbny IDS, skorzystam z programu fragroute. Powstał on w celu ułatwienia testowania systemów ID przy wykorzystaniu technik opisanych w publikacji: ``Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection''.

Fragroute korzysta z pliku konfiguracyjnego. W pliku tym możemy definiować sposób w jaki chcemy aby nasz ruch się zachowywał. Dla przykładu, poniższy wpis w pliku konfiguracyjnym spowoduje, że wygenerowany ruch tcp będzie wysyłany w porcjach po 14 bajtów danych (payloadu) oraz właściwe dane pojawią się w pakietach wysłanych na początku a każdy nakładający się pakiet (o powtórzonym numerze sekwencyjnym tcp) będzie zawierał śmieci.

tcp_seg 14 old
print

Aby podzielić na fragmenty ruch wysyłany do maszyny docelowej wystarczy w konsoli uruchomić program w poniższy sposób:

fragroute -f plik_konfiguracyjny.conf 192.168.1.17

gdzie host o adresie 192.168.1.17 będzie celem naszych testów. Po uruchomieniu Fragroute cały ruch z komputera źródłowego do komputera docelowego będzie odpowiednio zmodyfikowany.

Do dalszych rozważań, komputer o adresie 192.168.1.21 będzie źródłem ruchu a 192.168.1.17 celem; dodatkowo na 192.168.1.17 uruchomiony będzie Snort (Debian linux).

Po zainstalowaniu i skonfigurowaniu Snorta, uruchomiłem go z włączonym preprocesorem frag3 oraz poniższą regułą. Jeśli więc przyjdzie połączenie do serwera, którego zawartość będzie pasowała do łańcucha "to jest sesja testowa zawierajaca lancuch wojtekw jeden raz" to wyświetlony zostanie alarm z informacją zawartą w parametrze msg.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"WOJTEKW string to server"; flow:to_server,established; content:"to jest sesja testowa zawierajaca lancuch wojtekw jeden raz"; sid:2000001;)

Aby móc oglądać alarmy na ekranie trzeba uruchomić opcję "-A console":

snort -i eth0 -c snort.conf -l ./ -A console

Po uruchomieniu Snorta, trzeba sprawdzić czy działa prawidłowo wysyłając do niego pakiety zawierające wcześniej ustalony łańcuch. Do tych celów świetnie nadaje się netcat, przez który komunikujemy się z dowolnym nasłuchującym portem testowanej maszyny. W dalszej części wykorzystywałem do tego port ssh gdyż jest to standardowo uruchomiona usługa w linuxie i nie musiałem przeprowadzać dodatkowych konfiguracji. Po nawiązaniu połączenia wkleiłem interesujący nas łańcuch i wysłałem do celu przez wciśnięcie klawisza ENTER; w tym przypadku nie jest ważne, że połączenie ssh nie zostało nawiązane, ponieważ celem jest wysłanie jakichkolwiek danych tak żeby zostały odebrane przez docelowy komputer. Stąd zwrócony błąd od serwera SSH: Protocol mismatch.

wojtek@grafzero:~$ nc 192.168.1.17 22
SSH-2.0-OpenSSH_4.3p2 Debian-9
to jest sesja testowa zawierajaca lancuch wojtekw jeden raz
Protocol mismatch.

11:35:36.192686 IP 192.168.1.21.56864 > 192.168.1.17.ssh: P 1:61(60) ack 32 win 92
0x0000: 4500 0070 35e6 4000 4006 8332 c0a8 0115 E..p5.@.@..2....
0x0010: c0a8 0111 de20 0016 d76c d688 e54b af50 .........l...K.P
0x0020: 8018 005c 4185 0000 0101 080a 0948 f881 ...\A........H..
0x0030: 0095 57ff 746f 206a 6573 7420 7365 736a ..W.to.jest.sesj
0x0040: 6120 7465 7374 6f77 6120 7a61 7769 6572 a.testowa.zawier
0x0050: 616a 6163 6120 6c61 6e63 7563 6820 776f ajaca.lancuch.wo
0x0060: 6a74 656b 7720 6a65 6465 6e20 7261 7a0a jtekw.jeden.raz.

Jak widać testowy ciąg znaków został przetransportowany jednym pakietem (wyszczególniłem tylko właściwy pakiet) co spowodowało wygenerowanie alertu przez Snorta:

03/18-11:35:37.010489 [**] [1:2000001:0] WOJTEKW string to server [**] [Priority: 0] {TCP} 192.168.1.21:56864 -> 192.168.1.17:ssh

Tak więc mamy pewność, że dane dochodzą a IDS działa prawidłowo.

W takim razie możemy przejść do dalszych badań. Snort został uruchomiony tylko z preprocesorem frag3, stąd pakiety IP będą składane w całość prawidłowo. Jeśli szukany łańcuch zmieści się w jednym pakiecie TCP to zostanie wykryty bez problemu tak jak to miało miejsce w pożyszym przykładzie. A co się stanie jeśli te same dane wyślemy w wielu pakietach TCP? Sprawdźmy!

Na jednej z wirtualnych konsol uruchomiłem fragroute, który podzielił ruch na pakiety z 14bajtowym payloadem. Na innej ponownie włączyłem netcata.

grafzero:/home/wojtek# fragroute -f fragroute.conf 192.168.1.17
fragroute: tcp_seg -> print
192.168.1.21.51812 > 192.168.1.17.ssh: S 4282832080:4282832080(0) win 5840 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: . ack 266999924 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: . ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: P 4282832081:4282832095(14) ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: P 4282832095:4282832109(14) ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: P 4282832109:4282832123(14) ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: P 4282832123:4282832137(14) ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: P 4282832137:4282832141(4) ack 266999955 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: . ack 266999974 win 92 (DF)
192.168.1.21.51812 > 192.168.1.17.ssh: F 4282832141:4282832141(0) ack 266999975 win 92 (DF)

A tak wyglądają wysłane dane (dla czytelności tylko wybrane pakiety):

11:46:14.864143 IP 192.168.1.21.51812 > 192.168.1.17.ssh: P 0:14(14) ack 32 win 92
0x0000: 4500 0042 8a6a 4000 4006 2edc c0a8 0115 E..B.j@.@.......
0x0010: c0a8 0111 ca64 0016 ff46 d4d1 0fea 1893 .....d...F......
0x0020: 8018 005c 3cfd 0000 0101 080a 0952 b759 ...\<........R.Y
0x0030: 009f cb2e 746f 206a 6573 7420 7365 736a ....to.jest.sesj
0x0040: 6120 a.

11:46:14.864188 IP 192.168.1.21.51812 > 192.168.1.17.ssh: P 14:28(14) ack 32 win 92
0x0000: 4500 0042 65ce 4000 4006 5378 c0a8 0115 E..Be.@.@.Sx....
0x0010: c0a8 0111 ca64 0016 ff46 d4df 0fea 1893 .....d...F......
0x0020: 8018 005c e39d 0000 0101 080a 0952 b759 ...\.........R.Y
0x0030: 009f cb2e 7465 7374 6f77 6120 7a61 7769 ....testowa.zawi
0x0040: 6572 er

11:46:14.864205 IP 192.168.1.21.51812 > 192.168.1.17.ssh: P 28:42(14) ack 32 win 92
0x0000: 4500 0042 089f 4000 4006 b0a7 c0a8 0115 E..B..@.@.......
0x0010: c0a8 0111 ca64 0016 ff46 d4ed 0fea 1893 .....d...F......
0x0020: 8018 005c 1708 0000 0101 080a 0952 b759 ...\.........R.Y
0x0030: 009f cb2e 616a 6163 6120 6c61 6e63 7563 ....ajaca.lancuc
0x0040: 6820 h.

11:46:14.864221 IP 192.168.1.21.51812 > 192.168.1.17.ssh: P 42:56(14) ack 32 win 92
0x0000: 4500 0042 9460 4000 4006 24e6 c0a8 0115 E..B.`@.@.$.....
0x0010: c0a8 0111 ca64 0016 ff46 d4fb 0fea 1893 .....d...F......
0x0020: 8018 005c f7d5 0000 0101 080a 0952 b759 ...\.........R.Y
0x0030: 009f cb2e 776f 6a74 656b 7720 6a65 6465 ....wojtekw.jede
0x0040: 6e20 n.

11:46:14.864238 IP 192.168.1.21.51812 > 192.168.1.17.ssh: P 56:60(4) ack 32 win 92
0x0000: 4500 0038 071c 4000 4006 b234 c0a8 0115 E..8..@.@..4....
0x0010: c0a8 0111 ca64 0016 ff46 d509 0fea 1893 .....d...F......
0x0020: 8018 005c 06c1 0000 0101 080a 0952 b759 ...\.........R.Y
0x0030: 009f cb2e 7261 7a0a ....raz.

Łańcuch został podzielony na części i wysłany kilkoma pakietami. Niestety IDS nie wykrył tego łańcucha, ponieważ nie potrafił go złożyć do postaci takiej jak otrzymał to serwer sshd nasłuchujący na tym porcie. Tym samym atak się powiódł lecz nie został wykryty.

W jaki sposób się przed tym bronić? Produkt Sourcefire daje nam możliwość reasemblacji także pakietów TCP. Dawniej do tego celu używany był preprocesor stream4, obecnie jest do dyspozycji stream w wersji piątej - stream5. Stream5 w przeciwieństwie do starszego modułu, potrafi składać fragmenty TCP tak jak to robi obserwowany system operacyjny lecz trzeba go odpowiednio skonfigurować. Gdy skonfiguruje się nieprawidłowo, można w prosty sposób oszukać system ID.

W poniższym przykładzie konfiguracja stream5 jest bardzo prosta. W parametrach globanych ustawiłem tylko śledzenie połączeń TCP, reszta jest w tym przypadku niepotrzebna.

preprocessor stream5_global: track_tcp yes, \
track_udp no, \
track_icmp no

Następnie dla protokołu TCP przyporządkowałem następujące parametry:

preprocessor stream5_tcp: \
policy first, \
ports both 22

Parametr "policy first" oznacza, że Snort do reasemblacji będzie brał pod uwagę dane w pakietach wysłanych na początku. Jeśli w systemie monitorowanym, stos sieciowy zachowuje się w ten sposób, to wszystko będzie ok. Spróbujmy więc powtórzyć poprzedni sprawdzian, dzieląc ruch na części.

grafzero:/home/wojtek# fragroute -f fragroute.conf 192.168.1.17
fragroute: tcp_seg -> print
192.168.1.21.56837 > 192.168.1.17.ssh: S 796536500:796536500(0) win 5840 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: . ack 1109316671 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: . ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: P 796536501:796536515(14) ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: P 796536515:796536529(14) ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: P 796536529:796536543(14) ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: P 796536543:796536557(14) ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: P 796536557:796536561(4) ack 1109316702 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: . ack 1109316721 win 92 (DF)
192.168.1.21.56837 > 192.168.1.17.ssh: F 796536561:796536561(0) ack 1109316722 win 92 (DF)

Tym razem Snort poradził sobie z zadaniem i wyświetlił alarm:

03/18-12:05:14.105488 [**] [1:2000001:0] WOJTEKW string to server [**] [Priority: 0] {TCP} 192.168.1.21.56837 -> 192.168.1.17.ssh

Czyli system ID działa tak jak chcemy:) Czyżby? Przecież Linux faworyzuje dane przesłane w najnowszych pakietach a stream5 został ustawiony na odwrót. Jest więc okazja na przeprowadzenie udanego ataku typu EVASION:D System detekcji odrzuci najnowsze pakiety.

Wyślemy ten sam łańcuch, ale w nakładających się pakietach. Systemem docelowym jest Linux więc zreasembluje pakiety, które zostały nałożone najpoźniej. Do pliku konfiguracyjnego fragroute dodajemy new:

tcp_seg 14 new
print

19:59:51.333152 IP 192.168.1.21.42789 > 192.168.1.17.ssh: P 14:28(14) ack 42 win 92
0x0000: 4500 0042 83e1 4000 4006 335e c0a8 0115 E..B..@.@.3^....
0x0010: c0a8 0111 a725 0016 39a4 b563 59e0 5251 .....%..9..cY.RQ
0x0020: 8018 005c 40cb 0000 0101 080a 0b16 a0c5 ...\@...........
0x0030: 0000 7ecd 6944 5068 316d 5a31 5646 3059 ..~.iDPh1mZ1VF0Y
0x0040: 7900 y.

19:59:51.333171 IP 192.168.1.21.42789 > 192.168.1.17.ssh: P 42:56(14) ack 42 win 92
0x0000: 4500 0042 5609 4000 4006 6136 c0a8 0115 E..BV.@.@.a6....
0x0010: c0a8 0111 a725 0016 39a4 b57f 59e0 5251 .....%..9...Y.RQ
0x0020: 8018 005c 92a4 0000 0101 080a 0b16 a0c5 ...\............
0x0030: 0000 7ecd 5277 6258 3941 4645 345a 5545 ..~.RwbX9AFE4ZUE
0x0040: 3500 5.

19:59:51.333179 IP 192.168.1.21.42789 > 192.168.1.17.ssh: P 56:60(4) ack 42 win 92
0x0000: 4500 0038 6f5f 4000 4006 47ea c0a8 0115 E..8o_@.@.G.....
0x0010: c0a8 0111 a725 0016 39a4 b58d 59e0 5251 .....%..9...Y.RQ
0x0020: 8018 005c 992a 0000 0101 080a 0b16 a0c5 ...\.*..........
0x0030: 0000 7ecd 7261 7a0a ..~.raz.

19:59:51.333198 IP 192.168.1.21.42789 > 192.168.1.17.ssh: P 0:28(28) ack 42 win 92
0x0000: 4500 0050 b644 4000 4006 00ed c0a8 0115 E..P.D@.@.......
0x0010: c0a8 0111 a725 0016 39a4 b555 59e0 5251 .....%..9..UY.RQ
0x0020: 8018 005c bfa9 0000 0101 080a 0b16 a0c5 ...\............
0x0030: 0000 7ecd 746f 206a 6573 7420 7365 736a ..~.to.jest.sesj
0x0040: 6120 7465 7374 6f77 6120 7a61 7769 6572 a.testowa.zawier

19:59:51.333203 IP 192.168.1.21.42789 > 192.168.1.17.ssh: P 28:56(28) ack 42 win 92
0x0000: 4500 0050 7370 4000 4006 43c1 c0a8 0115 E..Psp@.@.C.....
0x0010: c0a8 0111 a725 0016 39a4 b571 59e0 5251 .....%..9..qY.RQ
0x0020: 8018 005c ae08 0000 0101 080a 0b16 a0c5 ...\............
0x0030: 0000 7ecd 616a 6163 6120 6c61 6e63 7563 ..~.ajaca.lancuc
0x0040: 6820 776f 6a74 656b 7720 6a65 6465 6e20 h.wojtekw.jeden.

Powyżej widać że najpierw zostały wysłane śmieci - bajty 14:28(14), 42:56(14). Następnie fragment szukanego ciągu znaków: 56:60(4), a dalej właściwe, nakładające się dane 0:28(28), 28:56(28). Tym samym atak się powiódł, lecz nie został wykryty - brak alertu.

Pozostało nam już tylko sprawdzić, jak zachowa się IDS w tym samym teście, lecz skonfigurowany prawidłowo:

preprocessor stream5_tcp: \
policy linux, \
ports both 22

Po restarcie Snorta, powtórzono próbę. Poniżej widać nakładające się pakiety:

grafzero:/home/wojtek# fragroute -f fragroute.conf 192.168.1.17
fragroute: tcp_seg -> print
192.168.1.21.42799 > 192.168.1.17.22: S 1235196251:1235196251(0) win 5840 (DF)
192.168.1.21.42799 > 192.168.1.17.22: . ack 1788877048 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: . ack 1788877089 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: P 1235196266:1235196280(14) ack 1788877089 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: P 1235196252:1235196280(28) ack 1788877089 win 92 (DF) [delay 0.001 ms]
192.168.1.21.42799 > 192.168.1.17.22: P 1235196294:1235196308(14) ack 1788877089 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: P 1235196280:1235196308(28) ack 1788877089 win 92 (DF) [delay 0.001 ms]
192.168.1.21.42799 > 192.168.1.17.22: P 1235196308:1235196312(4) ack 1788877089 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: . ack 1788877108 win 92 (DF)
192.168.1.21.42799 > 192.168.1.17.22: F 1235196312:1235196312(0) ack 1788877109 win 92 (DF)
192.168.1.21.42790 > 192.168.1.17.22: . ack 1548706571 win 1002 (DF) [tos 0x10]

grafzero:/home/wojtek# nc 192.168.1.17 22
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.6
to jest sesja testowa zawierajaca lancuch wojtekw jeden raz
Protocol mismatch.

Tym razem zdarzenie zostało wykryte:

03/18-19:36:14.613567 [**] [1:2000001:0] WOJTEKW string to server [**] [Priority: 0] {TCP} 192.168.1.21:42799 -> 192.168.1.17:22

W powyższych przykładach widać jak ogromne znaczenie ma odpowiednie skonfigurowanie systemu detekcji intruzów w zależności od monitorowanego systemu operacyjnego. Przez długi czas wykrycie tego typu ataków było w zasadzie niemożliwe. Obecnie mamy do dyspozycji kolejne bardzo dobre narzędzie, które daje nam ogromne możliwości wykrywania nieprawidłowych zdarzeń w sieci.

19.03.2008
W konfiguracji stream5_tcp usunąłem "overlap_limit 1" ponieważ w tym przypadku nie wprowadzało to nic do treści a mogło zaciemnić tekst. Opcja ta byłaby użyteczna np. z włączonym detect_anomalies.

ISSA Wrocław

Pierwsze spotkanie ISSA we Wrocławiu przeszło do historii. Sala konferencyjna banku BZ WBK w Rynku wypełniona była po brzegi. Biorąc pod uwagę nieoficjalne grudniowe spotkanie, na którym omawialiśmy sprawy organizacyjne, frekwencja tym razem była oszałamiająca;)

Tematem przewodnim styczniowego wydarzenia, było bezpieczeństwo aplikacji webowych. W prezentacjach omówiono rodzaje i przykłady ataków na aplikacje www oraz sposoby obrony. Po zakończeniu części oficjalnej odbyło się "afterparty" . Niestety tym razem zmęczenie i obowiązki uniemożliwiły mi zakończenia w ten sposób środowego wydarzenia:(

Bardzo się cieszę, że lokalne środowisko bezpieczników się uaktywnia. Od tej pory spotkania powinny odbywać się co miesiąc a może nawet częściej. Najbardziej nie mogę się doczekać tych w konwencji BYOL a także czegoś w rodzaju SANS ICE GAMES.

P.S.

Do tej pory nie wpadłem na to, że można użyć googla do "odszyfrowania" haseł w md5 ;) np. takich:

9743a66f914cc249efca164485a19c5c

:P