Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych

Podatności, incydenty oraz
praktyczne możliwości ochrony
środowisk bazodanowych
Bartosz Kryński
bartosz.krynski@clico.pl

>> Studencki Festiwal Informatyczny 2013

© 2013 CLiCO LTD

Plan wystąpienia

•

Wprowadzenie

•

Ataki z zewnątrz

•

Incydenty Client-side oraz Server-side

•

Przykłady wycieku danych inicjowane przez
uprzywilejowanych użytkowników

•

Metody zabezpieczenia baz danych

•

Podsumowanie


©CLICO Sp. zo.o., 2010
©CLICO Sp. CLiCO LTD
© 2013 z o.o., 2010

Incydenty dotyczące dostępu do baz danych

Dostęp
zewnętrzny

Ataki
Techniczne

Aplikacje

Ataki
Logiczne

Centrum danych

1.E-commerce
2.Bankowość elektr.
3.Systemy HR

Dane
1.Dane finansowe
2.Numery kart kredyt.
3.Dane personalne

Dostęp
wewnątrz

Błędy
uprawnień
Egzekwowanie
polityki

Oszustwa

Klienci,
Partnerzy,
Pracownicy,
Intruz

Kontrola
nad
zdarzeniami

Podatności
baz danych

Operacje
uprzywilejowane

Brak zabezpieczeń
transmisji danych

Pracownicy
Złośliwi użytkownicy,
Stacje skompromitowane

Administratorzy/Dostawcy

© Imperva LTD


© 2013 z o.o., 2010

Skąd wziąć informacje dot. infrastruktury
Podatności w firmach:
• Niezabezpieczone hasłem elementy baz danych, np.
Listener w bazie Oracle
• Niezabezpieczone hasłem aplikacje Web do zarządzania
• Informacje o sieci i zabezpieczeniach na stronach Web
• Informacje z innych serwerów (np. usługi DNS)
• Anonimowe FTP z plikami konfiguracyjnymi
• Nieświadomi pracownicy
• Aplikacje typu SNMP, WMI
• Stosowanie domyślnych haseł i kont


© 2013 z o.o., 2010

Ataki typu Client-side vs Server-side
Client-side attack:
•
•
•

Stacja klienta (np. administratora lub dostawcy) zostaje
zainfekowana
Klient podłącza stację do sieci z bazami danych
Złośliwe oprogramowanie penetruje sieć lub podsłuchuje
transmisję klienta

Server-side attack:
•

•

Intruz lub oprogramowanie intruza atakuje serwer bazy danych
(np. poprzez wykorzystanie przygotowanego wcześniej kodu
exploit)
poprzez wykorzystanie podatności instalowane jest złośliwe
oprogramowanie na serwerze, lub nawiązywana sesja zdalna
z hostem intruza


© 2013 z o.o., 2010

Ataki typu Client-side w aspekcie ochrony
baz danych
Etapy pośredniego włamania do bazy danych na
przykładzie Oracle
Etap 1) zachęcenie osoby uprawnionej do pobrania oraz
wykonania złośliwego kodu

Etap 2) Infekcja stacji administracyjnej
Etap 3) Próby ataku środowiska bazy danych lub pasywny
nasłuch komunikacji administrator  baza danych


© 2013 z o.o., 2010

Etap 1. Przykłady zachęcania ofiary do
pobrania spreparowanego pliku

•

Wysłanie odnośnika do pliku, np. xls

•

Udostępnienie na serwerze plików (np. ftp, cifs) nowej wersji
aplikacji zarządzania bazą, jak analizator zapytań, klienta SSH
(jak np. putty)

•

Przesłanie pocztą pliku pdf z ciekawą nazwą (np. wypłaty 2012,

plany zwolnień 2013, pytania_exam_sem_letni.pdf). Ile osób nie
otworzy powyższych plików? 


© 2013 z o.o., 2010

Etap 2. Przykładowe możliwości infekcji stacji
administracyjnej
•

Spreparowany plik posiada wewnątrz exploit, który
wykorzystując podatność aplikacji wprowadza oprogramowanie
backdoor na stację administratora, lub zestawia połączenie
zwrotne payload do serwera intruza.

•

Przykłady „referencyjnych” programów
z dużą ilością podatności:
•

Adobe Reader

•

Flash Player

•

Microsoft Excel


© 2013 z o.o., 2010

Etap 2. Przygotowanie pliku pdf
•

•

Tworzymy plik z exploitem dla aplikacji Adobe Reader

Wysyłamy plik do ofiary
(poprzez email, ftp, odnośnik na stronie etc)


© 2013 z o.o., 2010

Etap 2. Konfiguracja serwera nasłuchu

•

Włączamy kolejny exploit typu listener / handler


