Ci sono due aspetti di bluepill: come avviene l'infezione e se è possibile rilevarla una volta accaduto.
Il primo aspetto è lo stesso di tutto il malware. L'aspetto novità di bluepill era la rivendicazione "è irrilevabile".
Sono state condotte ricerche approfondite su questo argomento e sono stati ideati diversi metodi per il rilevamento.
Dovresti notare che, al momento, non c'erano minacce di bluepill viste in natura.
Rilevare se il sistema operativo è in esecuzione all'interno di una macchina virtuale
I primi metodi di rilevamento pubblicati riguardavano i tempi. Da un'intervista con Anthony Liguori :
Hardware virtualization requires a technique know as “trap and
emulation”. The idea is that the hardware traps certain instructions
and the VMM emulates those instructions in such a way as to make the
software believe it is running in a virtual machine.
Software emulation implies that these instructions take much longer to
complete when executed under a VMM then on normal hardware. This fact
is what can be used to detect the presence of a VMM.
I approached Rutkowska about this and she attempted to address it in
her prototype by adjusting one of the processors clocks on every exit.
However, there is nothing that she can due about external time sources
and she’s admitted to this on her blog.
She refers to this as a theoritical weakness in her system but I
assure you that it is quite practical to exploit.
L'autore originale del concetto bluepill (Joanna Rutkowska) ha pubblicato anche un altro articolo (RedPill) che potrebbe essere sfruttato per rilevare un rootkit BluePill.
Non sono riuscito a trovare il documento, ma ho trovato questo eccellente riassunto :
int swallow_redpill () {
unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
*((unsigned*)&rpill[3]) = (unsigned)m;
((void(*)())&rpill)();
return (m[5]>0xd0) ? 1 : 0;
}
The heart of this code is actually the SIDT instruction (encoded as
0F010D[addr]), which stores the contents of the interrupt descriptor
table register (IDTR) in the destination operand, which is actually a
memory location. What is special and interesting about SIDT
instruction is that, it can be executed in non privileged mode (ring3)
but it returns the contents of the sensitive register, used internally
by operating system.
Because there is only one IDTR register, but there are at least two OS
running concurrently (i.e. the host and the guest OS), VMM needs to
relocate the guest's IDTR in a safe place, so that it will not
conflict with a host's one. Unfortunately, VMM cannot know if (and
when) the process running in guest OS executes SIDT instruction, since
it is not privileged (and it doesn't generate exception). Thus the
process gets the relocated address of IDT table. It was observed that
on VMWare, the relocated address of IDT is at address 0xffXXXXXX,
whereas on Virtual PC it is 0xe8XXXXXX. This was tested on VMWare
Workstation 4 and Virtual PC 2004, both running on Windows XP host OS.
Un altro metodo è esaminato in questo articolo è del 2008:
The idea is to intercept a hypervisor's start by another hypervisor
(let’s call the latter a Virtual Intrusion Prevention System, or
VIPS). When any hypervisor (malicious or legitimate) starts, it turns
VM root mode on. This event can be easily intercepted by a VIPS. So
what's next? There are 2 ways to handle this event: blocking a
hypervisor completely, or allowing it to work through emulation.
The first way consists in emulating a PC with disabled HVT feature in
BIOS. This will block a HVT rootkit from working.
The second way consists in allowing a hypervisor to work through
emulated hardware virtualization (or nesting). This should be done for
legitimate virtualization software.
In both cases (blocking or emulating), a VIPS intercepts a hypervisor
at the moment it tries to start. VIPS can read the hypervisor’s body
and analyze it. A notification message can be shown.
È davvero una minaccia
Poi ci sono gli aspetti pratici dell'attacco da considerare.
Un rootkit bluepill deve implementare lo xen o qualcosa di simile, il che è un grande sforzo. Poiché non c'è davvero alcuna garanzia che non venga rilevato o bloccato in ogni caso, gli attaccanti sceglieranno un percorso più semplice che è un rootkit classico.
Credo che questo sia in parte il motivo per cui i rootkit bluepill non sono stati visti allo stato selvatico.