Un rootkit è un set di strumenti che si esegue su un computer di destinazione quando in qualche modo si ottiene l'accesso ad esso con i privilegi a livello di root. Il punto del rootkit è trasformare quell'accesso transiente in una porta sempre aperta. Un esempio di un rootkit sarebbe una modifica del sshd binario, in modo che accetti sempre " 8gh347vb45 " come password per root , indipendentemente da quale sia la password "normale" per root. Permette all'attaccante di tornare più tardi, senza dover ricominciare da capo l'exploit che ha usato per primo.
Il primo compito di un rootkit è nascondersi e resiste agli aggiornamenti. Se il rootkit modifica semplicemente sshd (che è un esempio), il prossimo aggiornamento del pacchetto openssh rimuoverà il rootkit. Un rootkit più resistente altererebbe anche il gestore dei pacchetti, in modo che quando openssh viene aggiornato, il nuovo sshd viene modificato automaticamente in modo che il punto di accesso aggiuntivo per l'attaccante sia tenuto aperto.
I rootkit più potenti modificano il kernel , che è la parte del software che gestisce effettivamente l'hardware. Tutti i processi (per tutti gli utenti, incluso root), quando accedono ai dati o alle risorse hardware (ad esempio, leggendo o scrivendo file), lo fanno chiedendo gentilmente il kernel. Un rootkit installato nel kernel può nascondere i file in modo abbastanza efficace e può reinstallare se stesso ad ogni aggiornamento del kernel, poiché tale aggiornamento sarebbe la sostituzione del file contenente il codice del kernel con un altro - cioè un'operazione che passa necessariamente attraverso il kernel.
Un modulo del kernel è un pezzo di codice che viene caricato dinamicamente nel kernel. In Linux, fino ad un certo punto della serie 1.3.x, c'era un singolo blocco di codice monolitico che veniva caricato in RAM dal bootloader in un colpo solo. I moduli sono blocchi di codice che possono essere aggiunti in un secondo momento al kernel live; il loro punto era inizialmente quello di consentire al kernel potenzialmente di gestire centinaia di tipi di hardware senza dover contenere il corrispondente codice del driver nella RAM in ogni momento. L'idea è che quando viene rilevato un nuovo pezzo di hardware sulla macchina, il codice corrispondente viene caricato e collegato al kernel, come se fosse stato lì fin dall'inizio.
L'utente root ha il potere di chiedere il caricamento di un modulo. Quindi questo è un modo per un codice con privilegi di root per ottenere del codice arbitrario inserito nel kernel stesso, e in esecuzione con i poteri concessi al kernel, cioè la padronanza su tutto l'hardware e i processi (il cosiddetto 'ring 0' in il mondo x86). Questo è esattamente ciò di cui ha bisogno un kernel rootkit.
Modifica: come per la terza domanda (puoi applicare patch alle rookits), la risposta generica è no (per costruzione, su un sistema Unix, root può fare tutto su una macchina), ma la risposta specifica può essere sì . Ad esempio, esistono framework di sicurezza che aggiungono vincoli a ciò che la maggior parte dei processi di root può fare (ad es. SELinux ), e può non consentire il caricamento del modulo del kernel. Ciò significa che l'accesso root temporaneo previsto da parte dell'utente malintenzionato non è un accesso root true , ma solo un "quasi-root". Un'altra possibile caratteristica è moduli firmati (il kernel rifiuterà i moduli che non sono stati firmati crittograficamente, quindi il rootkit dovrebbe individuare e utilizzare la chiave privata prima di installare il proprio modulo, cosa che potrebbe non essere possibile se tale chiave non è memorizzata sulla macchina stessa) (non sono sicuro che il supporto dei moduli firmati sia attualmente integrato nel kernel di Linux). Inoltre, i moduli devono essere collegati al codice del kernel, rendendoli piuttosto sensibili alle variazioni tra le versioni del kernel - quindi anche in assenza di contromisure effettive, è difficile per un rootkit attendibilmente reinfettare i kernel più recenti aggiornamenti.