Kod nie był podatny. Podpis był prawdziwy.
Przez wyciek kluczy UpdraftCentral napastnicy instalowali tylne furtki na stronach WordPress poleceniami, które strona uznawała za w pełni legalne. Bo były podpisane prawdziwym kluczem.
27 października CERT Polska ostrzegł, że przejęte klucze usługi UpdraftCentral Cloud są wykorzystywane do ataków na strony WordPress. UpdraftPlus to jedna z najpopularniejszych wtyczek do kopii zapasowych, z ponad czterema milionami aktywnych instalacji. UpdraftCentral to panel, z którego można zdalnie zarządzać wieloma takimi stronami naraz: robić kopie, aktualizować, instalować wtyczki.
Pod względem technicznym ta historia jest prosta. Pod każdym innym względem warto ją rozłożyć na części, bo pokazuje coś, co w tym roku widzieliśmy wiele razy w zupełnie innych miejscach.
Co się stało
TeamUpdraft potwierdził, że po nieautoryzowanym dostępie do jego serwisu prawdopodobnie odczytano bazę klientów. Były w niej między innymi klucze połączeń z usługami, w tym klucze UpdraftCentral. Firma zapewnia, że sama wtyczka, jej pliki do pobrania i kopie zapasowe w zewnętrznych magazynach klientów nie zostały naruszone.
18 października o 15:32 Patchstack zarejestrował pierwszą instalację tylnej furtki. Następnego dnia rano Nethemba wykryła atak na trzech własnych stronach, z czego na dwóch zainstalowano złośliwe wtyczki. Patchstack doliczył się co najmniej 99 różnych nazw tych wtyczek. Łącznej liczby zaatakowanych stron nikt nie podał.
Kod nie był podatny
Tu jest sedno. Napastnik wysyłał do strony polecenie „zainstaluj wtyczkę” tym samym kanałem, którym robi to panel UpdraftCentral. Polecenie było podpisane prawdziwym kluczem panelu, więc strona sprawdzała podpis, uznawała go za ważny i wykonywała polecenie. Patchstack pisze wprost: oficjalny kod wtyczki nie był podatny. Atak działał, bo podpisy były prawdziwe.
Zainstalowana wtyczka udawała narzędzie porządkowe („Small maintenance toolkit: keeps option storage tidy”). Czekała na wywołanie z tajnym parametrem, a wtedy zakładała konto z uprawnieniami do zarządzania stroną i instalowania wtyczek, po czym logowała napastnika ciasteczkiem. Ciasteczko omija formularz logowania, a z nim uwierzytelnianie dwuskładnikowe, limity prób i wtyczki chroniące logowanie. Konto zostaje nawet po usunięciu wtyczki.
Jest w tym szczegół, który dobrze pokazuje, jak podstępne są takie ataki. Część próbek miała błąd, przez który strona zwracała błąd 500. Patchstack ostrzega, żeby takiej wtyczki nie naprawiać, bo poprawienie błędu uruchamia furtkę. Odruch dobrego administratora, czyli „coś się sypie, naprawię to”, działa tu na korzyść napastnika.
Każde zabezpieczenie, które sprawdza, czy polecenie jest prawidłowo podpisane, przepuści takie polecenie. Każde, które sprawdza, czy logowanie przeszło przez formularz, nie zauważy ciasteczka. W marcowym radarze pisaliśmy, że granica między legalnym a złośliwym przestała być punktem odniesienia. Tu przestała istnieć w kodzie: złośliwe polecenie różniło się od legalnego tylko tym, kto trzymał klucz.
Klucz żyje na stronie
Drugi szczegół jest równie ważny. CERT Polska podkreśla, że samo usunięcie strony z panelu UpdraftCentral nie wystarcza. Patchstack wyjaśnia dlaczego: para kluczy powstaje na stronie i to strona przechowuje klucz publiczny panelu. Usunięcie strony z panelu zmienia to, co widzisz w panelu, ale nie to, komu ufa strona. Klucz, który się liczy, żyje na stronie.
To ta sama lekcja, którą kilka dni wcześniej dało PHP2Shell, gdzie komunikat hostingodawcy to jedno, a stan serwera to drugie. Panel pokazuje deklarację. Stan sprawdza się tam, gdzie zapada decyzja o zaufaniu: na samej stronie, w jej opcjach, plikach i kontach. Dlatego zalecenia CERT każą sprawdzać wtyczki z poziomu systemu plików, a nie tylko w kokpicie, bo nie wszystko, co działa na stronie, widać w panelu.
Warstwa zarządzania jako cel
Narzędzia do zdalnego zarządzania stronami istnieją po to, żeby jedna osoba mogła bezpiecznie obsłużyć wiele stron. Właśnie dlatego są tak atrakcyjnym celem: jeden wyciek oznacza klucze do wszystkich podłączonych stron naraz. Kto przejmie pilota, nie musi się włamywać do żadnego telewizora.
W październikowym radarze opisaliśmy, że ekosystem agentowy stał się klasą celów: biblioteki pośredniczące do modeli, konsole narzędzi deweloperskich z kluczami do wielu dostawców, konektory asystentów. UpdraftCentral nie ma nic wspólnego z agentami AI, ale mechanizm jest identyczny. Każda warstwa, która trzyma klucze do wielu systemów, jest celem wartym więcej niż suma tych systemów. Agenci i ich konektory to po prostu najnowsza wersja tego samego pilota.
Do tego ironia, której nie da się pominąć: furtkę otworzył kanał zarządzania wtyczką do kopii zapasowych, a jednym z zaleceń jest przywrócenie strony z kopii sprzed 17 października. Kopia ratuje tylko wtedy, gdy leży poza zasięgiem tego, co zostało przejęte.
Co sprawdzić
Szczegółowe instrukcje są w komunikacie CERT Polska. W skrócie:
- Zaktualizuj UpdraftPlus do wersji 1.26.13 albo 2.26.13 (Premium). Ta wersja unieważnia stare klucze. Usunięcie strony z panelu nie wystarczy.
- Sprawdź konta użytkowników po uprawnieniach, a nie po nazwach. Szukaj redaktorów, którzy mogą zarządzać ustawieniami strony, i adresów e-mail w domenach przykładowych.
- Sprawdź wtyczki w systemie plików, nie tylko w kokpicie, i nie naprawiaj wtyczki, która nagle zaczęła zwracać błąd 500.
- Przejrzyj logi pod kątem wskaźników podanych przez CERT.
- Jeśli strona została przejęta, przywróć ją z kopii sprzed 17 października, zmień hasła i ponownie autoryzuj zewnętrzne magazyny kopii.
I rada szersza, która zostaje po tej historii: każde narzędzie, które może instalować coś na twojej stronie z zewnątrz, jest kluczem, który ktoś inny trzyma razem z twoim. Warto wiedzieć, ile takich kluczy wydałeś, i odpinać te, których już nie używasz.
Źródła