Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podsumowanie

CVE-2024-28080 to obejście uwierzytelniania w wbudowanej usłudze SSH Gitblit, spowodowane nieprawidłowym zarządzaniem stanem sesji przy integracji z Apache MINA SSHD. Jeśli konto użytkownika ma zarejestrowany co najmniej jeden publiczny klucz SSH, atakujący, który zna nazwę użytkownika oraz którykolwiek z publicznych kluczy tego użytkownika, może się uwierzytelnić bez prywatnego klucza i bez hasła.

  • Dotknięte: Gitblit < 1.10.0 (zaobserwowane w 1.9.3)
  • Naprawione: 1.10.0
  • Wymagania do exploitu:
  • Git over SSH włączony na instancji
  • Konto ofiary ma zarejestrowany co najmniej jeden publiczny klucz SSH w Gitblit
  • Atakujący zna nazwę użytkownika ofiary oraz jeden z jej publicznych kluczy (często możliwe do znalezienia, np. https://github.com/.keys)

Przyczyna (state leaks between SSH methods)

W RFC 4252 uwierzytelnianie przy użyciu klucza publicznego przebiega w dwóch fazach: serwer najpierw sprawdza, czy podany klucz publiczny jest akceptowalny dla danej nazwy użytkownika, a dopiero po challenge/response z podpisem uwierzytelnia użytkownika. W MINA SSHD, PublickeyAuthenticator jest wywoływany dwukrotnie: przy akceptacji klucza (jeszcze bez podpisu) oraz później, gdy klient zwraca podpis.

PublickeyAuthenticator Gitblit zmodyfikował kontekst sesji podczas pierwszego, przed‑podpisem wywołania przez powiązanie uwierzytelnionego UserModel z sesją i zwracanie true (“key acceptable”). Gdy uwierzytelnianie później przechodziło do hasła, PasswordAuthenticator zaufał temu zmodyfikowanemu stanowi sesji i przerwał proces, zwracając true bez weryfikacji hasła. W efekcie dowolne hasło (w tym puste) było akceptowane po wcześniejszej public‑key “acceptance” dla tego samego użytkownika.

Ogólny, wadliwy przebieg:

  1. Klient oferuje username + public key (jeszcze bez podpisu)
  2. Serwer rozpoznaje, że klucz należy do użytkownika i przedwcześnie przypisuje użytkownika do sesji, zwraca true (“acceptable”)
  3. Klient nie może podpisać (brak prywatnego klucza), więc uwierzytelnianie przechodzi do hasła
  4. Uwierzytelnianie hasłem widzi, że użytkownik jest już obecny w sesji i bezwarunkowo zwraca sukces

Eksploatacja krok po kroku

  • Zbierz nazwę użytkownika ofiary i jeden z jej kluczy publicznych:
  • GitHub udostępnia publiczne klucze pod adresem https://github.com/.keys
  • Serwery publiczne często udostępniają authorized_keys
  • Skonfiguruj OpenSSH tak, aby prezentował tylko część publiczną (bez prywatnej), tak aby generowanie podpisu się nie powiodło, wymuszając powrót do hasła, a jednocześnie wywołując ścieżkę akceptacji klucza publicznego na serwerze.

Przykładowa konfiguracja klienta SSH (brak dostępnego prywatnego klucza):

# ~/.ssh/config
Host gitblit-target
HostName <host-or-ip>
User <victim-username>
PubkeyAuthentication yes
PreferredAuthentications publickey,password
IdentitiesOnly yes
IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)

Połącz się i naciśnij Enter przy monicie o hasło (lub wpisz dowolny ciąg):

ssh gitblit-target
# or Git over SSH
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>

Uwierzytelnianie powiodło się, ponieważ wcześniejsza faza public‑key zmieniła stan session na uwierzytelnionego użytkownika, a password auth błędnie ufa temu stanowi.

Uwaga: Jeśli w konfiguracji SSH włączono ControlMaster multiplexing, kolejne polecenia Git mogą ponownie użyć uwierzytelnionego połączenia, zwiększając wpływ.

Impact

  • Pełne podszycie się pod dowolnego użytkownika Gitblit, który ma co najmniej jeden zarejestrowany SSH public key
  • Dostęp do odczytu/zapisu do repozytoriów zgodnie z uprawnieniami ofiary (eksfiltracja źródła, nieautoryzowane pushes, supply‑chain risks)
  • Możliwy wpływ administracyjny przy ataku na konto administratora
  • Czysty exploit sieciowy; nie wymaga brute force ani private key

Detection ideas

  • Przejrzyj logi SSH w poszukiwaniu sekwencji, w których próba publickey jest następowana przez udane uwierzytelnienie password z pustym lub bardzo krótkim hasłem
  • Szukaj przepływów: metoda publickey oferująca nieobsługiwany/niepasujący materiał klucza, po którym następuje natychmiastowe powodzenie password dla tej samej nazwy użytkownika

Mitigations

  • Zaktualizuj do Gitblit v1.10.0+
  • Do czasu aktualizacji:
  • Wyłącz Git over SSH na Gitblit, lub
  • Ogranicz dostęp sieciowy do usługi SSH, oraz
  • Monitoruj w poszukiwaniu opisanych powyżej podejrzanych wzorców
  • Rotuj dane uwierzytelniające dotkniętych użytkowników, jeśli podejrzewa się kompromitację

General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Wzorzec: Jeśli public‑key authenticator serwera modyfikuje user/session state podczas etapu pre‑signature “key acceptable”, a inne authenticatory (np. password) ufają temu stanowi, można obejść uwierzytelnianie przez:

  • Prezentowanie legalnego public key dla docelowego użytkownika (bez private key)
  • Wymuszenie, by klient nie podpisał, tak że serwer przechodzi do password
  • Podanie dowolnego hasła, podczas gdy password authenticator przerywa procedurę z powodu leaked state

Praktyczne wskazówki:

  • Public key harvesting at scale: pobieraj public keys z powszechnych źródeł takich jak https://github.com/.keys, katalogi organizacji, strony zespołów, leaked authorized_keys
  • Forcing signature failure (client‑side): ustaw IdentityFile tylko na .pub, ustaw IdentitiesOnly yes, zachowaj PreferredAuthentications tak, by zawierało publickey a następnie password
  • MINA SSHD integration pitfalls:
  • PublickeyAuthenticator.authenticate(…) nie powinien przyłączać user/session state dopóki ścieżka weryfikacji po podpisie nie potwierdzi podpisu
  • PasswordAuthenticator.authenticate(…) nie powinien wywnioskowywać sukcesu na podstawie jakiegokolwiek stanu zmodyfikowanego podczas wcześniejszej, niekompletnej metody uwierzytelniania

Powiązane uwagi protokołu/projektowe i literatura:

  • SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
  • Historyczne dyskusje na temat early acceptance oracles i auth races, np. spory wokół CVE‑2016‑20012 dotyczące zachowania OpenSSH

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks