Utrzymywanie stanu systemu

Transkrypt

1 Rozdzia l 9 Utrzymywanie stanu systemu Contents 9.1 Tripwire Rootkits Przyk ladowe rootkity Telnet Pow loka na porcie TCP Adore Knark SSH na wysokim porcie T0rn Pow loka CGI Nas luchuj acy dostȩp na porcie udp Telnet czy pow loka nas luchuj aca na z lamanym hoście Komunikacja przez kana l icmp Odwrócona tunelowana pow loka Firedoor Dostȩp aktywowany specjalnym zdarzeniem (magiczny) Oparty na snifferze Pakiet Q SAdoor Kana l ukryty Ukrywanie informacji Sniffer pos luchiwacz CIPE Istotne jest utrzymanie systemu w stanie nie naruszonym. Tu pracować bed a systemy kontrolujace integralność systemu, takie jak Tripwire. Analogicznie dla atakujacego ważne jest, by po w lamaniu zapewnić sobie dostep do z lamanego hosta. Do tego s luża wszelkie pakiety typu rootkit. 9.1 Tripwire Tripwire jest programem śledzacym stan systemu i monitorujacym wszystkie ewentualne modyfikacje w czu lych miejscach. Konieczne jest zainstalowanie go zaraz po instalacji systemu, najlepiej przed pod l aczeniem do sieci. Pozwoli to wykrywać wszystkie podejrzane modyfikacje systemu, w szczegolności zainstalowane przez napastników programy. 155

2 156 Utrzymywanie stanu systemu 9.2 Rootkits Rootkit jest pakietem s lużacym do utrzymywaniu pożadanego środowiska i dostepu na haście do którego atakujacy uzyska l dostep. Istnieje kilka podstawowych typów metod dostepu telnet czyli po l aczenie z systemem wprost, co nie jest raczej stosowane, bo latwe do wykrycia pow loka na porcie TCP zwiazana z portem i uruchamiana przez inetd; latwe do wykrycia, bo wymaga modyfikacji pliku konfiguracyjnego inetd.conf; analogiczne moga być trojany różnych demonów systemowych ssh na wysokim porcie to na sta le przypisany do portu o wysokim numerze demon sshd; zaleta jest kodowanie komunikacji, przez co trudniejsze do wykrycia, w szczególności pewne podejrzane komendy wykrywane ewentualnie przez IDS-y; ssh pojawi sie w listingu netstat, pod warunkiem, że netstat nie jest strojanowany by nie wypisywać tego konkretnego procesu; pow loka CGI na web serwerze zwykle wykorzystywany gdy administrator wykry l u usuna l podstawowe tylne wejścia; skrypt cgi bedzie wykonywać koemndy i wyświetla swoje listingi w przegladarce nas luchujacy dostep na porcie udp ze wzgledu na to, że rzadziej przeglada sie porty udp niż tcp; konieczna jest definicja jakiegoś protoko lu; może też przydać sie kodowanie telnet czy pow loka nas luchujaca na z lamanym hoście otwierajaca po l aczenie od maszyny zaatakowanej do maszyny atakujacego dzieki czemu zaatakowana maszyna nie bedzie mia la otwartych portów, a także obejdzie zabezpieczenia regu l firewalli; atakujacy musi mieć uruchomiony na swojej maszynie program netcat by nas luchiowa l po l aczeń; może być aktywowane przez specjalny pakiet albo ewentualnie zegar; komunikacja przez kana l icmp czyli bardzo s labo widoczny, np. kana l Loki; taki protokó l nie wykorzystuje żadnych portów, nie bedzie wiec widoczny ani w netstat ani skanowaniu portów; systemy IDS moga być uwrażliwione na dziwne pola w komunikatach icmp odwrócona tunelowana pow loka możliwe przez wykorzystanie takich protoko lów jak http, gdzie jest możliwość komunikowania sie z portem 80: pow loka http bedzie imitować po l aczenie przegladarki wewnatrz strzeżonego obszaru z serwerem webowym na zewnatrz; duża zaleta jest ca lkowita imitacja ruchu http, w zwiazku z czym sa ma le szanse wy lapania przez jakikowliek system IDS; komunikacja inicjowana jest specjalnym magicznym pakietem albo zegarem dostep aktywowany specjalnym zdarzeniem (magiczny) jest po l aczeniem odwróconej pow loki i bezpośredniego po l aczenia: po otrzymaniu specyficznego pakietu, na przyk lad pakietu tcp ze specjalnymi wartościami parametrów, otwierane jest po l aczenie, badź wykonaywana pojedyncza instrukcja oparty na snifferze nie otwiera żadnego portu, lecz rozpoczyna nas luchiwanie ruchu i gdy napotkany zostanie specjalny pakiet, wcale niekonieczne adresowany do atakowanego hosta, wystarczy, że dla niego widzialny, to wykonywana jest akcja; odpowiedź też czesto jest w jakiś sposób fa lszowana, by nie by lo latwo znaleźć atakujacego; w laściwie możliwe do śledzenia tylko na poziomie drugim, a wiec jedynie wewnatrz tej samej sieci lokalnej kana l ukryty w różnych komunikacjach cz esto używanych protoko lów z komunikatami ukrytymi w różnych parametrach; bardzo trudny do wykrycia Pakiety typu rootkit rozprowadzane sa w różny sposób, jako pakiety binarne modu ly jadra biblioteki

