Analiza powłamaniowa systemu Linux za pomocą sysdig

02 czerwca 2014, 21:51 | Teksty | komentarzy 13
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Wstęp

Nie tak dawno firma złożona z niewielkiego zespołu – Draios – ogłosiła wydanie narzędzia open source, które nazwała sysdig. Pozwala ono na przechwytywanie, zapisywanie, filtrowanie oraz analizę aktywności różnych procesów w systemie Linux. Jak sami autorzy wspominają, łączy ono w sobie takie narzędzia jak strace, tcpdump oraz lsof.

Dla administratorów systemów może to być jedno z lepszych narzędzi do wyszukiwania i diagnozowania różnych problemów oraz wąskich gardeł pod względem wydajności w systemie [podobne narzędzie dla systemów z rodziny Unix (Solaris, Mac OS X, FreeBSD) stworzył Brendan D. Greggdtrace]. Poświęcając kilka minut na zapoznanie się z jego podstawowym użyciem oraz kilkoma przykładami, jesteśmy w stanie zapomnieć o bólu związanym z badaniem różnych problemów systemu – czy to w środowiskach zwirtualizowanych, czy na „gołym metalu”.

Narzędzie to można również bardzo prosto wykorzystać do stworzenia honeypotu, co udowodnił Gianluca Borello, który dzięki różnym dostawcom (AWS, Rackspace oraz Digital Ocean) stworzył ponad 20 maszyn w chmurze (opartych o system Ubuntu 12.04) z dość ubogą pod względem bezpieczeństwa konfiguracją (serwer SSH umożliwiał zalogowanie się na serwer za pomocą konta „root” przy użyciu hasła: password). Użytkownicy przejmujący się choć trochę bezpieczeństwem swoich systemów w publicznych chmurach bez problemu potwierdzą popularność systematycznego skanowania i ataków brute force na serwery SSH w tego typu środowiskach i sieciach (np. 1757 prób z 242 adresów IP w ciągu 30 dni). Po 4 godzinach jedna z maszyn została skompromitowana. Jednak zanim to nastąpiło, na maszynie został odpalony sysdig, który za pomocą s3fs-fuse zapisywał całą aktywność z maszyny na udział S3.

Od razu można było zauważyć obcą aktywność, ponieważ wielkość jednego z plików odpowiedzialnych za dany host skoczyła z normalnego szumu aktywności systemu operacyjnego wynoszącego mniej więcej 100KB na godzinę do paru megabajtów. Podsłuch maszyny skończył się na pliku o zajętości 150MB. Wstępna analiza procesów wykazała, że serwer już zaczął świadczyć podejrzane usługi (w pierwotnej wersji uruchomiony był tylko daemon SSH):

Sieciowo również serwer nie próżnował, generując blisko 800MB ruchu przez protokół UDP. Możliwe, że maszyna stała się częścią botnetu sterowaną za pomocą sieci IRC do generowania ataków DoS na żądanie.

Za pomocą funkcji spy_users autor pułapki mógł zobaczyć, jakie dokładnie polecenia wydał złośliwy użytkownik:

Agresor stworzył katalog o dość sprytnej nazwie „.shm” w ścieżce /usr/sbin i do niego ściągnął oraz skompilował program pośredniczący pomiędzy klientem a serwerem IRC o nazwie muh. Gianluca był na tyle szybki, że udało mu się ponownie ściągnąć archiwum, w którym znalazł inne ciekawe rzeczy włamywacza, w tym dość spersonalizowane pliki konfiguracyjne, dane różnych użytkowników z hasłami oraz kilka nazw kanałów IRC w sieci Undernet. Przy okazji, pozostając w tematyce sprytnych nazw katalogów wśród włamywaczy – Fernando Duran, korzystając z prostego honeypota SSH – Kippo, zarejestrował ciekawe zdarzenie:

Intruz w tymczasowym katalogu, który zazwyczaj jest udostępniony globalnie do zapisu, stworzył na swój sposób „ukryty” katalog, którego nazwa składała się tylko z jednej [:spacji:], co nie stanowi dość częstego widoku.

Wracając do naszego pierwotnego włamywacza, którego kolejnym krokiem było:

  1. ściągnięcie skryptu perl pod fałszywą postacią ukrytego pliku PDF,
  2. odpalenie go oraz
  3. upewnienie się, że ruch sieciowy na lokalnym firewallu zostanie przepuszczony dla portu 9000 (ruch przychodzący) oraz 6667 (ruch wychodzący – standardowy port serwerów IRC).

