Problem polega na tym, że wiele rootkitów potrafi przetrwać eksport logiczny (nie mówiąc już o kopii fizycznej). Gdy autor rootkita przyłoży się i umieści w obiektach bazy kod instalujący "dodatek" nawet po jego usunięciu, trudno mówić o bezpieczeństwie. Rootkit umieszczony w bazie Microsoft SQL Server 2000 również bezproblemowo przetrwa odtworzenie z kopii bezpieczeństwa - jeśli tylko autor to przewidział.

Kolejna sprawa to wykrywanie przez analizę logów. Dobrze napisany rootkit nie zostawia śladów w logach (czyści je lub modyfikuje procedury audytu). Gdy rootkit służy do ukrycia działalności polegającej na okresowej kradzieży danych, bez operacji wiążących się z zapisem, intruz nie musi nawet (zazwyczaj) czyścić dziennika powtórzeń. Prawdopodobieństwo wykrycia takiego procederu jest znikome.

Użytkownicy klastra zauważą być może okresowe znaczące spadki wydajności spowodowane czyszczeniem śladów w pamięci motoru bazy. Jednak równie dobrze działalność rootkita może być skorelowana z uruchamianiem średnio obciążających raportów. Jeśli serwer nie jest na granicy wydajności, wątpliwe, by ktoś wnikliwie, a przy tym systematycznie badał różnice obciążeń rzędu + - 10%. Takie badanie wymaga sporego nakładu pracy.

Kontrola procesów za pomocą przeglądania perspektyw nie pokaże ukrytych procesów ani użytkowników. Konsola SQL Servera w opcji Current Activity pokaże tylko prawidłowe procesy i zadania. Wbrew pozorom w pewnych przypadkach wcale nie musi się to wiązać z modyfikacją oryginalnych perspektyw - włamywacz może posłużyć się innymi środkami.

Pytania cisną się same. Kto z administratorów baz danych Oracle sprawdzi dokładnie kilka tysięcy obiektów w schematach SYS i SYSTEM? Który z administratorów SQL Server 2000 dokładnie sprawdza strukturę obiektów i ich uprawnienia? Kto wie, które z nich są szczególnie ważne i jak powinny wyglądać? Kto ma pojęcie jak naprawdę wyglądają uprawnienia dostępu do bazy dla użytkowników systemu operacyjnego? Kto zauważy wyzwalacze i modyfikację publicznych synonimów? Kto zauważy dziwne wpisy? Kto wyciągnie z nich prawidłowe wnioski?

Rootkit wkompilowany

Nowsze wersje bazy danych Oracle umożliwiają kompilację procedur do postaci kodu binarnego albo kodu pośredniego Java lub. Net. W oczywisty sposób przyspiesza to wykonywanie bardzo skomplikowanych obliczeniowo procedur, ale włamywacz również może wykorzystać taką możliwość do skutecznego zamaskowania swojej działalności. Uprawnienia do wykonania takiej czynności (czy reinstalacji rootkita po jego wykryciu) nie są problemem - w wielu aplikacjach administrator po prostu musi mieć wysokie uprawnienia. Wystarczy więc umieścić stosowny skrypt dokonujący modyfikacji bazy wewnątrz procedur, o których wiadomo, że są uruchamiane z bardzo wysokimi uprawnieniami. Jedyne co trzeba obejść w przypadku Oracle to konieczność zalogowania się z uprawnieniami SYSDBA, ale i na to są sposoby.

W przypadku serwera Microsoftu jego ścisła integracja z systemem Windows może sprawiać jeszcze ciekawsze niespodzianki. Wiele zadań można wykonać za pośrednictwem programu-agenta, który w określonych przypadkach musi mieć wysokie uprawnienia. Tak się składa, że wśród tych zadań mogą być polecenia systemu operacyjnego. W szczególności można tą drogą manipulować strukturą bazy, a nawet konfiguracją systemu operacyjnego. Tym właśnie sposobem można ukryć skrypt ponownie instalujący rootkita po jego usunięciu.

