Rootkit to coś, co kojarzy się z systemem operacyjnym. Nadchodzi jednak nowa fala - najnowsze rootkity wraz z towarzyszącymi im programami typu koń trojański powstają dla serwerów baz danych.

Rootkity służące do ukrywania kont, uprawnień, plików i procesów są powszechnie znanym narzędziem służącym włamywaczom do zacierania śladów swojej regularnej bytności w systemach operacyjnych. Jak się okazuje - nie tylko tam. Ostatnio włamywacze wzięli sobie za cel bazy danych i ich osiągnięcia na tym polu są co najmniej zastanawiające. Jedno jest pewne: dotychczasowe narzędzia przeciw rootkitom nie wystarczają do zapewnienia bezpieczeństwa danych przechowywanych w bazach.

Baza jak system

Administratorzy ograniczają dostęp do serwerowni, zmieniają uważnie hasła, weryfikują pliki systemu operacyjnego, szyfrują połączenia oraz sprawdzają poprawność działania systemu. Pomimo wszystkich tych zabiegów dane zawarte w bazie mogą być zagrożone - wystarczy, że włamywacz niespostrzeżenie utworzy z poziomu bazy danych konto użytkownika o uprawnieniach systemowych (większość serwerów baz danych umożliwia to bez problemu i to jest największa słabość całego systemu zabezpieczeń), a następnie zamaskuje jego istnienie.

Połączenie do serwera bazodanowego może być całkowicie "niewinne" i umknąć nawet dobrze skonfigurowanemu systemowi zapobiegania włamaniom - wszak to mogą być takie same polecenia SELECT, jakie wykonuje aplikacja, użytkownik może mieć też stosownie dobrany login oraz dobrze skomplikowane hasło, zaś włamywacz wcale nie dokonuje żadnych podejrzanych działań - po prostu łączy się do bazy.

Dla większości administratorów rootkit to modyfikacja dokonana w systemie operacyjnym oraz specjalnie napisana aplikacja, której zadaniem jest ukrywanie podejrzanych plików i procesów. Baza danych jest poza podejrzeniami, jako że sama zawiera niezależne od systemu operacyjnego mechanizmy kontroli dostępu. Nowoczesne bazy danych zaczynają jednak przypominać systemy operacyjne (m.in. integrują się coraz bardziej z serwerami aplikacji, np. w przypadku Oracle 10g i SQL Server 2005), zawierają coraz bardziej skomplikowane struktury i należy oczekiwać dalszego wzrostu ich złożoności.

Logicznie myśląc, pojawienie się rootkitów działających w środowisku bazodanowym było tylko kwestią czasu. Zbiega się to w czasie z powszechnym wykorzystywaniem baz danych do składowania w nich wszelkiego rodzaju danych, także dokumentów. Jedna baza danych służy wielu różnym aplikacjom i usługom, co jest pokłosiem faktu, że zarządzanie jedną bazą jest łatwiejsze i bezpieczniejsze. Jest też tańsze niż utrzymywanie kilku oddzielnych środowisk bazodanowych. Serwerem baz danych, który najczęściej spełnia rolę wielkiego "wora na dane", jest Oracle. Produkt ten jest popularny w segmencie średnich i dużych przedsiębiorstw, co czyni go atrakcyjnym celem włamań.

Rootkit w bazie danych jest bardzo groźny - z punktu widzenia bezpieczeństwa informacji jest groźniejszy niż rootkit zainstalowany w systemie operacyjnym serwera. Co ciekawe, napisanie prostego rootkita dla serwera Oracle jest banalne - można to wykonać w pół godziny, wliczając w to czas potrzebny na napisanie skryptu PL/SQL automatyzującego późniejszą instalację. Z punktu widzenia włamywacza skuteczność takiego prymitywnego rootkita jest bardzo dobra - żadne z testowanych przeze mnie narzędzi nie wykazało jego obecności, niemniej naprawdę doświadczeni administratorzy po uważnej analizie obiektów w bazie być może zaczęliby mieć podejrzenia. Być może.

Intruz bez śladów

