Ochrana perimetru je prolomitelná a hrozby pro databáze navíc nepocházejí jen z okolí podniku, ale i od tzv. insiderů, tedy uživatelů, kteří mají legální přístup do podnikové sítě.
Pokud se nespokojený zaměstnanec rozhodne poškodit podniková data, nic mu v tom často nebrání. Existují však cesty, jak útočníkům jejich snažení znemožnit nebo alespoň značně ztížit.
Typické zranitelnosti databází
První skupinou zranitelností jsou obecné nedostatky v konfiguraci databáze. Na vedoucím místě je v tomto případě nedostatečná politika hesel, která má za následek nemalé procento úniků dat.
Špatně nastavená přístupová práva, chybějící přehled v uživatelských účtech a přidělených oprávněních – to jsou jen další příklady konfiguračních nastavení, které by měl administrátor databáze neustále sledovat a udržovat, často se tak ale neděje.
Další skupinou jsou chyby plynoucí z databázové logiky a cílené útoky, které je mohou zneužít. Klasickým příkladem je útok typu SQL Injection. Tento typ lze rozdělit na dvě kategorie.
V prvním případě se útočník snaží zneužít interní chyby databázové logiky, v případě druhém pak vede cesta přes nevalidované aplikační formuláře, případně jinak špatně ošetřenou aplikační logiku.
Ochrana samotné databáze tak nezačíná až při vlastním provozu, ale na zabezpečení je třeba myslet již při návrhu aplikací spolupracujících s databází. Pokud administrátor konfiguraci databáze udržuje v souladu s aktuálními doporučeními, může tím zásadně ztížit situaci útočníkovi i pro zneužití dalších zranitelností.
Bohužel se musí počítat i se situací, kdy je útočníkem samotný databázový administrátor, který by neměl mít neomezený přístup ke všem citlivým datům uloženým v databázích.
Konkrétním příkladem SQL Injection útoku je zneužití interních chyb databáze k eskalaci oprávnění, typicky na úroveň práv databázového administrátora. V databázi se oprávnění jednotlivým uživatelům standardně přidělují jejími správci, díky některým chybám v zabezpečení však útočník může využít obyčejné účty s minimálními oprávněními pro ovládnutí celé databáze.
Je zcela zřejmé, že pokud existuje v celé databázi byť jen jeden uživatelský účet s výchozím heslem, případně heslem velmi slabým, útočník má cestu k ovládnutí celé databáze značně ulehčenou. Obvykle je takto databáze zranitelná jen do chvíle, dokud se neaplikují příslušné bezpečnostní záplaty, což však může trvat relativně dlouho.
Pokud si vezmeme za příklad databázi Oracle, za závažnou lze považovat nedokonalost autentizačního protokolu Oracle verze 11g, kdy je útočník schopen poměrně snadno prolomit jakékoli heslo do databáze prakticky bez zanechání stop.
Limitovaný je přitom jen časem k prolomení hesla, což však při dnešním výpočetním výkonu není relevantní překážka. Výpočet hesla navíc probíhá off-line, tedy bez nutnosti generovat požadavky na přihlášení k databázi. Výčet zranitelností je však mnohem širší, a pokud nechcete přijít o svá data, měli byste jim věnovat patřičnou pozornost.
Eliminace častých zranitelností
Administrátoři by měli sledovat aktuální trendy a doporučení při konfiguraci jednotlivých funkcí a databázových doplňků. Výchozí instalace databáze totiž většinou obsahují množství konfiguračních nedostatků, které mohou útočníkovi posloužit jako potenciální cesta ke kompromitaci databáze.
Základní konfigurační nastavení lze také jen těžko vynucovat jinými prostředky. Mnoho bezpečnostních děr je možné však ošetřit vhodnými nástroji a aplikací bezpečnostních záplat.
· Záplatování databází a jeho obtíže
Základem pro eliminaci velkého množství zranitelností je záplatování. To má mimo aspekty bezpečnostní i několik dalších rozměrů. Především jde o výkon databáze a ošetření dalších potenciálních chyb v databázové logice, které nemají přímý vliv na bezpečnost příslušné databáze.
Největší riziko vzniká ve chvíli, kdy se zranitelnost zveřejní. V lepším případě chybu objeví samotný výrobce, případně komunita uživatelů, kteří ji nemají v úmyslu zneužít. Po jejím zveřejnění pak producent reaguje vydáním bezpečnostní záplaty.
Následně se musí naplánovat a nasadit záplata na testovací prostředí. Závěrečnou a leckdy nejobtížnějšími fázemi jsou naplánování odstávky na produkčním prostředí a následná implementace záplaty.
Problémem procesu aplikace bezpečnostních záplat je tedy jeho relativní zdlouhavost. Od zveřejnění chyby až po implementaci záplaty často uplynou týdny, měsíce, ale dokonce i roky. Po celou tuto dobu je tak databáze nechráněná. Podle dostupných výzkumů je velké procento administrátorů DB ve velkém zpoždění s jejich instalací nebo bezpečnostní záplaty dokonce neinstaluje vůbec.
· Workaround
Některé chyby se mohou ošetřit za pomoci tzv. workaroundů. Lze se tak chránit po dobu, než bude možné nasadit bezpečnostní záplatu. Příkladem workaroundu může být např. dočasné omezení databázových oprávnění, která jsou často v určité míře nutná k využití jednotlivých zranitelností.
Ačkoli na tyto bezpečnostní nedostatky upozorní každý lepší skener databázových zranitelností, málokdo tomu skutečně věnuje pozornost. Obecně je však aplikování workaroundů poměrně náročné, neboť klade velkou režii na sledování veškerých zveřejněných chyb.
Většina zranitelností se dá za pomoci workaroundu ošetřit, může to však mít vážný dopad na funkčnost databáze, případně aplikace okolo ní.
Autor pracuje jako DB security specialist ve firmě Sefira.
Příště se podíváme na virtuální patching či produkty třetích stran ve spojení s bezpečností databází a také vás seznámíme s důležitými vlastnostmi skenerů zranitelností či systémů pro monitoring a ochranu databází.
Tento příspěvek vyšel v Security Worldu 1/2015.
PŘEDPLATNÉ
ČLÁNKY DO MAILU