Linux-Specific

SUID/SGID Programs

The set user ID ( SETUID , or SUID ) and set group ID ( GUID ) bits tell Linux that the executable file they are set for should be run as the owner of the file, not as the user who launched it. Finding these on a Linux system is easy if you are root; you can simply use the find command:

find / -perm -4000

This shows all SUID files and folders. Setting the UID and GID (User ID and Group ID) bits is also easy to do with chmod by issuing the u+s or g+s flags, and removing them just requires using u-s or g-s as appropriate.

Quite a few common Linux executables can be used for privilege escalation if SUID permission is set. These include cp , find, the Bash shell, more and less , editors like vim and nano, and even older versions of Nmap! Just finding these applications on a system doesn’t guarantee that you’ll be able to exploit them, so make sure you look for the SUID or GUID bits. The list of executables containing SUID and GUID bits will vary from distribution to distribution, and systems may gather more over time if the administrator isn’t careful.

Unsecure SUDO

The Linux Super User Do, or sudo , command allows users to escalate their privileges based on settings found in the sudoers file (typically found in /etc ). When the sudo command is called, the sudoers file is checked and rights are granted if they are permitted.

If you can identify and compromise a sudo -capable user account that can run a program as root, you may be able to use that access to run a shell as root. Access to run Python or Perl as root is sometimes required for scripts on a system, and an otherwise low-privileged account may have this capability.

Ret2libc

ret2libc (return to libc) attacks are buffer overflow attacks that target the C library found on many Linux and Unix systems. Modern 64-bit machines that use address space layout randomization (ASLR) make ret2libc attacks far less likely to succeed, making them less useful in many cases.

Sticky Bits

Sticky bits , also known as restricted deletion flags, are permission bits set on files or directories that prevent unprivileged users from deleting or renaming a file or directory unless they own it. You can see the sticky bit set on a directory with a t when you perform a directory listing.

The sticky bit for /tmp means that users who share the directory cannot delete files belonging to other users. As a penetration tester, you need to know the impact of the sticky bit being set and that you will not be able to write to or delete a file or directory that has it set unless you are the owner or have root permissions.

Windows

Cpassword

For years, passwords could be stored as an attribute called cPassword in Windows Group Policy items, making it easier to use those passwords for a preference item. Domain administrators would even use this capability to easily create local administrator accounts using Group Policy. That also made passwords stored in the cPassword accessible to any authenticated user in the domain, where they are stored in a shared directory on the domain controller and they are easily decrypted using a static public key published by Microsoft.

For the penetration tester, cracking cPassword credentials is made even easier by the Group Policy Preferences module in Metasploit (post/windows/gather/credentials/gpp) or via PowerSploit modules like Get-CachedGPPPassword and Get-GPPPassword, which can be used on the cPassword values found in $SYSVOL in a file named Groups.xml.

Clear Text Credentials in LDAP

LDAP, the Lightweight Directory Access Protocol, is built into Active Directory (AD) and is used for authentication for many services in an AD domain. Fortunately for penetration esters, it is also a commonly misconfigured service. In fact, AD doesn’t force SSL/TLS by default because of compatibility concerns, and developers who use LDAP commonly often don’t use proper security practices for their LDAP authentication.

Kerberoasting

Kerberoasting is a technique that relies on requesting service tickets for service account service principal names (SPNs). The tickets are encrypted with the password of the service account associated with the SPN, meaning that once you have extracted the service tickets using a tool like Mimikatz, you can crack the tickets to obtain the service account pass-word using offline cracking tools.

The Kerberoasting toolkit is found at https://github.com/nidem/kerberoast . Kerberoasting is most effective against shorter, less complex passwords, as it relies on offline cracking, which can be slow when service accounts use long passwords.

Kerberoasting is a four-step process:

Scan Active Directory for user accounts with service principal names (SPNs) set.

Request service tickets using the SPNs.

Extract the service tickets from memory and save to a file.

Conduct an offline brute-force attack against the passwords in the service tickets.

Credentials in LSASS

The Local Security Authority Subsystem Service (LSASS) enforces security policies on Windows systems. On older versions of Windows, up to and including Windows Server 2008 and Windows 7, LSASS stored passwords in cleartext, allowing them to be easily extracted using Mimikatz or other tools. Newer versions of Windows, including Windows 8 and 10 as well as Server 2012 and 2016, encrypt passwords, making this attack less effective unless you can change Registry settings for Wdigest authentication to cache credentials.

Thus, if you encounter an older Windows server or workstation, you can likely use Mimikatz or Metasploit to retrieve credentials easily. If you can gain administrative credentials that provide access to the Registry on a newer system, you can also modify the Registry to enable caching and gain the same access.

Unattended Installation

Windows Deployment Services (WDS) encodes the local administrator password in either plain text or Base-64 encoded form in multiple locations for unattended system installations. If you gain access to a WDS image, you can find the password stored in the following locations:

• C:\unattend.xml
• C:\Windows\Panther\Unattend.xml
• C:\Windows\Panther\Unattend\Unattend.xml
• C:\Windows\system32\sysprep.inf
• C:\Windows\system32\sysprep.xml

As you might expect, there is a Metasploit module designed specifically to recover passwords used in unattended installations. You can find it in post/windows/gather/ enum_unattend via the Metasploit console.

SAM Database

The Windows Security Accounts Manager (SAM) database is one of the first places that you are likely to target when you gain access to a Windows system. The SAM contains password hashes that can be easily dumped using Mimikatz or the Mimikatz functionality built into Metasploit, as shown in Figure 10.7. Note that first debugging was set, then privi-leges were escalated to NT Authority/System, and finally the SAM was dumped. Without appropriate privileges, this process will not work!

DLL Hijacking

Many Windows applications rely on Dynamic Link Libraries (DLLs) to function. DLLs are modular program elements that can be loaded as they are needed. DLLs are often found with the .dll , .ocx , .cpl , or .drv filename extension, so if you’re looking for DLLs to attack, you’ll find a lot to work with!

DLL hijacking replaces the original DLL that would be loaded by an application with a malicious DLL. Multiple methods can be used for DLL hijacking, including these:

• Search order hijacking, which takes advantage of the default search order for files that don’t have hard-coded locations. Windows will search the directory the application is in, followed by the current directory, the Windows system directory, the Windows directory, and then directories listed in the PATH variable. This means that if you can write to the current directory, you may be able to replace a DLL quite easily.
• Changing the Registry entries for known DLLs (those the system already has registered in a KnownDLL directory), or excluding known DLLs from the known DLL directory via the Registry, causing a search to occur.
• Side-loading DLLs by taking advantage of the side-by-side functionality Windows uses when multiple versions of the same DLL are required. This loads DLLs into C:\Windows\WinSxS, and it requires the application to have a manifest that lists the correct DLL—so you’ll have to make sure the manifest changes!
• Phantom DLLs, or DLLs that are not necessary for their applications and are no longer found by default on Windows systems, can be exploited by simply providing a DLL, which is then loaded by the application.

Defenders often look for unsigned DLLs or multiple DLLs with the same name inside the search path. Using concealment techniques, placing DLLs into the side-by-side directory, or otherwise making it harder for defenders to find your hijacking tools, can help you stay hidden!

Exploitable Services

Unquoted Service Paths

When Windows systems start a service, the operating system attempts to find the location of the executable to start it. The secure way to do this is to enclose the executable in quotes, “”, but in some cases this isn’t done properly. When that occurs, Windows will attempt to locate the executable by checking its entire path.

Exploiting this requires first identifying all of the services running on a target and figuring out which services may not be enclosed in quotes. Fortunately, a simple wmic command can find this.

Once you know which services have unquoted service paths, you can determine their privilege level by checking them in the services list. The SSH server found in Figure 10.8 is running as a service account.

An ideal service to exploit would run as system, but in this case the SSH server is properly locked down to a named service account. If the service were running as system, the next step would be to check whether the service had write permissions in the directory where the service executable is located or in a parent directory that would be useful to the penetration tester.

Writable Services

Windows services can also be targeted if they provide write permissions to the service or the folder that contains the service. The SysInternals accesschk tool (https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk) provides an easy way to check for permis-sions that the currently logged-in user can modify.

Accesschk shows that the user has complete access to the services listed, and thus the services could be potential targets. Querying the service manager using sc qc [servicename]for each service can provide details of which service the service is started as. As with the other Windows exploits we have looked at, LocalSystem is a desirable target, and once you find a service that is running as LocalSystem, you can then change the binary path name to run a command on the system, allowing greater access.

Metasploit’s /exploit/windows/local/service_permissions module can conduct this exploit in an automated fashion, and Powersploit’s Get-ModifiableService and Invoke-serviceAbuse modules provide the same functionality

Unsecure File/Folder Permissions

As a penetration tester, you will often fi nd that carefully reviewing the filesystem of a computer to which you have gained access will provide useful information. User-managed filesystems are an easy place to fi nd misconfigured permission structures or files and folders whose access rights are overly broad. System administrators aren’t immune to this problem, either. In fact, the first step that many administrators will take in troubleshooting is to remove restrictive permissions, and remembering to put them back in place, or putting them back in place properly, is often difficult.

While searching for directories in Linux using ls and then using grep on the output to search for weak permissions is easy, searching for poor file permissions in Windows may initially seem more difficult. Fortunately, the AccessEnum and Accesschk Sysinternals tools can provide easy-to-review reports. PowerShell’s Get-Acl command can provide detailed information, and the icacls command shows details of how permissions inheritance will work on a given file or folder.