3 9.3 Przyk ladowe rootkity Przyk ladowe rootkity Telnet Pow loka na porcie TCP Adore Adore jest robakiem wyszukujacym różne hosty Linuxowe sprawdzajac, czy sa podatne na określony atak. Jeśli taki zostanie znaleziony, to robak podmienia jedynie plik ps usuwajac oryginalny do /usr/bin/adore, który ukrywa procesy robaka, a potem umieszcza swoje pliki w /usr/lib/lib wysy lajac maile z informacja na pewne ustalone adresy, o których nie wiadomo nic. Wysy la tam pliki z has lami, różne informacje o systemie, liste znanych hostów. Wtedy uruchamia progarm icmp, który zaczyna nas luchiwać na ustalonym porcie na pakiety o ustalonej d lugości. Gdy oczekiwany pakiet nadejdzie otwiera pow loke z prawami roota. Raz na dobe uruchamia (o 04:02 czasu lokalnego) proces usuwajacy ślady w lamania, jednak nie swoje oprogramowanie. Adore jest zaimplementowany jako ladowalny modu l (LKM) pozwalajac na dzia lanie jako root, wykonywanie jako root komend, czynienie procesu niewidocznym, a nawet usuniecie LKM. Adore ustanawia nas luchujacy na po l aczenia port. To rozwiazanie jest jednak bardzo nieodporne na znalezienie przez netstat. Adore potrafi jednak ukrywać nie tylko procesy jak i pliki, potrafi też modyfikować wyjście netstat-a. Adore zawira procedure, która przeglada ca le wejście pochodzace od użytkownika i szuka w nich alńcucha netstat. Jeśli znajdzie, to sprawdza w swoich sta lych pod którym numerem ustalony jest port nas luchiwania a nastepnie usuwa z wyjścia netstat-a ta w laśnie linijke! Jednak, co istotne, nie jest to zrobione przez modyfikacje netstat-a!!!! Zmieniona jest natomiast w ladowalnym module procedura write(). Uruchamiana pow loka jest prosta zwyk la pow loka z prawami administratora. Po usunieciu adore z systemu (przez usuniecie modu lu), system wraca do ca lkiem poprzedniego stanu. Przy ostrożnym użyciu atakujacy może pozostać niewykryty. Sygnatury Adore nie czyści logów trzeba tam patrzeć. Oczywiści etrzeba śledzić wszelkie niewyt lumaczone wysokie użycie maszyny w nocy, miejsce na dysku, itp. Jednym z narzedzi bedzie chkrootkit, który szuka wszelkich śladów ladowalnych modu lów porównujac wynik podawany przez ps z tym w /proc. Zabezpieczenie Podstawowa metoda zabezpieczenia jest oczywiście wykluczenie możliwości ladowania modu lów. Także przy rebootowaniu maszyny adore przestaje być już cześci a jadra. Osoba korzystajaca z adore musi wiec napisać odpowiedni skrypt, który bedzie ladowa l modu l od nowa po rebootowaniu. Skrypt bedzie musia l jednak być wywo lany przez jeden ze skryptów inicjujacych, w zwiazku z czym bardzo ważne jest utrzymywanie ich integralności. Innym rootkitem zbudowanym jako ladowalny modu l jest knark Knark Knark jest jest chyba jednym z pierwszych LKM ladowalnych modu lów. Zaprojektowany przez creed@sekure.net. Knark to po szwedzku heroin e. Pozwala na ukrywanie kartotek i plików poleceniem hidef ukrywanie po l aczeń tcp i udp poleceniem nethide wykonywanie redyrekcji wykonywanych procesów, na przyk lad./ered /usr/local/sbin/sshd /usr/lib/sshd-trojan spowoduje, że kiedykolwiek wywo lywany jest sshd, w zamian wykonany b edzie sshdtrojan wzmacnianie przywilejów dla dowolnego użytkownika (polecenie rootme )

