Vista la nuova vulnerabilità critica di account-bypass appena scoperta e classificata come CVE-2023-7028, gli amministratori di GitLab dovrebbero applicare subito l’ultima serie di patch di sicurezza. La vulnerabilità è considerata molto grave sfrutta una modifica introdotta nella versione 16.1.0 nel maggio 2023, che consente agli utenti di inviare la password di ripristino attraverso un indirizzo e-mail secondario.

Gli aggressori che prendono di mira le istanze GitLab autogestite vulnerabili potrebbero utilizzare una richiesta HTTP appositamente creata per inviare un’e-mail di reimpostazione della password a un indirizzo e-mail non verificato e controllato dall’aggressore, che può così completare l’acquisizione senza alcun intervento da parte dell’utente; chi non ha abilitato l’autenticazione a due fattori (2FA) è il primo bersaglio di questo attacco.

Gli utenti con 2FA abilitata non sono vulnerabili all’acquisizione dell’account, a meno che l’aggressore non abbia anche il controllo dell’autenticatore 2FA, ma è comunque possibile reimpostare la password. GitLab non supporta il 2FA basato su SMS ma quello su app o emesso tramite un dispositivo WebAuthn, che sono molto più sicuri.

Tuttavia, le seguenti versioni delle edizioni Community ed Enterprise di GitLab sono state colpite e richiederanno una patch il prima possibile:

  • Da 16.1 a 16.1.5
  • Da 16.2 a 16.2.8
  • Da 16.3 a 16.3.6
  • Da 16.4 a 16.4.4
  • Da 16.5 a 16.5.5
  • Da 16.6 a 16.6.3
  • Da 16.7 a 16.7.1

vulnerabilità github

Secondo GitLab, sono interessati tutti i meccanismi di autenticazione, anche alcuni di quelli che utilizzano il single sign-on (SSO). “Gli utenti che non utilizzano l’SSO sono vulnerabili”, afferma GitLab. “Se la vostra configurazione consente l’uso di un nome utente e di una password oltre alle opzioni SSO, siete vulnerabili. La disabilitazione di tutte le opzioni di autenticazione con password tramite https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#password-authentication-enabled mitigherà la vulnerabilità per i clienti autogestiti che hanno configurato un fornitore di identità esterno, in quanto ciò disabiliterà la possibilità di eseguire il reset della password”.

Al momento non ci sono prove che la vulnerabilità sia stata sfruttata con successo, ma quando una vulnerabilità viene resa pubblica, con un exploit semplice come questo, è probabile che si verifichino tentativi di sfruttamento più ampi e diventa una corsa contro gli aggressori per applicare la patch alla falla. Visto che amministratori avranno bisogno di tempo per applicare le patch, una soluzione provvisoria più rapida sarebbe quella di imporre il 2FA su tutti gli account, che nella maggior parte dei casi ne impedirà i tentativi di acquisizione.

Nel frattempo GitLab ha dichiarato che i clienti possono controllare i loro log alla ricerca di segni di sfruttamento, evidenziandone due:

  • Controllare gitlab-rails/production_json.log per le richieste HTTP al percorso /users/password con params.value.email costituito da un array JSON con più indirizzi e-mail
  • Controllare gitlab-rails/audit_json.log per le voci con meta.caller_id di PasswordsController#create e target_details costituito da un array JSON con più indirizzi email

Da quando la vulnerabilità è stata portata all’attenzione di GitLab tramite il suo programma di bug bounty, l’azienda ha aggiunto nuovi test per convalidare la logica di reimpostazione della password per evitare che vulnerabilità simili si verifichino in futuro. Nella stessa serie di patch è stata affrontata anche una seconda vulnerabilità critica (CVE-2023-5356), alla quale è stato assegnato un punteggio CVSS 9.6 e che consente agli aggressori di eseguire comandi slash in Slack o Mattermost. Anche se non è grave come un’acquisizione di account, un exploit riuscito potrebbe dare agli aggressori la possibilità di aggiungersi ai canali, esponendo potenzialmente il lavoro segreto di un’organizzazione a parti non autorizzate.