Questions regarding Rakshasa

The goal of the creator of Rakshasa was to avoid having any malware, which could potentially be flagged by an antivirus, to be stored anywhere in the machine (whether it is on the hard-disk, in a firmware, or anywhere else).

To achieve this, Jonathan Brossard (to call the creator by his name) implemented Rakshasa with the following principle:

• Rakshasa is composed mainly, if not only of Opend-Source components which are usually used in legit ways. These components include a free BIOS firmware, an associated TCP stack, and software allowing to download a remote image and boot from it. Such solution is widely used in corporate scenarios like kiosk computers, thin clients or corporate rescue systems: it allows all computer to share the system image, so you have only one share image to update instead of n machines.
• The main difference here is that Rakshasa will not actually download a legit system image as this is the case for above corporate examples, it will download a modified Kon-boot image (but this could have been actually anything else) and start from it.

So, if I get back to your question:

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

There is no remote infection happening here.

Actually, the creator goes very fast over the initial contamination step which is out-of-scope of his demonstration. He mentions that the initial contamination could be done for instance by the hardware provider himself, by a parcel seizure during the delivery process, or by anyone else having a physical access to the machine (even if some TPM-based security measures may make this last one more difficult).

Contamination through malicious software should also be possible, but here comes again the antivirus detection issue since it is not part of a usual software behaviour to try to flash BIOS and network cards firmwares...

Anyway, most of this presentation consider an already infected machine. This means:

• The BIOS firmware has been reflashed with a custom Open-Source firmware configured to download boot kits from a set of servers owned by the attacker,
• With a full fledged attack, the firmware of a network card (I suppose another PCI device may also be fine) has also been reflashed with a custom modified firmware allowing to reinfect the BIOS firmware in case it gets cleaned by the machine owner,
• The hard-disk hasn't been and will never be touched to avoid any detection.

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

It is not really a boot partition. It it just a boot images, which are actually standard files (for the sake of the example the presenter even named them using .pdf extensions) containing binary code to be downloaded and executed by the machine during its startup sequence.

As mentioned earlier, you will most typically find such system implemented in corporate environment for thin clients, kiosk computers and as a rescue systems: instead of reading the boot instructions from the local hard-disk, such system will read instructions from a downloaded file.

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

In the above mentioned corporate example, the downloaded boot image will be used instead of the hard-disk, whether because there may not be even any hard-disk at all (thin clients, kiosk computer) or because the hard-disk may not be bootable anymore and needs to be reimaged (corporate network rescue system).

Such boot images therefore contain a full operating system dedicated to whatever it should be used for.

Rakshasa used a standard way, on the contrary, do not mean to fully replace the original operating system: it wants to be as most transparent to the user as possible.

Therefore, the downloaded boot image will not contain a full operatig system, its code will only:

1. Contain all requested malware and payload (Kon boot, anti-security measures, etc.) and execute them in the requested order with some of them then staying resident in the memory,
2. Once all payloads have been successfully executed, it will give back control to the first bootable partition, ie. from now on the machine will retrieve a normal boot sequence.

As a side note (I don't remember if it was mentionned during the presentation), while this "first bootable partition" will usually be the hard-disk, it could also be a CD-ROM if the machine owner was booting from a CD instead of a hard-disk. This has some importance since it means that booting from a Live-CD as it is often recommended to avoid malware and backdoors will not bring any security against such threats.