Exploring Privilege Escalation with rsync and bash setuid

In CTF (Capture The Flag) competitions and security assessments, exploiting permission flaws and improper configurations of tools like rsync is a recurring technique for privilege escalation. These flaws are often found in misconfigured systems where permission management does not follow security best practices. The absence of strict permission management can create critical vulnerabilities, providing malicious users the ability to gain unauthorized privileges. This article addresses a specific scenario in which it is possible to exploit a task involving rsync and a bash binary with SUID to acquire root privileges. We will explore each command used, the impacts generated, as well as mitigation measures and best practices that administrators can adopt to protect their systems against similar attacks.

Privilege Escalation Scenario

The privilege escalation flow begins with a user who has access to the /home/dev/ directory, which contains the app-staging/ folder with appropriate permissions for the current user. This scenario is common in development environments, where different users access shared folders to facilitate collaborative work. However, improperly configured permissions can be exploited to gain unauthorized control. In this context, there is a task configured to use the rsync command with sudo permissions, which synchronizes the content of this directory with the /opt/app/ directory, changing file ownership to the root user.

The vulnerability exploited here results from the combination of write permissions in shared folders and the execution of rsync with elevated privileges, creating an opportunity for an attacker to obtain root privileges on the system. This type of scenario is often overlooked by system administrators, who may not realize that improper permissions in shared directories can lead to severe security breaches. Below, we discuss the step-by-step exploitation of this vulnerability.

1. Copying the bash binary to the accessible directory

1
2

cd /home/dev/
cp /bin/bash app-staging/bash

In this step, the user copies the bash binary to the app-staging/ directory, where they have write permission. This copy will serve as a backdoor shell that will later be manipulated to gain privileged access. Since the directory is accessible and the user has write permission, they can introduce binaries or scripts that will be used in the escalation process. The absence of strict control over what can be placed in this directory creates an evident opportunity for abuse.

2. Setting the SUID bit on the bash binary

1

chmod u+s app-staging/bash

The chmod u+s command adds the SUID bit to the bash binary. This means that when the binary is executed, it will run with the privileges of its current owner. At this moment, bash is still owned by the user who performed the copy, but the goal is to move it to the /opt/app/ directory and change its ownership to root. By setting the SUID bit, anyone who later executes this binary will do so with elevated privileges, making this configuration extremely dangerous if the binary becomes owned by root. The SUID bit is a commonly exploited vulnerability by attackers to gain unauthorized privileged access.

3. Executing rsync with sudo

1

