Rootkity w bazach danych

1. Rootkity w bazach danych sposoby ataków i obrony autor: Przemysław Górski

2. Agenda • Rootkit - co to jest? • Podobieństwa pomiędzy OS i DB • Generacje rootkitów w bazach danych • Wykrywanie ataku • Aplikacja – omówienie • Aplikacja – przykład działania • Podsumowanie

3. Rootkit - co to jest? rootkit (pluralrootkits) (computing) A set of softwaretools used by a third party after gaining access to a computer system in order to conceal the altering of files, or processes being executed by the third party without the user's knowledge. Źródło :en.wiktionary.org

4. Podobieństwa pomiędzy OS i DB Systemy operacyjne i systemy baz danych są podobne w swojej architekturze. Obydwa posiadają: • Użytkowników • Procesy • Zadanie • Pliki wykonywalne • Symboliczne linki • … Bazy danych są „rodzajem systemu operacyjnego”

5. Podobieństwa pomiędzy OS i DB Źródło: Black Hat 2006; Alexander Kornbrust

6. Generacje rootkitów bazodanowych • Pierwsza generacja Modyfikacje w strukturach bazy danych – modyfikacje kodu obiektów • Druga generacja Modyfikacje dokonywane są w plikach binarnych systemu bazy danych • Trzecia generacja Modyfikacje dokonywane są w pamięci operacyjnej w której składowane są obiekty bazy danych

7. Rootkit pierwszej generacji Najprostszy atak na bazę danych Oracle: „Insert into dual values (‘y’);” Wady: Natychmiastowy efekt działania Ulepszenie: Zastosowanie mechanizmu job’ów – skrypt ataku jest wykonywany w ustalonym przez zakładającego job momencie. Wada: Ktoś może wykryć nadmiarowy job Ulepszenie: Ukrycie job’u przed innymi użytkownikami systemu (w szczególności przed DBA) – zastosowanie rootkit’a pierwszej generacji

8. Rootkit pierwszej generacji Skrypt pozwalający ukryć job: CREATE OR REPLACE VIEW DBA_JOBS (JOB, LOG_USER, PRIV_USER, SCHEMA_USER, LAST_DATE, LAST_SEC, THIS_DATE, THIS_SEC, NEXT_DATE, NEXT_SEC, TOTAL_TIME, BROKEN, INTERVAL, FAILURES, WHAT, CURRENT_SESSION_LABEL, CLEARANCE_HI, CLEARANCE_LO, NLS_ENV, MISC_ENV) AS select JOB, lowner LOG_USER, powner PRIV_USER, cowner SCHEMA_USER, LAST_DATE, substr(to_char(last_date,'HH24:MI:SS'),1,8) LAST_SEC, THIS_DATE, substr(to_char(this_date,'HH24:MI:SS'),1,8) THIS_SEC, NEXT_DATE, substr(to_char(next_date,'HH24:MI:SS'),1,8) NEXT_SEC, (total+(sysdate-nvl(this_date,sysdate)))*86400 TOTAL_TIME, decode(mod(FLAG,2),1,'Y',0,'N','?') BROKEN, INTERVAL# interval, FAILURES, WHAT, cur_ses_label CURRENT_SESSION_LABEL, CLEARANCE_HI, CLEARANCE_LO, nlsenv NLS_ENV, env MISC_ENV from sys.job$ j where job <> 7 /

9. Rootkit pierwszej generacji Istnieje kilka dróg przez które można stworzyć rootkit’a pierwszej generacji. Najczęściej stosowanymi w tym celu środkami są: • modyfikacja obiektów w bazie danych • zmiana ścieżki wykonywania poleceń • zmiana zapytania SQL wykorzystując mechanizm wirtualnych prywatnych baz danych (VPD)

10. Rootkit drugiej generacji Przykład modyfikacji pliku binarnego w celu ukrycia użytkownika. Źródło: Black Hat 2006; Alexander Kornbrust

11. Rootkit trzeciej generacji Działanie kodu rootkita odbywa się tylko w pamięci operacyjnej, do której dostęp jest możliwy tylko z poziomu systemu operacyjnego. Uruchomienie kodu rootkita może jednak nastąpić z poziomu bazy danych. W tym celu wykorzystany może być mechanizm pozwalający na kompilacje kodu procedur PL/SQL z wykorzystaniem natywnych kompilatorów systemu operacyjnego. ALTER SYSTEM set plsql_native_make_utility=‘rootkit.exe’;

12. Wykrywanie ataku Zaimplementowany sposób wykrywania ataku opiera się porównaniu dwóch zestawów obliczonych sygnatur obiektów poddanych kontroli. Sygnatura obiektu jest to zestaw nie powtarzalnych cech obiektu, nie zmiennych w czasie oraz powiązanych z funkcjonalnością obiektu. Przykład: obiektu o typie SYNONYM– jako sygnatura obiektu brana pod uwagę jest nazwa obiektu typ obiektu oraz nazwa obiektu do którego synonim się odnosi obiektu o typie TABLE – jako sygnatura to nazwa tabeli oraz nazwy kolumn, typy danych w kolumnach oraz długość danych przechowywanych w poszczególnych kolumnach.

13. Aplikacja – założenia Przykładowe funkcje bezpieczeństwa realizowane przez aplikację są następujące: • Sprawdzanie obiektów przechowywanych w bazie danych • Sprawdzanie pakietów systemowych • Sprawdzanie synonimów • Sprawdzanie job’ów • Sprawdzanie triggerów • Sprawdzanie wykorzystania wrażliwych pakietów Przykładowe założenia realizacyjne funkcji bezpieczeństwa: • Funkcje bezpieczeństwa wykonuje pakiet PL/SQL eksportowany za każdym uruchomieniem mechanizmu monitorowania do monitorowanej instancji bazy danych • Przechowywanie wyników działania programu poza monitorowanymi instancjami baz danych lub wręcz przechowywanie wyników poza bzami danych.

14. Aplikacja - działanie Architektura aplikacji

15. Aplikacja - działanie Sposób działania aplikacji

16. Aplikacja – przykład działania • Uruchomienie aplikacji w trybie pobranie sygnatur referencyjnych • Zasymulowanie działania rootkita po przez zainstalowanie widoku DBA_JOBS ze zmienionym kodem • Uruchomienie aplikacji w trybie porównania zbiorów sygnatur • Wynik: <Report_List> <DBObject> <ObjectID>78</ObjectID> <ObjectRefName> DBA_JOBS</ObjectRefName> <ObjectRefType>View</ObjectRefType> <Reason>Nie zgadzająca się wartość funkcji skrótu</Reason> <ObjectRefHash>36fe2e8339e715ed4e17f1d09d9532bb</ObjectRefHash> <ObjectCountHash>36fe2e8339e715ed4e17f1d09d9532bc</ObjectCountHash> </DBObject> </Report_List>

17. Szerszy kontekst • Monitorowanie spójności środowisk w organizacji • Wprowadzanie nie autoryzowanych poprawek do kodu aplikacji • Kontrola działalności DBA na bazach danych • Funkcja kontrolna Release and Deployment Management • Centralizacja wiedzy o stanie środowisk w organizacji

18. Dalsze możliwe drogi rozwoju aplikacji • Automatyczne sprawdzanie środowisk • Możliwość definicji wyjątków • Dodanie możliwości sprawdzania danych w określonych tabelach • Zwiększenie wydajności • Centralizacja nadawania i kontroli uprawnień

19. Dziękuję za uwagę Pytania