thegaminggallifreyan/liberationplay-cve-2025-24132-airbourne-pocPOC per CVE-2025-24132 (AirBourne). Attualmente innesca solo l'overflow e provoca un crash.
POC per CVE-2025-24132 (AirBourne). Attualmente si limita a innescare l'overflow e causare un crash.
Nel tentativo di ottenere accesso root all'unità principale della mia auto, ho ricercato e compilato tutto ciò che ho imparato sull'exploit Airplay CVE-2025-24132 (chiamato Airbourne) scoperto da Oligo Security.
https://www.oligo.security/blog/airborne
Questo è il mio primo progetto di reverse engineering. Mi sono lanciato senza aver mai usato un debugger, con pochissima esperienza in Linux e programmazione, e senza aver mai toccato MacOS fino a metà del progetto. Forse avrei dovuto iniziare con qualche CTF... Vabbè. Ci ho lavorato sporadicamente negli ultimi mesi solo per vedere se fossi in grado di farcela.
Ci sono voluti diversi mesi per ottenere una copia vulnerabile e una corretta (patch) di un binario da confrontare (diff), e poi un altro mese per farli effettivamente funzionare in un emulatore.
Ma a quanto pare, il codice vulnerabile è impossibile da raggiungere in un emulatore, poiché richiede la comunicazione con un chip MFi fisico sulla scheda logica. Dopo aver lottato per 2 mesi chiedendomi perché non riuscissi a raggiungere l'overflow e poi aver capito il problema, sono riuscito a cannibalizzare abbastanza il binario eliminando (patch) i controlli delle risposte del chip MFi e riempiendo ciò che avrebbe dovuto restituire con dati spazzatura. Questo mi ha permesso finalmente di raggiungere l'overflow e capirne abbastanza da causare un crash su un sistema reale.
L'overflow esiste all'interno della gestione della crittografia AES CTR. La dimensione della chiave di crittografia passata in un pacchetto SETUP non viene controllata e si presuppone sia 16, e viene creato un buffer di 16.
Questi crash sono appena percettibili, poiché il server di solito si riavvia immediatamente e si riconnette, risultando solo in una breve perdita audio o qualche secondo di schermo nero su un sistema CarPlay. Non sono ancora riuscito a capire come viene divulgata (leaked) la memoria, quindi al momento ciò è fattibile solo su dispositivi con protezioni dello stack disabilitate.
Trovare un modo per divulgare la memoria per bypassare le protezioni dello stack.
Funziona contro unità CarPlay o AirPlay che non richiedono alcun tipo di autorizzazione. Se è richiesto un PIN per l'accoppiamento iniziale, questo non funzionerà poiché sono coinvolti ulteriori passaggi di accoppiamento non implementati.
Per dispositivi basati su Bluetooth, per evitare di dover fare tutte le seccature di capire l'accoppiamento Bluetooth, puoi invece semplicemente scaricare un'app come Pyto ed eseguire lo script direttamente dal telefono come ho fatto io. Molto più facile.
Aggiungerò qui i dispositivi noti corretti (patch) man mano che li scopro.
Tutti i ricevitori AV Onkyo che supportano Airplay dovrebbero essere vulnerabili a questo. La mia unità di test è stata un TX-NR656 che non ha alcuna protezione dello stack.
Le unità Creston DM-NAX-8ZSA con firmware precedente alla 3.1 sono vulnerabili e non hanno canary, ma il processo Airplay viene eseguito in un contenitore.
Le unità principali Kia CCNC hanno una corretta protezione dello stack e finora non sono riuscito a superarla, ma secondo i log di sistema, carplayserver viene eseguito come root.
