Domanda:
Un virus può distruggere il BIOS di un computer moderno?
user73910
2019-04-02 12:27:28 UTC
view on stackexchange narkive permalink

Alla fine degli anni '90, un virus informatico noto come CIH iniziò a infettare alcuni computer. Il suo carico utile, quando attivato, sovrascriveva le informazioni di sistema e distruggeva il BIOS del computer, essenzialmente bloccando qualsiasi computer infettato. Un virus che colpisce i sistemi operativi moderni (come Windows 10) potrebbe distruggere il BIOS di un computer moderno e essenzialmente lo blocchi allo stesso modo, oppure è ora impossibile per un virus accedere al BIOS di un computer moderno?

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/91977/discussion-on-question-by-user73910-can-a-virus-destroy-the-bios-of-a-modern-com).
Alcune (o la maggior parte?) Delle schede madri desktop hanno una ROM usata per recuperare il BIOS da qualche forma di supporto (ai vecchi tempi, floppy disk, oggigiorno, chiavette USB, forse cd-rom).La ROM non può essere modificata, tuttavia il ripristino di solito richiede l'apertura del case e lo spostamento di un ponticello per l'avvio in modalità di ripristino del BIOS.Non so come gestiscano i laptop.
sì, ma dal punto di vista di un attaccante è uno spreco o risorse ... Maggiori informazioni su un rootkit per UEFI come esempio nel documento seguente ... https://www.welivesecurity.com/wp-content/uploads/2018/09 / ESET-LoJax.pdf
Correlato: https://security.stackexchange.com/q/13105/165253
Nove risposte:
#1
+121
Philipp
2019-04-02 13:42:17 UTC
view on stackexchange narkive permalink

I computer moderni non hanno un BIOS, hanno un UEFI. L'aggiornamento del firmware UEFI dal sistema operativo in esecuzione è una procedura standard, quindi qualsiasi malware che riesce a essere eseguito sul sistema operativo con privilegi sufficienti potrebbe tentare di fare lo stesso. Tuttavia, la maggior parte degli UEFI non accetterà un aggiornamento che non sia firmato digitalmente dal produttore. Ciò significa che non dovrebbe essere possibile sovrascriverlo con codice arbitrario.

Ciò, tuttavia, presuppone che:

  1. i produttori di schede madri riescano a mantenere segrete le loro chiavi private
  2. l'UEFI non presenta vulnerabilità di sicurezza involontarie che consentono di sovrascriverlo con codice arbitrario o che possono essere altrimenti sfruttate per causare danni.

E questi due presupposti non sono necessariamente validi .

Riguardo alle chiavi trapelate: se una chiave di firma UEFI diventasse nota al grande pubblico, allora si può presumere che ci sarebbero molti rapporti sui media e patch isteriche in corso. Se segui alcune notizie IT, probabilmente vedrai molti titoli allarmisti "Se hai una scheda madre [marca] AGGIORNA ORA IL TUO UEFI !!! 1111oneone" . Ma un'altra possibilità è firmare le chiavi trapelate segretamente agli attori statali. Quindi, se il tuo lavoro potrebbe essere interessante per lo spionaggio industriale, allora questa potrebbe anche essere una minaccia credibile per te.

Per quanto riguarda i bug: gli UEFI acquisiscono sempre più funzionalità che hanno sempre più possibilità di bug nascosti. Inoltre mancano della maggior parte delle funzionalità di sicurezza interna che hai dopo aver avviato un sistema operativo "reale".

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/92028/discussion-on-answer-by-philipp-can-a-virus-destroy-the-bios-of-a-calcolo moderno).
#2
+47
Stephane
2019-04-02 13:37:54 UTC
view on stackexchange narkive permalink

Sì, è decisamente possibile.

