Domande su Rakshasa

L'obiettivo del creatore di Rakshasa era di evitare che qualsiasi malware, potenzialmente potenzialmente contrassegnato da un antivirus, potesse essere memorizzato ovunque nella macchina (sia sul disco rigido, in un firmware o altrove ).

Per riuscirci, Jonathan Brossard (per chiamare il creatore con il suo nome) ha implementato Rakshasa con il seguente principio:

• Rakshasa è composto principalmente, se non solo, da componenti Opend-Source che vengono normalmente utilizzati in modo legittimo. Questi componenti includono un firmware BIOS libero, uno stack TCP associato e un software che consente di scaricare un'immagine remota e avviare da esso. Tale soluzione è ampiamente utilizzata in scenari aziendali come computer kiosk, thin client o sistemi di salvataggio aziendali: consente a tutti i computer di condividere l'immagine del sistema, quindi è sufficiente aggiornare una sola immagine di condivisione anziché macchine n .
• La differenza principale qui è che Rakshasa non scaricherà effettivamente un'immagine di sistema legittima, come nel caso di esempi aziendali precedenti, scaricherà un'immagine Kon-boot modificata (ma potrebbe essere in realtà qualsiasi altra cosa) e inizierà da esso.

Quindi, se torno alla tua domanda:

How is the bootkit [...] infecting the connected harddrive remotely?

Qui non si verificano infezioni remote.

