Słabo zabezpieczone instancje baz danych PostgreSQL na komputerach z systemem Linux padają ofiarą kryptograficznych ataków hakerskich. Jak wygląda taki atak oraz jak się zabezpieczyć, opisujemy poniżej.
Kilka słów o PostgreSQL oraz jego bezpieczeństwo
PostgreSQL to zaawansowany open-source’owy system zarządzania bazami danych (RDBMS), ceniony za swoją wydajność, stabilność i bogaty zestaw funkcji. Ze względu na elastyczność i skalowalność jest często wykorzystywany w różnorodnych aplikacjach, od małych systemów webowych po rozbudowane systemy korporacyjne. Często jest wdrażany w chmurze, środowiskach Kubernetes i lokalnej infrastrukturze organizacji.
Choć PostgreSQL jest potężnym narzędziem z rozbudowanymi opcjami zabezpieczeń, niewłaściwa konfiguracja, opóźnienia w aktualizacjach oraz złożoność niektórych mechanizmów mogą sprawić, iż baza danych będzie narażona na ataki.
Bazy danych PostgreSQL wystawione na działanie Internetu są ulubionym celem grup kryptokradzieży i okazjonalnie oszustów. zwykle wykorzystują oni słabe zabezpieczenia (np. słabe hasła) lub błędne konfiguracje (np. domyślną konfigurację, która wiąże PostgreSQL ze wszystkimi interfejsami sieciowymi, w tym publicznym).
Obecnie Shodan „widzi” ponad 780 tysięcy wystawionych baz danych PostgreSQL.
Jak wygląda atak na PostgreSQL?
Słabe zabezpieczenia bazy mogą skutkować dużym zainteresowaniem wśród atakujących. I tak jest w opisywanym dzisiaj przypadku, w którym słabo zabezpieczone bazy danych PostgreSQL działające na komputerach z systemem Linux padają ofiarą ataków kryptograficznych.
Atak na PostgreSQL został zaobserwowany przez badaczy z Aqua Security w ich systemie honeypot. Rozpoczyna się od zdobycia danych uwierzytelniających przez atakujących przy użyciu metody brute-force.
Po uzyskaniu dostępu atakujący:
- Tworzy nową rolę użytkownika, która ma możliwość logowania i posiada wysokie uprawnienia.
- Usuwa uprawnienia superużytkownika z naruszonej roli, aby ograniczyć możliwości innych potencjalnych napastników, którzy mogliby również uzyskać dostęp metodą brute-force.
- Zaczyna zbierać informacje o systemie baz danych.
- Uruchamia polecenia powłoki, aby pobrać dwa pliki do systemu.
Pierwszy ładunek, PG_Core, jest zaprojektowany głównie do usuwania zadań cron bieżącego użytkownika oraz zakończenia procesów powiązanych z innym złośliwym oprogramowaniem do wydobywania kryptowalut, takich jak Kinsing, WatchDog czy TeamTNT.
„Sprawca zagrożenia zatrzymuje wcześniejsze ataki zarówno swoje, jak i innych, co wskazuje, iż posiada pewne informacje o konkurentach” – mówi Assaf Morag, główny analityk danych w zespole badawczym Nautilus firmy Aqua.
„Na koniec sprawca zagrożenia usuwa pliki takie jak binarka ‘pg_core’ oraz logi złośliwego oprogramowania, na przykład ‘ps_stat_good’, aby ominąć mechanizmy obronne (takie jak skanery oparte na analizie wolumenu)”.
Drugi pobrany i wdrożony ładunek – PG_Mem – to dropper Linuxa, który zawiera kryptominer XMRIG i przechowuje go w systemie.
„Kryptominer […] jest wykonywany z argumentem „deleted”, a ponadto aktor zagrożenia tworzy zadanie cron z wykonaniem pg_mem i wstawia pustą wartość do pliku konfiguracyjnego pg_hba” – dodaje badacz.
Schemat ataku został przedstawiony na poniższym diagramie.
Źródło: Aqua SecurityKonfiguracje PostgreSQL stwarzające zagrożenie ataku
Udostępnianie PostgreSQL bezpośrednio do Internetu jest ogólnie uważane za ryzykowne i nie jest zalecane ze względu na obawy dotyczące bezpieczeństwa. Istnieje jednak kilka powodów, dla których niektórzy mogą to robić.
Niektóre organizacje lub osoby mogą potrzebować dostępu do swoich baz danych PostgreSQL z różnych lokalizacji lub za pośrednictwem różnych usług, co sprawia, iż bezpośrednie udostępnienie Internetu wydaje się wygodne. Bywa też, iż programiści tymczasowo udostępniają serwer PostgreSQL podczas tworzenia lub testowania, nie biorąc pod uwagę implikacji bezpieczeństwa.
Niektórzy użytkownicy konfigurują swój serwer PostgreSQL bez wdrożenia odpowiednich środków bezpieczeństwa, zakładając, iż domyślne konfiguracje są wystarczające. Ponadto złożoność i koszty uniemożliwiają małym firmom lub osobom o ograniczonych zasobach skonfigurowanie bezpiecznych metod dostępu, takich jak sieci VPN, tunele SSH lub odwrotne serwery proxy.
Dobre praktyki zabezpieczenia PostgreSQL
Aby zabezpieczyć dostęp do baz danych PostgreSQL, wdróż silne zabezpieczenia sieciowe, używając zapór sieciowych, sieci VPN lub tuneli SSH w celu ograniczenia dostępu i upewnij się, iż wszyscy użytkownicy mają silne hasła. Stosuj dzienniki audytu, systemy wykrywania włamań i bezpieczne kopie zapasowe. Ponadto wyłącz niepotrzebne funkcje i chroń aplikacje przed wstrzykiwaniem kodu SQL.
Jeśli używasz PostgreSQL w środowiskach chmurowych i Kubernetes, zabezpieczenie go wymaga połączenia dobrych praktyk konfiguracyjnych i regularnego monitorowania. Oto kilka ogólnych wskazówek:
- Używaj najnowszej wersji PostgreSQL i instaluj niezbędne poprawki.
- Używaj silnego hasła podczas korzystania z metod uwierzytelniania opartych na haśle.
- Zastosuj odpowiednie uprawnienia do zabezpieczania plików konfiguracyjnych, takich jak pg_hba.conf.
- Włącz SSL/TLS, aby zabezpieczyć połączenie między klientem a usługą PostgreSQL.
- Przeprowadź audyt użytkowników i ich ról zabezpieczeń oraz postępuj zgodnie z zasadą najmniejszych uprawnień.
- Używaj sekretów przestrzeni nazw Kubernetes.
- Uruchom usługę PostgreSQL jako użytkownik inny niż root, co doda dodatkową warstwę obrony w przypadku naruszenia.
- Ogranicz zasoby kontenerów dostępne dla usługi PostgreSQL do szacunkowego poziomu.
- Monitoruj hosty i kontenery pod kątem wszelkich złośliwych działań.
- Używaj mechanizmu Zero Trust, aby zezwolić na wymagany dostęp do usługi w klastrze.
- Używaj proaktywnego rozwiązania bezpieczeństwa w celu identyfikacji błędnej konfiguracji i luk w zabezpieczeniach
Polecamy również dobrą lekturę ma temat zabezpieczania PostgreSQL dostępną pod tym linkiem.
