Shell Upgrade

Some Linux systems use restricted shells to keep users in a secure sandbox. Restricted shells limit the commands or applications that can be used. Common examples are found in the Bash shell using rbash or bash -r , in the Korn shell using rksh or ksh -r , and in the Bourne shell and similar shells using sh -r or rsh .

Restricted shells commonly prevent users from changing directories, setting PATH or SHELL variables, specifying absolute pathnames, and redirecting output. Some may even add additional limitations, which can be frustrating when attempting to compromise a targeted host from a restricted account!

Fortunately, breaking out of restricted shells can be as simple as starting a new unrestricted shell or using a utility like vi that has a built-in shell function to escape the Attacking Hosts329restricted shell! In general, when you are confronted with a restricted shell, you should do the following:

• Check the commands you can run, particularly looking for SUID commands.
• Check to see if you can use sudo and what sudo commands you can execute.
• Check for languages like Perl, Python, or Ruby that you can run.
• Check to see if you can use redirect operators like | or > and escape characters like single quotes, double quotes, or other execution tags.

VM

Attacking individual virtual machines normally follows the same process that attacks against a physical system would. In fact, in many cases you won’t know if you’re attacking a virtual machine, a container, or a physical machine until you have compromised it (and perhaps not even then!). If you suspect that you have compromised a virtual machine, you can look for common signs that the system is virtual, including the hardware that is presented to the operating system. In many cases, checking for the network interface card, or for virtualization plug-ins like VMware tools or VirtualBox extensions, can tell you if you have compromised a VM. On a Windows system, you can do this quite easily by using wmic:

wmic baseboard get manufacturer,product

The Linux system-detect-virt command is an easy way to determine what virtualization package is running if the system is running system-d. Other options include using the demidecode command, which can provide similar information, and checking the disk IDs to see if the system is being virtualized by using the ls -l /dev/disk/by-id listing command.

Virtualization is rarely obfuscated in real-world production system environments, so detecting virtualization should be possible on most systems you encounter. Once you know which hypervisor you are dealing with, you can conduct research on the attack methods that may be available for that specific environment.

Exploit tools that allow attackers to escape a virtual machine to directly attack the hypervisor have been sought after for years, with high prices paid for working exploits on the open market. Exploits have been found for VMware, Xen Project, Hyper-V, and VirtualBox, but each has been patched shortly after it was found. In most virtualization environments, VM escape isn’t likely to work unless a new exploit is introduced and you are able to use it to exploit a compromised host before it is patched by your target organization. That means that most penetration testers will be far more successful attacking the underlying administrative infrastructure so that they can access the virtualization management tools and systems than they will be if they rely on VM escape exploits.

Container

Attacks against OS-level virtualization tools like Docker often start by compromising the application that is running in the container. Typical penetration testing processes can be used, including port and vulnerability scanning and service exploitation. Once you have compromised a container, you can then attempt to access the container’s host — in fact, in some cases, like the vulnerable Docker instance that Not So Secure provides, you can simply run the Docker client from one of the vulnerable Docker containers and connect to the Docker daemon running on the virtual machine! As with most penetration testing efforts, you should carefully document the environment, check for misconfigurations and exposed or vulnerable services, and then pivot as you gain further access.