Belkin Wemo Smart Plug V2: l'overflow del buffer che non verrà corretto

Belkin Wemo Smart Plug V2: l'overflow del buffer che non verrà corretto

Timestamp: 16 maggio 2023 1:59
Nodo di origine: 2657924
by

Ricercatori della società di sicurezza IoT Sternum scavato dentro una popolare spina di alimentazione domotica del noto marchio di dispositivi Belkin.

Il modello che hanno guardato, il Mini presa intelligente Wemo (F7C063) apparentemente sta arrivando alla fine della sua durata di conservazione, ma ne abbiamo trovati molti in vendita online, insieme a consigli dettagliati e istruzioni sul sito di Belkin su come configurarli.

Vecchi (nel senso moderno a breve termine) per quanto possano essere, i ricercatori hanno notato che:

Il nostro interesse iniziale per il dispositivo derivava dall'avere molti di questi in giro per il nostro laboratorio e usati nelle nostre case, quindi volevamo solo vedere quanto fossero sicuri (o meno) da usare. [… T]questo sembra essere un dispositivo di consumo piuttosto popolare[; Sulla base di questi numeri, è lecito stimare che le vendite totali solo su Amazon dovrebbero essere dell'ordine di centinaia di migliaia.

In poche parole, ci sono molte persone là fuori che hanno già acquistato e collegato queste cose e le stanno usando proprio ora per controllare le prese elettriche nelle loro case.

Una "presa intelligente", in poche parole, è una presa di corrente che si collega a una presa a muro esistente e che interpone un interruttore controllato Wi-Fi tra la presa di rete sulla parte anteriore della presa a muro e una presa di rete dall'aspetto identico su la parte anteriore della presa intelligente. Pensalo come un alimentatore che invece di convertire, ad esempio, una presa europea rotonda in una triangolare britannica, converte, ad esempio, una presa americana commutata manualmente in una presa americana commutata elettronicamente che può essere controllata da remoto tramite un'app o un'interfaccia di tipo web.

La S nell'IoT...

Il problema con molti dei cosiddetti dispositivi Internet of Things (IoT), come dice una vecchia barzelletta, è che è la lettera "S" in "IoT" che sta per sicurezza...

…il che significa, ovviamente, che spesso non c'è tutta la sicurezza informatica che ci si potrebbe aspettare, o addirittura nessuna.

Come puoi immaginare, un dispositivo domotico poco sicuro, in particolare uno che potrebbe consentire a qualcuno fuori casa, o anche dall'altra parte del mondo, di accendere e spegnere gli elettrodomestici a piacimento, potrebbe portare a un sacco di guai.

Abbiamo già scritto sull'insicurezza dell'IoT in un'ampia gamma di prodotti diversi, da bollitori internet (sì, davvero) che potrebbe divulgare la tua password Wi-Fi domestica, alle telecamere di sicurezza che i truffatori possono utilizzare per mantenere i loro occhio a te invece del contrario, alle unità disco collegate alla rete a rischio di ottenere schizzato da ransomware direttamente su Internet.

In questo caso, i ricercatori hanno trovato un buco di esecuzione di codice remoto nel Wemo Mini Smart Plug nel gennaio 2023, lo hanno segnalato nel febbraio 2023 e hanno ricevuto un numero CVE nel marzo 2023 (CVE-2023-27217).

Sfortunatamente, anche se ci sono quasi certamente molti di questi dispositivi in ​​uso attivo nel mondo reale, Belkin ha apparentemente affermato di considerare il dispositivo "alla fine della sua vita" e che quindi la falla di sicurezza non verrà riparata.

(Non siamo sicuri di quanto sarebbe accettabile questa sorta di licenziamento di "fine vita" se il dispositivo risultasse avere un difetto nei suoi circuiti elettrici a 120 V CA o 230 V CA, come la possibilità di surriscaldamento ed emissione di sostanze chimiche nocive o impostazione in fiamme, ma sembra che i guasti nell'elettronica digitale a bassa tensione o nel firmware del dispositivo possano essere ignorati, anche se potrebbero portare un cyberattaccante ad accendere e spegnere ripetutamente a piacimento l'interruttore di alimentazione principale del dispositivo.)

