Common *nix Attack Techniques

Commonalities Among *nix-Based Vulnerabilities

The *nix-based operating systems all have their roots in Unix. Besides the various forms of Unix itself, this OS family includes Linux, Android, macOS (and its BSD-based predecessors), iPhone iOS, and others. Vulnerabilities for *nix-based operating systems have the following commonalities:

• All of the generic risks apply, including physical, administrative, coding, and social engineering.
• Although the *nix OSs have more kernel types than Windows, they are still written in some variant of the C programming language. They have the same inherent risks related to insufficient input validation and lack of bounds-checking.
• Although the open source community (in theory) has “more eyes” vetting the software, incorporation of secure coding best practices is inconsistent among developers. For example, Apple iOS has a very strict application vetting process, requiring apps to be digitally signed with an Apple-supplied certificate before they can be installed. Linux and Android, on the other hand, allow apps to be side-loaded or installed without digital signatures.
• The *nix-based OSs are also subject to cross-platform exploits including POODLE, Heartbleed, XSS, XSRF, SQL injection, and SMB overflows and enumeration.

As a pen tester, you will use the same methodologies with *nix OSes that you used with Windows to find vulnerabilities and exploits.

Note: Most Android apps are written in Java, and many userland (non-kernel) Linux components are written in Python.

---

Linux Operating System Vulnerabilities

The name “Linux” actually refers to the kernel of the operating system. DistroWatch.com reports that there have been (so far) nearly 800 Linux distributions, or distros, since 2001. Some are commercial products, though the vast majority are developed and maintained by the open source community. Many no longer exist. Because there are wide variations in distribution features, there are also wide variations in vulnerabilities between the products. Many vulnerabilities are introduced because of services and applications that are added to the core installation.

Linux vulnerabilities fall into the same major categories that are found in Windows. The following list shows the top vulnerabilities in order of descending frequency:

• DoS
• Information disclosure
• Buffer or heap overflows
• Privilege escalation
• Remote code execution
• Memory corruption
• Security feature bypass
• Directory traversal

Note: Data obtained from https://www.cvedetails.com/top-50-products.php

---

Frequently Exploited Linux Features

Exploit-db.com lists 1,214 exploits related to Linux. The Metasploit query grep -c exploit search platform:linux returns a count of 293 Linux exploit modules. The following table summarizes some of the most notable Linux vulnerabilities of all time.

Vulnerable Feature	Description	Exploits and Tutorials
ret2libc	An existing function in the C library that eliminates the need for the attacker to inject their own shell code to take control of a target. This result allows arbitrary code execution and escalation of privilege.	https://www.exploit-db.com/docs/english/28553-linux-classic-return-to-libc-&-return-to-libc-chaining-tutorial.pdf
Insecure sudo	Under certain conditions, this vulnerability allows attackers to circumvent protections and execute commands that would normally require a password, resulting in privilege escalation.	Exploit-db.com lists 24 sudo-related exploits.
Sticky bits	Sticky bits are permission bits set on (mostly) directories. They only permit the owner to delete or rename files in that directory. They are especially useful in the shared directories of /var/tmp and /tmp. Sticky bit exploits can be disruptive and cause denial of service.	https://www.exploit-db.com/exploits/16216 https://www.thegeekdiary.com/what-is-suid-sgid-and-sticky-bit https://gist.github.com/anonymous/10165224
SUID executables	SUID allows a user to run a command as another user. It is often used by administrators to change a user’s password. When an application needs to run as the owner, an SUID permissions bit is set to allow this. A number of executables use SUID, but are poorly coded and can allow an attacker to escalate privilege. Note: This same technique can be used for setting the group ID (SGID).	https://www.pentestpartners.com/security-blog/exploiting-suid-executables
Dirty COW Bug	A race condition in mm/gup.c leverages incorrect handling by the copy-on-write (COW) feature by kernel memory subsystem /proc/self/mem. Allows writing to private, read-only memory mappings. Affects Linux kernel 2.6.22 < 3.9 (x86/x64). CVE-2016-5195.	https://www.exploit-db.com/exploits/40839 https://www.exploit-db.com/exploits/40616
Five Year Bug	A race condition created by raw mode PTY local echo permits privilege escalation. Affects Linux kernel 3.14-rc1 < 3.15-rc4 (x64). CVE-2014-0196.	https://www.exploit-db.com/exploits/33516
Remote Root Flaw	Unsafe second checksum in udp.c can give a remote attacker complete control of a system via UDP traffic. Affects pre-4.5 Linux kernel. CVE-2016-10229.	https://www.rapid7.com/db/vulnerabilities/panos-cve-2016-10229

