Przejęcie BGP dało ważny certyfikat, potem root

33-godzinne przejęcie własnego ruchu Softaculous

Między 20:57 UTC 28 sierpnia a 06:10 UTC 30 sierpnia 2026 roku atakujący przejął routing BGP bloku adresów IP hostowanych w Hetznerze, należących do Softaculous, firmy stojącej za powszechnie używanym panelem kontrolnym VPS Virtualizor. Nieuczciwa sieć AS62390, działająca pod nazwą NexonHost, ogłosiła bardziej szczegółową trasę dla bloku 162.55.80.0/24 niż własne ogłoszenie Hetznera. Softaculous opiera się na Hetznerze pod względem infrastruktury stojącej za serwerami licencji, aktualizacji i pobierania Virtualizora, co właśnie sprawiło, że przejęty blok był tak wartościowy dla atakującego.

Zgodnie ze standardowymi zasadami wyboru trasy w BGP, bardziej szczegółowa trasa wygrywa wszędzie tam, gdzie jest akceptowana, więc ruch przeznaczony dla serwerów Softaculous został przekierowany do infrastruktury atakującego na około 33 godziny. Zarówno BleepingComputer, jak i The Register poinformowały o przejęciu 1 września 2026 roku, a Softaculous potwierdził później chronologię i szczegóły techniczne we własnym raporcie powypadkowym. Cybersecuritynews.com i GBHackers opublikowały tego samego dnia potwierdzające doniesienia, opisując przejęcie jako podręcznikowy przykład ataku z bardziej szczegółowym prefiksem na przestrzeń adresową dostawcy hostingu.

Dlaczego certyfikat nigdy nie wywołał ostrzeżenia

Przejęcie nie tylko przekierowało ruch, ale też przechwyciło kontrole walidacji domeny, których Let's Encrypt używa do potwierdzenia, kto kontroluje daną domenę, co pozwoliło atakującemu poprosić o prawdziwy, prawidłowo podpisany certyfikat TLS dla przejętej domeny i go otrzymać. Połączenia z serwerem atakującego nie wykazywały żadnego ostrzeżenia certyfikatu, ponieważ dla urzędu certyfikacji żądanie wyglądało tak, jakby pochodziło od prawowitego właściciela domeny. Ani kłódka w przeglądarce, ani łańcuch certyfikatu, ani samo połączenie nie sygnalizowały niczego niepokojącego.

To niewygodna część tego incydentu: zautomatyzowana walidacja Let's Encrypt zadziałała dokładnie tak, jak została zaprojektowana. Sprawdza ona, czy ten, kto odpowiada pod danym adresem IP, kontroluje domenę, a w oknie przejęcia atakujący rzeczywiście odpowiadał pod tym adresem. Fałszerstwo nie tkwiło w certyfikacie, lecz w routingu, który decydował, kto mógł udowodnić własność. Ta różnica ma znaczenie: samo zaostrzenie walidacji domeny nie zapobiegłoby powtórce, ponieważ słabość leży w warstwie routingu poniżej.

Klient aktualizacji, który nigdy nie sprawdzał podpisu

Złośliwy pakiet aktualizacji Virtualizora trafił do niewielkiej liczby instalacji, konkretnie do tych, które akurat sprawdzały aktualizacje w oknie przejęcia, a nie do szerszej bazy użytkowników Virtualizora. Własny klient aktualizacji Virtualizora nie weryfikuje kryptograficznie pobieranych pakietów, więc ważny certyfikat na przejętej trasie wystarczył, by uruchomić kontrolowany przez atakującego kod jako root na zaatakowanych serwerach. Virtualizor jest używany do zarządzania dużą częścią budżetowego i średniej klasy hostingu VPS na całym świecie, co tłumaczy, dlaczego nawet wąskie, ograniczone w czasie naruszenie przyciągnęło uwagę wielu mediów zajmujących się bezpieczeństwem.

Ładunek zainstalował nieautoryzowane klucze SSH oraz fałszywą usługę systemd podszywającą się pod java-jre-update.service, dając atakującemu trwały backdoor, który przetrwałby restart i na pierwszy rzut oka wyglądał jak zwykła aktualizacja Javy. Softaculous wydał załataną wersję Virtualizor 3.2.9.9 1 września 2026 roku, wraz z własnym opisem incydentu. Zalecenia firmy wskazują, by szukać zarówno nieuprawnionych kluczy SSH, jak i podszywającej się usługi po nazwie, ponieważ backdoor zbudowano tak, by zlewał się z uprawnionymi procesami systemowymi.

Co operatorzy w UE są winni zgodnie z NIS2

Dla każdego operatora z UE lub Wielkiej Brytanii prowadzącego infrastrukturę w Hetznerze lub u innego europejskiego dostawcy, praktyczna nauka jest taka, że ważny certyfikat HTTPS nie jest dowodem autentyczności, gdy leżący u jego podstaw routing można sfałszować. Ogłoszenie tras przez Hetznera pozostało poprawne przez cały czas trwania incydentu; naruszenie tkwiło wyłącznie w ruchu, który zamiast tego wybrał bardziej szczegółową trasę atakującego. Mechanizm automatycznej aktualizacji, który nie weryfikuje podpisów, jest pojedynczym punktem awarii, niezależnie od tego, jak solidna jest otaczająca go infrastruktura. Ta sama zasada dotyczy nie tylko Virtualizora, ale każdego produktu, który automatycznie pobiera i instaluje kod bez sprawdzania podpisu kryptograficznego.

Zalecane działania naprawcze dla każdego, kto korzysta z Virtualizora lub klienta automatycznej aktualizacji innego dostawcy bez weryfikacji podpisów, są proste: rotować i ograniczać dane uwierzytelniające API oraz audytować serwery pod kątem nieautoryzowanych kluczy SSH, kont, zaplanowanych zadań i połączeń wychodzących. Zgodnie z NIS2 firmy z UE, które polegają na oprogramowaniu firm trzecich w krytycznej infrastrukturze, mają obowiązki należytej staranności w łańcuchu dostaw, i incydent, w którym własny kanał aktualizacji dostawcy stał się wektorem ataku, mieści się dokładnie w tym obowiązku.

Dlaczego to robimy

Robimy to dla wszystkich, którzy próbują nadążyć za tym, co technologia robi z naszym życiem. Dla ludzi, którzy ją budują, i dla ludzi, których to dotyka. Servola Journal istnieje po to, by to, czego się uczymy, należało do nich wszystkich.

Nikt nam za to nie płaci. Żadnych reklam, żadnego paywalla, za darmo dla wszystkich. Po prostu wierzymy, że zrozumienie tego, co dzieje się z nami wszystkimi, nie powinno zależeć od tego, kogo na to stać.

Jeśli dzisiaj coś ci to dało, powiedz nam, żebyśmy kontynuowali. Obserwuj nas, zostaw polubienie albo napisz pozytywny komentarz. Czytamy każdy jeden, i to właśnie one nas napędzają.

Czytaj dalej: Zespoły Bezpieczeństwa UE Bez Głosu W Sprawie Astry  |  Wykorzystane Tygodnie Przed Łatą PaperCut