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

>> Studencki Festiwal Informatyczny 2013 © 2013 CLiCO LTD

Podatności, incydenty oraz

praktyczne możliwości ochrony środowisk bazodanowych

Bartosz Kryński

[email protected]

©CLICO Sp. z o.o., 2010 ©CLICO Sp. z o.o., 2010 >> Studencki Festiwal Informatyczny 2013 © 2013 CLiCO LTD

• 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

Plan wystąpienia


Incydenty dotyczące dostępu do baz danych

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

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

Aplikacje Dane Centrum danych

Dostęp zewnętrzny Dostęp

wewnątrz

Administratorzy/Dostawcy

Klienci, Partnerzy, Pracownicy, Intruz

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

Ataki Techniczne

Ataki Logiczne

Oszustwa

Kontrola nad

zdarzeniami

Błędy uprawnień

Egzekwowanie polityki

Podatności baz danych

Brak zabezpieczeń transmisji danych

Operacje uprzywilejowane

© Imperva LTD


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


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


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


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?


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


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)


Etap 2. Konfiguracja serwera nasłuchu

• Włączamy kolejny exploit typu listener / handler


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.


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


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.


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.


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 ................

(...)


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>


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


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


Incydenty dotyczące dostępu do baz danych

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

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

Aplikacje Dane Centrum danych

Dostęp zewnętrzny Dostęp

wewnątrz

Administratorzy/Dostawcy

Klienci, Partnerzy, Pracownicy, Intruz

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

Ataki Techniczne

Ataki Logiczne

Oszustwa

Kontrola nad

zdarzeniami

Błędy uprawnień

Egzekwowanie polityki

Podatności baz danych

Brak zabezpieczeń transmisji danych

Operacje uprzywilejowane


Problemy techniczne i organizacyjne Zarządzanie uprawnieniami w bazach danych


Problemy techniczne i organizacyjne 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?


Problemy techniczne i organizacyjne Wyciek danych przez pracowników i firmy zewnętrzne

Aplikacje

Portale

Administratorzy

Bazy danych

db

us

er: a

pp

1

db

us

er: s

ysd

ba

IPSec/SSL VPN

db user: app1???

db

us

er: s

ysd

ba


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


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


Metody zabezpieczania baz danych Database Firewall

• Dostęp na zasadzie Least Privileges, na bazie „typowych zachowań

użytkowników”

• Szablony akceptowalnych zapytań do bazy danych


Metody zabezpieczania baz danych 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


Metody zabezpieczania baz danych Database Activity Monitoring

• 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

Logi dotyczące wszystkich kluczowych zdarzeń

Gdzie? Kto? Do czego? Jak?


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 …


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.

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

Documents

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