CERT Polska w komunikacie z 24 września ostrzega o lukach GitLab umożliwiających uwierzytelnionemu atakującemu wykonanie kodu na serwerze. Według komunikatu producent opublikował jedenaście podatności, a CERT Polska rekomenduje pilną instalację poprawionych wersji. Dla organizacji korzystającej z GitLab to powód, by ustalić stan aktualizacji oraz zakres dostępu do repozytoriów i sekretów procesu budowania.

Czy na pytanie o bezpieczeństwo firmowego GitLab wystarczy odpowiedzieć, że dostęp wymaga logowania? W ostrzeżeniu CERT Polska uwierzytelnienie jest właśnie warunkiem opisanej możliwości wykonania kodu. Proponujemy więc zacząć od pytania, które kierownictwo powinno zadać także o system produkcyjny: kto potrafi potwierdzić wersję i termin wprowadzenia poprawek? Następnie poprośmy tę osobę o wskazanie właściciela przeglądu dostępu do repozytoriów oraz sekretów budowania. To propozycja kontroli własnego środowiska, bez założenia, że doszło w nim do ataku. Odpowiedź „mamy procedurę aktualizacji” potraktujmy jako początek rozmowy o GitLab, a potwierdzenie jej wykonania jako oczekiwany wynik.

Uwierzytelnienie jest warunkiem opisanym w ostrzeżeniu

Według CERT Polska luki pozwalają uwierzytelnionemu atakującemu wykonać kod na serwerze GitLab. W ocenie własnej instalacji zachowajmy oba elementy: wymagane uwierzytelnienie i możliwe wykonanie kodu. Informacji o jedenastu podatnościach nie przedstawiajmy jako dowodu, że każda z nich ma ten sam skutek. Przywołane informacje nie pozwalają rozstrzygnąć szczegółów mechanizmów ani wymaganego poziomu uprawnień.

Przegląd dostępu do repozytoriów i sekretów procesu budowania potraktujmy jako zadanie wynikające z przyjętego zakresu kontroli. Nie opisujmy go jako reakcji na potwierdziony wyciek, bo fakty nie dokumentują takiego zdarzenia. Poprośmy administratora GitLab o ustalenie, jaki dostęp istnieje w naszej konfiguracji i które uprawnienia wymagają uzasadnienia. Ocenę możliwych następstw oprzyjmy dopiero na tych ustaleniach.

Wymaganie logowania do GitLab nie powinno zamykać rozmowy o poprawkach, gdy ostrzeżenie dotyczy uwierzytelnionego atakującego.

W zapisie oceny GitLab rozdzielmy warunki podane w ostrzeżeniu od odpowiedzi dotyczących naszej instalacji. Przy wymaganiach, których nie udało się potwierdzić, pozostawmy jawne pytanie do administratora. Nie zastępujmy brakującej wiedzy założeniem, że każde konto daje taki sam dostęp.

Procedurę aktualizacji GitLab sprawdź na konkretnej instalacji

Po rekomendacji CERT Polska proponujemy zestawić firmową procedurę z aktualnym zapisem wersji GitLab. Poprośmy o wynik sprawdzenia, osobę odpowiedzialną za dalsze działanie oraz termin aktualizacji, jeśli jest potrzebna. Gdy wersja pozostaje nieustalona, oznaczmy ten stan w zadaniu. Nie zamykajmy go samą deklaracją, że zespół regularnie instaluje poprawki.

Zderzenie procedury z praktyką powinno tutaj przyjąć formę kontroli, ponieważ fakty nie opisują zachowania administratorów żadnej konkretnej organizacji. Sprawdźmy, czy zapis dotyczący GitLab pozwala odróżnić zaplanowane prace od zakończonej instalacji poprawki. Jeśli brakuje potwierdzenia wykonania, poprośmy o jego uzupełnienie albo wskazanie przeszkody. Nie przypisujmy zaniedbania osobie tylko dlatego, że dokumentacja wymaga wyjaśnienia.

W uzgodnieniu okna aktualizacji GitLab określmy także sposób potwierdzenia wyniku. Zalecamy, aby zadanie zawierało wersję ustaloną przed pracami i potwierdzoną po ich wykonaniu. Decyzję o terminie odnieśmy do pilności rekomendacji CERT Polska. Nagłówek stałej rubryki „Co z tym zrobić w poniedziałek” nie powinien być powodem odkładania reakcji do kolejnego tygodnia.

Repozytoria i sekrety budowania włącz do decyzji o dostępie