sudo /usr/bin/rsync -a --exclude=.hg /home/dev/app-staging/* --chown root:root /opt/app/

This rsync command is executed with sudo privileges, allowing all files in the app-staging/ directory to be copied to /opt/app/, with the file ownership changed to the user and group root. At this point, the bash binary that was manipulated to have the SUID bit set is also copied and becomes owned by root. This creates a situation where the bash binary can be executed as root by any user, leading to privilege escalation. The --chown root:root option ensures that all copied files have their ownership changed to root, including the malicious bash binary. The combination of rsync with sudo permissions and the lack of rigorous verification of the files being copied results in a critical vulnerability.

4. Executing bash with root privileges

1

/opt/app/bash -p

Finally, the bash binary with the SUID bit set and owned by root is executed with the -p flag, providing the attacker with a shell with root privileges, allowing privilege escalation in the system. This means that the attacker now has full control over the system, being able to execute commands as a superuser, compromise the machine’s integrity, modify critical system files, install backdoors, alter permissions, and even render the system unusable.

Impact Analysis

The privilege escalation exploited in this scenario results from a combination of improperly configured permissions and the execution of rsync with sudo without adequate control over the files being copied. Using the --chown root:root command to copy bash to a directory under the user’s control allowed an arbitrary binary (in this case, bash with SUID) to be changed to root ownership, enabling privilege escalation. The lack of rigorous validation of the copied files and the absence of robust permission control contribute to making this vulnerability exploitable.

Furthermore, this type of flaw highlights the importance of role segregation and strict security control to prevent a user with limited access from manipulating administrative tasks and, consequently, gaining elevated privileges. In shared environments, such as development servers where multiple users collaborate on projects, improper permission configuration can be exploited by any of them to compromise the entire system.

Improper permissions in development directories, combined with the execution of privileged commands without proper control, represent a serious information security risk. This vulnerability could be exploited not only in competitive environments but also in real-world situations where development servers are shared by multiple users, making the attack even more impactful and harder to detect, as the abuse occurs during routine file synchronization tasks.

Mitigation Strategies

• Restrict Sudo Usage: Avoid allowing rsync to be executed with sudo privileges by untrusted users or without strict control over the files to be synchronized. Ideally, limit sudo usage to specific commands and trusted users, minimizing the possibility of abuse. In addition, whenever possible, configure strict access control policies, ensuring that only authorized users can perform operations with elevated privileges.
• File Whitelist: Configure rsync to work only with a specified set of files, or use a more restrictive permission system to prevent malicious binaries from being introduced into the process. Ensuring that only known and approved files are synchronized significantly reduces the possibility of a malicious file being copied with elevated permissions. This type of granular control is essential to prevent potentially dangerous files from being included in the synchronization process.
• Remove SUID Bit: Avoid using the SUID bit on binaries unless absolutely necessary, and regularly review which binaries have this bit set. Many privilege escalation attacks rely on binaries with SUID, so periodically reviewing which files have this bit active and removing it when not essential is a good security practice. Whenever possible, remove the SUID bit and use alternatives that do not compromise system security.
• Environment Segregation: Use separate development, testing, and production environments with different permission levels. This ensures that even if a development environment is compromised, the impact is limited and does not directly affect the production environment. Environment segregation helps minimize damage in the event of a compromise and makes it easier to track potential attacks.
• Permission Auditing: Perform regular audits to verify permissions in directories and binaries. These audits help identify excessive or unnecessary permissions, allowing them to be corrected before they can be exploited by an attacker. In addition, implementing monitoring tools to log suspicious activities can help detect exploitation attempts before they succeed.
• Change Control: Implementing a formal change control process can ensure that system changes are reviewed and approved before being applied. This includes changes to permissions, scripts, and automated tasks. Change control helps identify potential issues before they are exploited.
• Activity Monitoring: Use monitoring tools that alert about suspicious changes in sensitive directories or the execution of binaries with SUID, which can be essential for detecting and mitigating privilege escalation attempts. Solutions such as IDS/IPS (Intrusion Detection System/Intrusion Prevention System) can be used to identify unusual activities.

Conclusion

The exploitation of vulnerabilities related to rsync and misconfigured permissions is a classic example of how a lack of adequate control in synchronization tasks can result in system compromise. Security practices such as restricting sudo usage, defining a file whitelist, and removing unnecessary SUID bits are essential to mitigate these risks. Additionally, proper environment segregation and continuous permission auditing are fundamental to ensuring that potential flaws cannot be exploited to compromise system security.

System administrators must be attentive to inadequate security practices, especially in environments where multiple users have access to shared resources. Vulnerabilities like this can be easily avoided by applying the principle of least privilege and strict control over permissions, ensuring that only authorized users have access to the system’s most sensitive functions. By implementing these measures, it is possible to drastically reduce the chances of an attacker exploiting flaws and escalating privileges, thereby protecting the integrity and security of the infrastructure.

Moreover, it is crucial that administrators educate users about the risks associated with the misuse of permissions and the impact this can have on system security. Continuous training and clear security policies are essential to ensure that everyone is aware of best practices and knows how to identify and report potential security issues. Information security is a collective responsibility, and ensuring that all users follow good practices is a key step to keeping the infrastructure secure and protected against malicious attacks.