---

Password Cracking in Linux

As with Windows, there are a number of ways to crack passwords in Linux. The concepts are the same, but the location and format of the files are different. Originally, passwords in Linux were stored in cleartext along with their user accounts in /etc/passwd. For security, they are now stored as hash values in /etc/shadow.

Here are some common attack methods and sample tools.

Attack Method	Tools
Brute force the login passwords of services such as SSH, telnet, FTP, HTTP, Samba, VNC, etc.	John the Ripper Medusa Hydra Ncrack Crowbar Metasploit modules such as: auxiliary/scanner/ssh/ssh_login auxiliary/scanner/ftp/anonymous auxiliary/scanner/ftp/ftp_login auxiliary/scanner/vnc/vnc_login auxiliary/scanner/smb/smb_login
Copy the /etc/passwd and /etc/shadow files, unshadow (combine) the copies, and send them to a password cracker.	John the Ripper, etc. (see previously listed tools)
Dump the hashes from a compromised machine and send them to a password cracker.	Metasploit module post/linux/gather/hashdump John the Ripper, etc. RainbowCrack Hashcat
Dump cleartext passwords currently stored in memory.	Mimipenguin—https://github.com/huntergregal/mimipenguin
Pass the hash if the passwords take too long to crack. Works particularly well against Samba with LM or NTLM authentication.	Metasploit module auxiliary/scanner/smb/smb_login
Install a physical or software-based keylogger to capture login credentials.	Meterpreter keyscan_start and keyscan_dump Hardware-based USB keyloggers
Use social engineering to obtain user passwords.	Shoulder surfing Mobile device across-the-room camera recording Kali Social Engineering Toolkit (SET) WiFi-Pumpkin
Boot target into single user mode.	Reboot the computer and interrupt the boot process. Edit GRUB to go into single user mode, where you are automatically logged in as root with no password. Change the password. Requires physical access. Works for Red Hat and other distros. Does not work for Debian-based distros, including Kali.

Note: Metasploit has many modules that will attempt to brute force or bypass the login of specific services, particularly those that are HTTP-based. To find more examples, conduct a Google search. Alternatively, at the msfconsole, enter search auxiliary/scanner, search login platform:linux or search login platform:linux -S http.

Linux /etc/shadow Hashing Algorithms

The hashing algorithm used in /etc/shadow depends on the distribution. It can be MD5, Blowfish, (or more recently) SHA-256 or SHA-512. To find the hashing algorithm in use, at a terminal window, enter the command sudo cat /etc/shadow. Look for hashes that begin with a $ and compare them to this list:

• $1 = MD5
• $2a = Blowfish
• $5 = SHA-256
• $6 = SHA-512

https://www.dcode.fr/sha512-hash

https://crackstation.net/

Note: For more information about Linux /etc/passwd, at a terminal window, enter man 3 crypt.

---

Linux Service and Protocol Configurations

The same types of issues that apply to Windows service and protocol configurations also apply to Linux. As with Windows, most Linux distros ship with default services, but many are added after installation. The key difference is that Microsoft provides the software for most of the common Windows-based services. Linux, on the other hand, depends on third parties to develop and provide the software. You choose the application you want, and download the package that is appropriate for your distribution and platform. This “mix and match” approach makes the range of possible service and protocol configurations much wider in Linux. As a pen tester, you should research possible exploits for the Linux kernel, service/application, and protocol versions that you discover.

Some notable exploits that have affected Linux services and protocols include the following.

Exploit	Description
GHOST CVE-2015-0235	Exploits how the popular EXIM mail server uses the gethostbyname function in the GNU C library (glibc). Can give an attacker remote control over the entire system. Affects nearly all distros that have EXIM installed. Metasploit module exploit/linux/smtp/exim_gethostbyname_bof.
Shellshock CVE-2014-6271, CVE-2014-6278	Exploits a vulnerability in how the Bash shell handles external environment variables. Exploit-db.com lists 15 exploits. Metasploit has 10 exploit modules; search shellshock.
Heartbleed CVE-2014-0160	A platform-independent information disclosure vulnerability in the OpenSSL encryption library. OpenSSL uses a special heartbeat message that echoes data back to confirm that it was received correctly. If exploited properly, it can induce the server to also echo back random data from memory, including login credentials and session cookies. Metasploit module auxiliary/scanner/ssl/openssl_heartbleed, https://gist.github.com/eelsivart/10174134
POODLE CVE-2014-3566, CVE-2014-8730	A platform-independent man-in-the-middle attack that forces web servers and browsers to negotiate down from the stronger TLS to the weaker SSL 3.0. https://github.com/mpgn/poodle-PoC

Linux Service Installation Methods

The most common installation commands include:

• Debian/Ubuntu APT apt-get install <package name>
• Fedora/Redhat yum yum install <package name>
• Mandriva URPM urpmi <package name>
• SUSE YaST yast -i <package name>
• Generic source code, often distributed as a tarball tar -xzvf <name>.tar.gz

---

Linux File Systems

The Linux file system is organized differently from Windows. Rather than starting the directory structure at the volume level (C:, D:, E:, etc.), the entire system is a virtual tree structure organized under / (pronounced “root”). Under the root are a number of top-level directories, including:

• bin—binaries
• boot—system boot files
• dev—a virtual directory of device files (like USB sticks, webcams)
• etc—configuration files
• home—users’ personal directories
• lib—libraries (application code snippets)
• media—where inserted removable media is mounted
• mnt—(legacy) where storage or partitions are manually mounted
• opt—where software you compile often ends up
• proc—a virtual directory that contains information about running processes
• root—home directory of the root superuser
• usr—shared application files
• sbin—applications only the superuser can run
• srv—data for servers
• sys—virtual directory about connected devices
• tmp—temporary files
• var—logs

Linux File System Navigation

Here are some key points to remember when navigating the Linux file system:

• The Linux Bash (command-line interface) has its own commands that are case sensitive and (mostly) different from Microsoft DOS commands. Examples include:
• ls -l—list files in long format (show file type, permissions, owner, group, size, last modified date and time, file name)
• cd /—change directory back to /
• pwd—display the present working directory
• cd ~—change directory to the current user’s profile
• Use a forward slash (/) to separate path levels. For example:cd /root/Desktop leafpad /etc/network/interfaces
• Everything, including running processes, is treated as a file.
• Files with spaces in their names are enclosed in quotes.
• Bash uses different colors for different file types. For example:
• White: Document
• Blue: Directory
• Green: Executable or recognized data file
• Sky Blue: Symbolic link file
• Yellow: Device
• Pink: Graphic image file
• Red: Archive file

Note: Your top-level directories may be somewhat different, depending on your Linux distribution.

---

Linux Permissions

Linux file system permissions are more straightforward and less complex than their Windows counterparts. There are several file types:

• – = Regular File
• d = Directory (folder)
• l = Symbolic Link
• b = Block Special Device
• c = Character Device
• s = Unix Socket
• p = Named Pipe

You can view permissions by entering ls -l. Each file will have only three types of entities that can access it:

• User (u)—the file’s owner
• Group (g)—any user in the file’s group
• Other (o)—everybody else

Each entity can have three permissions, any of which can also be set to none (-):

• r—read
• w—write
• x—execute (if set on a directory, you can enter the directory and list its contents)

Examples:

rwxrwxrwx = user, group, and other all have full permissions

rwxr-xr– = user has full permissions, group can read and execute, everyone else can only read

