Gli aggressori possono eseguire comandi del sistema operativo in remoto sfruttando questa vulnerabilità di GitLab

Sembra che non importa quanto le aziende siano disposte a spingersi per proteggere i loro prodotti, gli aggressori sono sempre un passo avanti e trovano modi ingegnosi per aggirare ogni protezione.

In questo mondo online in continua evoluzione, proteggere i tuoi dati sensibili sta diventando sempre più difficile e siamo qui per parlarvi di un'altra vulnerabilità che viene attivamente sfruttata in la selvaggia.

Un'altra vulnerabilità di GitLab attivamente sfruttata in natura

Secondo HN Security, sono stati trovati due account utente sospetti con diritti di amministratore sul server GitLab CE esposto a Internet.

A quanto pare, questi due utenti sono stati registrati tra giugno e luglio 2021, con nomi utente dall'aspetto casuale. Ciò è stato possibile perché questa versione di GitLab CE consente la registrazione dell'utente per impostazione predefinita.

Inoltre, l'indirizzo email fornito durante la registrazione non è verificato per impostazione predefinita. Ciò significa che l'utente appena creato viene automaticamente connesso senza ulteriori passaggi.

Per rendere le cose più complicate, agli amministratori non vengono inviate assolutamente notifiche.

Uno degli allegati caricati ha attirato l'attenzione degli esperti, quindi hanno creato il proprio server GitLab e hanno effettivamente tentato di replicare ciò che hanno osservato in natura.

Un exploit rilasciato di recente per CVE-2021-22205 abusa della funzionalità di caricamento per eseguire in remoto comandi del sistema operativo arbitrari.

La suddetta vulnerabilità risiede in ExifTool, uno strumento open source utilizzato per rimuovere i metadati dalle immagini, che non riesce ad analizzare determinati metadati incorporati nell'immagine caricata.

GitLab è composto da più elementi, come Redis e Nginx. Quello che gestisce i caricamenti si chiama gitlab-workhorse, che a sua volta chiama ExifTool prima di passare l'allegato finale a Rails.

Scavando più a fondo nei registri, sono state scoperte alcune prove di due caricamenti non riusciti all'interno dei registri di Workhorse.

Questo payload utilizzato dall'exploit pubblico può eseguire una shell inversa, mentre quello utilizzato contro il nostro cliente ha semplicemente aumentato i diritti di amministratore dei due utenti precedentemente registrati.

echo 'utente = Utente.find_by (nome utente: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | console gitlab-rails /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails console

Quindi, fondamentalmente, quella che sembrava essere una vulnerabilità di escalation dei privilegi si è rivelata in realtà una vulnerabilità RCE.

Come hanno spiegato gli esperti di sicurezza, l'intero processo di sfruttamento si riduce a due sole richieste.

Su un'installazione GitLab predefinita (fino alla versione 13.10.2) non è necessario abusare dell'API per trovare un progetto valido, non è necessario aprire un problema e, soprattutto non c'è bisogno di autenticarsi.

Tutte le vulnerabilità descritte nell'articolo (ExifTool, abuso API, registrazione utente, ecc.) non sono presenti nell'ultima versione di GitLab CE al momento della stesura.

Tuttavia, consigliamo vivamente di prestare attenzione quando si ha a che fare con tutto ciò che implica la tua presenza online, in modo da non avere esperienze sfortunate.

Qual è la tua opinione su questa situazione? Condividi la tua opinione con noi nella sezione commenti qui sotto.