Moderní databáze ukládají všechny druhy dat. Od triviálních až po vysoce citlivé. Restaurace, které navštěvujeme, naše umístění na mapě, naše identifikační údaje (např. čísla sociálního zabezpečení, adresy, lékařské záznamy, bankovní údaje atd...) a vše mezi tím je více než pravděpodobně někde uloženo v databázi. Není divu, že data jsou tak cenná.
Databázové technologie postupují závratným tempem. Inovace, pokrok, integrita a vylepšení jsou v popředí jako přímý výsledek práce inteligentních a oddaných inženýrů, vývojářů a robustních komunit podporujících tyto dodavatele.
Je tu však i druhá strana mince. To bohužel v tomto světě založeném na datech koexistuje ve formě malwaru, virů a exploitů v masivním a trvale vysokém měřítku.
Data jsou cenná i pro strany na této straně operace. Ale z různých důvodů. Kterýkoli z nich může být, ale není omezen na moc, vydírání, finanční zisk a přístup, ovládání, zábava, žerty, zlomyslnost, krádež, pomsta... Chápete. Seznam je nekonečný.
Bohužel, musíme pracovat s bezpečnostním myšlením. Bez tohoto myšlení necháme naše systémy zranitelné vůči těmto typům útoků. PostgreSQL je stejně náchylný ke kompromitaci, zneužití, krádeži, neoprávněnému přístupu/kontrole jako jiné formy softwaru.
Jaká opatření tedy můžeme přijmout, abychom snížili počet rizik pro naše instalace PostgreSQL?
Pevně cítím, že podpora povědomí o známých hrozbách je stejně dobrým místem, kde začít. Vědění je síla a měli bychom využít vše, co máme k dispozici. Kromě toho, jak můžeme hlídat to, čeho si ani neuvědomujeme, abychom zpřísnili zabezpečení těchto instancí PostgreSQL a chránili data, která se tam nacházejí?
Nedávno jsem hledal známé bezpečnostní „obavy“ a „hrozby“ zaměřené na prostředí PostgreSQL. Moje hledání zahrnovalo nedávné zprávy, články a příspěvky na blogu v prvním čtvrtletí roku 2018. Kromě tohoto konkrétního časového rámce jsem prozkoumal dobře známé dlouhodobé obavy, které jsou dnes stále životaschopnými hrozbami (jmenovitě SQL Injection), i když nebyly vyleštěny. nebo se oháněl jako „nedávno objevené '.
Příležitost k fotografování
Hluboký ponor do databázových útoků [Část III]:Proč obrázek Scarlett Johansson dostal moji databázi Postgres, aby mohl začít těžit Monero
Slovo o tomto prohnaném malwarovém útoku vrátilo nejvíce „zásahů“ z mých objektivních výsledků vyhledávání.
Navštívíme jeden z několika skvělých blogových příspěvků a přehled jeho obsahu. Na konec této sekce jsem také zahrnul další blogové příspěvky, takže si buďte jisti, a navštivte i ty, které tento průnik podrobně popisují.
Postřehy
Informace od společnosti Imperva, hlásí, že jejich databáze honeypot (StickyDB) objevila malwarový útok na jednom z jejich serverů PostgreSQL. Síť honeypotů, jak Imperva systém pojmenuje, je navržena tak, aby přiměla útočníky k útoku na databázi, aby se o ní (Imperva) dozvěděli a byli bezpečnější. V tomto konkrétním případě je nákladem malware, který kryptomizuje Monero, vložené do fotografie Scarlett Johansson.
Užitná zátěž je za běhu uložena na disk pomocí funkce lo_export. Ale zjevně se to děje proto, že lo_export je záznam v pg_proc oproti běžnému přímému volání (lo_export).
Zajímavé detaily přímo z blogového příspěvku zde pro extrémní přehlednost (viz citovaný článek),
Nyní je útočník schopen provádět místní systémové příkazy pomocí jedné jednoduché funkce – fun6440002537. Tato funkce SQL je obal pro volání funkce v jazyce C, „sys_eval“, malá exportovaná funkce v „tmp406001440“ (binární soubor založený na sqlmapproject), který v podstatě funguje jako proxy pro vyvolání příkazů shellu z klienta SQL.
Jaké budou tedy další kroky útoku? Nějaký průzkum. Takže to začalo získáním podrobností o GPU spuštěním lshw -c video a pokračovalo se v cat /proc/cpuinfo pro získání podrobností o CPU (obrázky 3-4). I když to zpočátku zní divně, dává to úplný smysl, když je vaším konečným cílem těžit více vaší oblíbené kryptoměny, že?
Díky kombinaci přístupu k databázi a možnosti spouštět kód na dálku, to vše při „létání pod radarem ' monitorovacích řešení, narušitel si poté stáhne užitečné zatížení prostřednictvím fotografie Scarlett Johansson.
(Poznámka:Fotka byla mezitím odstraněna ze svého hostovaného umístění. Zmínku naleznete v odkazujícím článku.)
Podle zprávy je užitečné zatížení v binárním formátu. Tento binární kód byl připojen k fotce, aby se při nahrávání stal aktuální fotkou a umožnil tak zobrazení obrázku.
Viz obrázek 6 příspěvku pro SQL odpovědné za použití wget, dd a spouštění chmod pro oprávnění ke staženému souboru. Tento stažený soubor pak vytvoří další spustitelný soubor, který je zodpovědný za skutečnou těžbu Monera. Po vší téhle hanebné práci je samozřejmě potřeba úklid a úklid.
Obrázek 7 znázorňuje provádění SQL.
Imperva doporučuje sledovat tento seznam potenciálních oblastí narušení v závěrečné sekci:
- Dejte si pozor na přímá volání PostgreSQL pro lo_export nebo nepřímá volání prostřednictvím položek v pg_proc.
- Dejte si pozor na volání funkcí PostgreSQL do binárních souborů v jazyce C.
- Používejte bránu firewall k blokování odchozího síťového provozu z databáze do Internetu.
- Ujistěte se, že databáze není přiřazena k veřejné IP adrese. Pokud ano, omezte přístup pouze na hostitele, kteří s ním komunikují (aplikační server nebo klienti vlastnění správci databází).
Imperva také provedla různé antivirové testy spolu s podrobnostmi o tom, jak mohou útočníci potenciálně lokalizovat zranitelné servery PostgreSQL. I když jsem je zde pro stručnost neuvedl, prostudujte si článek pro úplné podrobnosti o jejich zjištěních.
Doporučená četba
- Imperva má 2 předchozí články, které doprovázejí část 3 (ten, o kterém se diskutuje zde). I když se nezaměřují tak silně na PostgreSQL, jak jsme právě přehlédli, jsou vysoce informativní:
- Část 1
- Část 2
- Útok malwaru Scarlett Johansson PostgreSQL
- Hackeři cílí na databáze PostgreSQL pomocí Coinmineru skrytého v obrázku Scarlett Johannsson
- Vlákno Hacker News o exploitu.
Podrobnosti, hlášení a zranitelnosti CVE
Navštívil jsem tento web, který zveřejňuje nejnovější bezpečnostní hrozby podle jednotlivých dodavatelů, a objevil jsem 4 zranitelnosti v 1. čtvrtletí roku 2018. Stránka s informacemi o zabezpečení PostgreSQL je také obsahuje, takže neváhejte a konzultujte tento zdroj.
Ačkoli většina z nich byla řešena, považoval jsem za důležité zahrnout je do tohoto příspěvku, aby se o nich dozvěděli čtenáři, kteří o nich možná nevěděli. Mám pocit, že se od všech můžeme učit. Zejména v různých způsobech objevených zranitelností.
Jsou uvedeny níže v pořadí podle data zveřejnění:
I. CVE-2018-1052 datum zveřejnění 2018-02-09 :Datum aktualizace 3/10/2018
Přehled:
V PostgreSQL 10.x před verzí 10.2 byla nalezena zranitelnost odhalení paměti při rozdělování tabulek, což umožnilo ověřenému útočníkovi číst libovolné bajty paměti serveru prostřednictvím účelově vytvořeného vložení do rozdělené tabulky.
Tato chyba zabezpečení byla opravena vydáním PostgreSQL 10.2 potvrzeným zde. Starší verze 9.x jsou také zmíněny, takže navštivte tento odkaz a zkontrolujte svou konkrétní verzi.
II. CVE-2018-1053 datum zveřejnění 2018-02-09 :Datum aktualizace 15. 3. 2018
Přehled:
V PostgreSQL 9.3.x před 9.3.21, 9.4.x před 9.4.16, 9.5.x před 9.5.11, 9.6.x před 9.6.7 a 10.x před 10.2 vytvoří pg_upgrade soubor v aktuálním pracovním adresáři obsahující výstup z `pg_dumpall -g` pod umask, která byla účinná, když uživatel vyvolal pg_upgrade, a ne pod 0077, která se normálně používá pro jiné dočasné soubory. To může ověřenému útočníkovi umožnit číst nebo upravovat jeden soubor, který může obsahovat šifrovaná nebo nešifrovaná hesla databáze. Útok je neproveditelný, pokud adresářový režim blokuje útočníkovi prohledávat aktuální pracovní adresář nebo pokud převládající umask blokuje útočníkovi otevření souboru.
Stejně jako u předchozího CVE-2018-1052 opravila PostgreSQL 10.2 tuto část chyby zabezpečení:
Zajistěte, aby všechny dočasné soubory vytvořené pomocí "pg_upgrade" nebyly čitelné ve světě
Touto chybou zabezpečení je postiženo mnoho starších verzí PostgreSQL. Ujistěte se a navštivte uvedený odkaz pro všechny uvedené verze.
III. CVE-2017-14798 datum zveřejnění 2018-03-01 :Datum aktualizace 26. 3. 2018
Přehled:
Spor v iniciačním skriptu PostgreSQL by mohl být použit útočníky, kteří mají přístup k účtu PostgreSQL, k eskalaci svých oprávnění na root.
Ačkoli jsem nikde na odkazující stránce nenašel, že byla zmíněna PostgreSQL verze 10, mnoho starších verzí je, takže pokud používáte starší verze, navštivte tento odkaz.
Uživatele Suse Linux Enterprise Server by mohly zajímat 2 propojené články zde a zde, kde byla tato chyba zabezpečení opravena pro init skript verze 9.4.
IV. CVE-2018-1058 datum zveřejnění 2018-03-02 :Datum aktualizace 22. 3. 2018
Přehled:
Byla nalezena chyba ve způsobu, jakým PostgreSQL umožňoval uživateli upravit chování dotazu pro jiné uživatele. Útočník s uživatelským účtem by mohl tuto chybu využít ke spuštění kódu s oprávněním superuživatele v databázi. Ovlivněny jsou verze 9.3 až 10.
Toto vydání aktualizace zmiňuje tuto chybu zabezpečení se zajímavým propojeným dokumentem, který by měli všichni uživatelé navštívit.
Článek poskytuje fantastického průvodce od komunity s názvem A Guide to CVE-2018-1058:Protect Your Search Path, který obsahuje neuvěřitelné množství informací o zranitelnosti, rizicích a osvědčených postupech pro boj s ní.
Pokusím se to shrnout, ale navštivte průvodce pro váš vlastní prospěch, porozumění a porozumění.
Přehled:
S příchodem PostgreSQL verze 7.3 byla schémata zavedena do ekosystému. Toto vylepšení umožňuje uživatelům vytvářet objekty v samostatných jmenných prostorech. Ve výchozím nastavení, když uživatel vytvoří databázi, PostgreSQL také vytvoří veřejné schéma, ve kterém jsou vytvořeny všechny nové objekty. Uživatelé, kteří se mohou připojit k databázi, mohou také vytvářet objekty ve veřejném schématu této databáze.
Tato sekce přímo z průvodce je velmi důležitá (viz citovaný článek):
Schémata umožňují uživatelům objekty jmenného prostoru, takže objekty stejného jména mohou existovat v různých schématech ve stejné databázi. Pokud existují objekty se stejným názvem v různých schématech a konkrétní pár schéma/objekt není specifikován (tj. schema.object), PostgreSQL rozhodne, který objekt použít, na základě nastavení search_path. Nastavení search_path určuje pořadí, ve kterém jsou schémata prohledávána při hledání objektu. Výchozí hodnota pro search_path je $user,public, kde $user odkazuje na jméno připojeného uživatele (které lze určit provedením SELECT SESSION_USER;).
Další klíčový bod je zde:
Problém popsaný v CVE-2018-1058 se točí kolem výchozího „veřejného“ schématu a toho, jak PostgreSQL používá nastavení search_path. Možnost vytvářet objekty se stejnými názvy v různých schématech v kombinaci s tím, jak PostgreSQL vyhledává objekty ve schématech, představuje příležitost pro uživatele upravit chování dotazu pro ostatní uživatele.
Níže je uveden seznam na vysoké úrovni, který průvodce doporučuje použití těchto postupů, jak je stanoveno pro snížení rizika této chyby zabezpečení:
- Nepovolit uživatelům vytvářet nové objekty ve veřejném schématu
- Nastavte výchozí cestu hledání pro uživatele databáze
- Nastavte výchozí cestu hledání v konfiguračním souboru PostgreSQL (postgresql.conf)
Injekce SQL
Jakékoli 'se zaměřením na zabezpečení Příspěvek nebo článek na blogu SQL se nemůže jako takový označit bez zmínky o SQL injection. I když tato metoda útoku není v žádném případě „nové dítě na bloku ', musí být zahrnuto.
SQL Injection je vždy hrozbou a možná ještě více v prostoru webových aplikací. Jakákoli databáze SQL – včetně PostgreSQL – je vůči ní potenciálně zranitelná.
I když nemám hlubokou znalostní základnu o SQL Injection – také známém jako SQLi – udělám, co bude v mých silách, abych vám poskytl stručné shrnutí toho, jak to může potenciálně ovlivnit váš PostgreSQL server a nakonec, jak snížit rizika pádu kořistí. k tomu.
Podívejte se na odkazy uvedené na konci této části, z nichž všechny obsahují množství informací, vysvětlení a příkladů v oblastech, o kterých nejsem schopen adekvátně komunikovat.
Bohužel existuje několik typů SQL injekcí a všechny sdílejí společný cíl vkládat útočné SQL do dotazů pro provedení v databázi, které možná nebyly původně zamýšleny ani navrženy vývojářem.
Neupravený uživatelský vstup, špatně navržená nebo neexistující kontrola typu (AKA validace) spolu s neuniknutým uživatelským vstupem – to vše může potenciálně ponechat dveře dokořán pro potenciální útočníky. Mnoho rozhraní API pro webové programování poskytuje určitou ochranu proti SQLi:např. ORM (Object Relational Mapper), parametrizované dotazy, kontrola typu atd... Je však odpovědností vývojáře vynaložit veškeré úsilí a omezit primární scénáře pro vkládání SQL implementací ty odklony a mechanismy, které mají k dispozici.
Zde jsou pozoruhodné návrhy, jak snížit riziko injekce SQL z Cheat Sheetu OWASP SQL Injection Prevention. Ujistěte se a navštivte jej, kde najdete kompletní podrobný příklad použití v praxi (viz citovaný článek).
Primární obrana:
- Možnost 1:Použití připravených výpisů (s parametrizovanými dotazy)
- Možnost 2:Použití uložených procedur
- Možnost 3:Ověření zadání bílé listiny
- Možnost 4:Escapování veškerého vstupu poskytnutého uživatelem
Další obrany:
- Také:Vynucení nejmenšího privilegia
- Také:Provádění ověření vstupu bílé listiny jako sekundární obrana
Doporučená četba:
Zahrnul jsem další články se spoustou informací pro další studium a povědomí:
- Co je SQL injection? Tato stará, ale vychytávka může vaše webové aplikace bolet
- Injekce SQL (Wikipedie)
- SQL Injection (CLOUDFLARE)
- SQL Injection (w3schools.com)
- Cheat Sheet prevence vkládání SQL
- Testování SQL Injection
- Chyby zabezpečení SQL Injection a jak jim předcházet
- Cheat Sheet pro SQL Injection
Oprávnění role Postgres
Máme přísloví pro něco v duchu „Jsme sami sobě nejhorším nepřítelem ."
Určitě to můžeme aplikovat na práci v prostředí PostgreSQL. Zanedbání, nepochopení nebo nedostatek pečlivosti jsou stejně příležitostí k útokům a neoprávněnému použití jako ty úmyslně spuštěné.
Možná ještě více, když neúmyslně umožňuje snazší přístup, trasy a kanály pro provinilé strany.
Zmíním oblast, která vždy potřebuje čas od času přehodnocení nebo přehodnocení.
Neoprávněná nebo nadbytečná oprávnění role.
- SUPERUSER
- CREATROLE
- VYTVOŘENOB
- GRANT
Toto sloučení privilegií rozhodně stojí za pozornost. SUPERUSER a CREATROLE jsou extrémně výkonné příkazy a lépe by je sloužil v rukou DBA než analytika nebo vývojáře, nemyslíte?
Potřebuje role skutečně atribut CREATEDB? A co GRANT? Tento atribut má potenciál ke zneužití ve špatných rukou.
Než povolíte rolem tyto atributy ve vašem prostředí, důkladně zvažte všechny možnosti.
Strategie, osvědčené postupy a posílení
Níže je uveden seznam užitečných blogových příspěvků, článků, kontrolních seznamů a průvodců, které se vrátily za „rok zpět“ (v době psaní tohoto článku) výsledky vyhledávání. Nejsou uvedeny v žádném pořadí podle důležitosti a každý nabízí pozoruhodné návrhy.
- Jednoduché způsoby, jak ochránit servery Postgres před nepravděpodobným vektorem útoku:Nepovedený obrázek Scarlett Johansson
- Pomáháme zabezpečit vaši databázi PostgreSQL
- Nebuďte tvrdohlaví... Zpevněte svou databázi PostgreSQL, abyste zajistili bezpečnost
- Jak zabezpečit databázi PostgreSQL – 10 tipů
- Zabezpečení PostgreSQL před externím útokem
- Oprávnění a zabezpečení PostgreSQL – uzamčení veřejného schématu
Závěr
V tomto blogu jsme prošli bezpečnostními problémy, které se týkají správců PostgreSQL po celém světě:mezi ně patří SQL injection, což je svatý grál všech bezpečnostních incidentů, překlepy v základních přístupech k řešení zabezpečení dat, jako je selhání řádného zpřísnění oprávnění ve vaší infrastruktuře a také některé méně známé bezpečnostní problémy, které mohou být přehlédnuty. Pokud jde o bezpečnost našich dat, je důležité, abychom přijali a uplatňovali rady od důvěryhodných stran, jako je Imperva a podobně, které nám poskytují způsoby, jak se chránit jak před základními útoky, tak před nulovými útoky (zneužití, které ještě nebylo známé dříve) podobně, protože renomované rady znamenají dobrou budoucnost pro naše databáze a infrastrukturu jako celek.
Mějte na paměti, že bezpečnostní opatření, která musíme přijmout, by do značné míry závisela na zranitelnostech, kterým se chceme bránit, ale obecně platí, že znalost všech nezbytných obran k odražení SQL injection, správným používáním privilegia a vždy je zásadní snaha snížit naši úroveň rizika souvisejícího se zranitelnostmi. Zůstat v obraze o tom, co se děje v bezpečnostním prostoru PostgreSQL, nám také udělá divy:naše servery (a následně i data) můžeme dobře bránit pouze tehdy, když víme, co mohou útočníci sledovat.
Pokud hledáte další osvědčené postupy pro zlepšení zabezpečení nebo výkonu vašich instalací PostgreSQL, obraťte se na ClusterControl:jelikož je tento nástroj vyvíjen špičkovými odborníky na databáze z celého světa, rozezpívají vaše databáze během okamžiku. Tento produkt je také dodáván s 30denní bezplatnou zkušební verzí, takže si nenechte ujít vyzkoušení všech funkcí, které může ClusterControl vaší firmě nabídnout, a vyzkoušejte to ještě dnes.
Další obsah o tom, jak byste měli postupovat při zabezpečení instancí databáze PostgreSQL, najdete na blogu Somenines, kde najdete radu:naučit se automatizovat audity zabezpečení pro PostgreSQL bude jistě krok správným směrem. Nezapomeňte nás sledovat na Twitteru, LinkedIn a přihlásit se k odběru našeho RSS kanálu pro další aktualizace a uvidíme se u dalšího.