Metasploitable 2 The Trembling Uterus

Showing posts with label Metasploitable 2. Show all posts

Metasploitable 2 Walkthrough: Part X

Exploiting Port 8180 – Apache Tomcat

Apache Tomcat provides software to run Java applets in the browser. Coyote is a stand-alone web server that provides servlets to Tomcat applets. That is, it functions like the Apache web server, but for Java Server Pages (JSP). All this means is, web pages accessed through port 8180 will be assembled by a Java web application.

The Nmap scan didn't return the version, so that's probably the first thing we'll want to figure out.

There are many Metasploit modules available for Tomcat so you should focus on your goals:

Survey the website

Exploit possible vulnerable pages

Obtain credentials
Deploy payload

Surveying Apache Tomcat using Metasploit

Load the proper Metasploit auxiliary module and run it

These turn up some interesting pages that can potentially be bypassed:

This initial recon will set the criteria for the choice of the next Metasploit modules. First, you have a login page - this provides a way to brute-force login credentials. Second, you have a WebDAV interface, and a potential avenue for uploading a PHP shell.

Getting Apache Tomcat credentials using Metasploit

Using the proper Metasploit module will produce immediate results:

That was easy, this module apparently found a set of valid credentials (tomcat/tomcat).

Let’s try to confirm these credentials:

Pay attention to the default settings. Change them if you want, or try them as they are:

Deploying a payload to Apache Tomcat using Metasploit

Just as obtaining a remote shell on the web server with Apache required uploading and executing a PHP script, obtaining a remote shell on this web server will require uploading and executing a file - but for Tomcat, the executable must be a JSP (Java Server Pages) application.

This is solved by the tomcat_mgr_deploy module

Pay attention to the selection of targets and payloads. With the default java/meterpreter/reverse_tcp payload you will probably won’t succeed in getting a session. Try different combinations until you do.

And there is also the tomcat_mgr_upload module which is very similar but it also requires a change of the default payload.

Try it also.

In both cases, you get a low privilege shell

Deploying a payload to Apache Tomcat manually

If, for some reason, the Metasploit automated payload deployment fails you can still exploit this server manually.

The management web interface gives us a place to upload WAR files, and a way to execute them manually.

The .war are Web ARchive files that contain all the files needed for a Java based web application. These are the files used by the Metasploit modules.

Using msfvenom, you can create shellcode and then specify what type of file to send it to. It just so happens, that one of the filetypes that msfvenom supports is .war.

Use msfvenom to craft a WAR file with the payload, then manually upload and execute it.

Kali IP: 172.16.1.6
Kali port: 5555

Access the manager at [Target IP]:8180/manager/html. You will be asked for credentials but that is not a problem; just enter tomcat/tomcat.

Select the previous file and deploy it.

Note that this does NOT execute the payload yet!!!

To execute the payload and run the actual .war file, you will need to visit the page http://[Target IP]:8180/runme/. However, this will try and connect to our command-and-control server on port 5555, so you need to be listening for the incoming connection.

Use Netcat to receive the incoming shell once the WAR file is executed.

Now, Netcat will listen for the incoming connection, so you're ready to execute your payload.

Run the applet/exploit on your browser:

And you will have a shell:

NOTE: You can also setup a listener using Metasploit’s multi handler module.

The advantage of using Metasploit is the possibility of changing the session from command shell to meterpreter.

Cleaning up

Remove the runme.war file by going back to [Target IP]:8180/manager/html and clicking "Undeploy".

Exploiting 8787 – Distributed Ruby

Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes.

Easy exploit, just load the proper Metasploit module and use it

This concludes the Metasploitable 2 exploitation. In some of the ports/services you can explore other alternatives but this series of posts illustrates pretty much all there is to it.

The next series of post will deal with Metasploitable 3 Windows and that will be somewhat different, specially because the Windows OS and the services installed in that vulnerable VM offer a lot of possibilities…

Next post: Metasploitable 3 Windows Walkthrough: Part I

Metasploitable 2 Walkthrough: Part IX

Exploiting Port 5900 - VNC

Virtual Network Computing or VNC service can be exploited using a module in Metasploit to find the login credentials.

Now, connect to VNC Viewer

The credentials work and we have a remote desktop session that pops up in Kali.

And you have another root shell.

Exploiting Port 6667 – Unreal IRDC

The Unreal IRCD can be exploited using a Metasploit module created to connect to a malicious backdoor present in the Unreal server.

And you have another root shell.

Metasploitable 2 Walkthrough: Part VIII

Exploiting Port 3632 – DistCC

DistCCd is the server for the DistCC distributed compiler. It accepts and runs compilation jobs for network clients. Metasploit has a module to exploit this service.

This is another low privileged account.

Exploiting Port 5432 – PostgreSQL

One of the first pieces of information you will need, even before running a brute-force attack on a PostgreSQL login, is a database name.

Fortunately, the way that PostgreSQL works is by shipping with a default database called template1 that is the template database from which all other databases are created. This means that you can (probably) always find a database named template1 in any PostgreSQL database.

There is also a template0 database, which contains no local settings and is even more basic than template1, so there should always be at least these two known databases in any PostgreSQL service.

Brute forcing PostgreSQL using Metasploit

There are several Metasploit modules to be used against PostgreSQL, but you should start with the one that might give you access to the database.

The procedure is exactly the same as for the previous services:

Load module
Check default options
Select user and password files, or other creds
Run module

