Zeabur kończy działalność po drugim naruszeniu bezpieczeństwa w ciągu dwóch miesięcy

securitybeztabu.pl 6 godzin temu

Wprowadzenie do problemu / definicja

Zeabur, platforma do hostingu i wdrażania aplikacji dla deweloperów, poinformowała o kolejnym poważnym incydencie bezpieczeństwa, który doprowadził do kompromitacji infrastruktury oraz wycieku danych klientów i sekretów środowiskowych. Z perspektywy cyberbezpieczeństwa to istotny przykład tego, jak niepełna remediacja po wcześniejszym incydencie, niewłaściwe zarządzanie poświadczeniami uprzywilejowanymi oraz nadmierna ekspozycja systemów administracyjnych mogą doprowadzić do eskalacji skali naruszenia.

W skrócie

Drugi incydent w krótkim odstępie czasu objął najważniejsze elementy środowiska produkcyjnego platformy. Atakujący wykorzystali ujawnione wewnętrzne poświadczenia przechowywane w postaci jawnej, uzyskali dostęp do współdzielonej infrastruktury hostingowej, części serwerów dedykowanych oraz bazy produkcyjnej.

Naruszenie objęło ponad 321 tysięcy kont.
Wyciekło około 3,2 mln rekordów zmiennych środowiskowych.
Odnotowano logowania root na serwerach GCP.
Napastnicy dodawali klucze SSH i podłączali kopie dysków klientów do kontrolowanych przez siebie maszyn.
Firma ogłosiła wygaszenie usług do końca grudnia 2026 roku.

Kontekst / historia

Zeabur oferowała usługę upraszczającą wdrażanie aplikacji poprzez integrację z repozytoriami kodu oraz automatyzację zarządzania infrastrukturą, bazami danych i HTTPS. Tego rodzaju platformy PaaS operują na dużej liczbie sekretów, tokenów i poświadczeń, dlatego są atrakcyjnym celem dla przeciwników zainteresowanych zarówno przejęciem infrastruktury, jak i dostępem do danych wielu klientów jednocześnie.

W sierpniu 2026 roku firma doświadczyła wcześniejszego naruszenia, w którym napastnicy wykorzystali podatność w aplikacji klienta i poruszali się dalej przez niewystarczająco odseparowane systemy wewnętrzne. Tamten incydent doprowadził do kradzieży poświadczeń chmurowych, dostępu do bazy produkcyjnej oraz ekspozycji danych kont, kluczy API i innych sekretów. Najnowszy atak był jednak jeszcze bardziej rozległy i pokazał, iż wcześniejsze działania naprawcze okazały się niewystarczające.

Analiza techniczna

Według ujawnionych informacji drugi incydent rozpoczął się od wykorzystania wyciekłych wewnętrznych poświadczeń Zeabur. Szczególnie niepokojące jest to, iż część danych uwierzytelniających miała być przechowywana w postaci plaintext, co znacząco obniżyło próg wejścia dla atakującego po uzyskaniu dostępu do systemu pośredniego lub danych konfiguracyjnych.

Po przejęciu poświadczeń napastnicy weszli do klastra współdzielonego, części serwerów dedykowanych oraz systemów wewnętrznych, a następnie dotarli do bazy platformy. Łańcuch ataku wskazuje na klasyczny scenariusz kompromitacji tożsamości uprzywilejowanej i późniejszego ruchu bocznego. Oznacza to, iż kluczowym problemem nie była wyłącznie pojedyncza podatność techniczna, ale przejęcie zaufanych mechanizmów administracyjnych i brak skutecznych ograniczeń po uzyskaniu dostępu.

Istotnym elementem była także niewystarczająca higiena zarządzania sekretami po poprzednim incydencie. Tokeny administracyjne nie miały terminu wygaśnięcia, nie były rotowane od momentu utworzenia w styczniu 2024 roku i nie zostały objęte pełną rotacją po sierpniowym naruszeniu. Dodatkowo portale administracyjne pozostawały dostępne z publicznego Internetu, co zwiększało powierzchnię ataku i umożliwiało bezpośrednie użycie przejętych danych uwierzytelniających.

Skala dostępu uzyskanego przez atakujących sugeruje brak wystarczającej segmentacji środowisk i niedostateczne ograniczenie uprawnień. Zgłoszone logowania root na 101 serwerach GCP wykonane przez 92 użytkowników, dodanie kluczy SSH do 50 serwerów oraz podłączenie 16 kopii dysków klientów do maszyn kontrolowanych przez napastników wskazują na aktywność wykraczającą poza prosty odczyt bazy danych. Taki poziom ingerencji oznacza możliwość trwałego osadzenia się w systemach oraz prowadzenia działań post-exploitation na wielu hostach równocześnie.

