Pegasus iOS exploit e Kernel Memory Corruption

5

Al momento sto leggendo su Pegasus, il malware su iOS che utilizza 3 giorni zero, nel Blog di Lookout.

Post del blog su Pegasus

Sono uno studente di cs nel primo anno e capisco che il malware ha bisogno di accedere ai privilegi del kernel per ottenere il pieno controllo del sistema, ma non capisco come funziona il processo. Sono davvero curioso e ho pensato di specializzarmi in Information Security più avanti nei miei studi.

In particolare:

  1. In che modo Pegasus (che sta funzionando con parsimonia su un sito Web in qualche modo? Mi dispiace, non ho mai fatto lo sviluppo web) da Safari nel kernel? Usa codice javascript dannoso o come dovrei immaginarlo? Quindi, come corrompe la memoria del webkit e perché mi dà quella posizione di memoria?

  2. Perché è sbagliato che un programma / un utente malintenzionato conosca la posizione di memoria del kernel? Pensavo che la memoria del kernel fosse protetta?

  3. In che modo la corruzione della memoria del kernel porta al jailbreak? La corruzione della memoria, per quanto ho capito, sta semplicemente annullando la memoria che viene usata da un altro programma, giusto? Perché il kernel dovrebbe eseguire il nuovo codice nella posizione di memoria?

Grazie in anticipo!

    
posta Seen 26.08.2016 - 22:20
fonte

1 risposta

5

L'exploit utilizza una combinazione di tre vulnerabilità. Ogni vulnerabilità è un bug in un componente iOS che consente all'aggressore di fare cose che non dovrebbero essere possibili.

Lo stage 1 ( CVE-2016-4657 ) è un bug in WebKit , una libreria di codice utilizzata per il rendering di pagine Web. Il codice WebKit viene eseguito nel contesto del browser web Safari di iOS. Nessun dettaglio è stato ancora rilasciato, solo la descrizione come "problema di corruzione della memoria è stata affrontata attraverso una migliore gestione della memoria". Potrebbe trattarsi di un overflow del buffer , un use-after-free , o qualche altro tipo di bug simile. L'idea generale dei bug di corruzione della memoria è che l'utente malintenzionato trasmetta dati inconsistenti (qui, alcuni contenuti di pagine Web - potrebbe essere HTML, CSS, JavaScript, ecc.) E invece di rilevare l'incoerenza il programma si comporta in modo incoerente e finisce per sovrascrivere alcune delle sue istruzioni con i dati forniti dall'attaccante. Ciò consente all'autore dell'attacco di eseguire il codice di propria scelta in Safari.

Lo stage 3 ( CVE-2016-4656 ) è anch'esso un bug di corruzione della memoria su cui non sono stati rilasciati dettagli, ma questa volta nel kernel. Questo bug permette a un'applicazione iOS di corrompere alcune strutture dati nel kernel e di eseguire codice nel kernel o (presumo che abbia la descrizione) almeno elevare i privilegi dell'applicazione chiamante in modo che possa fare cose che le applicazioni non dovrebbero fare, come installare programmi che ignorano le normali autorizzazioni iOS e quindi consentire ad es installazione di spyware che non verranno mostrati nell'elenco delle applicazioni installate perché si mascherano come parte del sistema operativo di base.

Lo stage 2 ( CVE-2016-4655 ) è un abilitatore per lo stage 3. Normalmente non dovrebbe importare che il programma sappia come il kernel mappa la sua memoria. E se l'attaccante è in grado di far eseguire al kernel codice arbitrario, il gioco viene perso. Ma può succedere (e questo è probabilmente il caso qui) che l'attaccante non abbia molto spazio in cui giocare. Per esempio, forse c'è un controllo delle dimensioni che è presente ma leggermente fuori, quindi l'attaccante è in grado di sovrascrivere solo pochi byte dopo il luogo in cui si trovano i dati iniettati. In questi casi, l'utente malintenzionato potrebbe aver bisogno di sapere esattamente cosa mettere in quella posizione, altrimenti non sarà in grado di causare effetti interessanti. Se il percorso che possono sovrascrivere è un puntatore, devono sapere cosa mettere lì per far sì che il kernel usi dati validi ma sbagliati, piuttosto che un puntatore non valido che causerebbe solo un arresto anomalo. Ad esempio, modificare un puntatore a un elenco di funzionalità all'indirizzo di un luogo in memoria che è noto per contenere ciò che sembra un elenco contenente alcune funzionalità di sistema chiave. Per questo, sapere dove il kernel mappa i suoi dati permette all'aggressore di calcolare il giusto valore del puntatore.

Per essere chiari, sto solo dando esempi di metodi di attacco plausibili che si adattano alle descrizioni di una linea che sono state rilasciate in questo momento.

Il modo migliore per avere un'idea di come funziona è scrivere da sé qualche exploit. Ottieni alcune vecchie versioni del software (preferibilmente open-source) con vulnerabilità sfruttabili conosciute , e vai e scrivi un exploit. Potresti anche voler riprodurre alcuni CTF .

    
risposta data 26.08.2016 - 23:42
fonte

Leggi altre domande sui tag