Jeśli zostaną wykorzystane, te luki mogą umożliwić atakującym uzyskanie nieautoryzowanego dostępu do poufnych informacji lub ogólnie spowodować problemy
Kilka dni temu GitHub ujawnił w poście na blogu szczegóły dotyczące luki w zabezpieczeniach , która umożliwia dostęp do zawartości zmiennych środowiskowych ujawnionych w kontenerach używanych w infrastrukturze produkcyjnej.
Luka została odkryta przez uczestnika programu Bug Bounty, którego celem jest wyszukiwanie luk w zabezpieczeniach i nagradzanie badaczy za ich odkrycia. Problem ten dotyczy zarówno usługi GitHub, jak i konfiguracji GitHub Enterprise Server (GHES) działających w systemach użytkowników.
Luka w zabezpieczeniach, skatalogowana jako CVE-2024-0200 i o wysokim wskaźniku ważności 7.2 (CVSS), nie została wykorzystana w praktyce. Analiza logów i audyt infrastruktury nie ujawniły żadnych dowodów wcześniejszej eksploatacji, poza działaniami badacza, który zgłosił problem. Jednak w ramach działań zapobiegawczych wymieniono wszystkie klucze szyfrujące i dane uwierzytelniające, które mogły zostać naruszone.
Wspomniano, że podatny na atak jest serwer GitHub Enterprise Server (GHES), jednak wykorzystanie tej luki wymaga uwierzytelnionego użytkownika z rolą właściciela organizacji, który musi zalogować się na konto na instancji GHES, co ogranicza potencjalne wykorzystanie luki.
Luka ta występuje również w GitHub Enterprise Server (GHES). Jednak exploit wymaga, aby uwierzytelniony użytkownik z rolą właściciela organizacji zalogował się na konto w instancji GHES, co stanowi ważny zestaw okoliczności łagodzących w przypadku potencjalnego exploita. Łatka jest dostępna dzisiaj, 16 stycznia 2024 r., dla wersji GHES 3.8.13, 3.9.8, 3.10.5 i 3.11.3. Zalecamy, aby klienci GHES zastosowali łatkę tak szybko, jak to możliwe.
Zmiana poświadczeń w naszych systemach produkcyjnych spowodowała serię przerw w świadczeniu usług w dniach 27–29 grudnia. Zdajemy sobie sprawę z wpływu, jaki wywarły one na naszych klientów, którzy polegają na GitHubie, i ulepszyliśmy nasze procedury rotacji danych uwierzytelniających, aby zmniejszyć ryzyko nieplanowanych przestojów w przyszłości.
Warto wspomnieć, że luka została naprawiona w serwisie GitHub, a aktualizacja produktu została wydana dla GHES w wersjach 3.8.13, 3.9.8, 3.10.5 i 3.11.3. GitHub określił lukę w GHES jako przypadek „niebezpiecznego użycia odbicia”, co stwarza ryzyko wstrzyknięcia odbicia i zdalnego wykonania kodu (ponieważ ten typ luki prowadzi do wykonania kodu lub metod kontrolowanych przez użytkownika po stronie serwera).
Wymiana tych wewnętrznych kluczy spowodowała przerwę w działaniu niektórych usług w dniach od 27 do 29 grudnia. Administratorzy GitHub starali się wyciągnąć wnioski z błędów popełnionych podczas aktualizacji kluczy, które dotknęły klientów.
Wśród podjętych działań znalazła się aktualizacja prywatnego klucza podpisywania commitów GPG GitHub, używanego do podpisywania commitów utworzonych w GitHubie. Dotyczy to commitów utworzonych w edytorze internetowym, za pośrednictwem przestrzeni kodu, za pośrednictwem wiersza poleceń w przestrzeni kodu lub poprzez operacje pull request lub Codespace. Stary klucz wygasł 16 stycznia, a od tego czasu używany jest nowy. Od 23 stycznia wszystkie nowe commity podpisane starym kluczem nie będą oznaczane jako zweryfikowane w GitHubie. Klucze publiczne używane do szyfrowania danych użytkowników przesyłanych przez API do GitHub Actions, GitHub Codespaces i Dependabot również zostały zaktualizowane 16 stycznia.
Dodatkowo użytkownikom, którzy używają publicznych kluczy GitHub do lokalnej weryfikacji zatwierdzeń i szyfrowania przesyłanych danych, zaleca się aktualizację kluczy GPG GitHub, aby ich systemy mogły nadal działać po zmianie kluczy.
Jeśli chcesz dowiedzieć się więcej, szczegóły znajdziesz pod poniższym linkiem.