4 158 Utrzymywanie stanu systemu zmiane w lasności uruchomionych procesów (uid i gid) poleceniem taskhack; w ten sposób można rozpoczać jakiś proces, a później ustawić, że jest to po prostu proces administratora uprzywilejowany demon wykonujacy zdalne polecenia nas luchujacy na porcie i ukrywajacy swoje istnienie przed ps ukrywanie procesu przez kill -31 wys lane do procesu, co spowoduje ukrycie kartoteki tego procesu z /proc; ukryci bed a także potomkowie tego procesu Lpdx dla wykorzystania procesu lpr T666 dla wykorzystnaia serwisu BIND Wugod dla wykorzystania wu-ftp Poniewaź redyrekcja wykonywania jest robiona w jadrze, procedury kontrolujace pliki niewiele znajda, ponieważ oryginalne pliki wykonywalne zostaja w miejscu. Dodatkowo razem z knarkiem jest modu l modhide, ladowany wcześniej, ktży powoduje, że lsmod nie pokazuje modu lu knarka. Wykrywanie i ochrona Istnieja dedykowane dla knarka narzedzia do jego wykrywania, np. knarkfinder. Porównuje on kartoteki procesów z informacjami o procesach w kartotece /proc/kmem. Nie wykrywa w ten sposób knarka, pokazuje jedynie, że sa jakieś ukryte procesy. Autor knarka mówi zreszta, że obecnie do l acza do dystrybucji knarka w laśnie program knarkfinder, ale jednocześnie poprawi l już sam program tak, by modyfikowa l próby czytania pliku /proc/kmem. Sam zreszta twierdzi w wywiadzie, że problem z udostepnionymi programami wykrywajacymi polega na tym, że szybko można napisać poprawke obchodzac a ta w laśnie metode. Metoda wykrywania może też być uruchomienie nmap dla skanowania portów i uruchomienie netstat dla sprawdzenia, czy te same po l aczenia sa wykrywane. Inna metoda bedzie próba wykonania któregoś z programów w dystrybucji, chociażby rootme, i sprawdzenie, czy dzia la tak jak powinien w przypadku gdy jest to knark. Knark nie wymaga autoryzacji, wiec dowolny użytkownik uzyska prawa. Podstawowa ochrona bedzie zabronienie ladowania modu lów, a zamiast tego budowanie statycznych jader. Jest też dostepny program lcap, który pozwala na usuwanie szeregu różnych praw z jadra od momentu jego wykonania, w szczególności możliwości ladowania modu lów. Można wykonywać lcap zaraz po za ladowaniu systemu SSH na wysokim porcie T0rn Bardzo szybki w instalacji skompilowane pliki, bardzo kompletny: dostajemy narzedzie do czyszczenia logów, sniffer, a także parser logów. t0rn udostepnia zestaw binariów takich jak du, find, ps, pg tworzy hasz dla klucza, ifconfig to samo, ale usuwa flage PROMISC dla ukrycia sniffingu, in.fingerd tworzy nowa pow loke roota, login tylne wejście z możliwościa użycia has la, ls ukrywa niektóre pliki i kartoteki, netstat ukrywa niektóre po l aczenia, pstree ukrywa wskazane procesy, sz modyfikuje rozmiar pliku na podstawie innego pliku, t0rn uruchamia po l aczenie ssh na wysokim (wskazanym) porcie, t0rnp parser logów, t0rns bardzo efektywny sniffer, t0rnsb modyfikator plików logów, top jak top, ale ukrywa niektóre procesy. t0rn udostepniany jest jako zestaw binariów podmieniajacych oryginalne. Zwykle uruchamiany jest sniffer w celu pods luchania wiekszej liczby hase l na innych hostach. t0rn uruchamia serwer ssh na wysokim porcie za pomoca którego możemy sie dostać do atakowanego hosta. Po jego uruchomieniu 1. zatrzymywany jest syslogd 2. sprawdza czy host loguje si e na innym hoście, jeśli tak, to jest znajdywany (albo wiele jest znajdywanych)

