Amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) dodała w tym tygodniu lukę, która została po raz pierwszy ujawniona w styczniu w raporcie GitLab platformę open source do swojego Znane wykorzystywane luki (KEV), wywołując lawinę ostrzeżeń wzywających użytkowników usługi do natychmiastowego zastosowania dostępnych poprawek.
Śledzone jako CVE-2023-7028 i odkryte w ramach programu nagród za błędy HackerOne firmy GitLab, usterka występuje w wersjach GitLab Community i Enterprise.
Jest to niewłaściwa luka w kontroli dostępu, która umożliwia atakującemu wysłanie wiadomości e-mail z resetem hasła na niezweryfikowany adres e-mail, co prowadzi do przejęcia konta. CISA stwierdziło, iż w momencie publikacji nie było wiadomo, czy został on wykorzystany jako czynnik w jakichkolwiek atakach ransomware.
Dodanie luki do katalogu KEV zobowiązuje organy rządowe USA do natychmiastowego załatania tej luki, jeżeli zostanie ona dotknięta – mają na to czas do końca maja – ale służy także jako użyteczny przewodnik i ostrzeżenie we właściwym czasie dla przedsiębiorstw i innych organizacji o tym, co nowe luki mają największy wpływ i dlatego są cenne dla cyberprzestępców i innych podmiotów zagrażających.
CVE-2023-7028 wpływa na wszystkie wersje GitLab C/EE od 16.1 przed 16.1.6, 16.2 przed 16.2.9, 16.3 przed 16.3.7, 16.4 przed 16.4.5, 16.5 przed 16.5.6, 16.6 przed 16.6.4 i 16.7 przed 16.7.2. Użytkownicy powinni natychmiast dokonać aktualizacji do wersji 16.7.2, 16.6.4 i 16.5.6.
„Naszym celem jest zapewnienie, iż wszystkie aspekty GitLab, które są widoczne dla klientów, lub iż dane klientów hosta są przechowywane zgodnie z najwyższymi standardami bezpieczeństwa” – napisał Greg Meyers z GitLab w zawiadomieniu ujawniającym organizacji. „W ramach zachowania higieny bezpieczeństwa zdecydowanie zaleca się, aby wszyscy klienci dokonali aktualizacji do najnowszej wersji zabezpieczeń obsługiwanej wersji”.
Oprócz zastosowania tej poprawki organizacje mogą rozważyć włączenie uwierzytelniania wieloskładnikowego (MFA) na swoich kontach GitLab i rotację wszystkich sekretów przechowywanych w GitLab, w tym poświadczeń i haseł do kont, tokenów interfejsu programowania aplikacji i certyfikatów. Więcej wskazówek można znaleźć tutaj.
Adam Pilton, konsultant ds. cyberbezpieczeństwa w firmie CyberSmarti były śledczy zajmujący się cyberprzestępczością w policji w Dorset, powiedział: „Jest to niepokojąca luka, ponieważ potencjalne skutki wykorzystania mogą być dalekosiężne i obejmować nie tylko działalność ofiary, ale potencjalnie osoby z nią blisko współpracujące.
„Pozytywną wiadomością jest to, iż dostępna jest łatka usuwająca tę lukę i nalegam, aby wszyscy, których to dotyczy, zastosowali ją tak szybko, jak to możliwe.
„Chciałbym podkreślić bohatera tej historii, a jest to po raz kolejny MSZ” – powiedział. „Użytkownicy, którzy wdrożyli MFA, byliby chronieni przed cyberprzestępcami chcącymi uzyskać dostęp do ich konta, ponieważ wymagane dodatkowe uwierzytelnienie uniemożliwiłoby pomyślne logowanie.
„Musimy wyciągnąć wnioski z każdego ataku, a wnioski wyciągnięte z tej luki mają umożliwić MFA, zapewnić regularne instalowanie poprawek i wymagać silnych środków bezpieczeństwa cybernetycznego w swoim łańcuchu dostaw” – powiedział Pilton.
Opóźnione łatanie
Niepokój innych członków społeczności zajmujących się bezpieczeństwem wzbudził fakt, iż chociaż CVE-2023-7028 został załatany w styczniu 2024 r., w środowisku naturalnym przez cały czas istnieje znaczna liczba podatnych na ataki instancji GitLab – według danych ShadowServer aktualnych na dzień 1 majaponad 300 w USA, Chinach i Rosji, ponad 200 w Niemczech, 70 we Francji i 40 w Wielkiej Brytanii.
„Exploit podnosi również kwestię łatania, co, jak wiemy, przez cały czas stanowi duże wyzwanie dla wielu organizacji” – powiedział Hackowość wiceprezes ds. strategii Sylvain Cortes. „Faktem jest, iż łatka usuwająca tę lukę została wypuszczona 11 stycznia, mimo to ponad tysiąc konfiguracji GitLab przez cały czas pozostaje ujawnionych w Internecie.
„Priorytetem dla zespołów jest upewnienie się, iż uporają się z problemami, które muszą najpierw rozwiązać. Oceny ważności są ważne, ale zespoły ds. bezpieczeństwa powinny priorytetowo traktować luki, które stanowią największe ryzyko dla ich środowiska.