Keylogger

Keylogger software and hardware can be useful as part of an ongoing exploitation process. Capturing keystrokes provides insight into the actions taken by users, and it can be a valuable source of credentials and other confidential information.

Metasploit’s Meterpreter builds in a keylogger that can be easily enabled from the Meterpreter prompt by typing keyscan_start , and its captured content can be viewed using keyscan_dump . Capturing login information is as simple as migrating Meterpreter to the winlogin process by checking the process list for the process ID of the winlogin.exeprocess, using the Meterpreter migrate command to migrate to the process, and then once again capturing keystrokes!

Hardware keyloggers can also be useful if you have physical access to systems. They are available in a number of designs, ranging from small USB devices that plug into the back of a PC to keyboards that capture input to a hidden internal device. Physical keyloggers may be discovered by alert users, but they provide the advantage of not being discoverable by most anti-malware tools. In fact, many keyloggers simply look like another keyboard or other innocuous USB device to security scans.

Scheduled Tasks

Using scheduled tasks to perform actions on a compromised Windows host is a tried-and-true method of retaining access. The same is true of cron jobs on Linux and Unix hosts, and this means that defenders will often monitor these locations for changes or check them early in an incident response process. That doesn’t mean that the technique isn’t useful—it merely means that it may be detected more easily than a more subtle method; but unlike memory resident exploits, both scheduled tasks and cron jobs can survive reboots.

To schedule a task via the command line for Windows, you can use a command like this, which starts the calculator once a day at 8:00 a.m.:

SchTasks /create /SC Daily /TN "Calculator" /TR "C:\Windows\System32\calc.exe" /ST 08:00

The same technique works with Linux or Unix systems using cron, although cron keeps multiple directories in /etc/ on most systems, including /etc/cron.hourly , /etc/cron.daily , /etc/cron.weekly , and /etc/cron.monthly . Scripts placed into these directories will be executed as you would expect based on the name of the directory, and the scripts can include a specific number of minutes after the hour, the 24-hour military time, the day of the month, the month, the day of the week, and the command to run. Thus 0 30 1 * * /home/hackeduser/hackscript.sh would run the fi rst day of every month at 12:30 a.m. and would execute hackscript.sh in the /home/hackeduser directory. Of course, if you’re trying to retain access to a system, you’ll want to be a lot more subtle with filenames and locations!

One of the most common uses of this type of scheduled task is to retain access to systems via a remotely initiated “call home” script. This prevents defenders from seeing a constant inbound or outbound connection and can be used to simply pick up fi les or commands from a system that you control on a regular basis.

Kernel Exploits

Linux

The Linux kernel is the core of the Linux operating system, and it handles everything from input and output, memory management, and interfacing with the processor to interfacing with peripherals like keyboards and mice. Exploiting the kernel can provide powerful access to a system, making Linux kernel exploits a favorite tool of penetration testers (and other attackers!) when they can be conducted successfully.

The CVE list ( https://cve.mitre.org/ ) classifies Linux kernel exploits based on the type of vulnerability, with categories for denial of service, code execution, overflow, memory corruption, directory traversal, bypass, information leakage, and privilege escalation vulnerabilities, all seen in the kernel over time. Denial of service attacks are the most common type of exploit, but they are the least interesting to most penetration testers. As you might expect, code execution, privilege elevation, and bypass attacks are most likely to be useful to penetration testers.

In the majority of cases, the most critical Linux kernel exploits require local access to the system, meaning that taking advantage of them will require you to have previously gained access to the system. The difficulty of executing kernel exploits and the fact that most kernel patches will require a system reboot also mean that many administrators will delay kernel patches. This provides an opportunity for penetration testers who can gain access to a system, as kernel exploits may not be patched due to a lower perceived risk!

A quick check that you can use to test a Linux system for potential kernel issues can be con-ducted by first checking the operating system release using lsb_release -a and then checking the kernel version using uname -a. These two simple commands can provide quick insight into what Linux distribution and kernel version are in use

Windows

Much like Linux, the Windows kernel can be attacked to gain high-level access to Windows systems. Metasploit’s post/windows/gather/enum_patches module will list any missing patches, which you can then reference against vulnerability databases to determine if an exploit exists for the unpatched issue. Metasploit also has exploit modules for many of the Windows kernel exploits discovered over time, allowing you to assess flaws and then attempt to exploit them once you have access to the system.

Kernel flaws have been found in every version of Windows desktop and server operating systems. As we saw with Linux kernel exploits, most Windows kernel exploits also require local access to the system to exploit, making Windows kernel exploits most useful after you have already gained access to the system.