Szpieg w stogu danych

Rootkity dla baz danych są trudniejsze do wykrycia i usunięcia, niż rootkity dla systemów operacyjnych. Zjawisko narasta, ale wiedzy o nim, a tym bardziej profesjonalnych narzędzi diagnostycznych wciąż brak.

Rootkity dla baz danych są trudniejsze do wykrycia i usunięcia, niż rootkity dla systemów operacyjnych. Zjawisko narasta, ale wiedzy o nim, a tym bardziej profesjonalnych narzędzi diagnostycznych wciąż brak.

W firmach i instytucjach, które traktują bezpieczeństwo danych poważnie, włamanie poprzez sieć stało się trudne. Ci, którym naprawdę zależy, zgromadzili zasoby ludzkie i narzędzia pozwalające kontrolować, co dzieje się w sieci. Podwyższenie poprzeczki nie pozostało bez reakcji - zamiast próbować obchodzić coraz doskonalsze zabezpieczenia sieciowe włamywacze zabrali się do sprawy inaczej, biorąc za cel serwery baz danych.

Osiągnięcia włamywaczy w radzeniu sobie z zabezpieczeniami baz danych są doprawdy zastanawiające. Okazuje się, że nawet wielce szacowne marki kwestię bezpieczeństwa traktowały dotychczas, najdelikatniej mówiąc, po macoszemu. Dla jasności: tu nie chodzi o kilka drobnych błędów w kodzie, które zdarzają się w każdym większym produkcie software'owym. Chodzi o wady konstrukcyjne oraz całe morze błędów przeróżnego kalibru, wskazujących na niedostatki testowania.

Ostatnio pojawiło się jeszcze jedno zagrożenie dla serwerów baz danych - powstały dla nich dedykowane rootkity! Tak, działanie tych programów jest analogiczne do tych, które od wielu lat są postrachem administratorów sieciowych systemów operacyjnych. A zatem wszystkie dotychczasowe metody zabezpieczania danych w bazach trzeba przemyśleć jeszcze raz, a być może nawet wprowadzić radykalne zmiany. Na początek obejdzie się bez solidnego audytu istniejącej konfiguracji bazy danych.

Baza jak system

Rootkit to aplikacja, której zadaniem jest ukrywanie plików i procesów w systemie operacyjnym. Nowoczesne serwery baz danych to środowiska składające się z wielu procesów i setek wątków. Są już tak rozległe i skomplikowane, że zaczynają przypominać systemy operacyjne (mają niezależne od systemu operacyjnego środowiska wykonawcze, składają się z wielu usług, zarządzają zasobami i same odtwarzają się po awariach). W przyszłości serwery baz danych staną się jeszcze bardziej złożone, co autorom rootkitów jest na rękę.

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 informacji w przedsiębiorstwach - obecnie nie można sobie wyobrazić nawet średniej wielkości firmy, bez bazy danych obsługującej takie systemy, jak ERP. Jeśli wdrożenie było rozsądnie przeprowadzone, w tej bazie jest dużo danych - firmy wybierają zazwyczaj rozwiązania zintegrowane, gdzie wszystkie dane są przechowywane w jednej bazie.

Napisanie prostego rootkita dla bazy Oracle jest bardzo łatwe. Wystarczy pół godziny, wliczając czas potrzebny na napisanie skryptu PL/SQL automatyzującego późniejszą instalację. Mimo prostoty, skuteczność rootkita jest bardzo wysoka. Doświadczeni, a przy tym dociekliwi administratorzy być może i wykryliby go, ale nie za pomocą standardowych procedur i narzędzi.

Rzut oka na archiwa list dyskusyjnych wystarczy, by dowiedzieć się, że podobne pomysły nurtowały hakerów od dawna, i to wcale nie wyłącznie w odniesieniu do serwerów Oracle. Podobnie skutecznie działają rootkity dla bazy SQL Server 2000. Rootkit ten niebawem będzie przystosowany do pracy w najnowszym produkcie bazodanowym Microsoftu, choć poprzeczka jest tu nieco wyższa. Do kompletu przewidziano także instalator przypominający dodatek Service Pack.

Strojanowanie systemu operacyjnego zapewniające łatwe wejście włamywaczowi oraz ukrycie tego faktu za pomocą stosownego rootkita daje dostęp do zasobów. Jednakże są już dostępne narzędzia do wykrywania rootkitów. Są lepsze i gorsze - wiele z nich nie radzi sobie z coraz nowocześniejszymi rootkitami. Nadal jednak istnieje możliwość, wprawdzie bardzo pracochłonnego, ale skutecznego ręcznego sprawdzenia systemu.

W każdej firmie poważnie traktującej bezpieczeństwo istnieje środowisko testowe, będące wierną kopią środowiska produkcyjnego, zatem warto skorzystać z możliwości porównania plików. Wiele systemowych rootkitów można ę w ten sposób wykryć - dystrybucja systemu Linux uruchamiana z płyty CD umożliwiająca obliczenie sum kontrolnych wszystkich plików przy niedziałającym systemie głównym jest potężną bronią w rękach doświadczonego administratora i działa na wielu platformach.

