Przez furtkę do bazy
-
- 06.02.2006
Ślepe narzędzia
Kolejne wersje baz Oracle różnią się wieloma szczegółami budowy wewnętrznej i dla zachowania zgodności z nowszymi i starszymi wersjami, utworzone zostały stosowne perspektywy, takie jak choćby wspomniane DBA_USERS. Wszystkie narzędzia administracyjne, jakie sprawdzałem (Oracle Enterprise Manager - DBA Studio z wersji 9.2.0.6 Linux x86, Embarcadero DBArtisan 7.2.1, TOAD 8.5.0.50g, TOra 1.3.12), pokazują nieprawdę.
Narzędzia te nie wyświetlą ukrytych kont użytkowników nawet w przypadku najprostszego z rootkitów, polegającego na modyfikacji kilkunastu perspektyw. Jest tak, ponieważ wszystkie te narzędzia czytają dane z perspektyw, a nie z tabeli SYS.USER$. Ilu administratorów sprawdza dane użytkowników za pomocą własnego skryptu PL/SQL czytającego dane wprost z SYS.USER$, a uruchomionego z okna programu SQL*Plus, łącząc się bez pośrednictwa listenera (CONNECT / AS SYSDBA)? Kto monitoruje "spłukanie" pamięci SGA?
Nowsze wersje bazy danych Oracle umożliwiają kompilację procedur do postaci kodu wewnętrznego, co bardzo przyspiesza wykonywanie skomplikowanych obliczeniowo procedur. Ta sama technika może być użyta przez intruza do instalacji "dodatku". Włamywacz wcale nie musi się trudzić, by ponownie instalować swoje dzieło w razie wykrycia. Wystarczy umieścić stosowny skrypt dokonujący modyfikacji bazy wewnątrz procedur, o których wiadomo, że są uruchamiane z bardzo wysokimi uprawnieniami (np. z poziomu administratora aplikacji korzystającej z bazy danych). Jedyne co trzeba obejść, to konieczność zalogowania się z uprawnieniami SYSDBA - ale na to też są sposoby.
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, gdzie pracuje baza. Dodatkowo należy sprawdzić jeszcze stację roboczą administratora bazy danych pod kątem programów rejestrujących naciskane klawisze.
Gdy rootkit jest częścią bazy danych, analiza zawartości plików wykonywalnych leżących na dyskach nic nie wykryje, bowiem żaden plik wykonywalny motoru bazy danych nie podlega tu modyfikacji. Od tej zasady są czasami wyjątki (np. dość popularna zmodyfikowana wersja listenera bazy 9.2 dla Windows, będąca "przy okazji" tylnymi wrotami). Rootkit niemodyfikujący w ogóle plików motoru bazy danych jest niemal regułą. W przypadku nowoczesnych rootkitów bazujących na modyfikacji pamięci SGA, badanie sum kontrolnych plików jest całkowicie bezcelowe. Rootkit bazujący na modyfikacji pamięci bazy nie zostawia śladów po restarcie bazy.
Związane ręce
Włamanie do serwera bazy danych jest znacznie łatwiejsze niż przełamywanie zabezpieczeń sieciowych czy domenowych, a jego skutki są równoważne włamaniu do domeny (dostęp do danych finansowych, CRM itd.). Równie dotkliwym dla firmy atakiem jest instalacja rootkita w bazie danych obsługującej system pracy grupowej. Pobranie poczty leżącej na serwerze może być znacznie owocniejszym źródłem informacji niż prymitywny sniffing, bowiem umożliwi wybranie z potoku informacji tylko tych listów, które spełniają określone kryteria.
W przypadku Oracle baza w typowych instalacjach pracuje przy niskich uprawnieniach systemu operacyjnego. Najczęściej dochodzi najpierw do kompromitacji samego systemu operacyjnego, a następnie włamania do bazy. Nie jest to jednak regułą, ponieważ starsze wersje Oracle (np. 8.1.6) miały całą masę błędów, które umożliwiały uzyskanie dostępu do bazy mimo zabezpieczeń.
Oczywiste jest, że administrator bazy danych powinien instalować aktualizacje bazy dostarczane przez producenta, jednak nie zawsze jest to możliwe - zwykle ze względu na to, że aplikacja "jeszcze" nie działa z nowszą wersją bazy danych.
Oczekiwanie na zgodność może trwać miesiącami, a nawet nie zdarzyć się w ogóle. Dla producenta oprogramowania sprawdzanie zgodności z kolejnymi wersjami bazy jest "niepotrzebnym" obciążeniem. Niezgodności wersji uniemożliwiające aktualizację (i poprawę zabezpieczeń) to bardzo poważny problem.
Ze starszych wersji serwera Oracle (np. 8.1.6) korzysta bardzo wiele firm, bowiem instalacja łat wymaga zakupu usługi wsparcia, a to dla wielu firm "niepotrzebny" koszt. Poza tym migracja nie musi być wcale takim prostym zadaniem. Gdy firma już zakupiła licencje wieczyste, bardzo trudno będzie przekonać zarząd do zakupu nowej wersji bazy - przecież obecna działa.
Szczęściem w nieszczęściu jest wybór licencji czasowych (np. na dwa lata), dzięki czemu po upływie okresu ważności licencji można przy okazji zakupu nowej licencji podnieść wersję bazy. Stare wersje (takie jak Oracle 8.1.6 czy SQL Server 7.0) są nie tylko przestarzałe - nie podlegają wsparciu technicznemu i nie ukazują się już aktualizacje producenta.
Narzędzia do wykrywania rootkitów, lepsze i gorsze, istnieją od dawna, ale wiele z nich nie radzi sobie z coraz nowocześniejszymi rootkitami. Najlepszą metodą wykrywania rootkitów nadal jest wyłączenie podejrzanego systemu i badanie sum kontrolnych kluczowych plików. Test MD5 (lub mocniejszy, bowiem wykazano już słabości tego algorytmu) służy do porównań z inną instalacją takiego samego systemu, o którym wiadomo na pewno, że jest "czysty" (np. z kopii zapasowej). Taki test można wykonać za pomocą dystrybucji systemu Linux działającego z płyty CD. Niektóre (nieliczne) rootkity przeznaczone dla systemu Microsoft Windows są już wykrywane nawet przez programy antywirusowe - najczęściej reaguje moduł analizy behawioralnej lub moduł heurystyczny.
Narzędzi, które od razu wykryłyby modyfikację podstawowych obiektów bazy Oracle na razie nie ma. Żadne z narzędzi dostarczonych przez producenta bazy nie jest tu pomocne - podobnie jak w systemach operacyjnych, trzeba skorzystać ze specjalnych skryptów, ale nawet one nie dają stuprocentowej pewności. Gdy baza danych nie przewiduje wykonywania kopii logicznej, a jedynie plikowej (jak np. w SQL Server 7.0), analiza bazy jest jeszcze trudniejsza. Ale nawet gdy to się uda, pojawiają się kolejne problemy. Gdy jednak jest plik eksportu, nadal nie będzie łatwo go analizować - trzeba użyć programu zdolnego otworzyć tak duży plik i wyłuskać z niego znaki niebędące danymi (z podstawowego zestawu ASCII).
