In un’aspettata mossa di estrema apertura, gli ingegneri di CFEngine hanno -forse- osato un po’ troppo nei dettagli della spiegazione di un bug di sicurezza molto grave nel loro prodotto Enterprise.
Facciamo un passo indietro: CFEngine è un software di configuration management ed automazione decentralizzato, alternativa a Puppet o Ansible (di cui più spesso parliamo in queste pagine). I problemi di sicurezza su questi software sono molto critici poichè, data la natura stessa dei Configuration Management di controllare l’intera infrastruttura, una falla in essi si può tradurre -nel peggiore dei casi- in una possibile violazione dell’intera infrastruttura che gestiscono.
Questa falla nel loro prodotto Enterprise, già identificata e di cui compensative e patch sono già state condivise, riguarda l’uso di particolari password interne per la connessione alle Mission Portal API (le API che controllano i task infrastrutturali) ed al database PostgreSQL interno:
CFEngine is using some internal secrets for authentication to the Mission Portal API and the PostgreSQL database when running background maintenance tasks. These internal secrets are randomly generated during the installation process and stored in files only the root user can access.
CFEngine utilizza alcuni secrets interni per l’autenticazione alle Mission Portal API ed al database PostgreSQL quando esegue operazioni di manutenzione in background. Questi secrets interni vengono generati durante il processo di installazione e salvati in file cui solo root ha accesso.
Fin qui tutto bene, il comportamento del software può avere un senso e, comunque, se un malintenzionato riesce ad avere accesso di root alla macchina per poter leggere questi file, è già troppo tardi.
Il problema sorge dopo, quando viene spiegato che recentemente i propri ingegneri hanno scoperto che i comandi che generano e salvano questi secrets loggano il tutto nel file /var/log/CFEngineHub-Install.log; file leggibile da chiunque faccia login sull’host hub, indipendentemente dal livello di permessi assegnati.
Dopo aver spiegato quindi che fondamentalmente è possibile per chiunque sia loggato leggere i comandi per generare questi secrets (e, questo, comporta l’ottenere i secrets stessi), assicurano che questo funzionamento è solo per l’host hub e che i diversi agent non soffrono di questo problema non utilizzando affatto queste “password”. Peccato che altri dettagli, come il nome esatto di un utente interno del sistema, vengano poi tranquillamente comunicati:
The internal CFE_ROBOT Mission Portal user has the admin role and logging in to Mission Portal or authenticating to the API as this user would allow an attacker to carry a range of very bad things
L’utente interno del Mission Portal CFE_ROBOT ha il ruolo di amministratore e loggarsi nel Mission Portal o autenticarsi alle API con questo utente permette all’attaccante di eseguire parecchie cose brutte.
Giusto per fare un esempio, quell’utente potrebbe aggiungere/modificare/cancellare utenti o modificare la configurazione del sistema di controllo versione e distribuire a tutti gli host avviati dall’hub infettato le policy che preferisce.
La soluzione più rapida è quella di rigenerare i secrets tramite uno script fornito, ma è stata già resa disponibile una patch che esegue l’operazione evitando di lasciare in giro in file di log informazioni troppo sensibili. Entrambe le soluzioni sono disponibili nel blog in cui si parla della vulnerabilità.
Sicuramente la mossa denota lo spirito di trasparenza che l’azienda vuole dare ma, nonostante sia comune avere CVE fornite insieme a paper molto dettagliati su come sfruttare la falla indicata, l’estrema semplicità di sfruttamento del bug, il fatto che si applichi ad un prodotto Enterprise, e che permetta di prendere il controllo di un’intera infrastruttura, fa pensare che forse un pochino di riserbo sarebbe stato più indicato (magari comunicando pubblicamente la vulnerabilità ed i dettagli su come sfruttarla ai soli acquirenti del software in versione Enterprise vulnerabile).
Voi che ne pensate?
Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.
Lascia un commento