 Hello, hi, is this okay? Can you hear me? Yeah, hi, I'm Camille Welcome to my talk about proof of concept Implementing evil mate attack on encrypted boot The talk has basically three main parts. The first one is understanding the basic boot process and it's about some Grub internals, then we will look at Exploiting evil mate attack on an unencrypted boot boot partition and we will see that it's very easy and Then we will switch to an encrypted boot partition and we see What changes and why it's not that easy to exploit it? What is this talk about and what not? And it's about Linux booting from BIOS MBR I'm using grub 205204 and looks as encryption. I Have it has to be I'm running Debian bullseye And this is not about any other operating system GPT or UEFI So let's start with the definition An evil mate attack is an attack on an unattended device in which an attacker with physical access Alerts it in some undetectable way so that they can later access the device or the data on it That's for example, you stay here in Karlsruhe and during the day You're here, but you leave your laptop in the hotel and someone has access to the laptop and can modify some data on the Laptop and this is the scenario. We're speaking here The technical problem is that the code that asks you during boot for the root password And for the full description password. It's not encrypted and it's not signed so an attacker can just modify this code and Can get the password The motivation for this project and this talk was that I couldn't find a proof of concept for an evil mate attack on Encrypted boot partition so I was motivated to write one and I'm really fascinated about Linux and learning basic stuff like what happens during boot And we will start by understanding the boot process From a high-level perspective The BIOS loads the boot loader, which is grub in our case Grub as the boot loader has the the task and goal to To run the operating system. So it first loads and executes the kernel and the init-rd init-rd is a temporary root file system init-rd mounts the root file system and Executes the init system like like system D and the init system starts services like SSH Yes, as I said grub has the main goal to run the operating system it has to handle limited space and Therefore it runs in multiple stages and As there are many different cases how a system can look like It uses modules and builds everything together with the modules to successfully boot a system so The first sector of the hard drive is a master boot record It contains Stage one of grub so grub has three stages stage one stage 1.5 and stage two The first 446 bytes are stage one of grub Then there are four partition table entries and at the end there is a magic number As there is not that much space the only task or goal of boot image Or stage one is to load the next stage with which is stage 1.5 or called core image Core image is stored At sector one so it's just one sector after the master boot record which is In many cases the space before the first partition Stage two is basically everything in slash boot. So the task of core image is to get access to slash boot and There are many Cases how a system can look like in the simplest case You just need to read data from the disk as you see need to speak to the disc Speak with the disc and understand the file system. So then you can mount slash boot but there are other special cases like booting from network peaks e Using all the discs or LVM or in our case later We are using for this encryption for slash boot So we need to decrypt the disk at this point and we need to speak with a keyboard and there's a keyboard layout So there are many things that can be part of core image and Yeah, to sum up it's the goal is to get slash boot Then in stage two There's a central configuration file grab dot config. We will see that later it contains The Linux kernel and the init rd It loads the kernel into the memory it extracts itself so the kernel is running then the init rd is Extracted and mounted and there are tools and scripts that first mount the file system therefore it needs to decrypt the disk and Then it starts in its system. We can take a look at how this works on Linux or how it looks like I have a test VM so if you want to use grub as bootloader you basically use grub install and use the The disk you have This is how you just install it It's a very common and well-known command and it's followed by an update grub which generates the grub configuration file I just want to show you the disk layout It's a little bit more complicated that it needs to be but there's basically one disk VDA with a 5 gigabyte gigabyte of size and The partition VDA 5 is a looks container containing LVM volumes and there is the root file system here As you can see there's no mount point for slash boot. So Boot is part of slash and it's also encrypted We can take a look at the master boot record using a DD so we say in input file step VDA and block sizes 512 count one and We remove This oh, yes, we need it Hex dump Yes, so we see the magic bytes at the end 5 5 a a right in front of it. There's the space for the boot for the partition table and Everything before is just stage one of grub which is a sampler code that is loaded into memory and executed and The task is to load the next part There's a file on your system called boot image It's placed in user lip something something and it's part of a package. It's part of grub PC bin and if you look at it you will Find out that it's very similar to your master boot record And this is very typical for grub which uses template files and it modifies some bytes and then writes it to disk One cool thing is that you can run grub install With minus V and you get verbose output. I will redirect it to in file As you can see there's a lot of things happening here and If we grab this output For core image Now we can see that grub install calls a tool called grub make image and this one creates a file Namely our core image This is The output so it's in slash boot. This is where core image is stored and later. It's written to disk So grab install innumerates the system what is needed to boot the system and you can see here These are all modules which are required. So x2 LVM crypto stuff And then we have a core image which is then stored at disk so this was oops This was stage one and stage one point five. Let's look at stage two. So everything in slash boot There's a config file in boot grub, which is grub.config. This is the central config file If you call update grub Then it's basically a wrapper. It's calling grub make config and outputs the grub file the grub config file What it basically does it goes to DC grub d And there are some baskets If you try to execute them You can by hand because you need to source some files before and this is basically what this Grub make config does it source some files. It's for example the well-known ETC default grub It's just get sourced And then for example here you can specify curdle parameters you want to have and if you check out the The grub config file You will see that Here begin grub d00 header. So it's basically the best script print staff and everything concatenated builds your grub configuration This is what it looks like in the grub configuration file Later it looks Whoops like this one It's not that sharp, but You basically can change this configuration and Edit for example add a kernel parameter in it bin bash This line for example in smart This every every line here is a command At this stage of doing boot and it loads a module for example in slew slash boot and You can look for crypto disk and we'll find that there's module with this name and Later you see a crypt mount command and And also in slash group a boot grub There is a file command Some great It's here and it shows you that the crypto mount command is part of the crypto disk module and There's two there are two echo commands as you can see them during boot this specifies The Linux kernel and parameters So this is basically what you can specify in the ETC default grub And this is where the init root system lays Yes, so basically What happens here is The kernel Is loaded into memory extract itself then we have the kernel running then init rd is loaded into memory extracted and then Yes, it months the disk in case of encryption It needs to be crypto disk first and then runs the init system. We will see that later Just Okay So now as we got some basics, let's talk about evil made attack on unencrypted boot partition The first question is where does the decryption takes place? In this case it takes place in slash boot to become To specify it's part of the init rd There is a crypto set up binary, which is called I can show it to you. So we can go It's gtzip so we can set cat it and it's a CPIO archive and we need this one IDMV and Now we can extract the init rd There's this init file, which is called which is basically a batch script And at the end of the batch script, there's something called run init and this is the part where It calls your init system Which is normally as been in it and it knows at this point the The mount point of the root file system where all your data lies In the script there are there are other scripts that are called. They are placed in the scripts folder and somewhere here there is The crypt setup binary is called from there. So there is the crypt setup binary somewhere here Yes, so We extracted the init rd. We can now modify some files rebuild it and That's our attack scenario you can Patch the crypt setup binary to dump the password the user enters or you can use one of the best To ask the user for the password if you just do Yes print and ask the user for the password and then you can add a look At another key slot Yeah, so basically that's it as a conclusion Exploiting this is very easy because you just have to modify a batch script and there are GitHub repositories You can just use them and exploiting is very easy So let's move on and let's pretend the boot partition is encrypted What changes? So now you can't just patch the init rd because it's encrypted and you don't have the password But the problem still remains which means the decryption code is still unencrypted and you can modify it as an attacker but it's harder to implement and As I couldn't find some information on the internet my idea was to let's build an exploit try this So again the same question. Where does the decryption takes place? As slash boot is encrypted It needs to be somewhere before and boot image has only about 400 bytes. That's not enough So it's somewhere in core image. So I needed to look at core image and as I've said core image is generated by the grub make image Executable and this is called by the grub install. So I just checked out the code and and Read the code try to understand the code This is the high-level structure of core image It's a concatenation of disc boot image lzma decompress image and Compress stuff The disc boot image is basically just for bootstrapping to load the rest of core image lzma decompress is the code to decompress data that is compressed with lzma The compressed stuff is a kernel image This is not the Linux kernel you have to keep in mind that at this point during boot you don't have the Linux kernel running and You don't have a file system. So there's basic Functionality that you need to implement and this is part of this is the task of kernel image Then there's a struct grab module info which holds just information about how many modules are part of core image and The modules have each one has a type size and the actual content For example module the most modules are elf binaries. So the kernel also needs an elf parser Sorry, yes, how can we exploit it? Sorry? We Can extract core image because it's not encrypted We can analyze it. I tell you in a moment why that this is important then we can Patch the looks module. It's the wall. That's this is where the decryption takes place. I Needed to add disk mod as a dependency to the core image Because otherwise I couldn't write a disk Then I can rebuild core image right into disk and during next boot My code gets executed. I can dump the password Okay So the output of grab install shows us how The core image is built we can call it directly and we can see that It's using the kernel image Elsa may decompress the disk boot image and This is basically the list of the modules that are included This is the looks module that I want to patch and the output file is this So it's 54 kilobytes Now from an attacker point of view I Have access to the disk. I can plug it to my PC. I Have it in this case here as a file and The first thing I can do is I can extract core image Because I know where it is. It's in the first sector. I know the length. It's part of the core image So I have here The image it's a little bit bigger Okay, then I wrote an analyzer so I can analyze the core image so we can now see all the modules and Have all parts that is included into core image As you can see a type zero means elf binary. There's a size and There are other types Which holds configuration or identify and at this point I Know that there are binary edit our modules and there are elf files But I don't know which one is the looks module. So what I do is I calculate the md5 hash sum And I have not in folder with Mods DBN 11 which stores all modules. They are public because they are part of the DBN system packages And so I can find which module is actually which module. So looks module is this one so the next steps are patching the looks module Rebellion core image and deploying it to the disk. I had the problem Cross-compile it from art and it didn't work So I Rebuild looks module on My DBN system. There is a file in grab core disk looks dot C So if you just build the whole thing this file gives you the looks module and My patch is basically Hmm, I wait for the user to enter the password then I check or I wait Until the check succeeds. So it's the valid password and my backdoor is a debug print. Thanks for your password I'm writing it to the disk. I open the first disk and Then I write the passphrase to the first disk at sector 2023 just because it was Zeroed out in my case I tried this and it didn't work and if you have yeah You don't have any debug output or Logging or something. So it just doesn't work and It makes sense that it doesn't work because grab disk right week is just not existent Because normally you don't need to write your disk during boot And that's why I needed to add the disk module as part of the module list And then it worked So I can compile it then I have my modified looks module I can put it to the attacker machine Then I have a script to Backdoor the core image and there are two important things as I just said here Loading the disk module and edit it as first module and I replaced the looks module with my malicious one and this gives me a new generated core image. I can analyze it and As you can see the first module is now the disk module and There's not the default looks module Instead, there's the looks backdoor working building on a Debian back module All right, and then we need to deploy to the disk so I have here a simple basket which first Makes a backup of the master boot record Then I zero out everything until the first partition starts with its sector 2048. I Restore the MBR and then I flash my core image Right after the master boot record. So block size 512 and seek one block We can do this But maybe we just stopped the VM before I have also a script or yeah, that just dumps me sector 2023 and it's empty right now. Now we can deploy the core image And if we boot again, I Can enter my password one two three and then you can see thanks for your password one two three writing it to disk and it's booting normally and Now I get the password one two three Yes So how can we fix it you can Store grab on an external USB drive. So the master boot record and core image Or you can move to UEFA and use it with secure boot It's not that hard to implement it if you're interested. You can just check out this repository. There are some tools and it's very easy to deploy and another learning that I had is If your system fails to boot just rebuild the broken stage So if you you've seen it or you know it if you boot your system There are a lot of debug messages or in general. There are a lot of messages and As an exercise try to map which Message belongs to which component So you have the the buyers Three stages of grub. There's the kernel in it rd the init system and Try to match each line of output to the to the component. So who locks which message and If something fails, just rebuild the stage so for example Refresh your bias here reinstall the the the kernel package or rerun grab install in a change route environment and That's basically it and I will publish the code and the slides on github the next days and Now I'm happy to give some Q&A Thank you very much Camilla for showing us how the Linux boot works and how you modified it So anybody who has questions, please raise your hand and I will come and You can speak them into the microphone I just wanted to add to your list of fixes that there is an from your honor wood coughs car the one of the Devs of Cube so as there is an anti-evil made system that works on pretty much all linux that works with the tpm to verify every Code that is run Any more questions, so There was one Where? I can see there's another one. I've got installed Linux with set-apid file system on boot and I've tried to install a group to the boot section and Had the problem that The parameter the node size isn't recognized by quip and This was added to an unknown file system error Do you know what's the issue for this no Sorry Are there any more questions I can't see any so if there are No questions anymore. Thank you very much. Can we do a round of applause, please?