Szpieg w stogu danych

W firmach, które poważnie traktują bezpieczeństwo danych, włamanie poprzez sieć stało się trudne. Dla uniknięcia ryzyka zgromadzono bowiem narzędzia pozwalające kontrolować, co dzieje się w sieci. Włamywacze jednak nie zrezygnowali – zamiast obchodzić coraz doskonalsze zabezpieczenia, wzięli na celownik serwery baz danych. Natychmiast okazało się, że nawet najpoważniejsze marki kwestię bezpieczeństwa traktowały do tej pory po macoszemu. I nie chodzi o kilka drobnych błędów w kodzie, ale przede wszystkim o wady konstrukcyjne. Ostatnio pojawiło się jeszcze jedno zagrożenie dla serwerów baz danych – powstały dla nich dedykowane rootkity. Rootkit to aplikacja, której zadaniem jest ukrywanie plików i procesów w systemie operacyjnym. A nowoczesne serwery baz danych są już tak rozległe i skomplikowane, że zaczynają te systemy przypominać. W przyszłości serwery baz danych staną się jeszcze bardziej złożone, co autorom rootkitów jest na rękę. Napisanie prostego rootkita dla bazy Oracle jest bardzo łatwe – wystarczy na to pół godziny. Skuteczność takiej aplikacji jest wysoka. 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. Na rynku dostępne są już narzędzia do wykrywania rootkitów – wiele z nich nie radzi sobie jednak z coraz nowocześniejszymi aplikacjami. Wiele rootkitów można wykryć poprzez skorzystanie ze środowiska testowego, które powinna posiadać każda firma poważnie traktująca bezpieczeństwo. Dla danych groźniejsze są rootkity w bazach danych, niż te z systemów 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. Błędy lub przekroczenia uprawnień w środowisku bazy mogą nigdy nie ujawnić się jako zagrożenia – nawet wtedy, gdy serwer danych zostanie obstalowany zaporami i sondami systemów do wykrywania włamań. Z zewnątrz wygląda na to, że nie dzieje się nic szczególnego, ale twórca dobrego rootkita może np. – 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 dane. Rootkit zainstalowany w systemie zintegrowanym może również w dłuższej perspektywie powodować trudne do wychwycenia problemy z oprogramowaniem. Na razie nie ma narzędzi, które od razu wykryłyby modyfikację podstawowych obiektów bazy Oracle. Nawet skorzystanie ze specjalnych skryptów nie daje stuprocentowej pewności. To samo dotyczy Microsoft SQL Server 2000. Rootkita umieszczonego w systemie operacyjnym można trwale usunąć, dokonując odtworzenia systemu z wcześniej wykonanej kopii, doinstalowując ewentualnie brakujące elementy. Inaczej wygląda sprawa z bazami danych. Gdy administrator podejrzewa strojanowanie serwera, zazwyczaj wykona pełen eksport danych, 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. Problem polega jednak na tym, że wiele rootkitów potrafi przetrwać eksport logiczny. Dobrze napisany rootkit nie zostawia śladów w logach. Użytkownicy klastra mogą natomiast zauważyć 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. Kontrola procesów za pomocą przeglądania perspektyw nie pokaże ukrytych procesów ani użytkowników. 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. Można w nim bowiem ukryć skrypt ponownie instalujący rootkita po jego usunięciu. Jeżeli wykryto włamanie do bazy i odnaleziono niedozwolone modyfikacje, to bezwzględnie należy dokonać sprawdzenia wszystkich istotnych obiektów w bazie, a także integralności systemu operacyjnego. Gdy rootkit zostanie umieszczony w bazie danych, żaden plik wykonywalny motoru bazy danych nie podlega modyfikacji. Trzeba wówczas badać sumy kontrolne obiektów w bazie, a jest to zadanie bardzo pracochłonne. Jednak 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. Rootkit bazujący na modyfikacji pamięci bazy nie zostawia śladów po restarcie bazy – analiza po restarcie (albo analiza pliku eksportu) nie przyniesie zatem żadnych rezultatów. Rootkit w systemie operacyjnym daje włamywaczowi dostęp do wszystkich zasobów serwera. Wiele firm przechowuje najważniejsze dane 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.

Więcej w baza danych, rootkit
Marketing bazodanowy bez tajemnic

Z biegiem czasu rola marketingu bezpośredniego ewoluowała z narzędzia służącego wyłącznie sprzedaży produktów do instrumentu budowania długofalowych relacji z klientami. Jednak to czy dany przekaz zostanie zauważony i wysłuchany w...

Zamknij