dilan-diaz/point-to-point-protocol-daemon-rce-vulnerability-cve-2020-8597-
Sri Lanka Institute of Information Technology
Compito 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
Point to Point Protocol Daemon RCE
Vulnerabilità (CVE-2020-8597)
Programmazione di Sistemi e Reti – IE2012
Contenuto
Introduzione
Il Point-to-Point Protocol (PPP) è un protocollo full-duplex che consente di incapsulare e distribuire dati semplici attraverso infrastrutture di Livello 2 o data-link che spaziano dalla connettività dial-up alla banda larga DSL, fino alle reti private virtuali (VPN) che incorporano la crittografia SSL. Poiché questi protocolli non consentono comunicazioni punto-punto, PPP viene utilizzato anche per instradare IP e TCP su due nodi direttamente connessi. Pppd è un demone utilizzato nei sistemi operativi Unix-like per gestire l'instaurazione di sessioni PPP e la terminazione delle sessioni tra due nodi.
PPP è il protocollo utilizzato per creare connessioni Internet tramite modem dial-up, connessioni DSL e diverse altre forme di connessioni punto-a-punto attraverso reti private virtuali (VPN), come il Peer to Point Tunneling Protocol (PPTP). Il programma pppd può anche autenticare un peer che si connette alla rete e/o fornire al peer i dettagli di autenticazione utilizzando vari protocolli di autenticazione come EAP.
A causa di un difetto nella gestione dei pacchetti Extensible Authentication Protocol (EAP) da parte del Point-to-Point Protocol Daemon (pppd), un attaccante remoto non autenticato può causare un overflow del buffer di stack che può consentire l'esecuzione arbitraria di codice sul sistema target. Questa debolezza è innescata da un errore nella validazione della dimensione dell'input prima di copiare i dati forniti in memoria. Poiché la validazione della dimensione dei dati è errata, dati arbitrari possono essere copiati in memoria, il che può innescare la fuga di file e contribuire a un'esecuzione di codice non intenzionale.
La debolezza risiede nella logica del codice di parsing EAP, in particolare nelle funzioni eap request() e eap response() in eap.c, chiamate da un gestore di input di rete. Queste funzioni, utilizzando il primo byte come tipo, accettano un puntatore e una lunghezza come input. Se il tipo è EAPT MD5CHAP(4), viene esaminata un'area incorporata di lunghezza 1 byte. La logica di questo codice è intesa a garantire che la durata incorporata sia inferiore alla lunghezza totale del pacchetto. Dopo questa verifica, tenta di copiare i dati forniti (hostname), che si trovano in un buffer locale dello stack dopo il campo di lunghezza incorporato. Questo controllo dei limiti non è corretto e consente la copia in memoria con una lunghezza arbitraria dei dati.
Un ulteriore errore logico fa sì che la funzione eap input() non verifichi se EAP è stato risolto durante il processo del Line Control Protocol (LCP). Ciò consente a un attaccante non autenticato di inviare un pacchetto EAP anche se ppp ha rifiutato di negoziare l'autenticazione a causa della mancanza di supporto per EAP o della non conformità con una passphrase pre-condivisa concordata nella fase LCP. In eap input, il codice pppd insicuro deve comunque elaborare il pacchetto EAP e causare l'overflow del buffer di stack. Questi dati non verificati e di dimensione sconosciuta possono essere utilizzati per compromettere la memoria del dispositivo target. Inoltre, pppd viene eseguito con privilegi elevati (system o root) e opera in tandem con i driver del kernel.
Il programma pppd è utilizzato anche con il progetto LWIP (lightweight IP) per fornire funzionalità pppd a computer di piccole dimensioni. L'installazione predefinita di lwIP non è suscettibile a questo overflow del buffer. Tuttavia, se si utilizza il codice sorgente di lwIP e lo si modifica esplicitamente per consentire EAP in fase di compilazione, il programma può essere suscettibile a un overflow del buffer.
CVE-2020-8597 è un bug di overflow del buffer in pppd dovuto a un difetto concettuale nel processore di pacchetti Extensible Authentication Protocol (EAP). Un attaccante remoto non autorizzato che invia un pacchetto EAP appositamente predisposto a un client o server PPP vulnerabile può causare una condizione di denial of service o un'esecuzione arbitraria di codice. Poiché pppd opera in tandem con i driver del kernel e dispone anche di privilegi elevati, come device o addirittura core, qualsiasi esecuzione di codice può essere eseguita con gli stessi privilegi.
Riferimenti su chi ha trovato la vulnerabilità
Scoperto dal ricercatore di sicurezza di IOActive Ilja Van Sprundel, il problema cruciale è un difetto di overflow del buffer di stack che si verifica a causa di un errore logico nel parser del modulo Extensible Authentication Protocol (EAP) delle applicazioni pppd, un'estensione che offre supporto per ulteriori metodi di autenticazione nelle connessioni PPP.
La debolezza, monitorata come CVE-2020-8597 con punteggio CVSS 9.8, può essere sfruttata da attaccanti non autorizzati per eseguire remotamente codice arbitrario sui dispositivi interessati e ottenere il controllo completo di essi.
Come è stata trovata
Questa debolezza è attribuita a un errore nella validazione della dimensione dell'input prima di trasferire i dati in memoria. Poiché la validazione della dimensione dei dati è errata, dati casuali possono essere copiati in memoria e possono innescare la frammentazione del database, contribuendo probabilmente all'esecuzione di codice non autorizzato.
La vulnerabilità si trova nella logica del codice di parsing EAP, in particolare nelle funzioni eap request() e eap response() in eap.c, che vengono chiamate dal gestore di input di rete.
È sbagliato concludere che pppd non sia insicuro se EAP non è consentito o se EAP non è stato avviato da un peer remoto tramite password o passphrase. Questo perché un intruso autenticato potrebbe essere sempre in grado di inviare un pacchetto EAP non richiesto per indurre un overflow del buffer.
La vulnerabilità è stata identificata nel daemon del Point-to-Point Protocol (PPP), o pppd. PPP è un protocollo di Livello 2 utilizzato per stabilire connessioni tramite modem dial-up, connessioni DSL e molte altre reti fisiche, incluse le reti mobili. PPP è stato incluso ed esteso per includere protocolli aggiuntivi, come il Point-to-Point Tunneling Protocol (PPTP), utilizzato nelle reti private virtuali (VPN) per fornire connessioni crittografate.
In questa situazione, il team di collaborazione SEI CERT ha collaborato con l'analista di sicurezza Ilja Van Sprundel (IOActive), che ha trovato questo difetto, e con lo sviluppatore software Paul Mackerras (OZlabs), che gestisce il codice sorgente, per esaminare facilmente il problema e trovare una soluzione. Il problema riguardava un overflow del buffer nel codice sorgente di pppd, dovuto a un overflow del buffer di base nell'espressione booleana e nell'implementazione delle istruzioni condizionali che ne derivavano. L'istruzione seguente può essere aggirata per consentire un input di lunghezza sconosciuta e copiarlo in un buffer dello stack. Questo è comunemente definito frame overload o overflow del buffer di stack.
if (vallen >= len + sizeof(rhostname)) { // Copy to buffer rhostname
La correzione per la vulnerabilità è stata semplicemente cambiare l'istruzione precedente nella logica booleana seguente.
if (len-vallen >= sizeof(rhostname)) { // Copy to buffer rhostname
Paul ha rilasciato CVE-2020-8597 per questo difetto e ha continuato a correggerlo nel codice sorgente che gestisce. L'aggiornamento di sistema necessario per correggere il bug è minimo e richiede solo poche righe di codice. Tuttavia, questa tecnologia insicura risiede in migliaia di librerie di progetti software. È stata adottata da più di 100 aziende che offrono dispositivi di accesso alla rete, dai router domestici all'hardware di rete aziendale. Poiché questa debolezza colpisce tutti i client e server PPP, colpisce anche i fornitori di servizi Internet (ISP).
Quando è stata trovata
Il 4 marzo 2020, i ricercatori del CERT Coordination Center (CERT/CC) hanno pubblicato la vulnerability note # 782301 per una vulnerabilità critica nel Point-to-Point Protocol Daemon (pppd) versioni 2.4.2 fino alla 2.4.8, con la divulgazione attribuita a Ilja van Sprundel di IOActive.
Quali danni può causare
Inviando un pacchetto EAP non richiesto a un client o server ppp vulnerabile, un intruso remoto non autorizzato può innescare una corruzione della memoria nel meccanismo pppd, che può consentire l'esecuzione arbitraria di codice.
Secondo il ricercatore, le versioni 2.4.2–2.4.8 del Point-to-Point Protocol Daemon—tutte le versioni pubblicate negli ultimi 17 anni—sono suscettibili a questo nuovo bug di esecuzione remota di codice.
Alcune delle distribuzioni Linux comunemente utilizzate e di successo elencate di seguito sono già state segnalate come colpite, e molti altri progetti sono molto probabilmente interessati anch'essi.
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
Inoltre, il numero di altre applicazioni e dispositivi suscettibili (alcuni dei quali menzionati di seguito) che includono applicazioni pppd è probabilmente vasto, offrendo un'ampia superficie di attacco per gli hacker.
Cisco CallManager TP-LINK products OpenWRT Embedded OS Synology products
A causa di un difetto nell'elaborazione dei pacchetti Extensible Authentication Protocol (EAP) nel Point-to-Point Protocol Daemon (pppd), un attaccante remoto non autenticato potrebbe causare un overflow del buffer di stack, che potrebbe consentire l'esecuzione arbitraria di codice sul sistema target. Questa vulnerabilità è dovuta a un errore nella validazione della dimensione dell'input prima di copiare i dati forniti in memoria. Poiché la validazione della dimensione dei dati non è corretta, dati arbitrari possono essere copiati in memoria e causare una corruzione della memoria, portando potenzialmente all'esecuzione di codice indesiderato.
Quali sono le tecniche di sfruttamento
Il problema critico è una vulnerabilità di overflow del buffer di stack che esiste a causa di un errore logico nel parser dei pacchetti Extensible Authentication Protocol (EAP) del software pppd, un'estensione che fornisce supporto per metodi di autenticazione aggiuntivi nelle connessioni PPP.
Per fare ciò, tutto ciò che un attaccante deve fare è inviare un pacchetto EAP malformato non richiesto a un client o server ppp vulnerabile attraverso un collegamento seriale diretto, reti ISDN, Ethernet, SSH, socket CAT, PPTP, GPRS o ATM. Inoltre, poiché pppd spesso viene eseguito con privilegi elevati e lavora in combinazione con i driver del kernel, il difetto potrebbe consentire agli attaccanti di eseguire potenzialmente codice dannoso con privilegi di sistema o di root.
Quale metodo di exploit hai scelto
Metodo di esecuzione remota di codice utilizzato per sfruttare il client vulnerabile. L'esecuzione remota di codice (RCE) riguarda la capacità di un intruso informatico di accedere a un dispositivo controllato da qualcuno e apportarvi modifiche, senza permesso e senza che il proprietario sappia dove si trova la macchina. La RCE consente a un attaccante di prendere il controllo di un computer o server eseguendo software malware arbitrario.
Ho utilizzato due macchine virtuali per testare sullo stesso computer. Una come server e una come client. Per collegare le macchine virtuali ho installato ssh. Utilizzando i loro indirizzi IP, ho collegato la macchina virtuale Fedora 29 come lato server e la macchina virtuale Kali Linux come lato client vulnerabile. Secondo le istruzioni, ho configurato un pppoe-server. Dopo aver aperto la modalità di debug e impostato il file di log, ho aggiunto quanto segue al file di log ‘/etc/ppp/pppoe-server-options’. Poi ho configurato un pppoe-client eseguendo ‘sudo pppoeconf’. Infine, utilizzando il codice Python è possibile sfruttare il client vulnerabile. Inoltre, inviando un pacchetto EAP non richiesto a un client ppp vulnerabile, un attaccante remoto potrebbe causare una corruzione della memoria nel processo pppd, che potrebbe consentire l'esecuzione arbitraria di codice.
Schermate dell'exploit
Ping con il client vulnerabile
Installazione di SSH sul server
Ottenimento dell'accesso root sul lato client
Dopo aver ottenuto l'accesso root del client
Abilitazione di SSH sul lato client
Crash
Risultato
Conclusione
GitHub Security Lab alla Riscossa
Mentre Vijay Sarvepalli studiava l'ultima iniziativa di protezione di GitHub, Vijay Sarvepalli voleva identificare le opportunità per sfruttare le soluzioni API e CodeQL di GitHub per affrontare il problema, e ha usato il codice per proporre la correzione agli utenti dei repository software. Ha contattato il nostro responsabile della protezione governativa, Allan Friedman (Direttore delle Iniziative di Cyber Security presso la National Telecommunications and Information Administration (NTIA) del Dipartimento del Commercio degli Stati Uniti), che ha riunito una serie di organizzazioni, tra cui GitHub, per creare una Software Bill of Materials (SBOM). Allan ha presentato Vijay Sarvepalli alle persone di GitHub dedicate alla riservatezza, e loro mi hanno messo in contatto con il capo del GitHub Security Lab, Nico Waisman.
Nico e il suo team internazionale del GitHub Security Lab hanno rapidamente trovato un modo per adattare il loro meccanismo di patching di sicurezza a questo problema. Hanno attivato una tecnologia automatica "robot" che ha contattato i proprietari di tutti i repository interessati da questo bug. I proprietari dei repository dovevano solo adottare alcune misure rapide per correggere e mettere in sicurezza la loro copia o fork del programma pppd, risolvendo il bug. Questa iniziativa comunitaria ci ha portati alla fase in cui la tecnologia veniva corretta. Ciò ha offerto un approccio modulare e tempestivo per implementare miglioramenti al codice sorgente al fine di aumentare la protezione. Entro quattro giorni dagli aggiornamenti automatici del GitHub Security Lab, 1.896 proprietari di repository hanno fornito i dettagli del bug e hanno avuto la possibilità di correggerlo in pochi clic. Almeno 42 di questi proprietari di repository hanno approvato una patch automatica; altri 13 hanno confermato che il problema era già stato risolto. Senza automazione, sarebbero necessari diversi giorni per contattare i proprietari dei repository interessati e correggere le loro applicazioni.
La sfida del DoD e il ruolo del CERT nel futuro del software
In quanto centro di ricerca e sviluppo finanziato a livello federale (FFRDC), il Software Engineering Institute (SEI) della Carnegie Mellon University e la sua CERT Division sono costantemente confrontati con le sfide che il Dipartimento della Difesa degli Stati Uniti (DoD) affronta nel cyberspazio. Il CIO del DoD Terry Halvorsen, un noto evangelista della cybersicurezza, ha dichiarato che "le azioni e contromisure difensive informatiche avverranno in millisecondi" nel suo discorso alla conferenza AFCEA. Queste azioni difensive informatiche desiderate non possono essere eseguite manualmente o attraverso processi di comunicazione macchinosi. Devono essere fornite tramite software e automatizzate il più possibile per limitare i problemi degli attuali modelli di patching con intervento umano.
In tutte le attività di gestione delle potenziali minacce, prevediamo di identificare situazioni in cui possiamo sfruttare gli incentivi (come questa partnership con il GitHub Security Lab) per accelerare il patching del codice sorgente contro le vulnerabilità della sicurezza delle informazioni. Sebbene comprendiamo che questo non risolverà ogni problema di protezione delle informazioni e non sostituisce buone pratiche di codifica, ci rendiamo conto che i bug tendono a essere trovati nelle informazioni dopo che sono state pubblicate. Quando le informazioni sono pervasive nella nostra vita quotidiana, le informazioni possono essere protette solo con una pronta identificazione delle vulnerabilità — e, se possibile, automatizzando sia l'identificazione che la risposta.
Riferimenti
• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html