14 września użytkownicy płatnej wtyczki Admin Menu Editor Pro mogli dostać zwykłą aktualizację do wersji 2.35. Aktualizacja przychodziła z legalnego serwera producenta. Problem w tym, że paczka zawierała plik includes/wp-user-consent.php, który instalował na stronie web shell, czyli mechanizm pozwalający zdalnie wykonywać polecenia na serwerze.

Producent usunął złośliwą paczkę i tego samego dnia wypuścił czystą wersję 2.36. Kilka godzin później także ona została podmieniona. Wtedy stało się jasne, że problem nie kończy się na przejętym koncie w panelu albo jednym pliku. Atakujący prawdopodobnie mieli dużo głębszy dostęp do infrastruktury.

To był atak na łańcuch dostaw, nie zwykła podatność WordPressa

W klasycznej podatności atakujący szuka błędu w kodzie zainstalowanym na stronie. Tutaj najpierw przejęto miejsce, któremu właściciele stron ufają, czyli serwer dystrybuujący aktualizacje. Dopiero potem z tego zaufanego źródła wysłano zmodyfikowaną wersję wtyczki.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

To właśnie jest atak na łańcuch dostaw. Nie trzeba przekonywać administratora do pobrania pliku z podejrzanej domeny. Jeżeli napastnik kontroluje prawdziwy kanał aktualizacji, złośliwa paczka wygląda jak normalny update.

Wersja 2.35 jest kompromitacją strony, 2.36 też nie daje spokoju

Oficjalny komunikat producenta jest jednoznaczny. Jeżeli wersja 2.35 została zainstalowana 14 września, stronę należy traktować jako przejętą. Wersję 2.36 także należy traktować jako potencjalnie przejętą, szczególnie jeśli została pobrana po 19:00 UTC. Wersja 2.34 według obecnej wiedzy powinna być czysta.

Producent szacował początkowo około 230 klientów dotkniętych pierwszym etapem incydentu, często posiadających więcej niż jedną stronę. Później wskazał jeszcze około 300 klientów potencjalnie narażonych w drugim oknie czasowym. To liczby dotyczące klientów, nie zweryfikowanej liczby zainfekowanych witryn.

Co robił złośliwy kod?

Najważniejszy element to web shell. W praktyce oznacza możliwość wykonywania kodu na przejętej stronie. Producent ostrzega więc, żeby zakładać pełną kontrolę atakującego nad witryną, a nie tylko obecność jednego podejrzanego pliku.

Zgłoszenia użytkowników pokazały też dodatkowe ślady: katalog /wp-content/object-cache z losowo nazwanym skryptem PHP, wpisy w bazie zaczynające się od wp_ocache albo _wp_ocache_, ukryte konto użytkownika z loginem zaczynającym się od wp_, podejrzane MU-pluginy i zadanie WP-Cron o nazwie _wp_cconsent_tick.

Producent zaznacza, że taki ukryty użytkownik może nie pojawiać się na zwykłej liście w panelu WordPressa, ale będzie widoczny bezpośrednio w tabeli wp_users. Sam szybki rzut oka do zakładki Użytkownicy może więc nie wystarczyć.

Pierwsza naprawa nie zadziałała, bo intruz nadal był w środku

Po wykryciu wersji 2.35 producent usunął ją i wypuścił 2.36. Później tego samego dnia wykrył kolejne włamanie, a wersja 2.36 również została naruszona. Próby zatrzymania ataku nie działały, więc serwer został wyłączony.

17 września pojawił się nowy trop: możliwa eskalacja do roota przez podatność w przestarzałym jądrze Linuxa. Jeżeli ten kierunek się potwierdzi, dobrze tłumaczy, dlaczego samo wyczyszczenie aplikacji i zmiana jednej paczki nie wystarczyły. Atakujący mógł pozostawać ponad warstwą, którą próbowano naprawiać.

Co powinien zrobić właściciel strony z tą wtyczką?

Jeżeli na stronie znalazła się wersja 2.35 z 14 września, najbezpieczniejszym wariantem wskazanym przez producenta jest odtworzenie witryny z kopii sprzed 14 września. W przypadku wersji 2.36 również nie należy zakładać, że sam numer wersji oznacza czystą instalację.

Producent zaleca usunięcie podejrzanej wersji, sprawdzenie opisanych artefaktów, zmianę haseł użytkowników WordPressa, wygenerowanie nowych kluczy i saltów w wp-config.php oraz rotację danych dostępowych przechowywanych przez stronę: bazy danych, SFTP lub FTP, panelu hostingowego i kluczy API. Do tego pełny skan oraz przegląd plików zmodyfikowanych od 14 września.

Producent sam zaznacza, że nadal nie ma pełnego obrazu payloadu i część kroków może być niewystarczająca. W takim incydencie “usunąłem plik i jest czysto” jest bardziej nadzieją niż procedurą.

Komentarz WebsiteGarage

Automatyczne aktualizacje są potrzebne. Aktualizacje od oryginalnego producenta też są potrzebne. Ten incydent nie jest argumentem, żeby je wyłączyć i wrócić do ręcznego klikania raz na kwartał. Pokazuje coś innego: aktualizacja jest elementem systemu bezpieczeństwa, a nie całym systemem.

Jeżeli przejęty zostaje producent, legalny kanał dystrybucji może stać się kanałem infekcji. Dlatego sens mają kopie zapasowe poza serwerem, monitoring zmian, możliwość odtworzenia strony, ograniczone uprawnienia i procedura reagowania na incydent. Bez tego bezpieczeństwo WordPressa łatwo sprowadzić do rytuału: wszystko zielone, wszystko aktualne, więc na pewno jest dobrze. A teraz pytanie zasadnicze – czy klikając w kolejne “aktualizuj” ktoś sprawdza jaki jest powód aktualizacji i że trzeba podjąć jakieś dodatkowe kroki? Jak widać warto zajrzeć czasem w informacje o wersji.

Najciekawsza lekcja jest jeszcze prostsza. Po pierwszej podmianie producent przygotował czystą wersję. Intruz ją podmienił ponownie. Jeżeli nie usuniesz przyczyny kompromitacji, poprawiony plik potrafi być tylko świeżym miejscem do ponownego zepsucia.