Niestety tym razem nie udało się ponownie ściągnąć pliku w celu jego analizy, ale na szczęście sysdig wywołany z parametrem -s 4096, rejestrując każdą operację I/O, zapisywał jej 4096 bajtów danych, a to pozwoliło zobaczyć, co dokładnie program wget zapisał na dysk:

Czyli na serwer został wgrany klient do przeprowadzania ataków DoS z możliwością sterowania nim z sieci IRC tak, aby szkodliwy użytkownik mógł łatwo sterować większą liczbą maszyn. Czytając nagłówek pobranego skryptu perl, można łatwo dojść do wniosku, że wystarczy przesłać klientowi wiadomość IRC „@udp”, aby ten zaczął atakować podany w tej samej wiadomości adres ofiary.

Za pomocą sysdig bardzo łatwo to można sprawdzić:

Jak widać bot otrzymał za pomocą połączenia TCP polecenie zaatakowania adresu IP: 39.115.244.150 na porcie 800 (przez 5 minut), co jest tym samym adresem, do którego wygenerowano na początku przygody z śledztwem blisko 800MB ruchu sieciowego (listing z połączeniami sieciowymi). Wszystko powoli zaczyna nabierać sensu.

Intruz, nie spoczywając na laurach, pomyślał, że warto zapewnić sobie dostęp do maszyny na wszelki wypadek, gdyby hasło do użytkownika root miało się zmienić:

Jak pokazuje Google mafixlibs to rootkit przeznaczony dla systemu Linux 2.6, a do badań teoretycznie możemy go pobrać stąd. Jego zawartość prezentuje się następująco:

Kilka dobrych, skompromitowanych plików binarnych nigdy nie jest złe, więc spy_users powinien również zauważyć, jak atakujący podmienia pliki systemowe:

I w rzeczy samej. Nawet był tak miły, że wykonał kopię zapasową oryginalnego pliku.

Na razie sysdig pozwolił wyjaśnić pochodzenie bota IRC, flood za pomocą pakietów UDP oraz podmienione pliki binarne.

Została tylko jedna rzecz do rozgryzienia. Dlatego topprocs_net pokazał, że cały ruch sieciowy został wygenerowany przez /usr/sbin/httpd (Apache?) oraz /usr/local/apache? – czyli pliki binarne(?), które nie zostały uwzględnione w żadnym poleceniu wychwyconym przez spy_users. Skoro skrypt w perlu został zainstalowany do wysyłania pakietów UDP – może on być odpowiednim tropem.

Możemy sprawdzić wszystkie zdarzenia związane z „/usr/local/apac”:

Przy okazji możemy zobaczyć, kiedy proces skryptu perl o id = 10200 wystartował:

Tak jak można było przewidzieć – proces udający serwer HTTPd jest niczym innym niż wcześniej ściągniętym plikiem „.sloboz.pdf„.

Ale co dokładnie przed chwilą się stało? Odpalony skrypt perl wykonał fork (zdarzenie 955716), ale w tej samej chwili, jeszcze przed tym faktem, zmienił swoją nazwę pliku wykonawczego oraz argumenty wywołania („exe” i „args”) z „perl .sloboz.pdf” (zdarzenie 954458) na losowy, „nie budzący” podejrzeń: „/usr/local/apach” (zdarzenie 955716). Ma to trochę na celu oszukać takie polecenia jak ps, czy top i patrzących na nich wynik mało doświadczonych użytkowników.

Czytając dalej kod źródłowy skryptu (za pomocą echo_fds), można potwierdzić tę tezę:

Proces skryptu zmienia swoje argumenty wywołania na losowe ciągi podane w tablicy @rps i wtedy forkuje się w celu przejścia w tryb pracy w tle. Po tych zabiegach maszyna pozostaje pod pełną kontrolą intruza. Ostatnim etapem jest posprzątanie po sobie i usunięcie swojej obecności z logów systemowych:

 

Podsumowanie

Sysdig jest dość młodym projektem (wypuszczonym ponad miesiąc temu), dlatego nie można oczekiwać, że w tej fazie rozwoju będzie działał bez błędów – szczególnie jeśli rozważamy jego używanie w środowisku produkcyjnym (któremu możemy zaserwować niestabilność). Jednak na pewno należy zainteresować się jego możliwościami i obserwować dalszy rozwój. Bardzo ładnie widać, jak z jego pomocą, zaczynając od wysokopoziomowej analizy po pojedyncze wywołania systemowe, można uzyskać bardzo wiele informacji o tym, co dzieje się lub stało w naszym systemie.