5 9.3 Przyk ladowe rootkity tworzony jest plik /etc/ttyhash w którym zapami etywany jest has lo wprowadzone w czasie instalacji dla ssh, telnet i finger 4. rozpakowuje plik ssh.tgz w którym jest nowy demon ssh, nowa konfiguracja ssh, pliki z kluczami prywatnym i publicznym 5. rozmiar i czas utworzenia nowego pliku login sa modyfikowane tak, by by ly identyczne ze starym, po czym nowy jest podmieniany za stary, a stary ukrywany w innej kartotece 6. tworzona jest kartoteka z plikami przechowywujacymi odpowiednie numery procesów i nazwy plików tak, by mog ly być one ukrywane przez podmienione procedury ps, pstree, top, ls, du, find, etc. 7. uruchamiany jest sniffer, logger, log cleaner 8. modyfikowane sa czasy wszystkich plików i kopiowane w miejsce oryginalnych 9. modyfikowana jest konfiguracja demona inetd by zezwolić na wejście przez telnet i finger 10. sprawdzane sa ewentualnie blokujace regu ly zapory 11. usuwana jest kartoteka instalacyjna, a demon syslogd restartowany Wykrywanie i zabezpieczanie podstawowa metoda bed a rozmiary plików, które zmieniaja sie po instalacji, podobnie jak sumy kontrolne. to znowu przypomina o konieczności wykorzystywania programów sprawdzajacych integralność, jak tripwire. Też kontrola otwartych plików programem lsof, który też pokazuje nas luchujace porty. Można też sprawdzać czesto wykorzystywane kartoteki. Warto jednak pamietać o korzystaniu wtedy z pewnych binariów Pow loka CGI Sk lada sie z pliku serwera i klienta. Serwer tworzy strone html dynamicznie, przy czym jeśli podane sa przez klienta parametry, to wykonuje je a wynik wypisuje w przegladarce. Natomiast klient pobiera adres strony cgi z która ma sie po l aczyć, pobiera ze standardowego wejścia komende. Komeny ulegaja wstepnemu przetwarzaniu, a nastepnie wykonywane jest po l aczenie. Po nawiazaniu wysy lana jest odpowienio sformatowana komenda GET z parametrami do skryptu. Po nadejściu odpowiedzi jest ona wypisywana w przegladarce. Oczywista zaleta jest komunikowanie sie z portem demona http. wykrywanie bedzie polega lo na wyszukiwaniu podejrzanych plików typu skryptów cgi na maszynach, które moga być warte ataku Nas luchuj acy dostȩp na porcie udp Telnet czy pow loka nas luchuj aca na z lamanym hoście Komunikacja przez kana l icmp Odwrócona tunelowana pow loka Firedoor Firedoor (napisany w javie) tworzy po l aczenie od systemu na zewnatrz, wed lug schematu [firedoor(listener)]<-- internet <--[FIREWALL]<++ network <++[firedoor(caller)]+>[files] jednak wykorzystuje serwer office gdzie umieszczony jest caller firedoora do przekierowywania po l aczeń gdziekolwiek. W tym celu tworzone sa dwa po laćzenia z caller do listener. Jedno to po l aczenie kontrolne s lużace do przekazywania inforamcji o hoście i porcie, a drugie dynamiczne gdy należy coś przekazać. Caller oczekuje ustalona liczbe sekund by skontaktować sie z na luchujacym listenerem.