© 2013 z o.o., 2010

Etap 2. Infekcja stacji administracyjnej
•

Użytkownik otwiera zainfekowany plik, aplikacja nie zostaje
uruchomiona lub administrator otrzymuje informacje na temat
niepoprawnej pracy

•

W menedżerze zadań Windows widać jedynie włączone procesy
Acrobat.


© 2013 z o.o., 2010

Etap 2. W tym czasie intruz zmienia proces, do
którego przypięty jest wykonywany payload
•

Intruz sprawdza jakie procesy
są aktywne (np. putty)

•

Intruz zmienia proces na
PID ID == putty


© 2013 z o.o., 2010

Etap 3. Podsłuch danych dostępowych do
środowiska bazy danych
•

Intruz włącza funkcję keylogger w aplikacji putty

•

Nieświadomy zagrożenia administrator wpisuje w putty dane
dostępowe do serwera bazy danych, w analogiczny sposób
mogą być to dane dostępowe do samej bazy dla innych

aplikacji.


© 2013 z o.o., 2010

Etap 3. Podsłuch danych dostępowych do
środowiska bazy danych
•

Intruz wyświetla dane dostępowe użytkownika root

•

Intruz jest w stanie wykonać wiele innych czynności, m.in.
wyświetlenie i zmiana wpisów w tablicy rutingu.


© 2013 z o.o., 2010

Przykład symulacji włamań do serwera bazy danych Oracle
ze stacji administratora bez znajomości hasła użytkownika
1.

Intruz z wykorzystaniem niezabezpieczonego hasłem procesu Listener uzyskał
informacje o systemie i bazie danych Oracle (wersja, katalogi)
# tnscmd10g.pl version -h <IP serwera> --indent
# tnscmd10g.pl status -h <IP serwera> --indent

2.

Intruz wykorzystując standardowe konto w Oracle 'dbsnmp' z hasłem 'dbsnmp'
uzyskał dostęp do bazy danych i odczytał hashe haseł użytkowników (m.in. sys
i system) w celu uzyskania hasła administratora bazy
# sqlplus dbsnmp/dbsnmp@<IP serwera>/spac
(...)
SQL> select username, password from dba_users;
USERNAME

PASSWORD

------------------------------ -----------------------------SYS
SYSTEM

................
................

(...)

© 2013 z o.o., 2010

Przykład symulacji włamań do serwera bazy danych Oracle
ze stacji administratora bez znajomości hasła użytkownika

3.

Intruz dokonał sprawdzenia haseł w bazie Oracle (narzędzia 'checkpwd')

4.

Intruz uzyskał hasło dostępu i zalogował się na konto administratora serwera
bazy danych i odczytał plik z hashami haseł użytkowników
# ssh <IP serwera>
# cd /etc/security
# cat passwd

5.

Intruz zatrzymał proces bazy danych Oracle Listener
# tnscmd10g.pl stop -h <IP serwera>


© 2013 z o.o., 2010

Ataki bezpośrednie wykorzystujące
podatności baz danych
•

W analogiczny sposób do pokazanego uprzednio intruz może bez posiadania
hasła administratora przejąć kontrolę nad bazą danych poprzez wykorzystanie
jej podatności


© 2013 z o.o., 2010

Niezabezpieczona komunikacja sieciowa

•

Szyfrowanie transmisji danych jest jednym z istotnych aspektów związanych
z bezpieczeństwem środowiska bazy danych

•

Sam mechanizm szyfrowania danych jest aspektem łatwym, gorzej
z wdrożeniem i utrzymaniem na dużą skalę, w wielkich środowiskach

•

Łamanie szyfrów jest nieopłacalne,
łatwiej wykraść klucze 


© 2013 z o.o., 2010

Incydenty dotyczące dostępu do baz danych

Dostęp
zewnętrzny

Ataki
Techniczne

Aplikacje

Ataki
Logiczne

Centrum danych

1.E-commerce
2.Bankowość elektr.
3.Systemy HR

Dane
1.Dane finansowe
2.Numery kart kredyt.
3.PII


Dostęp
wewnątrz

Błędy
uprawnień
Egzekwowanie
polityki

Oszustwa

Klienci,
Partnerzy,
Pracownicy,
Intruz

Kontrola
nad
zdarzeniami

Podatności
baz danych

Operacje
uprzywilejowane

Brak zabezpieczeń
transmisji danych

Pracownicy
Złośliwi użytkownicy,
Stacje skompromitowane

Administratorzy/Dostawcy

© 2013 z o.o., 2010

Problemy techniczne i organizacyjne
Zarządzanie uprawnieniami w bazach danych


© 2013 z o.o., 2010


Ograniczenia w regułach polityki bezpieczeństwa

•

