Metabase SQLi zero-day: jak błąd resetu hasła otworzył drogę do danych

Metabase opublikował awaryjne poprawki dla krytycznej podatności SQL injection, która była już wykorzystywana jako zero-day. Problem dotyczył nieuwierzytelnionego endpointu resetowania hasła i umożliwiał manipulowanie zapytaniem wykonywanym na bazie aplikacyjnej Metabase. To baza przechowująca konfigurację platformy, konta użytkowników oraz połączenia do źródeł danych — dlatego skutkiem nie był tylko błąd logowania, lecz możliwe przejęcie całej warstwy analitycznej.

Incydenty ujawnione przez Framework i Tally pokazują ważny wzorzec: publiczny panel BI często stoi pomiędzy internetem a wieloma wewnętrznymi bazami. Gdy atakujący przejmie sam Metabase, odziedziczy jego pozycję zaufanego pośrednika, zapisane dane dostępowe i uprawnienia nadane kontom technicznym.

Jak działał łańcuch ataku

Podatna ścieżka znajdowała się w POST /api/session/reset_password. Dane kontrolowane przez klienta trafiały do zapytania SQL dotyczącego bazy aplikacyjnej bez poprawnego rozdzielenia kodu zapytania od danych. Według advisory projektu Metabase luka miała maksymalny wynik ważności i nie wymagała wcześniejszego logowania.

Praktyczny łańcuch nie kończył się na odczycie jednej tabeli. Dostęp do bazy aplikacyjnej mógł ujawnić ustawienia, konta administracyjne i zaszyfrowane lub zapisane sekrety połączeń. Następnie atakujący mógł wykorzystać funkcje samego Metabase do odpytywania podłączonych hurtowni, zależnie od uprawnień kont bazodanowych. Właśnie dlatego zasada najmniejszych uprawnień dla konektorów BI jest kontrolą ograniczającą skutki, a nie tylko porządkiem administracyjnym.

W opisanych śladach pojawiał się nieudany z perspektywy HTTP, zwracający 400, request do resetu hasła, po którym następował udany GET /api/user/current. Sam kod 400 nie dowodzi więc, że próba była nieskuteczna. Do wykrywania trzeba łączyć zdarzenia w sesje i patrzeć na zmianę stanu uwierzytelnienia.

Które wersje wymagają aktualizacji

Metabase wskazał, że podatność obejmuje wydania od serii 0.58, wraz z odpowiadającymi im wydaniami Enterprise 1.x. Poprawione wersje społecznościowe to 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 i 0.63.5; użytkownicy Enterprise powinni zastosować odpowiadające im wydania 1.x. Aktualna lista pozostaje w komunikacie bezpieczeństwa Metabase.

Framework poinformował o dostępie napastnika 3 sierpnia i otrzymaniu informacji o podatności 6 sierpnia. Tally opisało osobny incydent obejmujący adresy e-mail i skróty haseł. Są to publiczne przypadki wykorzystania tej samej klasy problemu, a nie dowód, że dane każdej instalacji Metabase zostały skradzione.

Plan reakcji dla zespołu technicznego

1. Zaktualizuj Metabase do poprawionego wydania z używanej linii i potwierdź działającą wersję w każdym środowisku, nie tylko w repozytorium obrazów.
2. Ogranicz publiczny dostęp do panelu, jeżeli nie jest potrzebny; filtr WAF może zmniejszyć ekspozycję, ale nie zastępuje poprawki.
3. Przeszukaj logi proxy i aplikacji pod kątem żądań do /api/session/reset_password, szczególnie odpowiedzi 400 zestawionych z późniejszym /api/user/current.
4. Unieważnij aktywne sesje administratorów i obróć sekret szyfrujący aplikacji zgodnie z dokumentacją producenta.
5. Zrotuj hasła, tokeny i klucze do wszystkich baz dostępnych przez Metabase. Sama zmiana hasła administratora BI nie usuwa skradzionych poświadczeń konektorów.
6. Sprawdź historię zapytań, nowe konta, zmiany ról, eksporty danych oraz nietypowe połączenia z adresów IP serwera Metabase do systemów źródłowych.
7. Odtwórz oś czasu od pierwszego podejrzanego requestu i przyjmij szerszy zakres incydentu, jeśli nie masz logów pozwalających wykluczyć użycie zapisanych połączeń.

Jak ograniczyć skutki kolejnego błędu

Konto każdego konektora powinno mieć wyłącznie dostęp odczytowy do niezbędnych widoków, bez prawa tworzenia funkcji, zapisu plików czy administracji. Osobne konta dla środowisk i zbiorów danych ułatwiają rotację oraz analizę zasięgu. Warto również eksportować logi Metabase poza samą instancję, bo przejęta aplikacja nie jest wiarygodnym miejscem przechowywania dowodów.

Fakty i analiza Breachroad

Metabase potwierdził podatność, wersje naprawione i wcześniejsze wykorzystanie; Framework oraz Tally opisały skutki swoich incydentów. Nie ma podstaw, by z tych komunikatów wnioskować o kompromitacji każdej publicznej instancji. Zalecenie rotacji wszystkich sekretów konektorów po potwierdzonym przejęciu jest wnioskiem Breachroad z roli bazy aplikacyjnej w łańcuchu ataku.

Szkolenia techniczne dla zespołów IT uczą łączenia logów aplikacji, proxy i baz w jedną oś incydentu. Gdy trzeba potwierdzić realny zasięg, audyt bezpieczeństwa aplikacji obejmuje również konfigurację, uprawnienia konektorów i ekspozycję paneli administracyjnych.