CERT Polska skoordynował ujawnienie dwóch podatności QuickCMS: Session Fixation oraz XSS związanej z pobieraniem listy wtyczek przez HTTP. Komunikat z piątku 29 maja opisuje poprawkę z 15 maja, wydaną w obrębie tej samej wersji programu. Dla firm, których witryny utrzymuje własne IT albo zewnętrzna agencja, odpowiedź „mamy aktualną wersję” przestaje więc wystarczać przy odbiorze prac.

Wyobraź sobie hotel, w którym gość może przyjść do recepcji z kartą do pokoju otrzymaną od obcej osoby. Recepcja melduje gościa i zamiast wydać nową kartę, aktywuje tę przyniesioną. Ten, kto ją wręczył, zachował duplikat i od tej chwili otwiera ten sam pokój. Tak w uproszczeniu działa błąd opisany przez CERT Polska: według komunikatu identyfikator sesji w QuickCMS nie zmieniał się po uwierzytelnieniu, co pozwalało przejąć tak ustaloną sesję. Druga część analogii dotyczy kontroli. Hotel wymienia zamki, ale tabliczka na drzwiach dalej pokazuje ten sam numer pokoju. Kontroler, który patrzy wyłącznie na tabliczkę, nie odróżni drzwi z nowym zamkiem od drzwi ze starym. Przy poprawce z 15 maja rolę tabliczki pełni numer wersji CMS.

Sesja ustalona przed logowaniem przetrwała uwierzytelnienie

Identyfikator sesji jest dla serwera dowodem, że kolejne żądania pochodzą od osoby, która się zalogowała. Jeśli ktoś zna tę wartość jeszcze przed logowaniem ofiary, a system jej nie wymienia, po zalogowaniu ten sam identyfikator otwiera już sesję uwierzytelnioną. Tak CERT Polska opisuje Session Fixation w QuickCMS: wartość ustalona wcześniej przetrwała uwierzytelnienie, a tak ustaloną sesję można było przejąć. Skutek jest prosty do wytłumaczenia zarządowi: przejęta sesja pozwala działać w serwisie jako zalogowany użytkownik.

Druga podatność to XSS związana z pobieraniem listy wtyczek przez HTTP. XSS oznacza możliwość osadzenia obcego skryptu w stronie oglądanej przez użytkownika. Dla odbiorcy usługi utrzymania ważne jest, gdzie leży problem: w mechanizmie pobierania rozszerzeń, czyli w treści, która trafia do systemu z zewnątrz nieszyfrowanym kanałem.

Oba błędy należą do dobrze znanych klas. Pierwszy dotyczy uwierzytelniania, drugi zaufania do zewnętrznej treści. Usunięcie żadnego z nich nie zmieniło numeru wersji, który trafia do raportu z utrzymania.

Sesja, która przeżywa logowanie, należy także do tego, kto ją założył.

Ta sama wersja przed poprawką i po niej

Rozważmy typowy wpis w miesięcznym raporcie z utrzymania strony: „CMS w aktualnej wersji, bez uwag”. To przykład konstrukcji raportu, nie opis udokumentowanego przypadku. Przy QuickCMS taki wpis niewiele mówi, bo poprawka z 15 maja ukazała się w obrębie tej samej wersji. Witryna bez poprawki i witryna po jej wdrożeniu mogą pokazywać identyczny numer.

Każda kontrola oparta wyłącznie na numerze da w obu przypadkach ten sam wynik. Lista kontrolna, która porównuje wersję z wykazem „aktualnych”, odhaczy obie instalacje. Arkusz inwentaryzacji serwisów firmy zapisze je tak samo. Na papierze wszystko się zgadza, a na pytanie, czy poprawka z 15 maja działa na produkcji, nikt nie odpowiada.

Odpowiedź da się uzyskać na dwa sposoby. Pierwszy to zapis wdrożenia: data instalacji poprawki późniejsza niż 15 maja i wskazanie, której poprawki dotyczy zmiana. Drugi to sprawdzenie skutku: porównanie identyfikatora sesji przed zalogowaniem i po nim na koncie testowym. Jeśli wartość się nie zmienia, system zachowuje się dokładnie tak, jak opisał CERT Polska, niezależnie od deklaracji w raporcie.