Osobie odpowiedzialnej za środowisko wytwarzania proponujemy zlecić przegląd zakresu dostępu powiązanego z GitLab. Poprośmy o wskazanie repozytoriów oraz sekretów procesu budowania objętych sprawdzeniem, wraz z odpowiedzialnością za zatwierdzenie uprawnień. Tam, gdzie zasadność dostępu pozostaje niewyjaśniona, zażądajmy decyzji o jego utrzymaniu lub ograniczeniu. Nie zakładajmy z góry wyniku takiego przeglądu.

W informacji dla kierownictwa połączmy stan poprawek GitLab z listą nierozstrzygniętych pytań o dostęp. Przy każdej z nich wskażmy osobę, która ma dostarczyć odpowiedź, i termin. W ten sposób proponujemy przełożyć tezę o równej kontroli środowiska wytwarzania i produkcji na wymagania wobec konkretnego zadania. Odpowiedzialny za jego zamknięcie powinien móc sprawdzić wykonanie aktualizacji i rozstrzygnięcie pytań o uprawnienia.

Od aktualizacji GitLab wymagajmy takiego samego potwierdzenia wykonania jak od poprawki systemu produkcyjnego.

Koszt prac, długość okna aktualizacji GitLab i zakres ewentualnych zmian dostępu pozostają do ustalenia w organizacji. Nie wyliczajmy ich na podstawie samej informacji o podatnościach. Poprośmy zespół o oszacowanie potrzebnych prac i wskazanie zależności, które wymagają decyzji kierownictwa.

Komunikat CERT Polska wyznacza punkt odniesienia dla kontroli

Polskim punktem odniesienia jest ostrzeżenie CERT Polska z 24 września. W organizacji korzystającej z GitLab proponujemy przekazać je osobie odpowiedzialnej za aktualizacje oraz właścicielowi środowiska wytwarzania. Ustalmy, kto zbierze wyniki kontroli wersji, terminu prac i dostępu. Jeżeli te zadania należą do różnych osób, poprośmy o wspólny zapis ustaleń dotyczących instalacji.

W raporcie o reakcji na komunikat CERT Polska oddzielmy informację o podatnościach od ustalonego stanu firmowego GitLab. Nie przedstawiajmy ostrzeżenia jako dowodu włamania do własnej organizacji. Jeśli zespół nie potwierdził jeszcze wersji lub uprawnień, wpiszmy dokładnie tę niewiadomą. Odbiorca raportu powinien otrzymać pytanie wymagające rozstrzygnięcia i termin odpowiedzi, zamiast ogólnego zapewnienia o bezpieczeństwie repozytoriów.

Proponujemy zakończyć kontrolę GitLab dopiero po zebraniu potwierdzeń dotyczących przyjętego zakresu prac. Jeżeli przegląd dostępu pozostaje otwarty po aktualizacji, zachowajmy osobne zadanie z odpowiedzialnym za jego dokończenie. W zapisie dla kierownictwa pokażmy, które ustalenia są potwierdzone, a które nadal wymagają sprawdzenia przez zespół.

Co z tym zrobić w poniedziałek

  1. Ustal wersję GitLab. W ciągu 30 minut sprawdź dostępny zapis wersji i porównaj go z komunikatem CERT Polska. Zapisz wynik lub brak danych oraz osobę odpowiedzialną za wyjaśnienie. Nie oznaczaj niepotwierdzonej instalacji jako zaktualizowanej.
  2. Zapisz okno aktualizacji. Poświęć 30 minut na przygotowanie z administratorem propozycji terminu, odpowiedzialności i sposobu potwierdzenia poprawki GitLab. Jeśli termin wymaga decyzji, wskaż jej właściciela. Ten krok obejmuje przygotowanie prac, bez obietnicy wykonania aktualizacji w pół godziny.
  3. Rozpocznij przegląd dostępu. W ciągu 30 minut przejrzyj dostępny wykaz uprawnień do repozytoriów i sekretów budowania powiązanych z GitLab. Wypisz braki oraz dostępy wymagające uzasadnienia; przypisz osobę do dalszej weryfikacji. Pełny przegląd zaplanuj według ustalonego zakresu.

Infrastrukturę wytwarzania oprogramowania obejmijmy taką samą kontrolą poprawek jak system produkcyjny. Przy GitLab wymagajmy wskazania odpowiedzialności za wersję, aktualizację oraz przegląd dostępu do repozytoriów i sekretów budowania. Za kryterium zakończenia prac przyjmijmy sprawdzone wyniki tych zadań.

Źródła

Redakcja cyberinsight.pl.