Przez lata jednym z pierwszych celów atakujących były usługi zdalnego dostępu. SSH, RDP czy VPN stanowiły naturalny punkt wejścia do środowiska. Jeśli udało się przejąć serwer, można było zacząć dalszą eksplorację sieci.

Autor: 5 min czytania

Dziś coraz częściej wygląda to inaczej. Zamiast zdobywać dostęp do systemu operacyjnego, atakujący próbują dostać się bezpośrednio do baz danych. W wielu przypadkach jest to po prostu szybsze, łatwiejsze i bardziej opłacalne. Po co przejmować serwer, skoro można od razu dostać się do danych, czyli najcenniejszego zasobu organizacji?

Dane głównym celem

Przez długi czas baza danych była traktowana jako element ukryty głęboko wewnątrz infrastruktury. Administratorzy skupiali się na ochronie serwerów, stacji roboczych czy usług wystawionych do Internetu, zakładając, że sama baza jest bezpieczna za firewallem.

Problem polega na tym, że nowoczesne środowiska chmurowe, aplikacje SaaS i szybkie wdrożenia coraz częściej prowadzą do sytuacji, w której usługi bazodanowe są dostępne z Internetu lub niewłaściwie skonfigurowane. Wystarczy kilka minut od uruchomienia nowego serwera, aby automatyczne skanery zaczęły sprawdzać otwarte porty PostgreSQL, MySQL czy MongoDB.

Dla cyberprzestępców jest to znacznie atrakcyjniejszy cel niż tradycyjne usługi administracyjne.

Atak bez malware’u

Jedną z najciekawszych zmian ostatnich lat jest rosnąca popularność tzw. malware-less attacks. W takim scenariuszu atakujący nie musi instalować ransomware, backdoora ani żadnego złośliwego oprogramowania. Wystarczy, że zaloguje się do bazy danych przy użyciu słabego hasła lub błędnej konfiguracji, a następnie wykorzysta natywne funkcje samej platformy.

W praktyce oznacza to możliwość eksportowania danych, usuwania tabel, modyfikowania rekordów czy pozostawiania notatek z żądaniem okupu bez uruchamiania choćby jednej podejrzanej binarki. Wszystko odbywa się przy użyciu legalnych komend SQL. Z punktu widzenia wielu systemów bezpieczeństwa taka aktywność może wyglądać jak normalna praca administratora.

Bazy danych są łatwiejsze do monetyzacji

Przejęcie serwera czy aplikacji nie zawsze oznacza natychmiastowy zysk dla atakującego. Trzeba przeprowadzić rekonesans, znaleźć interesujące dane i często wykonać kilka kolejnych kroków.

W przypadku bazy danych sytuacja wygląda znacznie prościej. To właśnie tam znajdują się dane klientów, informacje finansowe, dane logowania, tokeny API, historia transakcji czy dane biznesowe organizacji. Atakujący dostaje więc dostęp do zasobu, który można sprzedać, wykorzystać do szantażu albo użyć w kolejnych kampaniach. Coraz częściej obserwujemy sytuacje, w których cyberprzestępcy nie szyfrują już danych. Zamiast tego kopiują je, usuwają oryginały i żądają okupu za ich zwrot lub niepublikowanie.

PostgreSQL, MySQL i MongoDB pod ostrzałem

Raporty dotyczące aktywności cyberprzestępczej pokazują wyraźny wzrost zainteresowania usługami bazodanowymi. Szczególnie często pojawiają się ataki na PostgreSQL, MySQL, MongoDB, Redis czy Elasticsearch.

Powód jest prosty. W wielu organizacjach nadal można znaleźć:

  • domyślne hasła,
  • słabe dane uwierzytelniające,
  • błędnie skonfigurowane reguły dostępu,
  • usługi wystawione bezpośrednio do Internetu.

Atakujący doskonale wiedzą, że takie błędy występują częściej, niż wydaje się administratorom. Najnowszy raport z honeyDB dobrze przedstawia ten trend:

Źródło: deception.substack.com

Tradycyjne detekcje mogą niczego nie wykryć

Tutaj pojawia się największy problem SOC-ów. Przez lata wiele mechanizmów detekcyjnych skupiało się na procesach systemowych, PowerShellu, SSH czy nietypowej aktywności użytkowników. Tymczasem współczesny atak na bazę danych może odbywać się całkowicie w ramach prawidłowego ruchu sieciowego.

Jeżeli użytkownik posiada poprawne dane logowania, wykonuje legalne zapytania SQL i korzysta ze standardowego klienta bazodanowego, wykrycie incydentu staje się znacznie trudniejsze. W praktyce organizacje muszą coraz częściej monitorować nie tylko to, kto loguje się do bazy, ale również co dokładnie robi po zalogowaniu.

W przypadku baz danych ogromne znaczenie ma analiza zachowania użytkowników i monitorowanie nietypowych operacji. Sygnałem ostrzegawczym mogą być nagłe eksporty dużych ilości danych, masowe operacje DELETE, tworzenie nowych kont administracyjnych czy nietypowe logowania spoza standardowych lokalizacji. Warto również monitorować wykorzystanie rzadko używanych funkcji administracyjnych oraz nietypowe zapytania wykonywane przez konta serwisowe.

Coraz większą rolę odgrywa również Database Activity Monitoring (DAM), który pozwala obserwować aktywność bezpośrednio na poziomie silnika bazy danych, a nie jedynie ruch sieciowy.

Podsumowanie

Najważniejszy wniosek z całego trendu jest prosty. Jeszcze kilka lat temu administratorzy pytali przede wszystkim: „Czy nasz dostęp SSH / RDP / VNC jest bezpieczny?”. Dziś równie ważne pytanie brzmi: „Czy nasza baza danych nie jest przypadkiem najbardziej narażonym elementem infrastruktury?”. Bo współczesny atak coraz częściej nie zaczyna się od przejęcia serwera, konta czy aplikacji. Zaczyna się od przejęcia danych.