Quando i nomi amichevoli sono il tuo nemico

Il problema scoperto dai ricercatori era un buon vecchio overflow del buffer dello stack nella parte del software del dispositivo che consente di modificare i cd FriendlyName del dispositivo: la stringa di testo che viene visualizzata quando ti connetti ad esso con un'app sul tuo telefono.

Per impostazione predefinita, questi dispositivi si avviano con un nome descrittivo sulla falsariga di Wemo mini XYZ, Dove XYZ denota tre cifre esadecimali che supponiamo siano scelte in modo pseudocasuale.

Ciò significa che anche se possiedi due o tre di questi dispositivi, quasi sicuramente inizieranno con nomi diversi in modo da poterli configurare facilmente.

Ma probabilmente vorrai rinominarli in seguito in modo che siano più facili da distinguere in futuro, assegnando quindi nomi amichevoli come TV power, Laptop charger ed Raspberry Pi server.

I programmatori Belkin (o, più precisamente, i programmatori del codice che è finito in questi dispositivi a marchio Belkin, che potrebbero aver fornito il software smart plug anche ad altri marchi) apparentemente hanno riservato 68 byte di memoria temporanea per tenere traccia del nuovo nome durante il processo di ridenominazione.

Ma si sono dimenticati di controllare che il nome che hai fornito si adattasse a quello slot da 68 byte.

Invece, presumevano che avresti utilizzato la loro app telefonica ufficiale per eseguire il processo di ridenominazione del dispositivo, e quindi che avrebbero potuto limitare la quantità di dati inviati al dispositivo in primo luogo, al fine di evitare qualsiasi overflow del buffer che potrebbe altrimenti presentarsi.

Ironia della sorte, si sono presi molta cura non solo di mantenerti al limite di 68 byte richiesto affinché il dispositivo stesso si comportasse correttamente, ma anche di limitarti a digitare solo 30 caratteri.

Sappiamo tutti perché lasciare che il lato client esegua il controllo degli errori, piuttosto che controllare invece (o, meglio ancora, anche) sul lato server, è una pessima idea:

  • Il codice client e il codice server potrebbero risultare non conformi. Le future app client potrebbero decidere che i nomi di 72 caratteri sarebbero una buona opzione e iniziare a inviare più dati al server di quanti ne possa gestire in sicurezza. I futuri programmatori lato server potrebbero notare che nessuno sembra mai utilizzare tutti i 68 byte riservati e decidere in modo non coerente che 24 dovrebbero essere più che sufficienti.
  • Un utente malintenzionato potrebbe scegliere di non preoccuparsi dell'app. Generando e trasmettendo le proprie richieste al dispositivo, aggirerebbero banalmente eventuali controlli di sicurezza che si basano solo sull'app.

I ricercatori sono stati rapidamente in grado di provare nomi sempre più lunghi al punto da poter mandare in crash il dispositivo Wemo a piacimento scrivendo oltre la fine del buffer di memoria riservato al nuovo nome e corrompendo i dati memorizzati nei byte immediatamente successivi.

Corrompere lo stack

Sfortunatamente, in un sistema operativo basato su stack, la maggior parte del software finisce con i suoi buffer di memoria temporanea basati su stack disposti in modo che la maggior parte di questi buffer sia seguita da vicino da un altro blocco vitale di memoria che dice al programma dove andare quando ha finito cosa sta facendo proprio adesso.

Tecnicamente, questi blocchi di dati "dove andare dopo" sono noti come indirizzi di ritornoe vengono salvati automaticamente quando un programma chiama ciò che è noto come a function, o sottoprogramma, che è un blocco di codice (ad esempio, "stampa questo messaggio" o "fai apparire una finestra di dialogo di avviso") che vuoi poter utilizzare in diverse parti del tuo programma.