Permissions can also be expressed in their octal equivalent. Each entity (u, g, o) has its three permissions added up into a single number:

• r = 4
• w = 2
• x = 1
• – = 0

Here are some examples. Both are regular files, as indicated by their first character, which is a “-“.

-rwxrwxrwx = 777—The User has r,w,x, which is the same as 4+2+1=7. Group and Other also have the same permissions.

-rwxr-xr– = 754—The User has r,w,x, which add up to 7, but Group only has r,x, which add up to 5, and Other only has r, which is 4.

Permissions Example

The following example has these settings:

• It’s a directory named Desktop.
• User can read, write, and execute (enter the directory to list its contents).
• Group can read and execute, but not modify.
• Other can read and execute, but not modify.
• It’s owned by root, and anyone in the root group has the Group level permissions (rx), though the root user itself has full permissions (rwx).
• Another way of writing the permissions is 755.

Setting Permissions

You can assign permissions with the chmod command. For example:

• chmod 777 myfile = everyone can read, write, and execute myfile.
• chmod 644 myfile = user rw, group r, other r.
• chmod 740 myfile = user rwx, group r, others can’t do anything.

Special Permission Bits

Linux also has special permission bits that are of interest to the attacker:

• setuid (SUID)—set user ID upon execution
• setgid (SGID)—set group ID upon execution
• sticky—only root or the file’s owner can change files in the directory

Setuid

When a file executes, it takes on the permissions of the user who launched it, not the owner who created it. This means a process can only read/write/execute what the user has permissions for. If you want to temporarily grant other users the same permissions as the owner, you can enable the SUID bit on that file. This lets the process run as owner, rather than as the user who just launched the process. As an example, say you created a script that has these permissions:

-rwxr--r--

At the moment, only you (the owner) can execute it. Everyone else (including the group) can read it, but they can’t run it. You want help desk technicians to also be able to run this script. You can either let them log in/sudo as you (bad idea; you don’t want them to know your password) or you can change the group permissions and put them in the group (might cause problems with other files), or you can enable the SUID bit so that when they launch that one script it runs in your privilege level and actually executes. You configure SUID by replacing the owner’s x with s. So the permissions would now look like this:

-rwsr--r--

You can set the SUID bit on a file with this command: chmod u+s myfile. You can remove it with chmod u-s myfile.

Enabling SUID on executables runs the risk of allowing an attacker to also run that executable as its owner (which might be root!). To find programs with the SUID bit set, enter sudo find / -perm -4000.

Note: SUID uses a lowercase s, unless the file did not have execute permissions to begin with, then it uses an uppercase S. In both cases, execute is implied.

Note: Do not confuse setuid with Windows runas. In setuid, the user does not need to invoke the permission and does not need to provide any password. The SUID bit transparently grants execute permission. The Windows runas command is closer to the Linux su command, where the user must provide a password.

Setgid

Similar to SUID, you could enable the SGID bit so a file can run in the file’s group privilege level, rather than the user’s primary group. For example, the file’s group might be admins, but the user’s group might be sales. You might not want to change someone out of the sales group, but you want them to run that one file as a member of the admins group. Setgid also has another behavior if set on a directory: all files inside the directory would take on the permissions of the group. You enable the SGID bit on the group permissions, not the user permissions:

-rwxr-sr--

To enable SGID, enter chmod g+s ourfile. To remove it, enter chmod g-s ourfile. To find programs with the SGID bit set, enter sudo find / -perm 2000.

Sticky bit

Setting the sticky bit protects files in a common directory such as /tmp or /home. If you were to set drwxrwxrwx on /home, everyone can delete or rename each other’s files. If you set the sticky bit, then people can only modify their own files. The root user, of course, can still modify everyone’s files. The /tmp directory has the sticky bit set by default.

To set the sticky bit, execute this command: chmod +t <dir name>. This appends a “t” to the end of the permissions:

drwxrwxrwxt

Remove the sticky bit with the command chmod -t <dir name>.

---

Sensitive Linux Files

Here are some sensitive files in Linux that attackers might seek to exploit.