In realtà, il creatore procede molto velocemente durante la fase di contaminazione iniziale, che è fuori dalla portata della sua dimostrazione. Egli menziona che la contaminazione iniziale potrebbe essere effettuata ad esempio dal fornitore di hardware stesso, da un sequestro di pacchi durante il processo di consegna, o da chiunque altro abbia un accesso fisico alla macchina (anche se alcune misure di sicurezza basate su TPM possono rendere quest'ultimo uno più difficile).

Anche la contaminazione tramite software dannoso dovrebbe essere possibile, ma ecco di nuovo il problema del rilevamento antivirus dal momento che non fa parte di un normale comportamento del software per provare a flash BIOS e schede di rete firmwares ...

Comunque, la maggior parte di questa presentazione considera una macchina già infetta. Questo significa:

• Il firmware del BIOS è stato rifuso con un firmware Open-Source personalizzato configurato per scaricare i kit di avvio da un set di server di proprietà dell'attaccante,
• Con un attacco completo, il firmware di una scheda di rete (suppongo che anche un altro dispositivo PCI possa andare bene) è stato anche rifuso con un firmware modificato personalizzato che consente di reinfettare il firmware del BIOS nel caso viene pulito dal proprietario della macchina,
• Il disco rigido non è stato né verrà mai toccato per evitare qualsiasi rilevamento.

Does this mean that there is a boot partition somewhere on a server and Rakshasa connects to this partition...

Non è in realtà una partizione di avvio. Si tratta solo di immagini di avvio, che sono in realtà file standard (per l'esempio il presentatore le ha persino denominate usando% estensioni.pdf) contenenti codice binario da scaricare ed eseguire dalla macchina durante la sua sequenza di avvio.

Come accennato in precedenza, troverete in genere tale sistema implementato nell'ambiente aziendale per thin client, computer kiosk e come sistemi di salvataggio: invece di leggere le istruzioni di avvio dal disco rigido locale, tale sistema leggerà le istruzioni da un file scaricato.

...and makes it so to say the boot partition of the physically connected harddrives on the victims pc?

Nell'esempio aziendale sopra riportato, l'immagine di avvio scaricata verrà utilizzata invece del disco rigido, sia perché potrebbe non esserci alcun disco rigido (thin client, computer kiosk ) o perché il disco rigido potrebbe non essere più avviabile e deve essere reimmaginato (sistema di salvataggio della rete aziendale).

Tali immagini di avvio contengono quindi un sistema operativo completo dedicato a qualsiasi cosa debba essere utilizzata.

Rakshasa ha usato un metodo standard, al contrario, non significa sostituire completamente il sistema operativo originale: vuole essere il più trasparente possibile all'utente.

Pertanto, l'immagine di avvio scaricata non conterrà un sistema operativo completo, il suo codice sarà solo:

1. Contiene tutto il malware e il carico utile richiesti (Kon boot, misure anti-sicurezza, ecc.) ed eseguili nell'ordine richiesto con alcuni di essi che rimangono residenti nella memoria,
2. Una volta che tutti i payload sono stati eseguiti con successo, restituirà il controllo alla prima partizione avviabile, es. d'ora in poi la macchina recupererà una normale sequenza di avvio.

Come nota a margine (non ricordo se è stata menzionata durante la presentazione), mentre questa "prima partizione avviabile" sarà solitamente il disco rigido, potrebbe anche essere un CD-ROM se il proprietario della macchina fosse l'avvio da un CD anziché da un disco rigido. Questo ha un po 'di importanza dal momento che significa che l'avvio da un Live-CD, come spesso si consiglia di evitare il malware e backdoor non porterà alcuna sicurezza contro tali minacce.

Sì, hai correttamente concluso ciò che sta facendo Rakshasa , tranne per il fatto che il disco rigido non è mai stato infettato e non ha alcuna prova del compromesso. Il compromesso vive esclusivamente come codice non dannoso nel BIOS, che carica il codice dannoso da un server di rete che vive esclusivamente nella RAM.

Questo è un video lungo per noi da guardare e recensire, quindi ho semplicemente saltato un po 'e ho letto DarkReading writeup e quindi potrebbe aver perso qualcosa chiave. In tal caso, ti preghiamo di notare una serie di tempi rilevanti per la tua domanda.

Sto osservando la diapositiva a 12:22 che parla dell'utilizzo di iPXE , che è un sistema di avvio di rete che note di Wikipedia "può essere utilizzato per abilitare i computer senza supporto PXE integrato per l'avvio dalla rete, o per estendere un'implementazione client PXE esistente in modo che supporti protocolli aggiuntivi."

iPXE viene utilizzato per avviare il sistema sulla rete, estraendo il bootkit da un host remoto. At 16:29 , oratore Jonathan Brossard note:

The bootkit never touches the disk, and it's not embedded in your PCI extension ROM, or in your BIOS ROM either.

Questo è un sistema di avvio di rete completo. Come indicato in un'altra diapositiva (in 16:09 ), "Malware: recuperato all'avvio, memorizzato solo nella RAM" . KON-BOOT , un Live CD avviabile utilizzato per l'esclusione della password (erm, "recupero"), è un wrapper attorno al sistema operativo locale (che si tratti di Windows, OS X o Linux) che garantisce l'accesso come root / amministratore senza password. Le modifiche di Rakshasa introducono ulteriori malware a questo sistema compromesso.

Con accesso root completo e un BIOS compromesso e un kernel compromesso, Rakshasa può fare praticamente qualsiasi cosa. Brossard ha scelto di compromettere un numero di istruzioni della CPU e introdurre anomalie che consentono ulteriori trucchi.

Informazioni su Linux: Sembra che il supporto per Linux sia stato rimosso dalla documentazione di KON-BOOT, anche se sospetto che sia ancora lì. Entrare in Linux con un disco di avvio è in realtà banale: avviare qualsiasi Live CD di Linux, montare /etc e modificare l'hash della password dell'utente root in /etc/shadow . Questo può anche essere fatto in modo non distruttivo usando qualcosa come UnionFS senza mai toccare un disco locale.

Tuttavia, è proprio come ottenere l'accesso come root.

Per fare il tipo di cose che sembra fare Rakshasa, sarebbe necessario un kernel personalizzato (o un modulo del kernel personalizzato?). Supportare ogni singolo kernel Linux non è pratico a meno che non stiamo parlando di un attacco altamente mirato, quindi immagino che un framework di attacco possa supportare solo sistemi come Ubuntu LTS e Red Hat Enterprise, nessuno dei quali varia molto nel tempo (ed entrambi di cui sono abbastanza popolari).

Se /etc è crittografato, è meno probabile che il tuo shadow file venga aggiunto, anche se UnionFS potrebbe teoricamente vincerlo senza bisogno di leggerlo. Detto questo, il caricamento di un kernel rogue (o di un modulo del kernel non autorizzato) consentirebbe un regno infinito di cose e precluderebbe il bisogno del file shadow .