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

4

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:

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:

Location of vulnerable GitLab instances

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!

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

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

  1. Avatar amedeo lanza
    amedeo lanza

    Ti preoccupi della sicurezza in ambienti evoluti ma tanti non se ne preoccupano neanche per cose ultrabanali; questo è il contenuto del crontab per un ambiente clonato dalla produzione per mettere su un sistema di staging:

    5 5 * * * /usr/bin/curl -L -m 300 -s "https://www.***.**/***-***/?inizializza=true" &>/dev null
    10 5 * * * /usr/bin/curl -L -m 300 -s"https://www.***.**/***-***/?elaborazione=add" &>/dev/null
    20 5 * * * /usr/bin/curl -L -m 300 -s "https://www.***.**/***-***/?mode=live&limit=10000" &>/dev/null

    capisco che sia leggermente fuori tema ma non posso sfogarmi insultando ferocemente il cliente (nota: l’url punta al sistema di produzione e l’applicazione è sviluppata con un framework che permette piuttosto facilmente la creazione di comandi CLI e la gestione di code)

  2. Avatar Raoul Scarazzini

    Beh ma questo è un capolavoro, altro che l’esorcista! Tra l’altro la chicca del /dev/null è spettacolare 😀

  3. Avatar amedeo lanza
    amedeo lanza

    Tra l’altro la chicca del /dev/null è spettacolare

    Tanto i log non si sognano di andarli a vedere come neanche a ripulire. Si sono accorti solo ieri che un export di ordini (che val al sistema centrale per la gestione amministrativa e le spedizioni) scarta degli ordini perché sul db mancano dei dati. La cosa succede dal 25 ottobre e avevo già avvisato della presenza di segnalazioni anomale nei log ma nessuno si è degnato di indagare.

    Mi viene spesso voglia di scrivere un articolo sulle minchiate incontrate in tanti anni di questo lavoro, magari lo preparo e te lo spedisco.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *