Setting up a sandboxed hacking lab in Virtualbox

Most of the newbies who wants to learn some hacking skills doesn't how to start and are a little confused. This article is about setting up a sandboxed secure hacking environment through which anyone interested in practicing some hacking is able to do so without worrying about breaking the law or attacking unauthorized targets. The most important point when setting up a sandboxed environment is to isolate the network, i.e, ensure that any packet has no chance to escape outside of your network. The very first time that I built my own hacking environment I was a little  bit puzzled about how to isolate my virtual machines from my network. Thank goodness the inventors of the Virtualbox hypervisor put things very easy in order to achieve so. I want to clear up  that this article is about setting up a hacking VIRTUAL environment rather than a physical one. The easiest way to create a physical isolated environment is to physically disconnect/unplug your network from the Internet and check that your wireless Network Interface Cards are switched off.

All right! Firstly, let's start explaining/clarifying some concepts. In particular, I'll introduce you the term sandboxing and the different network adapter options that Virtualbox provides us as well as different virtualization terminology, such as hypervisor and virtual machine. Finally, I'll show you which choice among the different ones is the perfect candidate to configure our sandboxed/isolated environment along with the needed configuration paramaters, such as Dynamic Host Configuration Protocol server, etc.

Sandbox in terms of security is a mechanism that separate running programs with the intention to avoid system failures, test unverified software that could end up being malware, analyse malware behavior, and so on. Virtualization is an example of sandbox implementation and it means to create a virtual version of whatever (hardware, network resources, storage devices, etc.). Hypervisors, aka Virtual Machine Monitor (VMM) allows a user to create, manage and govern multiple virtual machines which are sandboxed from the rest of the other systems, i.e, they are isolated from the other virtual machines as well as the host. The hypervisor is normally a piece of software that is in charge  of allocating the different hardware resources to each of the guest systems avoiding interruptions among them. Manufacturers commonly provide graphical interfaces for hypervisor configuration. On the other hand, virtual machines are just emulated entire computer systems.

Source: https://www.howtogeek.com/66734/htg-explains-what-is-a-hypervisor/

Now that I've explained superficially

UEFI Secure Boot: Signing kernel modules (Linux - Ubuntu)

After many times setting up different virtual labs by means of different hypervisors, such as Vmware Player and Virtualbox, there was once that I got struggled with starting up my already configured virtual machines and make their network capabilities work. After a little bit of investigation through Google along and thanks to the different output errors and my years of experience using Linux systems I realized that the "problem" was something called UEFI Secure Boot or Trusted Boot. Briefly, Secure Boot is simply a verification mechanism that takes place during the start-up process with the aim to prevent malicious code of being loaded and therefore to gain access to the computer. It just allows to load components trusted by the manufacturer or the user, i.e., signed binaries and kernel modules that are already signed by trusted keys. The term UEFI (Unified Extensible Firmware Interface) is basically the surrogate of the old and well-known BIOS (Basic Input/Output System) which includes such validation mode.

Throughout this article I will follow the same problem I faced when trying to launch my virtual machines. Moreover, I want to point out that this article is focused exclusively on signing kernel modules rather than other components, such as kernels, bootloaders, etc. I won't dive into many of the underlying concepts in detail, such boot process, key databases, machine owner keys (MOK), shim, certificates, cryptographic keys, etc. (just google it if you feel inquisitive). Some of those concepts will just be mentioned and others briefly explained for a better understanding.

Firstly and briefly, secure boot feature appeared in Windows 8 presinstalled computers. Ubuntu 64-bit versions support it as well. In few words, the concept of secure boot in Ubuntu requires the existence of  a chain of trust from the very first thing loaded (firmware), all the way through to components load by the O.S as part of the kernel, such as modules:

1. Root certificate (Microsoft) used to validate the shim binary.
2. A Canonical certificate along with a trust database is embedded in the shim. Such certificate is used to validate further components (bootloader) signed with the corresponding Canonical key. Everything else falling aside will require to be self-signed by the user herself.
3. Further signed components (GRUB binary, kernel, modules, etc.) will be validated against the trust database (any component signed with any trusted key is considered official/trusted in the Ubuntu realm and therefore it won't be refused). For instance, in order to load a kernel this must be signed to be allowed to load by GRUB (default bootloader) when secure boot is enabled. Disabling validation in shim as well as own signing process are two solutions to allow unsigned kernels to be loaded. 

The origin of the problem was that some critical kernel modules needed to properly run Virtualbox were not loaded into the kernel upon deman. But why?

The reason why is what I've earlier explained. Such modules are considered third-party/unofficial modules because they are not signed by any trusted key (neither Canonical's UEFI key) and from Ubuntu 16.04 is required that all the kernel modules are signed to be loaded during the start-up time (only if Secure Boot is enabled). Thus, when booting up my laptop with the secure boot enabled it was not possible to load those modules during the start-up process due to unsigned modules are refused as well as modules signed with untrusted keys (keys that are not contained in the trust database). If you try to insert those modules with modprob the process will just fail.

