Un bug senza patch nel repo-server di Argo CD potrebbe esporre i cluster Kubernetes alla presa di controllo

I ricercatori di sicurezza affermano che una vulnerabilità senza patch nel componente repo-server di Argo CD potrebbe consentire a un attaccante di eseguire codice e potenzialmente assumere il controllo di un cluster Kubernetes, purché riesca a raggiungere il servizio sulla rete interna.

Il problema è stato identificato da Synacktiv, che ha dichiarato di averlo segnalato ai manutentori di Argo CD nel gennaio 2025. Dopo aver atteso circa 18 mesi senza una correzione né l’assegnazione di un identificativo CVE, l’azienda ha divulgato i risultati per avvisare gli utenti. Secondo la sua analisi, la debolezza interessa l’interfaccia gRPC del repo-server, che non richiede autenticazione.

Come funziona l’attacco

Argo CD utilizza repo-server per recuperare repository Git e generare manifest Kubernetes. Synacktiv ha scoperto che è possibile creare una richiesta non autenticata al servizio GenerateManifest in modo da istruire kustomize a invocare uno script proveniente da un repository controllato dall’attaccante anziché il binario Helm previsto. Quando il servizio elabora la richiesta, lo script viene eseguito.

L’esposizione dipende in larga misura dalla raggiungibilità della rete. Argo CD offre policy di rete Kubernetes progettate per isolare repo-server e Redis dal resto del cluster, ma Synacktiv osserva che l’installazione comune basata su Helm lascia queste protezioni disabilitate per impostazione predefinita. In questa configurazione, un pod compromesso presente altrove nel cluster potrebbe riuscire a contattare repo-server e attivare la vulnerabilità.

Perché l’impatto è grave

Ottenere l’esecuzione di codice su repo-server può essere sufficiente per penetrare ulteriormente nell’ambiente. Synacktiv ha dimostrato che un attaccante potrebbe leggere la password Redis dall’ambiente del componente, connettersi alla cache Redis di Argo CD e modificare i dati di deployment memorizzati. Al ciclo di sincronizzazione successivo, Argo CD distribuirebbe contenuti forniti dall’attaccante.

I ricercatori hanno affermato che questo riapre anche lo schema di rischio alla base di CVE-2024-31989, un problema precedente in cui protezioni Redis deboli consentivano a un pod di avvelenare lo stato del deployment. Sebbene Argo CD abbia successivamente aggiunto una password Redis, i dati della cache non sono firmati crittograficamente; pertanto, i segreti esposti dal servizio in esecuzione possono ancora essere sfruttati.

Cosa dovrebbero fare gli amministratori

• Abilitare le policy di rete Kubernetes per i componenti di Argo CD, in particolare repo-server e Redis.
• Verificare le protezioni con kubectl get networkpolicy -A.
• Confermare che le policy previste siano presenti in ogni namespace utilizzato da Argo CD.

Synacktiv ha dichiarato di aver creato uno strumento di attacco chiamato argo-cdown, ma sta rimandandone la pubblicazione per concedere ai difensori il tempo di mettere in sicurezza le proprie distribuzioni. Fino a quando non sarà disponibile una patch, l’azienda raccomanda di considerare la rete del cluster non attendibile e di limitare l’accesso il più possibile.