L'indirizzo di ritorno viene magicamente registrato nello stack ogni volta che viene utilizzata la subroutine, in modo che il computer possa automaticamente "srotolare" il suo percorso per tornare al punto da cui è stata chiamata la subroutine, che potrebbe essere diversa ogni volta che viene attivata.

(Se una subroutine avesse un indirizzo di ritorno fisso, potresti chiamarla solo da un posto nel tuo programma, il che renderebbe inutile preoccuparsi di impacchettare quel codice in una subroutine separata in primo luogo.)

Come puoi immaginare, se calpesti quell'indirizzo di ritorno magico prima che la subroutine finisca di funzionare, quando finisce, si "srotolerà" fiduciosamente ma inconsapevolmente nel posto sbagliato.

Con un po' (o forse molta) fortuna, un utente malintenzionato potrebbe essere in grado di prevedere in anticipo come calpestare l'indirizzo di ritorno in modo creativo, e quindi deviare il programma in modo deliberato e dannoso.

Invece di bloccarsi semplicemente, il programma mal indirizzato potrebbe essere indotto con l'inganno a eseguire il codice scelto dall'attaccante, causando così ciò che è noto come esecuzione di codice remoto sfruttare, o RCE.

Due difese comuni aiutano a proteggere da exploit di questo tipo:

  • Randomizzazione del layout dello spazio degli indirizzi, nota anche come ASLR. Il sistema operativo carica deliberatamente i programmi in posizioni di memoria leggermente diverse ogni volta che vengono eseguiti. Ciò rende più difficile per gli aggressori indovinare come deviare i programmi difettosi in un modo che alla fine ottenga e mantenga il controllo invece di limitarsi a mandare in crash il codice.
  • Stack canarini, prende il nome dagli uccelli che i minatori portavano con sé sotto terra perché svenivano in presenza di metano, fornendo così un crudele ma efficace avvertimento precoce del rischio di esplosione. Il programma inserisce deliberatamente un blocco di dati noto ma casuale proprio davanti all'indirizzo di ritorno ogni volta che viene chiamata una subroutine, in modo che un overflow del buffer sovrascriva inevitabilmente e in modo rilevabile il "canarino", prima che si estenda abbastanza da calpestare sull'importantissimo indirizzo di ritorno.

Per far funzionare il loro exploit in modo rapido e affidabile, i ricercatori dovevano forzare la spina Wemo a disattivare l'ASLR, cosa che gli aggressori remoti non sarebbero stati in grado di fare, ma con molti tentativi nella vita reale, gli aggressori potrebbero comunque essere fortunati, indovina correttamente agli indirizzi di memoria utilizzati dal programma e ottenere comunque il controllo.

Ma i ricercatori non dovevano preoccuparsi del problema del canary dello stack, perché l'app buggy era stata compilata dal suo codice sorgente con la funzione "inserisci istruzioni di sicurezza per il controllo del canary" disattivata.

(I programmi protetti da Canary sono in genere leggermente più grandi e più lenti di quelli non protetti a causa del codice aggiuntivo necessario in ogni subroutine per eseguire i controlli di sicurezza.)

Cosa fare?

  • Se sei un proprietario di Wemo Smart Plug V2, assicurati di non aver configurato il router di casa per consentire l'accesso al dispositivo dall'esterno, tramite Internet. Questo riduce ciò che in gergo è noto come tuo superficie di attacco.
  • Se hai un router che supporta Universal Plug and Play, noto anche come UPnP, assicurati che sia disattivato. UPnP rende notoriamente facile che i dispositivi interni vengano aperti inavvertitamente agli estranei.
  • Se sei un programmatore, evitare di disattivare le funzionalità di sicurezza del software (come la protezione dello stack o il controllo canary dello stack) solo per risparmiare pochi byte. Se stai davvero esaurendo la memoria, cerca di ridurre il tuo footprint migliorando il tuo codice o rimuovendo le funzionalità piuttosto che riducendo la sicurezza in modo da poter stipare di più.

Timestamp:

Di più da Sicurezza nuda