6 160 Utrzymywanie stanu systemu Listener potrzebuje otworzenia dwóch portów. Numer portu po l aczenia dynamicznego jest przekazywany callerowi przez port kontrolny. Najpierw uruchamiany jest caller by oczekiwa l ustalony okres czasu, aż do nawiazania po l aczenia ze wskazanym hostem na wskazanym porcie > java -cp. firedoor -m caller -t 900 -h example.domain.com -p potem uruchamiany jest listener z parametrami, by caller powodowal redyrekcje skierowanych do niego po l aczeń na port 22 do wskazanego portu na innym hoście prompt> java -cp. firedoor -m listener -H P 22 -p wtdy wystarczy po l aczyć sie przez ssh do wskazanego portu ssh i nasze po l aczenie bedzie tunelowane do wewnetrznego hosta do kt.orego zwykle nie mielibyśmy po laczenia. Po l aczenie kontrolne zostanie nawiazane po odczekaniu wskazanego czasu Dostȩp aktywowany specjalnym zdarzeniem (magiczny) Oparty na snifferze Pakiet Q To pakiet zdalnego dost epu, który może być wykorzystany w z lych celach. Sk lada si e z pary klienta i serwera: qd demona nas luchujacego na pakiety kontrolne (z qs) i tworzacego nowe pow loki z po l aczeniem kodeowanym lub niekodowanym qs (stealth messanger) wysy lajacy pakiety raw IP do maszyn na których uruchomione sa demony i powodujacy otwarcie nowych pow lok; może być wykonana także pojedyncza komenda q klienta Q l acz acego sie z utworzonymi pow lokami ql demon poziomu użytkownika nas luchujacy na polecenia na ustalonym porcie, można sie z nim po l aczyć przez Q transd tunelowanie sesji czystego tekstu przez kodowany kana l Q; w późniejszych wersjach wbudowany do klienta q Q zapewnia mocne kodowanie. Autorem jest Mixter, ten sam, który stworzy l TFN Tribe Flood Network. Serwer qd wykorzystuje raw sockets do nas luchiwania wszelkiego ruchu tcp, udp, czy icmp na maszynie i rozpoznaje te pakiety, które sa do niego skierowane. Nie sa istotne numery portów ani protoko ly. W ten sposób można wysy lać pakiety do portów, które sa w zasadzie dozwolone przez regu ly firewalla, np. port 80. Kontroler qs qysy la komunikaty na losowe porty, ale może to być sterowane. To inny sposób nas luchiwania niż przez interfejs w trybie promiscuous. qd nas luchuje tylko w warstwie 3 i tylko protoko ly tej warstwy. Kontroler qs pozwala wysy lać do qd komendy, otwierać nowe pow loki, wykonywać pojedyncze komendy, wybierajac protokó l. Koemdy wysy lane sa pakietami SOCK RAW wystarczajaco przypominajacymi pakiety tcp, udp, czy icmp. Możliwe jest etż utworzenie nie pow loki, lecz odbijajacego programu, który bedzie wysy la l otrzymane komendy do innego hosta utrudniajac wykrycie. Wed lug jednego z autorów stosowana jest bardzo sprytna technika: pakiety tcp, udp, a nawet icmp majab l edne sumy kontrolne! Dzieki temu porty na które pakiety zaostaja wysy lane spokojnie nie obs luguja ich, a nie przeszkadza to qd korzystajacego z gniazd typu RAW. Późniejsze wrsje Q obliczaja poprawnie sumy kontralne icmp. Dzieki temu atakowany host nie odsy la komunikatów w stylu reset. Z drugiej strony system IDS może śledzić powtarzajace sie pakiety z z lych sumach kontrolnych. Parametry wywo lania, na przyk lad żadanie kodowania, czy numer portu na którym ma być otwarta pow loka, sa przekazywane w różnych polach pakietu icmp. Komenda qs -i I -p S zażada otwarcia nowej pow loki na porcie 1034 na wskazanym hoście. Klient q kontaktujac sie z uruchomiona pow loka podaje numer identyfikacyjny z którym serwer zosta l skompilowany. Do po l aczenia wykorzystywany jest normalny TCP.