Rootkita umieszczonego w systemie operacyjnym można trwale usunąć, dokonując odtworzenia systemu z kopii bezpieczeństwa sprzed okresu instalacji tego "dodatku", a wtedy wystarczy doinstalować brakujące elementy. Pliki tworzone w systemie zostawiają po sobie ślady, które przy odrobinie szczęścia można potem analizować. Inaczej się ma sprawa z bazami danych. Gdy administrator podejrzewa strojanowanie serwera, zazwyczaj wykona pełen eksport danych (względnie kopię plików bazy w trybie offline), zainstaluje od nowa system operacyjny, bazę danych i odtworzy dane z kopii bezpieczeństwa.

Być może użyje kopii bezpieczeństwa z opcją Disaster Recovery - co wydatnie skróci okres ponownego uzyskania sprawności systemu. Potem odtworzy dane bazy danych z kopii (np. zaimportuje plik eksportu) i jest przekonany o tym, że serwer jest bezpieczny. Problem polega jednak na tym, że wiele rootkitów dla baz Oracle potrafi przetrwać eksport logiczny (nie mówiąc już o surowej kopii fizycznej).

Gdy intruz przyłoży się nieco do wykonania zadania, umieści w obiektach bazy Oracle specjalne "wstawki" zakładające instalację trojana nawet po jego usunięciu. Rootkit umieszczony w bazie Microsoft SQL Server także bezproblemowo przetrwa odtworzenie z kopii bezpieczeństwa, jeśli tylko autor to przewidział. Dobrze napisany rootkit dla serwera Oracle nie zostawia śladów w logach, gdyż usuwa dotyczące siebie zapisy. Proces nasłuchu nie powoduje blokowania operacji na plikach log, więc stosowne wpisy można z powodzeniem usunąć za pomocą funkcji z pakietu UTL_FILE.

Jego śladów nie można także znaleźć w SGA - gdyż także je czyści (najczęściej "spłukuje" obszar pamięci SGA. Powoduje to krótkotrwały spadek wydajności, niemniej większość użytkowników obarczy winą inną osobę wykonującą bardzo skomplikowany raport). Dzienniki powtórzeń również nie zawierają tych informacji, bowiem po wypełnieniu do limitu zostały kilkakrotnie przełączone na kolejne. Bazy dużych firm niemal zawsze pracują w trybie archivelog, więc włamywacz musi także usunąć logi archiwalne powstałe po przełączeniu za pomocą polecenia ALTER SYSTEM SWITCH LOGFILE, jeśli dokonywał jakichkolwiek modyfikacji.

Gdy rootkit służy do ukrycia działalności polegającej na kradzieży danych, co zazwyczaj nie wiąże się z zapisem jakichkolwiek danych w bazie, intruz zazwyczaj nie musi czyścić dziennika powtórzeń. Prawdopodobieństwo wykrycia jest bardzo niskie. Użytkownicy rozwiązania Oracle RAC zauważą może okresowe znaczące spadki wydajności klastra - ale można to przypisać bardzo skomplikowanym zapytaniom uruchamianym przez użytkowników. Poza tym wykrycie takiego obniżenia wydajności wymaga stałego monitorowania klastra - nie każda firma to robi, bowiem wymaga to sporego nakładu pracy administratora.

Kontrola procesów za pomocą przeglądania perspektywy V$SESSION też nie pokaże ukrytych procesów, podobnie przeczytanie perspektywy DBA_USERS. Wbrew pozorom wcale nie musi się to wiązać z "cichą" modyfikacją oryginalnych perspektyw - wystarczy utworzyć ich zmodyfikowane kopie i zmodyfikować publiczny synonim. Włamywacz może też utworzyć tabelę, z której będzie wyświetlał stosowne dane, zaś za modyfikację tej tabeli odpowiadać może komplet wyzwalaczy założony na oryginalnej tabeli SYS.USER$.

Kto z administratorów obecnie sprawdza dokładnie obiekty w schemacie SYS, gdy jest ich tam kilka tysięcy? Kto wie, które z nich są szczególnie ważne i jak powinny wyglądać naprawdę? Kto zauważy wyzwalacze i modyfikację publicznych synonimów? Kto zauważy niespójność w numeracji plików logów archiwalnych? I wreszcie, kto wyciągnie z tego prawidłowe wnioski?