File	Description
GRUB (/boot/grub)	Most commonly used bootloader package that loads the Linux kernel.
/etc/passwd	List of all local accounts.
/etc/shadow	Password hashes for all local accounts.
/etc/group	List of all local groups.
/etc/gshadow	Password hashes for local groups.
/proc/cmdline	Kernel parameters.
/etc/rc.*	Run commands.
/etc/profile	Sets system-wide environment variables on user shells.
/etc/hosts	Host-name-to-IP mappings—checked before DNS for name resolution.
/etc/resolv.conf	Lists DNS servers for system to use.
/etc/pam.d	Password and lockout policies.
~/.bash_profile, ~/.bash_login, ~/.profile, /home/user/.bashrc, /etc/bash.bash.rc, /etc/profile.d	Possible locations to insert a script that will run when the shell starts.

Note: For information on how to hack the GRUB bootloader, see https://null-byte.wonderhowto.com/how-to/hack-like-pro-linux-basics-for-aspiring-hacker-part-21-grub-bootloader-0154965/

---

Privilege Escalation in Linux

As with penetration testing Windows targets, once you have compromised a Linux host, you probably need to escalate your privilege to achieve your objectives. Many of the basic concepts that are used in Windows are also used in Linux, though your specific targets and methods may be different. Here are common methods for escalating privilege in Linux.

Vulnerability/Technique	Description	Exploit
/etc/passwd, /etc/shadow	Obtain a copy of these files to crack root or privileged user passwords.	Metasploit module post/linux/gather/hashdump John the Ripper and other password crackers. (See previous discussion, “Password Cracking in Linux.”)
Weak process permissions	Find processes with weak controls and see if you can inject malicious code into those processes.	Metasploit modules: post/multi/recon/local_exploit_suggester post/multi/manage/shell_to_meterpreter Meterpreter migrate and getsystem commands Tarasco Process Injector
User application compromise	Compromise end user applications and plug-ins such as OpenOffice, VNC, and Adobe Flash Player. Some require social engineering to get the end user to open a file or browser page.	Metasploit modules such as: exploit/multi/vnc/vnc_keyboard_exec auxiliary/fileformat/odt_badodt exploit/multi/misc/openoffice_document_macro exploit/multi/browser/adobe_flash_hacking_team_uaf exploit/multi/browser/adobe_flash_nellymoser_bof
SetUID binaries	Locate applications you can run as root.	At a terminal, enter sudo find / -perm -04000
Services running as root	Locate services that are owned by (running as) root and see if you can compromise them.	Find out who you are whoami List all processes owned by you ps -x Locate processes owned by root ps -fU root List all processes and their owners ps -ef
Shared folders	Search for sensitive information in Samba shared folders, as it is common for them to have few or no restrictions.	Metasploit module auxiliary/scanner/smb/smb_enumshares
Kernel and service exploits	Find exploits that target the kernel and privileged services.	nmap -sV (Kali) Linux Exploit Suggester Metasploit module post/multi/recon/local_exploit_suggester Linux-soft-exploit-suggester https://github.com/belane/linux-soft-exploit-suggester
Meterpreter upgrade	If you have a Bash shell from Metasploit, try to upgrade it to the more versatile Meterpreter.	Metasploit module post/multi/manage/shell_to_meterpreter http://www.hackingarticles.in/command-shell-to-meterpreter/
Netcat upgrade	If you have a Netcat shell, try to upgrade it to a fully interactive TTY or Meterpreter.	https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/ https://www.hackingtutorials.org/networking/upgrading-netcat-shells-to-meterpreter/ https://security.stackexchange.com/questions/161214/upgrade-a-ncat-bind-shell-to-meterpreter
Exploit cron jobs	Exploit badly configured cron jobs to gain root access.	>http://www.hackingarticles.in/linux-privilege-escalation-by-exploiting-cron-jobs/
Missing patches and misconfigurations	Search for missing patches or common misconfigurations that can lead to privilege escalation.	BeRoot Project https://github.com/AlessandroZ/BeRoot

