Atak Khunt: Jak hakerzy zamienili bazę Oracle w platformę do dalszej eksploatacji

Jak doszło do ataku: SQL injection przez autouzupełnianie

Początkowym wektorem ataku była podatność SQL injection w publicznie dostępnej aplikacji Java działającej na Apache Tomcat . Funkcja autouzupełniania wyszukiwania nie walidowała poprawnie danych wejściowych, co pozwoliło atakującym wstrzyknąć polecenia SQL przez połączenie JDBC z bazą Oracle . Jak zauważyli badacze z Huntress, nie była to nowa klasa podatności – ataki SQL injection są znane od dziesięcioleci i są zazwyczaj wynikiem nieprawidłowego przetwarzania danych wejściowych . Brak prawidłowej sanityzacji prostego pola wyszukiwania wystarczył, by uruchomić cały łańcuch kompromitacji.

Narzędzie Khunt: Żyjąc wewnątrz bazy danych jako obiekty Javy

Zamiast wdrażać tradycyjne złośliwe oprogramowanie na skompromitowanym serwerze, atakujący użyli wbudowanej w Oracle maszyny wirtualnej Javy (JVM) i instrukcji CREATE JAVA SOURCE, aby skompilować i przechowywać cały zestaw narzędzi do dalszej eksploatacji jako obiekty schematu Javy w bazie Oracle . To podejście sprawiło, że narzędzie było niewidoczne dla standardowych zabezpieczeń na poziomie systemu operacyjnego, ponieważ EDR i antywirusy skupiają się na procesach, plikach binarnych i plikach – nie analizują one klas Javy i wrapperów PL/SQL przechowywanych w Oracle .

Zestaw khunt zawierał następujące komponenty, każdy przechowywany jako obiekt bazy danych:

Pełna kontrola systemu: z bazy danych do systemu Windows

Atakujący nie poprzestali na dostępie do bazy danych. Użyli zestawu khunt, aby przejść z warstwy bazy danych do systemu operacyjnego Windows w wieloetapowym procesie:

1. Wykonanie poleceń OS przez KhuntCmd: Użyli modułu KhuntCmd, aby uruchomić cmd.exe /c whoami, co potwierdziło, że działają z uprawnieniami SYSTEM na serwerze Windows, ustanawiając zdalne wykonanie kodu (RCE) z bazy do systemu operacyjnego .
2. Kradzież poświadczeń: Użyli PowerShell, aby wywołać reg.exe i skopiować gałęzie rejestru SECURITY i SYSTEM, zapisując je jako khuntSECURITY.hiv i khuntSYSTEM.hiv w F:\Oracle\ .
3. Enumeryzacja usług: Uruchomili tasklist /svc i zapisali wynik jako khunttasks.txt .
4. Dodatkowe wyodrębnianie gałęzi: Użyli esentutl.exe, aby skopiować gałąź SAM i drugą kopię SECURITY, zapisując je jako khuntSAM.hiv i khunt_SECURITY.hiv .

Wyeksfiltrowane gałęzie rejestru mogły być użyte offline do wyodrębnienia i odszyfrowania skrótów haseł dla wszystkich lokalnych kont w systemie .

Ślepe punkty monitorowania: kluczowe wnioski Huntress

Dochodzenie Huntress ujawniło kilka krytycznych luk, które pozwoliły na ten atak i uniknięcie wykrycia:

• Baza danych jako przyczółek ataku: Baza danych została przekształcona z pasywnego magazynu danych w aktywną platformę ataku, a złośliwe narzędzie żyło wewnątrz bazy danych, a nie na dysku czy w pamięci .
• Omijanie EDR/AV: Tradycyjne narzędzia EDR i antywirusy nie skanują klas Javy i wrapperów PL/SQL przechowywanych w Oracle, co czyni je niewidocznymi dla standardowych zabezpieczeń na poziomie systemu operacyjnego .
• Klasyczna podatność, nowatorski sposób dostarczenia: Początkowy SQL injection był dobrze znaną klasą błędów. Nie był potrzebny żaden zerowy dzień. Funkcja autouzupełniania wystarczyła, aby dotrzeć do PL/SQL, a następnie do systemu operacyjnego, co pokazuje, że podstawowe błędy walidacji wejściowej mogą prowadzić do głębokiej kompromitacji, gdy silnik bazy danych ma możliwości na poziomie systemu operacyjnego .
• Nadmiernie uprzywilejowane konta bazy danych: Nawet jeśli SQL injection się powiedzie, szkody są ograniczone, jeśli konto użytkownika bazy danych nie ma uprawnień do tworzenia źródeł Javy lub wykonywania procedur składowanych. Organizacje często nadają zbyt dużo uprawnień kontom bazy danych, co daje atakującym dodatkowe możliwości do wdrożenia khunt .

Zalecenia środków zaradczych od Huntress

Na podstawie tego ataku Huntress zalecił następujące środki zaradcze :

• Prawidłowa sanityzacja danych wejściowych i parametryzacja zapytań dla wszystkich danych pochodzących z aplikacji webowych
• Ograniczenie uprawnień użytkowników bazy danych, aby nawet wstrzyknięte zapytania nie mogły tworzyć źródeł Javy ani wykonywać dowolnych procedur składowanych
• Rozszerzenie zakresu monitorowania o obiekty bazy danych (klasy Javy, wrappery PL/SQL), a nie tylko o artefakty na poziomie systemu operacyjnego

Ten atak jest wyraźnym przypomnieniem, że silniki baz danych z wbudowanymi środowiskami programistycznymi (jak JVM w Oracle) mogą stać się ukrytymi platformami ataku, gdy połączą się z choćby jednym niesprawdzonym polem wejściowym. Zespoły ds. bezpieczeństwa muszą rozszerzyć swoje monitorowanie poza system operacyjny, aby objąć warstwę obiektów bazy danych.