7 9.4 Sniffer pos luchiwacz 161 Wersje 2.0 i 2.4 W kolejnej wersji pojawi la sie biblioteka libmix dla obs lugi pakietów raw tcp, udp i cmp. W trakcie kompilacji generowany jest klucz, króry należy sobie zapisać i usunać plik hash.h. Pozwala to na komunikacje z serwerami z klientów kompilowanych osobno klucz można podać w parametrze. Mixter nazywa to CSA. Do kodowania transmisji używany jest AES. Wersja 2.4 wykorzystuje identyfikacje przy wykorzystaniu algorytmu kluczy publicznych i prywatnych RSA (Rivest, Shamir, Adleman). Domyślna d lugość klucza to 4096 (!!!), która można skrócić przy kompilacji do maksymalnie 1536 dla przyspieszenia. Pakiety tcp i udp maja dalej b l ednie obliczana sume kontrolna, natomiast icmp ma poprawna, ale icmp i tak nie odpowiada w żaden sposób sygna lem b l edu, wiec nie jest to potrzebne. Nag lówek tcp ma zawsze ustawiona d lugość na 0, co może być wykrywane przez IDS. Trudno wykryć, czy by lo to zamierzone, czy nie. Wiekszość parametrów w nag lówkach tcp czy udp generowanych przez qs ma losowe wartości. Wydaje sie, że cześć powinna być generowana poprawnie, by zmniejszyć prawdopodobieństwo wykrycia przez IDS. Uruchomienie sesji przez klienta q jest normalnym po l aczeniem tcp, znormalnymi pakietami (nie raw), a wobec tego możliwe jest pasywne wykrywanie źród la. W trakcie tej fazy wymieniane jest 4096 bitów haszu klucza kodujacego na wydrukach tcpdump latwo zauważyć nag lówek poprzedzajacy klucz, a stad staje sie on dobrym kandydatem na odcisk palca (fingerprint) pozwalajacy na wykrywanie. Możliwe jest odbijanie komend z jednej maszyny na której dzia la demon qd na inna opcja -B. Odpowiedzi wracaja ta sama droga. Ca la komunikacja jest kodowana. Jednak nag lowki poprzedzajace poszczególne czesci komunikatu i identyfikujace ich typ sa, podobnie jak przy kluczu, 24 bitowe i latwo jest znaleźć latwe wzorce je wykrywajace przez sniffer systemowy typu tcpdump czy ethereal dzia laj acy w systemie IDS. Zagrożenia Chociaż Q w zasadzie s luży do komunikacji, może być latwo użyty do celów niecnych, cześciej nawet niż legalnych. Q potrafi ukrywać swoje nazwy procesów a pakiety sa na tyle dobrze kodowane, że trudno jest znaleźć wzorce (fingerprints) pozwalajace na latwe ich wykrywanie. Pozwala na redyrekcje, co czesto jest poczatkiem szerszego ataku. Sygnatury Snort zwykle nie daje sobie rady gdyż wzorce pakietów Q sa zbyt ogólne. NA dodatek d lugość danych jest ustawiana na 0 co myli Snort, który nie wie gdzie pakiet sie kończy! Zwykle wiec zostaje sprawdzanie nielegalnych albo fa lszowanych adresów w pakietach kontrolnych qs. DAne sa kodowane co wyklucza w laściwie wyszukiwanie s lów kluczowych. Najbardziej obiecujace sa lańcuchy nag lówków poprzedzajacych klucz identyfikacyjny. Poza tym konieczne jest kontrolowanie integralności systemu, chciażby za pomoca Tripwire9.1. SAdoor Sk lada sie z demona nas luchujacego na interfejsie sieciowym (NIC -Network Interface Card) na pakiety o ustalonych warto.sciach. Klient Sash jest w stanie je wysy lać. Demon szuka specjalnego klucza w pakietach i wykonuje odpowiednia prace. Pakiety sa kodowane przy użyciu Blowfish. Demon nas luchuje oczekujac najpierw co najmniej jednego pakietu kontrolnego o ściśle określonych parametrach, które zapowiadaja pojawienie sie pakietu z komenda. Ten pakiet IP musi nadejść w czasie nie d luższym niż ustalony i zawiera komende do wykonania Kana l ukryty Ukrywanie informacji 9.4 Sniffer pos luchiwacz 9.5 CIPE

8 162 Utrzymywanie stanu systemu