Oggigiorno, con la diffusione di UEFI, è ancora più preoccupante: UEFI ha una superficie di attacco molto più ampia rispetto al BIOS tradizionale e un (potenziale) difetto in UEFI potrebbe essere sfruttato per ottenere l'accesso alla macchina senza dover qualsiasi tipo di accesso fisico ( come dimostrato dalla gente di Eclypsium al Black Hat lo scorso anno).

#3
+20
Dewi Morgan
2019-04-03 00:39:48 UTC
view on stackexchange narkive permalink

In pratica, un virus è un software, quindi può fare tutto ciò che qualsiasi altro software può fare.

Quindi il modo più semplice di rispondere a questa domanda e a tutti gli altri class "I virus possono fare X?" è chiedere "Il software attualmente fa X?"

Tali domande potrebbero includere "un virus può portare a spasso il mio cane?" (non senza un robot che cammina con i cani); "Può un virus portarmi la pizza?" (sì: purtroppo questo non è l'obiettivo principale della maggior parte degli autori di virus, tuttavia).

I BIOS (UEFI) sono attualmente aggiornati tramite software? La risposta è sì, lo sono. Il mio è stato aggiornato la scorsa notte, quando ho riavviato.

E quindi la risposta è sì.

Con la stessa logica, i virus possono anche causare (e storicamente hanno causato) danni fisici alla CPU, ai dischi rigidi e alle stampanti.

Anche i sistemi di automazione domestica e i veicoli senza conducente sono possibili bersagli di danni fisici, ma non sono a conoscenza di virus che lo abbiano fatto.

Non mi dispiacerebbe molto se le mie informazioni personali fossero usate dagli sviluppatori di malware per ordinarmi pizza gratis e nient'altro.(+1 per ragionamento utile)
@Marc.2377, non mi dispiacerebbe molto se * le tue * informazioni personali fossero usate per ordinare * me * pizza gratis ... :-)
I virus moderni avranno difficoltà a causare danni fisici.Al massimo, potrebbero logorare un po 'l'hardware facendo funzionare la CPU molto calda, il che accorcia la vita utile, ma non è comune che possa causare _danni_.In passato però non era così.Vedi "il colpo di morte".
@Forest Sono d'accordo ... anche se il "periodo difficile" si applica alla maggior parte dei virus, poiché si basano sul comportamento non documentato e imprevisto dei loro exploit.Direi che man mano che i dispositivi diventano più complessi, il bricking malizioso diventa più fattibile (attraverso cicli termici, cicli di lettura-scrittura, vibrazioni, surriscaldamento, overvolt, overclock, firmware ...).Il fatto che non vediamo più attacchi di distruzione di dispositivi è sospetto di più perché gli autori di malware non sono interessati a loro;fanno per una divertente demo in una truffa di hacker, ma sono essenzialmente inutili in un vero virus o attacco.
@forest Le ventole e il software dei sistemi di raffreddamento non sono controllati in questi giorni?Non ne sono sicuro, ma scommetto che potresti in qualche modo sporcare la ventola della CPU o della GPU dal software.La Russia ha distrutto i generatori in remoto attivandoli e disattivandoli a una frequenza di risonanza - Scommetto che ci sono trucchi simili che potrebbero uccidere il tuo monitor abbastanza rapidamente.I dischi rigidi del piatto possono sicuramente essere cestinati ruotandoli su e giù ripetutamente, le unità a stato solido sono vulnerabili a ripetuti cicli di lettura / scrittura.Scommetto che un hacker motivato potrebbe fare molto ...
Ransomware che fa le sue richieste tramite una nota sepolta in una pizza apparentemente gratuita.Adesso c'è un'idea!
Ma io volevo ali non pizza.
Penso che avremmo bisogno di definire l'ambito di "causare danni fisici" prima di decidere se fosse possibile / plausibile.Se costringi la definizione a danneggiare letteralmente il computer che esegue il codice, è piuttosto ristretto e penso che @forest abbia ragione.Se includi il danno fisico in senso più generale, è molto più facile immaginare scenari in cui un computer infetto che controlla qualcos'altro (centrale elettrica, semafori, sistema di trasporto di massa, impianto di trattamento delle acque, ecc.) Potrebbe facilmente causare gravi danni fisici.
@dwizum Mi sembra che "Forest is right" sia una regola pratica affidabile, anche se non proprio una verità lapalissiana, poiché ci sono casi limite, differenze di esperienza e interpretazione, ecc. Interpreto "distruzione" nell'OP includendovi qualsiasibricking dove sarebbe necessario riparare hardware specialistico o sostitutivo.Ma sono d'accordo che dovremmo interpretare "danno fisico" in modo più rigoroso: ma comunque, cicli termici, cicli di lettura-scrittura, vibrazioni, surriscaldamento, overvolt, overclock ecc. Consentono molti danni a molte periferiche anche su normali PC invece che infrastrutturali nazionalicomputer.
@BillK Sebbene sia in gran parte controllato da software, non è possibile ignorarlo completamente poiché di solito un CPLD sulla scheda madre gestirà il controllo della ventola.È necessario, altrimenti un blocco rigido completo che blocca il computer potrebbe causarne il surriscaldamento e la rottura.Ma anche se in qualche modo potessi spegnere completamente le ventole (magari facendole pulsare in un modo che rompa i motori?), La CPU stessa si spegnerebbe dopo che la temperatura supera Tj Max, e questo non è qualcosa che il software può influenzare.
@DewiMorgan Quando ci penso di più, sono sicuro che sarebbe possibile in qualche modo, dal momento che i computer x86 moderni sono bestie complesse, ma non credo che ci siano modi ben noti.Un guru del BIOS probabilmente ne saprebbe di più (forse dovrei chiedere in #libreboot o #coreboot su Freenode!).
@BillK Riguardo ai monitor dannosi con frequenze malvagie, in realtà era una cosa per i monitor CRT e potresti facilmente distruggerli.Anche per alcuni vecchi sistemi LCD (GBA, credo?), C'erano modi per danneggiarlo fisicamente attraverso il software.Vedi https://en.wikipedia.org/wiki/Killer_poke#Game_Boy.
@Forest: D'accordo, gli unici attacchi di cui abbia mai sentito parlare per danneggiare l'hardware sono specifici per sistema: non ci sono attacchi generici "one-size-fits-all" (o anche "-many") per danneggiare l'hardware.I più vicini che posso immaginare sarebbero programmi di tipo stress test che esporrebbero i punti deboli dell'hardware difettoso se eseguiti per un fine settimana, ma non sono sicuro che conti come "attacco" tanto quanto "esporre i problemi con hardware a buon mercato".
Sì, stavo suggerendo che un attacco mirato contro un hardware specifico potrebbe ancora danneggiarlo.Scommetto che potresti trovare un qualche tipo di attacco software / risonanza / frequenza che potrebbe uccidere anche una scheda video (anche se è più probabile che potresti semplicemente spegnere la ventola, disattivare la sicurezza e riscaldare la scheda a seconda dell'implementazione).Nessuno sembra fare più nulla nell'hardware che non deve assolutamente fare, la tendenza a fare di più nel software ha reso tutto piuttosto vulnerabile.
E ovviamente, se l'attaccante può allegare un JTAG, tutte le scommesse sono annullate ...
@DewiMorgan Hm, JTAG può davvero danneggiare l'hardware (in un modo diverso dall'invio di una sovratensione sui TAP)?Non riesco a pensare a come possa farlo, ma è così complesso e può fare molto di più che controllare semplicemente la CPU che non sarei affatto sorpreso se potesse causare danni fisici tramite alcune cose di scansione dei confini.
@forest: È più che, utilizzando un JTAG, è possibile aggirare le protezioni integrate * contro * danni all'hardware, in componenti che non dovevano essere flaschabili dagli aggiornamenti del firmware.Non protezioni hardware, ovviamente: non puoi ignorare un fusibile!Ma puoi bypassare cose come la limitazione della velocità, la limitazione della corrente, ecc. Non è una preoccupazione realistica, tuttavia: con l'accesso completo, è molto più facile per qualsiasi avversario colpire la tavola con un martello.
#4
+12
emrys57
2019-04-03 11:50:42 UTC
view on stackexchange narkive permalink

Sì, è assolutamente possibile.

Ecco un esempio di aggiornamento del sistema operativo malware firmato in modo fraudolento con la chiave privata del produttore: https://www.theregister.co.uk/2019 / 03/25 / asus_software_update_utility_backdoor /

Secondo Kaspersky Labs, circa un milione di laptop Asus sono stati infettati da Shadowhammer , con un aggiornamento che sembrava essere firmato correttamente. Non è chiaro se ciò abbia alterato il firmware, ma certamente avrebbe potuto farlo.

#5
+4
scifi6546
2019-04-03 03:10:46 UTC
view on stackexchange narkive permalink

La tua domanda suggerisce un argomento più profondo che sono gli anelli e le autorizzazioni del codice su un sistema operativo. Su MS DOS il codice potrebbe fare quello che vuole. Se il codice volesse scrivere tutti gli 0x00 su un disco rigido, potrebbe farlo se volesse inviare strani output a un componente hardware, potrebbe anche non esserci nulla che fermi il codice dell'utente. Su un sistema operativo moderno esiste un concetto di anelli (questo è applicato dalla CPU). Il kernel gira sull'anello zero e potrebbe fare quello che vuole. Il codice dell'utente d'altra parte non può. Funziona su qualcosa chiamato ring 3 e gli viene dato il suo piccolo pezzo di memoria e all'interno di quella memoria può fare quello che vuole ma non può parlare direttamente con l'hardware. Se il codice dell'utente cerca di comunicare con l'hardware, il kernel interrompe immediatamente il programma. Ciò significa che è altamente improbabile che un virus normale possa uccidere l'hardware perché non può parlare direttamente con esso.

Se il kernel viene violato, il gioco è praticamente finito. Il kernel può fare quello che vuole e possono accadere tutta una serie di cose brutte come l'overclock della CPU fino a un punto in cui l'hardware è instabile, pulire i dischi rigidi (riempiendo il con zeri per esempio), o praticamente qualsiasi altro attacco plausibile .

* "Se il codice dell'utente cerca di comunicare con l'hardware, il kernel uccide immediatamente il programma" * - Davvero?Puoi fornire una citazione per questo?Pensavo che l'istruzione protetta semplicemente fallisse e spetta al programma occuparsene ragionevolmente o andare in crash.
@Marc.2377 È corretto.Se il codice dell'utente tenta di eseguire un'istruzione in CPL3 che richiede i privilegi CPL0, lancerà "#GP (0)" (errore di protezione generale o GPF).Questo fa sì che il codice salti nel kernel per vedere quale gestore di segnali è stato impostato per quell'evento.Per impostazione predefinita, il kernel terminerà il processo, sebbene sia tecnicamente possibile per il processo impostare un gestore di segnali per SIGSEGV, nel qual caso il kernel riprende l'esecuzione del processo nella posizione del gestore di segnali.In genere non è una buona idea perché un processo è considerato in un ...
... stato indefinito secondo POSIX se l'esecuzione riprende dopo che è stato sollevato un SIGSEGV che non proveniva da `raise ()`.Riprenderà l'esecuzione dall'istruzione fallita che verrà eseguita di nuovo e causerà il blocco del processo se il segnale viene ignorato.Quindi _può_ essere il programma a occuparsene, _se_ imposta un gestore di segnale per SIGSEGV, ma non c'è praticamente mai nessuna situazione in cui ciò sarebbe fatto (anche se penso che l'emulatore Dolphin rilevi i segfaults per una sorta di ottimizzazione hackyquindi non deve emulare qualche strano comportamento di paginazione e può fare affidamento sulla MMU).
Vedi [questo] (https://accidentallyquadratic.tumblr.com/post/142829260822/dolphin-emulator-trampoline-generation) per un (raro) esempio di quando _è_ all'altezza del programma.Oppure leggi [PoC || GTFO] (https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf) 6: 3.
#6
+3
520
2019-04-02 13:13:59 UTC
view on stackexchange narkive permalink

Potenzialmente. Tuttavia, sarebbe difficile da fare, poiché molto probabilmente dovrebbe mascherarsi come un aggiornamento del BIOS legittimo da qualche parte lungo la linea. Il metodo per farlo cambierà a seconda del tuo mobo, ma è probabile che debba comportare la fuga di chiavi private o hardware o altri segreti.

#7
+3
Qwertie
2019-04-04 09:08:35 UTC
view on stackexchange narkive permalink

Sì. È specifico per l'hardware, ma ecco un caso in cui un utente ha accidentalmente rotto il firmware della scheda madre dal livello del sistema operativo https://github.com/systemd/systemd/issues/2402

A bug nel firmware di un laptop MSI significava che la cancellazione delle variabili efi rendeva il laptop inutilizzabile. Poiché queste variabili erano esposte al sistema operativo e montate come file, l'eliminazione di ogni file dal livello del sistema operativo causava il problema che poteva essere sfruttato da un virus per mirare specificamente a queste variabili.

#8
+1
user21820
2019-04-04 16:45:19 UTC
view on stackexchange narkive permalink

Ci sono molti modi e alcuni di essi sono inquietanti. Ad esempio, Computrace sembra essere una backdoor permanente che può aggirare non solo il sistema operativo ma anche il BIOS. E più in generale, l ' Intel Management Engine ha il pieno controllo del tuo computer e può essere plausibilmente sfruttato. Questi possono modificare il BIOS ma non è nemmeno necessario. Solo nel 2017, i ricercatori di sicurezza hanno scoperto come sfruttare Intel IME tramite USB per eseguire codice non firmato.

Il punto è che anche se hai un sistema operativo completamente sicuro e tu non scaricare mai alcun software insicuro o dannoso, c'è ancora una possibilità non trascurabile che tu possa essere colpito da un malware che aggira tutto ciò sfruttando una vulnerabilità di sicurezza nel tuo hardware (anche quando il tuo computer è presumibilmente spento).

#9
  0
Lily Finley
2019-04-05 14:59:29 UTC
view on stackexchange narkive permalink

Qualcosa che non ho visto qui:

Se l'attaccante ottiene un'autorizzazione sufficiente per installare anche un firmware UEFI ufficiale, firmato correttamente dal produttore del sistema, può potenzialmente lasciare il computer in uno stato non avviabile spegnendo con forza il computer in un momento opportuno durante il processo.

Il codice di aggiornamento nei firmware moderni di solito cerca di ridurre al minimo la quantità di tempo che il computer trascorre in uno stato in cui un'interruzione di corrente provocherà il danneggiamento del firmware, e alcuni firmware hanno anche una modalità di ripristino che si attiverà in tal caso.

Tuttavia, molti di questi sistemi non sono completamente a prova di proiettile. Sebbene offrano una buona protezione contro interruzioni di corrente casuali, uno spegnimento tempestivo potrebbe comunque spegnerlo se il firmware non dispone di una robusta funzione di ripristino automatico.

Inoltre, potrebbe non essere necessario attaccare il firmware di sistema principale. Praticamente ogni dispositivo in un PC moderno ha un firmware di qualche tipo e molti di essi possono essere aggiornati tramite software. Questi dispositivi sono spesso anche meno sicuri. Possono accettare completamente firmware non firmati o almeno essere meno resistenti a spegnimenti dannosi durante il processo di aggiornamento.

Se si distrugge il firmware sul controller di alimentazione, controller di archiviazione, dispositivo di archiviazione, dispositivo video o controller di ingresso , il sistema potrebbe diventare inutilizzabile come se avessi attaccato l'UEFI.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...