CERT Polska opisał we wtorek 9 czerwca łańcuch luk w UniFi OS, który pozwala wykonać polecenia z uprawnieniami root bez uwierzytelnienia. Ten sam komunikat zaznacza, że aktualizacja nie usuwa skutków wcześniejszej kompromitacji, na przykład wykradzionych kluczy JWT. Właściciele sieci i menedżerowie dostawców IT powinni więc rozliczać tę sprawę w trzech krokach: poprawka, ocena kompromitacji i rotacja poświadczeń.

Wyobraź sobie biuro, do którego ktoś wszedł przez wadliwy zamek w drzwiach zaplecza. Ślusarz wymienia zamek następnego dnia i wystawia protokół: usterka usunięta. Protokół jest prawdziwy, ale pomija pytanie, które powinno paść jako pierwsze: czy intruz zdążył zabrać klucze z szuflady w recepcji? Jeżeli tak, nowy zamek w drzwiach zaplecza nic nie zmienia dla drzwi wejściowych, do których te klucze pasują. Komunikat CERT Polska o UniFi OS opisuje bardzo podobny układ. Łańcuch luk daje napastnikowi uprawnienia root bez logowania, a poprawka zamyka tę drogę na przyszłość. Sekrety, które mogły wyjść z systemu wcześniej, w tym klucze JWT wskazane przez CERT Polska, nadal działają, dopóki ktoś ich świadomie nie wymieni.

Łańcuch luk w UniFi OS kończy się na koncie root

Według CERT Polska problem nie sprowadza się do pojedynczej usterki. Komunikat opisuje łańcuch luk w UniFi OS, którego końcowym efektem jest wykonanie poleceń z uprawnieniami root, i to bez uwierzytelnienia. Napastnik osiąga więc najwyższy poziom uprawnień w systemie, nie znając żadnego hasła.

Stawką jest centralne zarządzanie siecią. Kto ma root w systemie, z którego administruje się infrastrukturą, ten może sięgnąć także po sekrety przechowywane na tym systemie. CERT Polska podaje jako przykład klucze JWT. Takimi kluczami podpisuje się tokeny, na podstawie których system uznaje, że ma do czynienia z uprawnionym użytkownikiem. Wykradziony klucz pozwala więc próbować wystawiać tokeny, które system przyjmie jako własne, także po wgraniu poprawki.

Czego z komunikatu nie wiemy? Fakty, na których opiera się ten tekst, nie mówią, czy łańcuch luk był już wykorzystywany ani w ilu instalacjach. Tej niewiadomej nie rozstrzygnie żadna aktualizacja. Rozstrzygnąć ją może tylko sprawdzenie, co działo się w systemie przed jej instalacją.

Poprawka zamyka drogę, którą napastnik mógł wejść. Nie zamyka dróg, które mógł sobie przygotować, zanim ją wgrano.

Status „zaktualizowano” opisuje jeden z trzech kroków

Jeżeli procedura reagowania na podatności kończy się wpisem „zainstalowano poprawkę”, dokumentuje tylko pierwszy z trzech potrzebnych kroków. Dla UniFi OS ten wpis odpowiada na pytanie, czy łańcuch luk nadal działa. Nie odpowiada na dwa kolejne: czy ktoś skorzystał z niego wcześniej i czy sekrety z tego systemu, w tym klucze JWT, pozostają w obiegu.

Tu zaczyna się papierowe bezpieczeństwo. Raport dostawcy z zieloną pozycją „UniFi OS: aktualny” wygląda jak zamknięta sprawa. W rzeczywistości zamknięta jest tylko luka. Ostrzeżenie CERT Polska wprost rozdziela zamknięcie luki od jej wcześniejszego wykorzystania, więc trudno później twierdzić, że rozróżnienie było nieoczywiste.

Proponujemy traktować każdą instancję UniFi OS jako pozycję z trzema osobnymi polami. Pierwsze pole mówi, czy wgrano poprawkę. Drugie, czy ktoś sprawdził ślady wcześniejszej kompromitacji i z jakim wynikiem. Trzecie, czy wymieniono klucze JWT i pozostałe poświadczenia znane temu systemowi. Pole puste albo „nie dotyczy” bez uzasadnienia oznacza zadanie otwarte.