Note: To search for Metasploit modules that are application specific, at the msf console, enter search <keyword> platform:linux. For example: search adobe platform:linux.

Note: For more information on privilege escalation in Linux, see:

• https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744
• https://hackmag.com/security/reach-the-root/
• https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
• https://guif.re/linuxeop

---

Default Accounts in Linux

Linux by itself has no accounts, but each distribution introduces its own. Additionally, different services (daemons) add their own accounts as well. All local accounts can be found in the /etc/passwd file. Common accounts that you will find among various distros include:

• root—superuser account that can do anything
• adm—used for diagnostics and monitoring
• mail—handles email. Used by sendmail and postfix daemons
• news—used for Usenet news
• www-data—default website user
• nobody—assigned by the NFS daemon to a mounted NFS share whose owner is not a local user
• sshd—used for unprivileged operations by the SSH daemon
• lp—used for the printer system
• ftp—used for anonymous FTP access
• uucp—controls ownership of serial ports

It is possible to add accounts to the root group. It is more likely, however, that accounts get admin privilege by being listed in the /etc/sudoers file. Accounts listed in this group can run commands as root. You can use various commands to find accounts and their privilege level on Linux.

To Do This Action:	Run This Command:
See all local accounts	cat /etc/passwd
See all password hashes	sudo cat /etc/shadow
Search for a particular account	grep jason /etc/passwd
See who has UID 0 (root)	getent passwd 0
See who is in the root group	getent group root
See who is in the wheel group (able to run the su command to change to root)	getent group wheel
See who is in the adm group (able to monitor the system and read log files)	getent group adm
See who is in the admin group (an administrative group in older distributions)	getent group admin
See who has the right to run the su command	sudo cat /etc/sudoers

---

Default Configurations in Linux

As with any operating system, software packages that you download and install in Linux will have default configurations. While the security risk of defaults depends on the product and vendor, many installations introduce vulnerabilities by default, or are later misconfigured by administrators. Here are some common default Linux configurations that add to the system’s overall vulnerability:

• User home permissions—the default permission on a home folder is 755, meaning that anyone who can access the server can view the contents of other users’ home directories. This could include developer scripts, administrator backup files, password lists and keys, or other sensitive documents.
• World-readable and world-writable directories/files—when a file is created, the default umask is to 022 (permission 644), meaning that everyone can read the file, though only the owner can write to it.
• Insecure mount or export options—the default for mount points (directories that point to another file system) includes rw, suid, dev, exec, auto, nouser, and async. These options allow users to create files in NFS shares as if they are root, resulting in information disclosure and privilege escalation.
• Services and applications with weak defaults—it’s also common to find newly installed services and applications that use less-secure communication protocols and default passwords, listening on all interfaces.

Note: For information on locating world-writable files and folders, see https://gist.github.com/anonymous/10166278

---

Guidelines for Exploiting *nix-Based Vulnerabilities

Here are some guidelines you can follow when exploiting Linux-based vulnerabilities.

• If you are less experienced with Linux, you can refer to Windows vulnerabilities and exploits to help you understand Linux equivalents.
• In addition to finding exploits online or in Metasploit, consider using common Linux features in your exploits.
• When cracking passwords in Linux, consider using a combination of techniques, including cracking offline copies of /etc/passwd and /etc/shadow, dumping hashes, brute forcing network services, and using SMB exploits against the Samba service.
• Use Nmap and online research to identify vulnerable services and protocols.
• Use sticky bits, SUID, and SGID to attack Linux file systems. Target directories that contain sensitive information or have weak permissions.
• After compromising a low-level Linux account, use password cracking, kernel exploits, SUID binaries, shared directories, weak permissions, poorly configured cron jobs, and suggested Metasploit modules to escalate privilege.
• Check to see which privileged default and service-added Linux accounts you can target for password cracking or hash dumping.
• Look for service and protocol versions, weak directory permissions, and weak mount points you can target.
• When attacking mobile devices, use physical access, social engineering/app side-loading, lack of basic security practices, and software exploits to compromise the target.
• If applicable, consider using hardware-based attacks against devices if you have physical access to them.