Third-party drivers are not compatible with Secure Boot enabled. Regardless, there are some possible ways to overcome this problem:

1. Disable the secure boot.
2. Do not use third-party drivers.
3. Sign those third-party modules.

The first solution is as simple as either disabling the Secure Boot mode through the PC's firmware menus or by just typing the following command and reboot the PC:

$ sudo mokutils --disable-validation

Disabling secure boot might be seen as the simplest solution. The weak spot of this fix is that your PC becomes more vulnerable and therefore the attack surface grows. Depending on the scenario you are facing it might be necessary to do so.

The second solution is not worth it at all. Avoiding third-party software is just foolish. At some point you will need to make use of "unofficial" software whatever your needs/motives. The non-use of third-party software is not even a choice to keep in mind.

Finally, although the last solution is the most confusing among the 3 solutions previously proposed, it is the most coherent one. Before starting to sign kernel modules it is necessary to create a Self Signed Certificate for module self-signing. The private key is generated simultaneously and the public key is part of the certificate itself:

$ openssl req -new -x509 -newkey rsa:2048 -keyout VIRTUALBOX.priv -outform DER -out VIRTUALBOX.der -nodes -days 36500 -subj "/CN=Virtualbox/

Once the public certificate and the private key are created, I would recommend you to keep both in a secure location (encrypted external storage if possible) and change their access permissions. Specially the private key should be well-protected because if an attacker succeeds in getting your key she will be able to generate binaries and therefore sign them. Your PC would accept them as trustworthy.

The next step to follow is to enroll the public key certificate, i.e, the .der file in the shim. The MOK utility is in charge to manage the use of user-provided keys in the trust of chain. The machine owner keys are keys that users generate to sign binaries and thus give them the ability to run, in this case, third-party kernel modules (it could also be bootloaders not delivered by the distribution maintaner, locally-compiled kernels, etc.). To enroll a key in the shim simply issue the following command and reboot (shim will display a blue screen before loading GRUB). Verify that the key has been enrolled afterwards:

$ sudo mokutil --import VIRTUALBOX.der
$ sudo cat /proc/keys 

Shim UEFI Key Managemen

All right, let's go now to sign things. In order to sign the kernel module there is a fabulous and handy tool in Linux called kmodsign (it only signs loadable kernel modules rather than kernels or bootloaders). We need the two keys previously generated and find out where the module is located. Loadable kernel modules have the .ko extensions at the end of their names.

$ sudo find / -name vboxdrv.ko

$ sudo kmodsign sha512 VIRTUALBOX.priv VIRTUALBOX.der /lib/modules/$(uname -r)/misc/vboxdrv.ko

CONGRATULATIONS 😋! Try to launch again your virtual machines to verify that the old output error doesn't longer appear.

References:

https://blog.ubuntu.com/2017/08/11/how-to-sign-things-for-secure-boot

http://www.rodsbooks.com/efi-bootloaders/secureboot.html#preloader

https://wiki.gentoo.org/wiki/Signed_kernel_module_support

https://wiki.ubuntu.com/UEFI/SecureBoot

  

Welcome!

The intent of this blog is twofold: publish, mainly, security-related issues that I come across in my day-to-day along with their solutions as well as a brief explanation of what's going on behind the scenes. The second objective is to clarify security concepts that might be sometimes confusing and messy.

 Why so?

Anyone who works with computers knows that such complex machines are not "straighforward" at all in the sense that your objectives are most of the times not achieved because of unforeseen incidents along the way.  For such reason I want to help out those people who sometimes get stuck with completing their tasks and don't know how to continue. Those hurdles might be a break on our final goals.

Google is largely the go-to tool to resolve all your uncertainties/troubles. It is most of the times tremendously useful but the other few times can be a pain in the neck because there are tons of information about one specific matter out there on the Internet. Besides, many times you search on google for a solution you end up having countless of open tabs blowing up your mind. My intention is to try to get you out of those troubles/obstacles. I also want to point out that all of the examples published in each article are truly reproduced by myself.

On the other hand, as a security enthusiast and practitioner I think that lots of the existing security concepts can be sometimes ambiguous and difficult to truly understand. Because of this I will also try to publish articles clarifying/explaining messy security concepts that I find interesting in the best way possible.

I hope you find this site useful  somehow. I will try to do my best and cover the fundamentals in each of the articles to HELP YOU OUT.