Reguły dotyczą poziomu grants, np.
grant select to min_salaries_annual to qwsa123;

•

Co w sytuacji, gdy qwsa123 mógłby wykonywać określone szablony zapytań na
tabeli min_salaries_annual, ale wyświetlenie np.
select * from min_salaries_annual;
powinno być blokowane?

•

Jak wykrywać incydenty wykonywane przez użytkowników SYS/SYSTEM/SYSDBA?
Oni nie mają w bazie danych ograniczeń dostępu

•

W jaki sposób wykryć incydent, wykonany przez użytkownika SYSDBA13p2, który
przez VPN wykonuje „nieautoryzowany” backup bazy danych?


© 2013 z o.o., 2010


Wyciek danych przez pracowników i firmy zewnętrzne
Aplikacje
Portale
db user: sysdba

db user: app1

IPSec/SSL VPN
db user: app1???
db user: sysdba

Bazy danych

Administratorzy


© 2013 z o.o., 2010

Problemy dotyczące wbudowanych
mechanizmów logowania zdarzeń
•

Brak szczegółowych informacji dotyczących zdarzeń

•

Bez możliwości analizy statystyk dotyczących ruchu

•

Moduły logowania przeznaczone dla administratorów

•

Brak SOD

•

Wpływ na wydajność (CPU/RAM/HDD)

•

Bez możliwości pobrania informacji o użytkownikach aplikacyjnych

Rys. 1 Przykład logów bazy Microsoft SQL Server 2005

Rys. 2 Przykład logów aplikacji Microsoft Sharepoint


© 2013 z o.o., 2010

Metody zabezpieczania baz danych

•

Niezależne audyty bezpieczeństwa środowiska baz danych, a w nich m.in.:
•

Analiza podatności składowych (jak: aplikacje, systemy operacyjne, bazy,
sieć, systemy zabezpieczeń + mechanizmy reakcji na incydenty)

•
Świadomość użytkowników (ang. social engineering)
Projektowanie oraz implementacja dostępu do baz danych zgodnie z dobrymi
zasadami
•
Weakest link security
•
Defense in depth
•
Compartmentalization of information
•
Least privilege
•

Wdrożenie systemów zabezpieczeń, pracujący klasy: DBF / DAM / URM / IM /
Szyfratory danych, pracujących w sposób niezależny od konfiguracji
i podatności baz danych


© 2013 z o.o., 2010

Database Firewall
•

Dostęp na zasadzie Least Privileges, na bazie „typowych zachowań
użytkowników”

•

Szablony akceptowalnych zapytań do bazy danych


© 2013 z o.o., 2010

Database Firewall
•

Szczegółowe reguły polityki bezpieczeństwa w dostępie do baz danych,
wszystkie informacje dot. incydentów

Alarm przy próbie wykonania
operacji uprzywilejowanej

Kto wykonał polecenie?

Zidentyfikowane zapytanie


© 2013 z o.o., 2010

Database Activity Monitoring

Logi dotyczące wszystkich kluczowych zdarzeń

Gdzie?

Kto?

Jak?

Do czego?

•

DAM powinien posiadać funkcję identyfikacji użytkowników łączących się przez
aplikacje Web do baz danych.

•

DAM powinien posiadać dodatkowo możliwość pobrania dodatkowych danych, np. na
temat użytkowników z zewnętrznych źródeł, jak system biletowy,
LDAP, bazy danych czy inne systemy, np. HR


© 2013 z o.o., 2010

Podsumowanie
• Incydenty związane z bezpieczeństwem baz danych
w każdym z analizowanych przypadków wykorzystują
podatność jednego lub wielu elementów środowiska
– Aplikacji

– Braku aktualizacji lub niewłaściwej konfiguracji bazy danych
– Błędów dot. systemu operacyjnego lub konfiguracji / architektury
sieci (np. możliwy do wykonania jest atak Pivoting poprzez
jednoczesne podłączenie użytkownika do sieci internet
i segmentu baz danych

• Najbardziej newralgicznym i często najprostszym do
„złamania” jest element zarządzający systemem …


© 2013 z o.o., 2010

Podsumowanie

•

Projektowanie, wdrażanie oraz właściwe utrzymanie
zabezpieczeń pracujących zgodnie z zasadą
Defense-in-Depth znacznie ogranicza możliwość
utraty danych oraz przeprowadzanie naruszeń
bezpieczeństwa, pomimo posiadania często
krytycznych podatności w środowisku.


© 2013 z o.o., 2010

Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (7)

Destacado

Destacado (14)

Similar a Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych

Similar a Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych (20)

Más de studenckifestiwalinformatyczny

Más de studenckifestiwalinformatyczny (6)

Podatności, incydenty oraz praktyczne możliwości ochrony środowisk bazodanowych