Warto podkreślić, iż część zmiennych środowiskowych wcześniej przeniesionych wyłącznie na serwery klientów miała uniknąć ekspozycji z poziomu bazy platformy, jednak przez cały czas mogła zostać ujawniona przez skompromitowane hosty. To pokazuje, iż choćby adekwatny kierunek działań naprawczych nie zapewnia pełnej ochrony, jeżeli przeciwnik utrzymuje kontrolę nad warstwą infrastrukturalną.

Konsekwencje / ryzyko

Konsekwencje incydentu są wielowarstwowe. Wyciek około 3,2 mln rekordów zmiennych środowiskowych może oznaczać ekspozycję kluczy API, danych dostępowych do baz, tokenów CI/CD oraz innych sekretów aplikacyjnych używanych przez klientów. Tego rodzaju informacje mają wysoką wartość operacyjną, ponieważ umożliwiają wtórne przejęcia aplikacji i eskalację do innych środowisk chmurowych oraz usług SaaS.

Kompromitacja 321 810 kont oznacza również ryzyko nadużyć tożsamości, przejęcia sesji, phishingu ukierunkowanego oraz wykorzystania ujawnionych danych do dalszych kampanii. o ile wśród pozyskanych informacji znalazły się metadane wdrożeń lub szczegóły topologii usług, atakujący mogli uzyskać dodatkowy kontekst wspierający kolejne etapy operacji.

Aktywność na poziomie root i manipulacja kluczami SSH znacząco zwiększają ryzyko trwałego utrzymania dostępu. choćby po wymuszeniu resetu haseł i rotacji tokenów środowisko mogło pozostać zagrożone, jeżeli na hostach utrzymywały się nieautoryzowane klucze, zmodyfikowane mechanizmy startowe, backdoory lub inne artefakty umożliwiające ponowne wejście.

Decyzja o zamknięciu działalności dodatkowo komplikuje sytuację klientów. Organizacje korzystające z platformy muszą równolegle prowadzić response na incydent, migrację usług, walidację integralności środowiska oraz szeroką wymianę sekretów. To znacząco zwiększa presję operacyjną i ryzyko błędów w krytycznym momencie.

Rekomendacje

Organizacje, które korzystały z platformy lub miały z nią powiązane zasoby, powinny potraktować incydent jako potencjalną pełną kompromitację sekretów i infrastruktury zarządzanej przez dostawcę. W praktyce oznacza to konieczność natychmiastowej rotacji wszystkich kluczy API, haseł, tokenów dostępowych, sekretów CI/CD, danych logowania do baz danych oraz poświadczeń chmurowych, które mogły być przechowywane jako zmienne środowiskowe.

Kolejnym krokiem powinno być unieważnienie wszystkich aktywnych sesji użytkowników i administratorów, wymuszenie ponownego logowania oraz przegląd kont uprzywilejowanych. o ile środowiska działały w GCP lub innych chmurach zintegrowanych z platformą, należy przeanalizować logi pod kątem nietypowych logowań, zmian kluczy SSH, tworzenia snapshotów, podpinania wolumenów oraz anomalii w aktywności maszyn wirtualnych.

W przypadku hostów, które mogły zostać objęte atakiem, bezpieczniejszym podejściem jest odtworzenie systemów z zaufanego źródła zamiast czyszczenia in-place. Rebuild infrastruktury, redeployment aplikacji i ponowna inicjalizacja kluczy są często jedynym sposobem przywrócenia zaufania do środowiska po kompromitacji na poziomie root.

Przechowywać sekrety wyłącznie w zabezpieczonych systemach secrets management.
Rotować poświadczenia po każdym incydencie, także dla kont technicznych i rzadko używanych tokenów.
Wymuszać terminy ważności dla tokenów administracyjnych.
Zapewnić pełną segmentację środowisk współdzielonych i wewnętrznych.
Ograniczać dostęp do paneli administracyjnych przez VPN, bastion, allowlisty lub model Zero Trust.
Wdrażać detekcję działań post-exploitation, w tym zmian kluczy SSH, logowań root i nietypowych operacji na dyskach.

Podsumowanie

Przypadek Zeabur pokazuje, iż wtórne naruszenia po pierwszym incydencie często wynikają nie z nowej klasy podatności, ale z pozostawionych poświadczeń, niepełnej remediacji i nadmiernego zaufania do już naruszonego środowiska. Połączenie jawnie przechowywanych sekretów, braku pełnej rotacji tokenów administracyjnych, publicznej ekspozycji systemów zarządzania oraz niewystarczającej izolacji infrastruktury doprowadziło do szerokiej kompromitacji i ostatecznie do decyzji o zamknięciu platformy. Dla zespołów bezpieczeństwa to kolejny sygnał, iż zarządzanie sekretami, segmentacja i response po incydencie muszą być traktowane jako proces ciągły i całościowy.