Numer wersji mówi, co zainstalowano. Zapis wdrożenia poprawki i test sesji mówią, co naprawiono.

Odbiór utrzymania strony powinien wymagać dowodu

Za firmową witrynę odpowiada firma także wtedy, gdy jej aktualizacje wykonuje agencja. Umowa utrzymaniowa przenosi pracę, ale decyzję o odbiorze podejmuje zamawiający. Jeśli kryterium odbioru brzmi „system zaktualizowany”, wykonawca spełnia je samym numerem wersji. Przypadek QuickCMS pokazuje, że takie kryterium nie odróżnia instalacji poprawionej od niepoprawionej.

Lepsze kryterium ma trzy elementy. Raport wskazuje konkretną poprawkę i datę jej wdrożenia, w tym przypadku późniejszą niż 15 maja. Zawiera wynik kontroli sesji, czyli potwierdzenie, że identyfikator zmienia się po zalogowaniu. Opisuje też, jak system pobiera listę wtyczek i czy ten mechanizm objęto przeglądem. Dla własnego działu IT to te same trzy pytania, zadane w notatce zamiast w protokole odbioru.

Komunikat CERT Polska nie podaje skali narażenia ani strat, więc nie wyceniajmy ryzyka na jego podstawie. Koszt kontroli da się za to oszacować bez trudu: kilka pytań w raporcie i jeden test logowania na koncie testowym. Zarząd nie musi rozumieć mechanizmu sesji, żeby wymagać odpowiedzi na pytanie, którą poprawkę wdrożono i kiedy.

CERT Polska koordynował ujawnienie, wykorzystania nie potwierdzono

Ujawnienie obu podatności koordynował CERT Polska, a komunikat opublikował w piątek 29 maja, 14 dni po poprawce z 15 maja. Administrator, który śledził wyłącznie komunikaty CERT, mógł się dowiedzieć o problemie dopiero dwa tygodnie po dacie poprawki. Dla agencji utrzymującej wiele witryn to argument, by oprócz komunikatów o podatnościach śledzić także informacje o poprawkach dla używanych systemów.

Komunikat nie potwierdza aktywnego wykorzystania. To przesuwa temat z nocnego dyżuru do planu tygodnia. Nie wiemy też, ile firmowych witryn w Polsce działa na QuickCMS; źródło tej liczby nie podaje. Dlatego sensownym ruchem na poniedziałek 1 czerwca jest inwentaryzacja i weryfikacja, bez ogłaszania incydentu.

Co z tym zrobić w poniedziałek

  1. Ustal, które firmowe witryny działają na QuickCMS i kto je utrzymuje. Przejrzyj listę serwisów, umów z agencjami i zadań własnego IT. Dla każdej witryny zapisz osobę odpowiedzialną za aktualizacje; brakujące dane oznacz jako nieustalone i przypisz wykonawcę.
  2. Poproś utrzymującego o potwierdzenie wdrożenia poprawki z 15 maja. Zapytaj o datę instalacji i wskazanie poprawki, nie o numer wersji. Odpowiedź „wersja aktualna” zapisz jako niewystarczającą i poproś o uzupełnienie z terminem.
  3. Zleć sprawdzenie sesji na koncie testowym własnej witryny. Wykonawca porównuje identyfikator sesji przed zalogowaniem i po nim, a wynik dołącza do zgłoszenia. Do tego samego zgłoszenia dopisz pytanie o sposób pobierania listy wtyczek.

Poprawka wydana w obrębie tej samej wersji odbiera numerowi wersji wartość dowodu. Odbiór usługi utrzymania strony powinien kończyć się wskazaniem konkretnej poprawki i wynikiem kontroli sesji. Firma, która tego nie wymaga, odbiera tabliczkę na drzwiach zamiast zamka.

Źródła

  1. CERT Polska: Podatności w oprogramowaniu QuickCMS, publikacja: 29 maja 2026.

Redakcja cyberinsight.pl.