Chesteroni's Blog: 2015

Recently I have purchased a book about The Metasploit Framework. The book starts slowly with the basics - what is the penetration test and what is not. Quite rapidly the reader is forced to dive deep into technical details - which is why I bought the book.
First - we are being told some technical basics - what is a shellcode, what is listener and how is metasploit built. Suddenly you know some entry points, e.g. MSFencode, MSFPayload, MSFCli and so on.
The book has no random chapters - the first two introduced the methodology and the basics of the main tool. In the next chapters we are doing a penetration test step by step. Starting with information gathering, vulnerability scanning we then learn how to maintain access using various techniques and how to avoid detection.
After that part the authors did not rest - they wrote a few chapters about other hacking techniques such as client-side attacks and social engineering - introducing another great tool: Social-Engineering Toolkit.
They also didn't forget about writing own modules for metasploit and creating own exploits. However own exploits are very underexplained - I really have no idea, how someone not already at least good in exploitation can understand how it works after reading that chapter. I know that that deserves to be detailed in a completely new book but I felt a bit disappointed because they didn't even wrote about bypassing DEP and ASLR.
The last chapters are about Meterpreter's own scripting language and simulated penetration test of 'Metasploitable' machine.
What I find the most useful, are the examples of use with real LHOST/ RHOST etc. values what makes the whole much more understandable.
Generally I found that book very useful - I learned about the basics and was able to test Metasploit against a test machine without any problem. Few things could be improved but if you want a good, technically correct starting point - that book is definitely perfect.
You may have some doubt because of the publishing year: 2011. That is an epoch in IT Security. However the Metasploit didn't change substantially and most of the knowledge (remember: basics!) is still valid. The book's knowledge is not too outdated to be obsolete and although the particular exploits changed, the mindset did not.

Linux allows users to use the so-called Full Disk Encryption and additionally the user's home directory. You can even use them simultaneously - double encryption is not the same as doubled ROT-13 ;-). However, encrypting the "whole" disk does not encrypt it totally and it is possible to steal the encryption password and leave backdoor in the user's system. Once you backdoor the system, the encryption is no longer the real data protection.

How does the booting process work?

On /boot partition there are vmlinuz and initrd files. The latter contains compressed RAM-disk image
In simple words (I do not want here to dive into BIOS details), during the boot process the initrd image is decompressed and becomes the basic system which allows the main system to run. The "init" process is responsible for running the system and if before that can occur - cryptsetup must be involved to decrypt the hard drive.

The problem

Imagine that you are the penetration tester and you have to hack into a workstation running Ubuntu, which are not so rare amongst the IT staff (Ubuntu is just an example, as this is the most popular distro). You boot the system, but you soon realise that the hard drive has been encrypted. One may think about the physical key logger but it is not an easy or even possible idea to implement with a laptop. With even a medium-strength password it may not be possible to decrypt the hard disk using a brute force techniques in a reasonable time frame.

The solution

You can boot that machine from the USB pen drive. Of course there may be some difficulty but it is always possible to overcome. Then you run already prepared bootkit and after the next correct booting the system by the legitimate user you will have remote root on that machine along with software key logger. It has been demonstrated on video here:

Preparing the bootkit

When you clone kitgen from GitHub, you see a bunch of shell scripts. Let's assume that your target runs Ubuntu 14.04 LTS with x86_64 architecture. Under kitgen/ubuntu_14.04_x86_64/binaries directory you see a script get_binaries.sh. If your pen drive's system is also Ubuntu, you can run that script. If it is other system - please copy to that directory binaries from Ubuntu, which you have to install somewhere else. The list of needed binaries is included within the get_binaries script.

I do not want to break the GPL and therefore it is not possible to distribute Linux binaries without providing the source code.

Also, under binaries, there is a payload directory. It should contain payloads which I intentionally did not include. But you have detailed instructions in payload/generators.

The last thing is to run kitgen/kitgen.sh which is a generator - it prepares the real bootkit script suitable to your needs - the targeted distro and the payloads' list of your choice.

How does it work?

When you run kitgen/pwn.sh after booting the victim from pen drive, the script mounts /boot partition and unpacks the initrd image on pen drive under kitgen/work_* directory. That image contains under scripts/local-top directory the file called cryptroot. This is a shell script which is responsible for decrypting the hard disk. Pwn.sh injects password capturing into that process and a shell payload. That payload uses the captured password to mount the encrypted partition and modify the system files. Only your imagination limits the possibilities, however three example payloads are included as a proof-of-concept.

The pwn.sh script also copies the binaries to the unpacked image because the basic image does not contain e.g. mount or mkdir capa.

The last stage is to pack again the initrd file and to put it on the /boot partition. That's all.

The payloads

I have included three payloads.

The first is a key logger. You can of course make it somehow with the root access but such an access is not always possible. And having key logger log file with the next physical access attempt may give you all the data (the password for encrypted disk is also written on /boot - look at the pwn.sh file configuration).

The second one is Meterpreter's reverse shell, very usable when you are running the Metasploit.

The third one is simple bash TCP reverse shell which only needs an IP and a port to run. You can always add your own or make some suggestions through a pull request.

How can you prevent such infection?

Basically... you cannot. But you can greatly reduce the risk. Below there are a few solutions that are worth mentioning and their analyses.

- Booting from USB - In my opinion the best and most cost-efficient option. If both GRUB and /boot partition are not on the machine but on a separate pendrive, there is no practical way of breaking it without capturing the USB pen drive. Protecting the pen drive is much more easier than protecting the whole laptop and requires the attacker to have a physical access to two things, not only one.

- Calculating the checksum of /boot - You can calculate /boot checksum from the external pen drive to verify its authencity - it looks quite good if you will do it at each and every boot attempt. You can even combine that method with the first one but it greatly reduces the usability. Of course after each kernel update you will have to update the checksum.

- Using TrustedGRUB - This method utilises the TPM and looks fine but... it is not well supported method and you are basically in a dead end with unsupported bootloader.

- Blocking BIOS/USB/CD/Everything - It is not a protection, it is only a minor difficulty. The attacker may simply use a screwdriver, get your disk out to their machine and then use what they need to infect. And also the machine's user will hate you and will try to work around your security means what is very dangerous.

Is such an attack a new concept?

Infecting initrd is definitely not a new idea, however such a generator greatly simplifies things and put some light on not a very popular attack vector. Many people using Linux are not aware of the initrd weakness and I was also surprised when I discovered that grabbing user's encryption password is such an easy task. In my opinion it shouldn't be. But nowadays, when BadUSB and Thunderstruck are in the wild, that is a minor problem. Remember that generally, when the attacker has physical access to your machine, they own it.

DISCLAIMER

You MUST NOT use the Kitgen nor the techniques described here against the system whose owner did not give you a clear permission to do so. Doing so may put you in jail and may result in financial responsibility. I am not responsible in any way for any harm that you may cause by any accidental or intentional use of described hacking method. You are acting on your own and I strongly recommend to do a backup copy and to re-assure the permission before taking any action.