Jeśli chodzi o charakterystykę powyższego włamania – to po zachowaniu intruza można odnieść wrażenie, że zależało mu tylko na zdobyciu kolejnego serwera do zastosowań typowo botnetowych:

  • nie zadbał o wykasowanie tylko ostatniej swojej aktywności z plików historii, aby zatrzeć starannie ślady, lecz „niechlujnie” usunął ich całą zawartość;
  • w krótkim przedziale czasu wysłał ponad 800MB ruchu sieciowego UDP;
  • odpalił nigdy nie uruchomione fałszywe serwery.

To wszystko z łatwością mogłoby zostać zauważone nawet przez nieświadomego niczego administratora. Jest to typowa gra na „masę” – złamać jak najwięcej maszyn i je wykorzystać – ponieważ nawet początkujące skrypciaki mają pełną świadomość, że czas kontroli nad taką maszyną może być bardzo krótki – dlatego należy ją maksymalnie wyeksploatować. Świadczyć o tym też mogą te wszystkie polecenia, których „wpisywanie” trwało zaledwie dwie minuty. Autor analizy jest prawie pewien, że wszystkie te kroki zostały wyzwolone przez zautomatyzowany skrypt odpalony prawdopodobnie z innego przejętego serwera. Przynajmniej do pierwszego hopa pozostaje „nienamierzalny”…

Więcej informacji: Honeypots, Fishing for hackers.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. SamSzatan
    Odpowiedz
    • Jest to w dużej mierze opracowanie tego – ale na tyle odkrywcze (w sensie pokazania toola), że przy ocenie przez 3 osoby tekst dostał w sumie najwięcej punktów. Będzie można jeszcze zgłosić sprzeciw przy kolejnych tekstach :)

      Odpowiedz
  2. Michał Margula

    To jest trochę kopia tego tekstu „Fishing for hackers”, który w necie jest od dłuższego już czasu. Co ciekawe sam też tego próbowałem w polskich warunkach i po ustawieniu hasła na root o treści „root”, zajęło około 4 godzin do momentu włamania. Soft ściągali z Chin, wrzucili parę backdoorów maskujących listę procesów.

    I teraz ciekawostka – żaden z plików który wrzucili nie został wykryty ani przez rkhuntera ani przez virustotala :)

    Odpowiedz
  3. To samo miałem napisać co SamSzatan. łłeeeee

    Odpowiedz
  4. asq
    Odpowiedz
  5. Panowie – będzie niebawem kolejny konkurs – będzie się można też sprawdzić ;)

    Szczególnie, że będziemy publikować też kolejne teksty z bieżącego konkursu – więc będzie można zobaczyć jak wyglądają pozostałe prace (swoją drogą większość jest bardzo OK!).

    Odpowiedz
    • SamSzatan

      No chyba trzeba będzie wziąć udział w następnym konkursie :)

      Odpowiedz
  6. Duży Pies

    Kochany Sekuraku!

    Zrób coś proszę ze stroną żeby się poprawnie parsowała gdy chcę ją sobie wydrukować albo wyeksportować do PDF. Zbieram dużo tutoriali i na Sekurakowych stronach jest sporo dobrej wiedzy – warto ją sobie wydrukować i mieć jako książeczkę do ćwiczeń. Bardzo mnie to wkurza że jak zrobię Ctrl+P to wychodzi z tego cała strona łącznie z bocznym menu. Ja tak nie chcę. Chcę żeby się wydrukowała sama treść. Dlatego Sekuraku, zrób coś proszę ze swoją stroną, bo to co jest teraz to mnie bardzo denerwuje…

    Odpowiedz
    • Spoko.
      Pracujemy nad sekurakiem offline – czyli tekstami z sekuraka w formie magazynu w pdf. Pierwsza wersja – ok 30 stron – już niebawem :)

      Odpowiedz
      • chesteroni

        Akurat tę potrzebę czytelnika dałoby się zaspokoić arkuszem CSS dla media = print gdzie pewne elementy byłyby wyłączone :)

        Odpowiedz
    • Damian Wąsik

      Przyłączam się do prośby!

      Odpowiedz
  7. darek

    Od jakiego czasu chodzi mi po głowie myśl, żeby postawić honeypota. Artykuł jak na zamówienie. Dzięki!

    Odpowiedz

Odpowiedz