Roundcube opublikował w niedzielę 24 maja aktualizacje bezpieczeństwa 1.6.16 oraz 1.7.1. Według komunikatu producenta lista napraw obejmuje między innymi wstrzyknięcia treści i XSS, SQL injection w dodatku virtuser_query oraz obejścia ochrony SSRF. Organizacje, które udostępniają pocztę przez Roundcube, powinny ustalić, kto odpowiada za ten webmail, jakie dodatki są w nim włączone i czy poprawka faktycznie działa.

Kto w Twojej organizacji odpowiada za Roundcube? Łatwa odpowiedź brzmi: „zespół od poczty”. Wyobraź sobie jednak recepcję biurowca, w której ochrona pilnuje głównego wejścia, a nikt nie wie, kto ma klucze do bocznych drzwi dobudowanych przy remoncie. Webmail bywa takim bocznym wejściem do korespondencji. Serwer pocztowy ma swojego opiekuna, harmonogram poprawek i miejsce w rejestrze zasobów. Interfejs przeglądarkowy i jego dodatki mogą trafiać do tego samego wpisu bez osobnej uwagi. Komunikat z 24 maja dobrze nadaje się do sprawdzenia, czy u Ciebie jest inaczej. Zawiera dwie wersje, kilka klas błędów i nazwę konkretnego dodatku, więc pytanie „czy mamy Roundcube?” można zamienić w trzy pytania: która wersja działa, które dodatki są włączone i kto potwierdził aktualizację.

Trzy klasy błędów w jednym komunikacie

Jak podaje Roundcube, poprawki 1.6.16 i 1.7.1 obejmują kilka rodzajów błędów. Pierwsza grupa to wstrzyknięcia treści i XSS, czyli możliwość umieszczenia w interfejsie elementów, których nie powinien on wyświetlać ani wykonywać. W narzędziu do czytania poczty taka klasa błędów może dotyczyć miejsca, w którym użytkownik ogląda treść przychodzącą z zewnątrz.

Druga pozycja to SQL injection w dodatku virtuser_query. Komunikat wskazuje więc z nazwy konkretny komponent. Dla oceny ekspozycji ma to praktyczne znaczenie: odpowiedź zależy od tego, czy ten dodatek jest w danej instalacji używany.

Trzecia grupa to obejścia ochrony SSRF. Ochrona przed SSRF ogranicza żądania, które serwer wysyła w imieniu użytkownika. Obejście oznacza, że zabezpieczenie istniało, ale dało się je ominąć.

Wymienione tu pozycje nie wyczerpują listy napraw. Pełny zakres trzeba odczytać bezpośrednio w komunikacie, zanim administrator zamknie zadanie.

Webmail jest częścią systemu pocztowego i powinien mieć własny wpis w rejestrze zasobów, z wersją i listą dodatków.

Czego rejestr zasobów nie mówi o tej aktualizacji

Materiał źródłowy nie opisuje, jak konkretne organizacje zarządzają Roundcube, więc nie przypisujemy nikomu zaniedbań. Można jednak wskazać, gdzie ogólny zapis inwentaryzacyjny rozmija się z tym komunikatem. Wpis „Roundcube, aktualny” nie mówi, czy instalacja korzysta z gałęzi 1.6, czy 1.7. Nie mówi też, czy włączono dodatek virtuser_query.

Tymczasem dla tej aktualizacji obie informacje decydują o ocenie. Wersja 1.6.16 i wersja 1.7.1 to dwa różne punkty docelowe. Administrator musi wiedzieć, na której gałęzi pracuje, zanim potwierdzi, że poprawka jest na miejscu. Przy virtuser_query wystarczy ustalić, czy dodatek jest włączony. Jeżeli nikt tego nie sprawdził, właściwy zapis to „nieustalone”, z nazwiskiem osoby, która uzupełni dane.

Drugi rozjazd dotyczy dowodu. Zgłoszenie zmiany w systemie ticketowym potwierdza, że ktoś zaplanował aktualizację. Nie potwierdza, że działająca instalacja ma numer 1.6.16 albo 1.7.1. Proponujemy, by przy odbiorze prac wymagać wersji odczytanej z działającej instalacji.

Zamknięte zgłoszenie aktualizacji Roundcube jest dowodem wykonania dopiero wtedy, gdy zawiera wersję odczytaną z działającej instalacji.

Kto odbiera aktualizację webmaila

Dla osoby odpowiedzialnej za pocztę organizacji komunikat z 24 maja wyznacza trzy decyzje: o wdrożeniu, zakresie i konfiguracji. Wdrożenie to potwierdzenie wersji. Zakres to porównanie pełnej listy napraw z używanymi funkcjami. Konfiguracja to lista włączonych dodatków, z virtuser_query na pierwszym miejscu.

Każdej z tych decyzji przypiszmy właściciela, nawet jeśli wszystkie czynności wykona ten sam administrator. Rozdzielenie ról ma prosty cel: przy przeglądzie wiadomo, kto odpowiada za który wynik. W raporcie dla zarządu wystarczy jedna linijka na instalację Roundcube, z wersją, statusem dodatku i datą potwierdzenia.

Źródło nie podaje kosztu aktualizacji. Nie wiadomo też, czy którąkolwiek z luk wykorzystano przed publikacją poprawek. Nie dopisujmy więc pilności ani skali, których materiał nie potwierdza. Do działania wystarczy sam komunikat producenta, bo opisuje kilka klas błędów w narzędziu, przez które użytkownicy czytają służbową korespondencję. Termin wdrożenia powinien wynikać z oceny własnego środowiska, a odstępstwo od niego wymaga decyzji właściciela poczty, zapisanej obok uzasadnienia.

Polskie organizacje bez danych o ofiarach

Nie wiadomo, czy błędy usunięte w wersjach 1.6.16 i 1.7.1 dotknęły polskie organizacje ani czy wydano w tej sprawie krajowe komunikaty. Punktem odniesienia jest datowany komunikat producenta z 24 maja. Do zlecenia przeglądu Roundcube dołączmy link do niego, żeby osoba odbierająca pracę mogła porównać wykonane czynności z pełną listą napraw i z wersją odczytaną z własnej instalacji.

Co z tym zrobić w poniedziałek

  1. Odczytaj wersję działającego webmaila. Ustal, czy instalacja korzysta z gałęzi 1.6, czy 1.7, i porównaj numer z wersjami 1.6.16 oraz 1.7.1. Zapisz wynik, źródło odczytu i osobę, która go potwierdziła.
  2. Sprawdź listę włączonych dodatków. Zacznij od virtuser_query, wskazanego w komunikacie z 24 maja. Przy każdym dodatku zapisz, czy jest używany i kto za niego odpowiada; pozycje nieustalone oznacz wprost.
  3. Porównaj pełną listę napraw z własnym środowiskiem. Otwórz komunikat Roundcube i zestaw wymienione błędy z funkcjami włączonymi u siebie. Zapisz pozycje wymagające dalszego sprawdzenia i termin ich zamknięcia.

Odpowiedzialność za pocztę powinna sięgać do webmaila i jego dodatków, bo to tam komunikat Roundcube lokuje część błędów. Aktualizację uznajmy za zakończoną, gdy wersja jest odczytana z działającego systemu, a lista dodatków sprawdzona. Do tego czasu zadanie pozostaje otwarte, niezależnie od statusu zgłoszenia.

Źródła

Redakcja cyberinsight.pl.