Try to run the module with the default settings, adjusting only the IP of the target machine

Another option is to use the credentials previously found and stored in the workspace

In this case, the result is exactly the same.

Now that you have login credentials for the PostgreSQL server, use them to do admin stuff like running arbitrary SQL statements with Postgres.

NOTE: Brute forcing the service using Hydra is exactly the same as it was done for previous services

Exploiting PostgreSQL using Metasploit

Load the auxiliary admin module to run the SQL commands

As you can see, the default options are almost perfect. Try to get the names of the existing databases:

Postgres implements its databases differently from MySQL, so to list all the databases, you need a different command then "SHOW DATABASES". For PostgreSQL, you can use the pg_database database.

The following SQL command gets names of databases from pg_database:

select datname from pg_database;

the following also works:

select pg_database.datname from pg_database;

Getting the /etc/passwd using PostgreSQL

With MySQL, you were able to obtain files on the remote machine using the SQL statement select load_file(\'/etc/passwd\'). However, the load_file function isn't available in PostgreSQL.

PostgreSQL implements it as load:

load \'/etc/passwd\'

This has a problem; invalid ELF header. (Like it is trying to load a binary file...?). So, this module doesn't allow you to load files as easily as, say, MySQL. Maybe you can try a different module.

Again, almost perfect default options.

It works perfectly, with an important bonus. Take a look at the end of the module output:

The contents of the /etc/password were saved inside the workspace for later use. You can see it with the loot command:

Delivering a payload with PostgreSQL

To deliver a payload, use the payload module associated with PostgreSQL.

Dumping the PostgreSQL database

To dump the contents of a PostgreSQL database, use the pg_dump command.

You can check all the flags with man pg_dump, but the basic ones you will need are:

Username
Password (does not accept password typed as an argument on command line, apparently?)
Database (one of the three above, postgres, template0, or template1)
Table (you can use wildcards to match table names)
A file to capture all the output

Like mysqldump, pg_dump will output the SQL commands required to exactly replicate the database and tables selected.

However, unlike mysqldump, postgres implements an additional layer, implemented within SQL itself, that enables a lot of additional functionality. This implements all sorts of different databases and tables for PostgreSQL user management and function definitions.

While this represents a huge attack surface that would make malicious code difficult to find, this PostgreSQL database does not appear to be used for anything. The port is open and the server is listening, but there is no purpose. (Other than to provide Metasploitable users another route into the machine.)

That means that --table='*' will dump out a lot of superfluous stuff.

Metasploitable 2 Walkthrough: Part VII

Exploiting Port 3306 – MySQL

MySQL is an open-source relational database management system. A relational database organizes data into one or more data tables in which data types may be related to each other.

There are several possibilities to explore when connecting to the MySQL service running on the Metasploitable 2 VM

Blank password

The MySQL database in Metasploitable 2 has negligible security so you can connect to it using the MySQL function of Kali by defining the username and host IP. The password will be left blank.

Once you have root access to the database access you can do anything

Brute forcing MySQL using Hydra

Brute forcing MySQL is in its essence the same as brute forcing any other applications and therefore similar tools and techniques can be used

Brute forcing MySQL using Metasploit

Use the proper auxiliary module. Note that in order to successfully use this, you'll need some wordlists for username and password combinations. Try using a single user (root) and the rockyou list for passwords:

The result is the same as before; the root account has a blank password.

Exploiting My SQL using Metasploit

Once you have credentials to connect to the MySQL server, you will want to pivot from recon mode to attack mode. This means you'll be using different exploits from MSF. Whereas the initial exploit was a scanner, the subsequent exploits will be admin exploits.

There are two different ways to exploit the MySQL server to obtain system information and database information. These are covered below.

The mysql_sql auxiliary module can be used to connect to the remote database and execute SQL commands. As an example, execute SQL's load_file() function to scan the contents of the /etc/passwd file and get a list of users on the system.

Enumerating MySQL users with Metasploit

This module will enumerate all of the MySQL accounts on the system and their various privileges.

Since we already have access to the root user in MySQL, there's no need to brute force other login names. However, if there were many users in a complex database, this might yield a treasure trove of usernames with different privileges, allowing you to see different sections of the database.

Take a look at the credentials you have stored so far:

Dumping the MySQL database contents

Use the show databases SQL command to show the databases available.

Use the use databasename SQL command to use a particular database.

Once you've selected a particular database, you can start to explore it.

Select a different database and explore it

You can use the describe command to describe the fields in each SQL table, as well as data types.

Dumping the MySQL database contents using mysqlshow

You can also use mysqlshow to easily show the contents of the database. Use the host option to use a remote database.

Dumping the MySQL database contents using mysqldump

Like the mysqlshow command, the mysqldump command accepts the host argument. To dump a table, run the command like this:

# mysqldump --host=10.0.0.27 [database] [tablename]

This will result in an SQL script that will recreate the entire database from scratch. Be careful and make sure you use mysqlshow –count before, to avoid dumping out a 500 GB database.

DVWA

Try it with the dvwa database:

Unfortunately, the current version of mysqldump doesn’t work with the currently available version of Metasploitable 2. An older Kali version (2015) will work just fine and dumping the dvwa web app reveals some usernames and password hashes.

From this, we can see a couple of interesting things.

First, we have 5 users in this web app. The password field of the table consists of strings of 33 characters, in hex. You can use Hash-Identifier to identify the hash.