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.
Links:
*Kitgen itself:
The main concept utilises the knowledge from the pages below:
- https://twopointfouristan.
wordpress.com/2011/04/17/ pwning-past-whole-disk- encryption/ - http://code.google.com/p/
logkeys/issues/detail?id=108 - comment 11 - http://www.linux-sxs.org/
storage/fedora2ubuntu.html
Also worth mentioning are:
http://www.phrack.org/issues/68/11.html - point 5.2
Brak komentarzy:
Prześlij komentarz