Dostawca IT powinien raportować poprawkę, ślady i rotację osobno

Dla menedżera dostawców IT ten komunikat jest dobrym testem umowy. Jeżeli dostawca odpowiada za sieć, menedżer sprawdza w umowie, czy zakres obejmuje tylko instalację poprawek, czy także ocenę kompromitacji i rotację poświadczeń po krytycznej luce. Jeżeli umowa milczy, decyzja nadal należy do kogoś po stronie organizacji. Lepiej, żeby był to ktoś wskazany z nazwiska.

Rotacja poświadczeń ma swój koszt organizacyjny: wymaga okna serwisowego, koordynacji i osoby, która ją zleci i odbierze. Dlatego nie zdarza się sama, przy okazji aktualizacji. Z perspektywy ryzyka rachunek jest jednak prosty. Luka w UniFi OS dawała root bez uwierzytelnienia, a CERT Polska ostrzega, że aktualizacja nie unieważnia wykradzionych kluczy JWT. Pozostawienie starych sekretów oznacza akceptację ryzyka, którego nikt nie zmierzył.

Właściciel sieci powinien więc dostać od dostawcy odpowiedź na trzy pytania. Kiedy wgrano poprawkę? Co sprawdzono pod kątem śladów wcześniejszego dostępu i co z tego wynikło? Które poświadczenia wymieniono, a które świadomie pozostawiono, i kto o tym zdecydował? Brak odpowiedzi na drugie i trzecie pytanie jest informacją samą w sobie.

Decyzja o niewymienianiu kluczy po krytycznej luce też jest decyzją. Powinna mieć właściciela i datę.

Komunikat CERT Polska z 9 czerwca to wspólny punkt odniesienia

Polskim punktem odniesienia jest komunikat CERT Polska „Krytyczne podatności w produktach Ubiquiti”, opublikowany 9 czerwca 2026 r. To otwarty dokument pierwotny. Na dzień publikacji tego tekstu nie dysponujemy niezależnym potwierdzeniem medialnym opisanych w nim ustaleń, dlatego trzymamy się wyłącznie tego, co podał CERT Polska.

Sprawa wpisuje się w serię problemów z urządzeniami brzegowymi, w których krytyczna luka w systemie zarządzania otwiera dostęp do całej sieci. Wspólny odnośnik do komunikatu ułatwia rozmowę właściciela sieci z dostawcą IT: obie strony pracują na tym samym opisie zagrożenia i tym samym zastrzeżeniu dotyczącym kluczy JWT. Wersje objęte problemem i szczegóły techniczne sprawdzajmy bezpośrednio w komunikacie, zamiast przepisywać je z drugiej ręki.

Co z tym zrobić w poniedziałek

  1. Spisz instancje UniFi OS. W 30 minut zestaw systemy UniFi OS używane w organizacji i przy każdym wpisz, kto odpowiada za jego aktualizację: zespół wewnętrzny czy dostawca. Pozycje, których wersji nie znasz, oznacz jako do sprawdzenia z komunikatem CERT Polska.
  2. Poproś dostawcę o trzy statusy. Wyślij dostawcy IT pytanie o każdą instancję: poprawka, ocena śladów kompromitacji, rotacja kluczy JWT i innych poświadczeń. Jeśli gotowy jest tylko pierwszy status, zapisz dwa pozostałe jako otwarte zadania z terminem.
  3. Wskaż właściciela decyzji o rotacji. Ustal, kto w organizacji zatwierdza wymianę poświadczeń po krytycznej luce w systemie zarządzania siecią. Zapisz tę osobę w procedurze reagowania na podatności obok osoby, która zatwierdza instalację poprawek.

Aktualizacja UniFi OS odpowiada na pytanie o przyszłość systemu, a ocena kompromitacji i rotacja poświadczeń na pytanie o jego przeszłość. Komunikat CERT Polska z 9 czerwca daje właścicielom sieci argument, by wymagać obu odpowiedzi od dostawców IT. Organizacja, która zamknie sprawę na poprawce, może zostawić w obiegu klucze JWT, o których nic nie wie.

Źródła

Redakcja cyberinsight.pl.