Questions regarding Rakshasa

Question

Regarding Jonathan Brossard's Hardware Backdooring is practical talk at Def Con 20 in 2012:

What does the developer mean by "The payload is booted via Networkboot"?

How does the bootkit (a modified version of Kon-Boot) infect the connected hard drive remotely?

Does this mean that there is a boot partition somewhere on a server and Rakshasa connects to this partition and makes it so to say the boot partition of the physically connected hard drives on the victim's PC?

Answer 1

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.

Answer 2

Yes, you have correctly concluded what Rakshasa is doing, except that the hard drive itself is never infected, nor does it have any evidence of the compromise. The compromise lives exclusively as non-malicious code in BIOS, which loads malicious code from a network server that lives exclusively in RAM.

That's a long video for us to watch and review, so I just skipped around a bunch and read the DarkReading writeup and therefore may have missed something key. If so, please note a range of times that are relevant to your question.

I'm looking at the slide at 12:22 which talks about using iPXE, which is a network boot system that Wikipedia notes "can be used to enable computers without built-in PXE support to boot from the network, or to extend an existing PXE client implementation so it supports additional protocols."

iPXE is used to boot the system over the network, pulling the bootkit from a remote host. At 16:29, speaker Jonathan Brossard notes:

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

This is a full network boot system. As noted in another slide (at 16:09), "Malware: fetched at boot time, only stored in RAM". KON-BOOT, a bootable Live CD used for password bypassing (erm, "recovering"), is a wrapper around the local OS (be it Windows, OS X, or Linux) that grants root/Administrator access without a password. Rakshasa's modifications introduce further malware to this compromised system.

With full root access and both a compromised BIOS and a compromised kernel, Rakshasa can then do pretty much anything. Brossard has chosen to compromise a number of CPU instructions and introduce anomalies that enable further trickery.

 

Regarding Linux: It appears Linux support has been removed from KON-BOOT documentation, though I suspect it's still there. Breaking into Linux with a boot disk is actually trivial: boot any Linux Live CD, mount /etc, and alter the root user's password hash in /etc/shadow. This can even be done non-destructively using something like UnionFS without ever touching a local disk.

However, that's just how to gain root access.

To do the types of things Rakshasa appears to do, a custom kernel (or custom kernel module?) would be needed. Supporting every single Linux kernel out there is impractical unless we're talking about a highly targeted attack, so I'd imagine an attack framework would only support systems like Ubuntu LTS and Red Hat Enterprise, neither of which vary much over time (and both of which are quite popular).

If /etc is encrypted, it is less likely that your shadow file will be mucked with, though UnionFS could theoretically trump it without needing to read it. That said, loading a rogue kernel (or rogue kernel module) would allow an infinite realm of things and would preclude needing the shadow file at all.