Z tego płynie bardzo ważny wniosek - jeśli wykryto włamanie do bazy i odnaleziono niedozwolone modyfikacje (lub są uzasadnione podejrzenia), to bezwzględnie należy dokonać sprawdzenia wszystkich istotnych obiektów w bazie, a także integralności systemu operacyjnego. Administratorzy starszych wersji SQL Server (6.5, 7.0) nigdy nie powinni odtwarzać z kopii bezpieczeństwa baz MASTER ani MSDB. Wszystkie brakujące obiekty należy utworzyć ręcznie. Dodatkowo należy sprawdzić jeszcze stację roboczą administratora bazy danych pod kątem programów rejestrujących zdarzenia klawiatury (keylogger).

Gdy rootkit zostanie umieszczony w bazie danych, żaden plik wykonywalny motoru bazy danych nie podlega modyfikacji. Od tej zasady są czasami wyjątki (np. dość popularna zmodyfikowana wersja listenera bazy 9.2 dla Windows będąca dodatkowo tylnymi wrotami), niemniej realizacja rootkita niemodyfikującego w ogóle plików motoru jest niemal regułą. Trzeba badać sumy kontrolne obiektów w bazie, a to jest bardzo pracochłonne.

W przypadku nowoczesnych rootkitów dla Oracle, których działanie opiera się na modyfikacji SGA, nawet to działanie nie przyniesie pożądanych skutków. W Oracle 10gR2 dostarczane są oficjalne interfejsy API do modyfikacji SGA, niemniej powszechnie wiadomo, że było to możliwe także w starszych wersjach. Rootkit bazujący na modyfikacji pamięci bazy nie zostawia śladów po restarcie bazy - analiza po restarcie (albo analiza pliku eksportu) nie przyniesie żadnych rezultatów.

Baza nie zawsze winna

Rootkit w systemie operacyjnym daje włamywaczowi dostęp do wszystkich zasobów serwera. Przy odrobinie umiejętności i szczęścia włamywacza daje to możliwość włamania się do większej liczby systemów. Przy zastosowaniu zewnętrznego uwierzytelniania nie będzie to automatyczne, jeśli jednak SQL Server 2000 pracuje z uprawnieniami administratora domeny (w bardzo wielu firmach tak właśnie jest), praktycznie wszystkie komputery stoją przed nim otworem.

Niejedna firma przechowuje najważniejsze dane (finansowe, CRM) w bazie zintegrowanego środowiska aplikacyjnego. Należy zwrócić uwagę, że uzyskanie uprawnień systemowych do tej bazy jest równoważne w skutkach ze zdobyciem całej domeny. Równie dotkliwym dla firmy atakiem jest instalacja rootkita w bazie danych obsługującej system pracy grupowej. To niedoceniane źródło informacji jest dużo ważniejsze niż prymitywny sniffing, bowiem umożliwia wybranie z potoku informacji tylko tych listów, które spełniają określone kryteria.

W typowym scenariuszu baza Oracle działa na koncie użytkownika z wąskimi uprawnieniami, w związku z czym włamanie do bazy danych następuje po złamaniu zabezpieczeń systemu. Nie jest to jednak regułą, ponieważ starsze wersje baz Oracle miały setki błędów, które umożliwiały uzyskanie nieautoryzowanego dostępu bez konieczności łamania systemu. Oczywiście, administrator bazy danych powinien instalować aktualizacje bazy dostarczane przez producenta, niemniej nie zawsze to robi.

Abstrahując od niedbalstwa, nie zawsze jest to po prostu możliwe. Często zdarza się, że bazę wypadałoby zaktualizować ze względów bezpieczeństwa, ale nie można tego zrobić, ponieważ dostawca aplikacji przeciąga testowanie lub zgoła twierdzi, że nowej wersji na razie wspierać nie będzie. Dla producenta oprogramowania sprawdzanie zgodności z kolejnymi wersjami bazy jest "niepotrzebnym" obciążeniem, skoro aplikacja funkcjonuje prawidłowo ze starszą, sprawdzoną wersją.