Co może rootkit w bazie

Rootkity w bazach danych są dla danych groźniejsze, niż rootkity instalujące się w systemach operacyjnych. Po pierwsze, dlatego że mało kto zdaje sobie sprawę z ich istnienia - zjawisko jest stosunkowo nowe, a do wykrycia rootkita w bazie doświadczenie zdobyte z rootkitami systemowymi nie wystarczy. Do znalezienia rootkita w bazie trzeba dogłębnej wiedzy o wewnętrznym funkcjonowaniu konkretnego serwera baz danych (a nawet konkretnej wersji), jak również o jego interakcjach z systemem operacyjnym.

Błędy lub przekroczenia uprawnień w jej środowisku mogą nigdy nie ujawnić się jako zagrożenia - nawet wtedy, gdy serwer bazy danych zostanie obstalowany zaporami i sondami systemów do wykrywania włamań. Specyfika konstrukcji baz danych oraz fakt, że instalowane są one często w systemie na prawach użytkownika z przywilejami administracyjnymi, sprawiają, że baza żyje w systemie niejako własnym życiem. Cała sprawa sprowadza się do tego, aby stworzyć w bazie danych użytkownika o prawach administracyjnych i ukryć go przed administratorem. Dalej idzie już jak z płatka.

Z zewnątrz wygląda na to, że nie dzieje się nic szczególnego. Ruch wygląda tak jak zwykle, obciążenie mieści się w widełkach, aplikacja działa bez anomalii, nie ma niestandardowych poleceń SELECT ani innych dziwnych zjawisk, które mogłyby świadczyć, że w bazie dzieje się coś niedobrego. A jednak się dzieje.

Jeśli twórca rootkita przyłoży się do wykonywanego zadania, może na przykład:

  • bezpośrednio manipulować kontami użytkowników w bazie

  • ukrywać obiekty, procesy i zadania

  • przekierowywać logowanie i komunikację sieciową

  • modyfikować dane

  • zmieniać "w locie" wykonywane zapytania, dodając np. dodatkowe warunki

  • modyfikować wyniki zwracane przez zapytania

  • zmieniać informacje o samym serwerze, podawać nieprawdziwe informacje np. o założonych dodatkach Service Pack, czy też wersji motoru i dostępnych opcjach.
Większość "opcji" z tej listy nie wymaga komentarza - ich szkodliwość jest oczywista na pierwszy rzut oka. O skutkach instalacji rootkita wraz z odpowiednimi procedurami w systemie zintegrowanym można myśleć także w kategoriach długofalowych - może on na przykład powodować trudne do wychwycenia problemy z oprogramowaniem. Choćby modyfikując dane, jakich spodziewa się system korzystający z bazy w określonym miejscu i czasie.

Ostatnia z powyższych opcji wydaje się na pozór stosunkowo niegroźna, ale wystarczy zwrócić uwagę na to, że poprawki są wydawane przez dostawców najczęściej po wykryciu bardzo poważnych luk w bezpieczeństwie lub funkcjonalności aplikacji. Zatem ukrycie faktycznego stanu aktualizacji serwera jest bardzo ważne, bowiem umożliwia łatwiejszy dostęp poprzez tzw. eksploitowanie istniejącej luki w bezpieczeństwie.

Nie widać, nie słychać

Na razie nie ma narzędzi, które od razu wykryłyby modyfikację podstawowych obiektów bazy Oracle. Żadne z narzędzi dostarczonych przez producenta nie jest specjalnie pomocne - podobnie jak w systemach operacyjnych, trzeba skorzystać ze specjalnych skryptów, ale nawet one nie dają stuprocentowej pewności. To samo dotyczy Microsoft SQL Server 2000.

Ważnym problemem jest to, że analiza niedziałającej bazy Oracle jest trudna, co wcale nie znaczy, że dobrze napisany rootkit nie ukryje się w bazie działającej. Analiza napotyka dodatkowe kłopoty także wtedy, gdy baza wykorzystuje klaster, np. Oracle RAC - ze względu na samą naturę takiego rozwiązania. Gdy zaś baza danych nie przewiduje wykonywania kopii logicznej, a jedynie plikowe (tak jak robi to SQL Server 7.0), analiza bazy nie skończy się na przeglądaniu pliku eksportu.

Rootkita umieszczonego w systemie operacyjnym można trwale usunąć, dokonując odtworzenia systemu z wcześniej wykonanej kopii, doinstalowując ewentualnie brakujące elementy. Mając takie środowisko, można zainstalować stosowny audyt umożliwiający wykrycie prób skorzystania przez intruza z pozostawionych uprzednio tylnych wrót. Pliki tworzone w systemie zostawiają po sobie ślady, które przy odrobinie szczęścia można potem analizować.

Inaczej wygląda sprawa z bazami danych. Gdy administrator podejrzewa strojanowanie serwera, zazwyczaj wykona pełen eksport danych (względnie "zimną" kopię plików bazy), 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. Gdy odtworzy dane z kopii sądzi, że serwer jest bezpieczny.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200