Nowoczesne bazy danych przechowują wszelkiego rodzaju dane. Od trywialnych do bardzo wrażliwych. Często odwiedzane restauracje, lokalizacje na naszych mapach, nasze dane uwierzytelniające (np. numery ubezpieczenia społecznego, adresy, dokumentacja medyczna, informacje bankowe itp.) i wszystko pomiędzy jest najprawdopodobniej przechowywane gdzieś w bazie danych. Nic dziwnego, że dane są tak cenne.
Technologie baz danych rozwijają się w zawrotnym tempie. Innowacje, postęp, integralność i liczne ulepszenia są na pierwszym planie jako bezpośredni wynik pracy inteligentnych i oddanych inżynierów, programistów i solidnych społeczności wspierających tych dostawców.
Jest jednak druga strona medalu. To, niestety, współistnieje w tym opartym na danych świecie w postaci złośliwego oprogramowania, wirusów i exploitów na masową, wszech czasów na dużą skalę.
Dane są cenne również dla stron po tej stronie operacji. Ale z różnych powodów. Każda z nich może być między innymi władzą, szantażem, zyskami finansowymi i dostępem, kontrolą, zabawą, psikusami, złośliwością, kradzieżą, zemstą... Masz pomysł. Lista jest nieskończona.
Niestety, musimy działać z nastawieniem na bezpieczeństwo. Bez tego sposobu myślenia narażamy nasze systemy na tego typu ataki. PostgreSQL jest tak samo podatny na włamanie, niewłaściwe użycie, kradzież, nieautoryzowany dostęp/kontrolę, jak inne formy oprogramowania.
Więc jakie środki możemy podjąć, aby zmniejszyć liczbę zagrożeń dla naszych instalacji PostgreSQL?
Jestem głęboko przekonany, że promowanie świadomości znanych zagrożeń jest równie dobrym miejscem do rozpoczęcia, jak każde inne. Wiedza to potęga i powinniśmy używać wszystkiego, co mamy do dyspozycji. Poza tym, w jaki sposób możemy nadzorować to, czego nawet nie jesteśmy świadomi, aby wzmocnić zabezpieczenia tych instancji PostgreSQL i chronić dane tam znajdujące się?
Niedawno przeszukałem znane „obawy” i „zagrożenia” dotyczące bezpieczeństwa, których celem było środowisko PostgreSQL. Moje poszukiwania objęły ostatnie raporty, artykuły i wpisy na blogach z pierwszego kwartału 2018 r. Oprócz tego konkretnego przedziału czasowego, zbadałem dobrze znane od dawna obawy, które są nadal realnymi zagrożeniami (mianowicie iniekcja SQL), choć nie zostały dopracowane. lub wymawiane jako „niedawno odkryte '.
Możliwość robienia zdjęć
Głębokie zanurzenie w atakach na bazy danych [Część III]:Dlaczego zdjęcie Scarlett Johansson dostało moją bazę danych Postgres, aby rozpocząć wydobywanie Monero
Słowo o tym podstępnym ataku złośliwego oprogramowania zwróciło najwięcej „trafień” z moich obiektywnych wyników wyszukiwania.
Odwiedzimy jeden z kilku świetnych wpisów na blogu i zapoznamy się z jego treścią. Dołączyłem również dodatkowe posty na blogu pod koniec tej sekcji, więc koniecznie odwiedź je również i opisz szczegółowo to włamanie.
Obserwacje
Informacje z Imperva donoszą, że ich baza danych honeypot (StickyDB) wykryła atak złośliwego oprogramowania na jeden z ich serwerów PostgreSQL. Sieć honeypot, jak nazywa system Imperva, ma na celu nakłonienie napastników do zaatakowania bazy danych, aby (Imperva) mogli się o tym dowiedzieć i zwiększyć bezpieczeństwo. W tym konkretnym przypadku ładunek to złośliwe oprogramowanie, które wydobywa krypto Monero, osadzone na zdjęciu Scarlett Johansson.
Ładunek jest zrzucany na dysk w czasie wykonywania za pomocą funkcji lo_export. Ale najwyraźniej dzieje się tak, ponieważ lo_export jest wpisem w pg_proc w przeciwieństwie do zwykłego bezpośredniego wywoływania (lo_export).
Interesujące szczegóły bezpośrednio z wpisu na blogu, aby zapewnić wyjątkową przejrzystość (patrz cytowany artykuł),
Teraz atakujący może wykonywać polecenia systemu lokalnego za pomocą jednej prostej funkcji – fun6440002537. Ta funkcja SQL jest opakowaniem do wywoływania funkcji w języku C, „sys_eval”, małej eksportowanej funkcji w „tmp406001440” (plik binarny oparty na sqlmapproject), która zasadniczo działa jako proxy do wywoływania poleceń powłoki z klienta SQL.
Jakie będą więc kolejne etapy ataku? Trochę rozpoznania. Zaczęło się więc od uzyskania szczegółów GPU przez wykonanie lshw -c video i kontynuowało cat /proc/cpuinfo w celu uzyskania szczegółów procesora (Rysunki 3-4). Choć na początku wydaje się to dziwne, ma sens, gdy Twoim celem końcowym jest wydobycie większej ilości ulubionej kryptowaluty, prawda?
Dzięki połączeniu dostępu do bazy danych i możliwości zdalnego wykonywania kodu, a wszystko to podczas „lotu pod radarem „rozwiązań monitorujących, intruz pobiera następnie ładunek za pomocą zdjęcia Scarlett Johansson.
(Uwaga:zdjęcie zostało już usunięte z hostowanej lokalizacji. Zobacz artykuł z łączem dla wzmianki).
Według raportu ładunek jest w formacie binarnym. Ten kod binarny został dołączony do zdjęcia w celu przekazania rzeczywistego zdjęcia podczas przesyłania, umożliwiając oglądanie obrazu.
Zobacz rysunek 6 w poście dotyczącym kodu SQL odpowiedzialnego za wykorzystanie wget, dd i wykonanie chmod w celu uzyskania uprawnień do pobranego pliku. Ten pobrany plik tworzy następnie inny plik wykonywalny, który jest odpowiedzialny za faktyczne wydobycie Monero. Oczywiście po całej tej nikczemnej pracy potrzebne są sprzątanie i sprzątanie.
Rysunek 7 przedstawia wykonywanie kodu SQL.
Imperva zaleca monitorowanie tej listy potencjalnych obszarów naruszeń w końcowej sekcji:
- Uważaj na bezpośrednie wywołania PostgreSQL do lo_exportu lub wywołania pośrednie przez wpisy w pg_proc.
- Uważaj na funkcje PostgreSQL wywołujące pliki binarne w języku C.
- Użyj zapory sieciowej, aby zablokować wychodzący ruch sieciowy z bazy danych do Internetu.
- Upewnij się, że Twoja baza danych nie ma przypisanego publicznego adresu IP. Jeśli tak, ogranicz dostęp tylko do hostów, które z nim współdziałają (serwer aplikacji lub klienci należący do administratorów baz danych).
Firma Imperva przeprowadziła również różne testy antywirusowe wraz ze szczegółowymi informacjami, w jaki sposób atakujący mogą potencjalnie zlokalizować podatne na ataki serwery PostgreSQL. Chociaż nie uwzględniłem ich tutaj dla zwięzłości, zapoznaj się z artykułem, aby uzyskać szczegółowe informacje na temat ich ustaleń.
Zalecana lektura
- Imperva ma 2 poprzedzające artykuły, które towarzyszą części 3 (omawianej tutaj). Chociaż nie są one ukierunkowane na PostgreSQL, tak jak to właśnie omówiliśmy, są one bardzo pouczające:
- Część 1
- Część 2
- Atak złośliwego oprogramowania Scarlett Johansson PostgreSQL
- Hakerzy atakują bazy danych PostgreSQL z Coinminerem ukrytym w obrazie Scarlett Johannsson
- Wątek Hacker News dotyczący exploita.
Szczegóły CVE, raport i luki w zabezpieczeniach
Odwiedziłem tę witrynę, która publikuje najnowsze zagrożenia bezpieczeństwa według dostawców i odkryłem 4 luki w zabezpieczeniach w pierwszym kwartale 2018 r. Strona z informacjami o zabezpieczeniach PostgreSQL również je zawiera, więc zachęcamy do zapoznania się z tym zasobem.
Chociaż większość z nich została omówiona, uważam, że ważne jest, aby uwzględnić je w tym poście, aby uświadomić czytelnikom, którzy mogli o nich nie wiedzieć. Czuję, że możemy się od nich wszystkich uczyć. Zwłaszcza w przypadku różnych sposobów odkrywania luk.
Są one wymienione poniżej w kolejności dat publikacji:
I. CVE-2018-1052 data publikacji 2018-02-09 :Data aktualizacji 3/10/2018
Przegląd:
Luka umożliwiająca ujawnienie pamięci w partycjonowaniu tabel została znaleziona w PostgreSQL 10.x przed wersją 10.2, umożliwiając uwierzytelnionemu napastnikowi odczytanie dowolnych bajtów pamięci serwera poprzez specjalnie spreparowaną wstawkę do partycjonowanej tabeli.
Ta luka została naprawiona wraz z potwierdzoną tutaj wersją PostgreSQL 10.2. Wspomniano również o poprawionej starszej wersji 9.x, więc odwiedź ten link, aby sprawdzić swoją konkretną wersję.
II. CVE-2018-1053 data publikacji 2018-02-09 :Data aktualizacji 15.03.2018
Przegląd:
W PostgreSQL 9.3.x przed 9.3.21, 9.4.x przed 9.4.16, 9.5.x przed 9.5.11, 9.6.x przed 9.6.7 i 10.x przed 10.2, pg_upgrade tworzy w bieżącym katalogu roboczym plik zawierający dane wyjściowe z `pg_dumpall -g` pod umask, który był aktywny, gdy użytkownik wywołał pg_upgrade, a nie pod 0077, który jest normalnie używany dla innych plików tymczasowych. Może to umożliwić uwierzytelnionemu napastnikowi odczytanie lub zmodyfikowanie jednego pliku, który może zawierać zaszyfrowane lub niezaszyfrowane hasła bazy danych. Atak jest niewykonalny, jeśli tryb katalogu blokuje atakującemu przeszukiwanie bieżącego katalogu roboczego lub jeśli dominująca umask blokuje atakującemu otwieranie pliku.
Podobnie jak w poprzednim CVE-2018-1052, PostgreSQL 10.2 naprawił tę część luki:
Upewnij się, że wszystkie pliki tymczasowe utworzone za pomocą „pg_upgrade” nie nadają się do odczytu na całym świecie
Podatność ta dotyczy wielu starszych wersji PostgreSQL. Pamiętaj i odwiedź podany link dla wszystkich wymienionych wersji.
III. CVE-2017-14798 data publikacji 2018-03-01 :Data aktualizacji 26.03.2018
Przegląd:
Sytuacja wyścigu w skrypcie startowym PostgreSQL może być wykorzystana przez atakujących, którzy mogą uzyskać dostęp do konta PostgreSQL w celu eskalacji swoich uprawnień do roota.
Chociaż nie mogłem znaleźć nigdzie na stronie z linkami wspomnianej wersji 10 PostgreSQL, jest wiele starszych wersji, więc odwiedź ten link, jeśli używasz starszych wersji.
Użytkownicy Suse Linux Enterprise Server mogą zainteresować się 2 powiązanymi artykułami tutaj i tutaj, w których ta luka została naprawiona w skrypcie inicjującym w wersji 9.4.
IV. CVE-2018-1058 data publikacji 2018-03-02 :Data aktualizacji 22.03.2018
Przegląd:
Znaleziono lukę w sposobie, w jaki PostgreSQL umożliwiał użytkownikowi modyfikowanie zachowania zapytania dla innych użytkowników. Atakujący posiadający konto użytkownika może wykorzystać tę lukę do wykonania kodu z uprawnieniami superużytkownika w bazie danych. Dotyczy to wersji od 9.3 do 10.
To wydanie aktualizacji wspomina o tej luce w interesującym dokumencie z łączem, który wszyscy użytkownicy powinni odwiedzić.
Artykuł zawiera fantastyczny przewodnik społeczności zatytułowany A Guide to CVE-2018-1058:Protect Your Search Path, który zawiera niesamowitą ilość informacji na temat luki w zabezpieczeniach, zagrożeń i najlepszych praktyk dotyczących jej zwalczania.
Zrobię co w mojej mocy, aby podsumować, ale odwiedź przewodnik dla własnej korzyści, zrozumienia i zrozumienia.
Przegląd:
Wraz z pojawieniem się PostgreSQL w wersji 7.3 do ekosystemu zostały wprowadzone schematy. To ulepszenie umożliwia użytkownikom tworzenie obiektów w oddzielnych przestrzeniach nazw. Domyślnie, gdy użytkownik tworzy bazę danych, PostgreSQL tworzy również publiczny schemat, w którym tworzone są wszystkie nowe obiekty. Użytkownicy, którzy mogą łączyć się z bazą danych, mogą również tworzyć obiekty w publicznym schemacie tej bazy danych.
Ta sekcja bezpośrednio z przewodnika jest bardzo ważna (patrz cytowany artykuł):
Schematy umożliwiają użytkownikom korzystanie z obiektów przestrzeni nazw, dzięki czemu obiekty o tej samej nazwie mogą istnieć w różnych schematach w tej samej bazie danych. Jeśli istnieją obiekty o tej samej nazwie w różnych schematach, a konkretna para schemat/obiekt nie jest określona (tj. schemat.obiekt), PostgreSQL decyduje, którego obiektu użyć na podstawie ustawienia search_path. Ustawienie search_path określa kolejność przeszukiwania schematów podczas wyszukiwania obiektu. Domyślną wartością search_path jest $user,public, gdzie $user odnosi się do nazwy połączonego użytkownika (którą można określić, wykonując SELECT SESSION_USER;).
Kolejny kluczowy punkt jest tutaj:
Problem opisany w CVE-2018-1058 koncentruje się wokół domyślnego schematu „public” i tego, jak PostgreSQL używa ustawienia search_path. Możliwość tworzenia obiektów o tych samych nazwach w różnych schematach, w połączeniu ze sposobem, w jaki PostgreSQL wyszukuje obiekty w schematach, daje użytkownikowi możliwość zmodyfikowania zachowania zapytania dla innych użytkowników.
Poniżej znajduje się lista wysokiego poziomu, w której przewodnik zaleca stosowanie tych praktyk zgodnie z zaleceniami w celu zmniejszenia ryzyka tej luki:
- Nie zezwalaj użytkownikom na tworzenie nowych obiektów w schemacie publicznym
- Ustaw domyślną ścieżkę wyszukiwania dla użytkowników bazy danych
- Ustaw domyślną ścieżkę search_path w pliku konfiguracyjnym PostgreSQL (postgresql.conf)
Iniekcja SQL
Wszelkie „związane z bezpieczeństwem Post na blogu lub artykuł dotyczący SQL nie może się oznaczyć jako taki bez wzmianki o wstrzyknięciu SQL. Chociaż ta metoda ataku nie jest zbytnio wyobrażona „nowy dzieciak na bloku ', musi być dołączony.
SQL Injection jest zawsze zagrożeniem, a może nawet większym w przestrzeni aplikacji internetowych. Każda baza danych SQL - w tym PostgreSQL - jest potencjalnie na nią podatna.
Chociaż nie mam głębokiej bazy wiedzy na temat SQL Injection - znanego również jako SQLi - zrobię co w mojej mocy, aby przedstawić krótkie podsumowanie, w jaki sposób może to potencjalnie wpłynąć na twój serwer PostgreSQL i ostatecznie jak zmniejszyć ryzyko padnięcia ofiarą do niego.
Zapoznaj się z linkami podanymi na końcu tej sekcji, z których wszystkie zawierają bogactwo informacji, wyjaśnień i przykładów w tych obszarach, których nie jestem w stanie odpowiednio przekazać.
Niestety istnieje kilka rodzajów wstrzyknięć SQL i wszystkie mają wspólny cel, jakim jest wstawianie obraźliwego SQL do zapytań w celu wykonania w bazie danych, być może nie pierwotnie zamierzonych ani zaprojektowanych przez programistę.
Nieoczyszczone dane wejściowe użytkownika, źle zaprojektowane lub nieistniejące sprawdzanie typu (walidacja AKA), wraz z nieuniknionymi danymi wejściowymi użytkownika, wszystko to może potencjalnie pozostawić drzwi szeroko otwarte dla potencjalnych napastników. Wiele interfejsów API programowania internetowego zapewnia pewną ochronę przed SQLi:np. ORM (Object Relational Mapper), zapytania parametryczne, sprawdzanie typów itp. Jednak to programista jest odpowiedzialny za dołożenie wszelkich starań i ograniczenie scenariuszy prime dla wstrzykiwania SQL poprzez implementację te dywersje i mechanizmy, którymi dysponują.
Oto godne uwagi sugestie dotyczące zmniejszenia ryzyka wstrzyknięcia SQL z arkusza OWASP dotyczącego zapobiegania wstrzykiwaniu SQL. Pamiętaj i odwiedź go, aby zapoznać się z pełnymi szczegółowymi przykładami zastosowań w praktyce (patrz cytowany artykuł).
Obrona podstawowa:
- Opcja 1:użycie przygotowanych instrukcji (z zapytaniami sparametryzowanymi)
- Opcja 2:korzystanie z procedur zapisanych
- Opcja 3:Weryfikacja danych wejściowych białej listy
- Opcja 4:Ucieczka od wszystkich danych wprowadzonych przez użytkownika
Dodatkowa obrona:
- Również:Egzekwowanie najmniejszych uprawnień
- Również:przeprowadzanie walidacji danych wejściowych białej listy jako obrona wtórna
Zalecana lektura:
Dołączyłem dodatkowe artykuły z mnóstwem informacji do dalszych badań i świadomości:
- Co to jest wstrzykiwanie SQL? Ten stary, ale smakołyk może sprawić, że Twoje aplikacje internetowe zaszkodzą
- Wstrzyknięcie SQL (Wikipedia)
- Iniekcja SQL (CLOUDFLARE)
- Iniekcja SQL (w3schools.com)
- Ściągawka dotycząca zapobiegania wstrzykiwaniu SQL
- Testowanie pod kątem wstrzykiwania SQL
- Luki związane z iniekcją SQL i jak im zapobiegać
- Ściągawka dotycząca wstrzykiwania SQL
Uprawnienia ról Postgres
Mamy powiedzenie w stylu „Jesteśmy naszym największym wrogiem ”.
Zdecydowanie możemy zastosować go do pracy w środowisku PostgreSQL. Zaniedbanie, niezrozumienie lub brak staranności są taką samą okazją do ataków i nieautoryzowanego użycia, jak te celowo wystrzelone.
Być może nawet bardziej, nieumyślnie umożliwiając łatwiejszy dostęp, trasy i kanały, do których mogą dotrzeć osoby, które dopuszczają się naruszenia.
Wspomnę o obszarze, który od czasu do czasu wymaga ponownej oceny lub ponownej oceny.
Nieuzasadnione lub obce uprawnienia roli.
- SUPERUŻYTKOWNIK
- KREATROL
- UTWORZONEB
- DOTACJE
To połączenie przywilejów jest zdecydowanie warte obejrzenia. SUPERUSER i CREATROLE to niezwykle potężne polecenia, które lepiej sprawdzałyby się w rękach administratora, w przeciwieństwie do analityka lub programisty, nie sądzisz?
Czy rola naprawdę potrzebuje atrybutu CREATEDB? A co z GRANTEM? Ten atrybut może zostać nadużyty w niewłaściwych rękach.
Dokładnie rozważ wszystkie opcje, zanim zezwolisz na przypisanie tych atrybutów ról w swoim środowisku.
Strategie, najlepsze praktyki i hartowanie
Poniżej znajduje się lista przydatnych postów na blogu, artykułów, list kontrolnych i przewodników, które pojawiły się po „roku wstecz” (w momencie pisania tego tekstu) wyników wyszukiwania. Nie są one wymienione w żadnej kolejności ważności, a każda z nich oferuje godne uwagi sugestie.
- Proste sposoby ochrony serwerów Postgres przed mało prawdopodobnym wektorem ataku:nieuczciwe zdjęcie Scarlett Johansson
- Pomoc w zabezpieczeniu bazy danych PostgreSQL
- Nie bądź natrętny... Wzmocnij bazę danych PostgreSQL, aby zapewnić bezpieczeństwo
- Jak zabezpieczyć bazę danych PostgreSQL — 10 wskazówek
- Zabezpieczenie PostgreSQL przed atakiem zewnętrznym
- Przywileje i bezpieczeństwo PostgreSQL — blokowanie schematu publicznego
Wniosek
W tym blogu omówiliśmy kwestie bezpieczeństwa, które dotyczą administratorów PostgreSQL na całym świecie:obejmują one wstrzykiwanie SQL, które jest świętym Graalem wszystkich incydentów związanych z bezpieczeństwem, wpadki w podstawowych podejściach do obsługi bezpieczne dane, takie jak nieprawidłowe zaostrzenie uprawnień w Twojej infrastrukturze, a także niektóre mniej znane problemy z zabezpieczeniami, które mogą zostać przeoczone. Jeśli chodzi o bezpieczeństwo naszych danych, bardzo ważne jest, abyśmy korzystali i stosowali porady od zaufanych stron, takich jak Imperva i tym podobne, które zapewniają nam sposoby ochrony zarówno przed podstawowymi atakami, jak i przed atakami zerowymi (exploity, które jeszcze nie zostały znane wcześniej), ponieważ renomowane porady oznaczają dobrą przyszłość dla naszych baz danych i całej infrastruktury.
Należy pamiętać, że środki bezpieczeństwa, które musimy podjąć, będą w dużym stopniu zależeć od luk, które chcemy odeprzeć, ale ogólnie rzecz biorąc, znajomość wszystkich niezbędnych zabezpieczeń, aby odeprzeć wstrzyknięcie SQL, właściwie używając przywilejów i zawsze próba zmniejszenia naszego poziomu ryzyka związanego z lukami ma kluczowe znaczenie. Bycie na bieżąco z tym, co dzieje się w przestrzeni bezpieczeństwa PostgreSQL, również nam zdziała cuda:możemy dobrze bronić naszych serwerów (i w konsekwencji naszych danych) tylko wtedy, gdy wiemy, czego mogą szukać napastnicy.
Jeśli szukasz więcej najlepszych praktyk dotyczących poprawy bezpieczeństwa lub wydajności instalacji PostgreSQL, zwróć się do ClusterControl:ponieważ narzędzie jest opracowywane przez najlepszych ekspertów ds. baz danych z całego świata, sprawi, że Twoje bazy danych zaczną śpiewać w mgnieniu oka. Produkt jest również dostępny z 30-dniową bezpłatną wersją próbną, więc upewnij się, że nie przegapisz wszystkich funkcji, które ClusterControl może zaoferować Twojej firmie, i spróbuj już dziś.
Aby uzyskać więcej informacji na temat tego, jak zabezpieczyć instancje baz danych PostgreSQL, zajrzyj do bloga Severalnines po poradę:nauka automatyzacji audytów bezpieczeństwa dla PostgreSQL z pewnością będzie krokiem we właściwym kierunku. Śledź nas na Twitterze, LinkedIn i zasubskrybuj nasz kanał RSS, aby uzyskać więcej informacji, a do zobaczenia w następnym.
