Tempesta perfetta su GitHub, GitLab e Jenkins. Si può fare CI senza preoccuparsi della sicurezza? Spoiler: no!

Cos’hanno in comune GitHub, GitLab e Jenkins? Come dite? Il fatto di essere piattaforme che consentono di configurare e gestire la Continuous Integration? Vero, ma hanno anche in comune un’altra cosa: alcuni problemi di sicurezza.

Perché quindi non cominciare la settimana con un po’ di sano allarmismo? In fondo ci piace anche così! Ecco quindi le notizie, curiosamente emerse tutte nell’ultima settimana, che riguardano la sicurezza dei tre attori citati nel titolo dell’articolo.

Si parte con GitHub, la piattaforma proprietà di Microsoft si è trovata costretta a ruotare le proprie chiavi di accesso (un’azione che non è propriamente un inedito, e che avevamo raccontato lo scorso aprile) per via di una poco entusiasmante vulnerabilità che è stata risolta, ma che ha imposto l’azione descritta:

We received a bug bounty report of a vulnerability which, if exploited, allowed access to credentials within a production container. We have patched https://t.co/0iKPk2jtk4 and rotated all affected credentials, and patches for GHES are available today. https://t.co/5youY6yNTA

— GitHub Security (@GitHubSecurity) January 16, 2024

Come recita l’articolo:

We strongly recommend regularly pulling the public keys from the API to ensure you’re using the most current data from GitHub. This will also allow for seamless adoption of new keys in the future

Raccomandiamo caldamente di scaricare le chiavi pubbliche dalle API per essere certi di utilizzare i dati di GitHub più aggiornati possibili. Questo ci assicurerà anche di poter adottare con più facilità nuove chiavi in futuro

Quindi, non fosse chiaro, se operate quotidianamente su GitHub, scaricate le nuove chiavi per poter serenamente continuare ad usare i servizi di GitHub.

Non se la passa meglio GitLab la cui piattaforma è stata identificata come vittima di una vulnerabilità (CVE-2023-7028) il cui peso è un tantinello alto: 10 punti su 10, il più grave, tanto da catalogare la vulnerabilità come zero-click account takeover.

L’impatto del problema è letteralmente globale, come mostra questo schema pubblicato nell’articolo che descrive la vicenda di Bleeping Computer:

Nonostante le fix siano già state pubblicate l’11 di gennaio la situazione, come si evince da qui sopra, è decisamente drammatica.

Se siete utilizzatori di GitLab un update è ampiamente consigliato, anche se il problema non riguarda quanti utilizzano l’autenticazione a due fattori.

Chiudiamo in bellezza con la CVE-2024-23897 che invece riguarda Jenkins, e che sostanzialmente è un exploit attivabile mediante code injection, per l’esecuzione di binari il cui limite in termini di pericolosità è rappresentato unicamente dalla fantasia.

Ecco alcuni esempi raccontati da Hacker News che non traduciamo semplicemente perché non c’è bisogno:

• Remote code execution via Resource Root URLs
• Remote code execution via “Remember me” cookie
• Remote code execution via stored cross-site scripting (XSS) attacks through build logs
• Remote code execution via CSRF protection bypass
• Decrypt secrets stored in Jenkins
• Delete any item in Jenkins
• Download a Java heap dump

Insomma, la vostra piattaforma di CI – qualsiasi essa sia – potrebbe avere un problema, state allerta!