Introduction
I guess we all know what Metasploit is, so we don't really need to present to the reader the basics of Metasploit. But it's still useful if we present the type of modules the Metasploit has. Metasploit has the following types of modules:
- Auxiliary Modules: perform scanning and sniffing and provide us with tons of information when doing a penetration test.
- Post Modules: gather more information or obtain more privileges on an already compromised target machine.
- Encoders: used to encode the payload being used for it to not be detected by the anti-virus software programs.
- Exploits: used to actually exploit a specific host.
- Payloads: are the actual instructions that will be executed on the target host. Payloads can be divided between singles that can be used standalone, like adding a user to the system. There are also stager payloads, that usually set-up a network connection between the victim and attacker and the stages payloads that are downloaded by the stager payloads. The stagers and stages provide execution of multiple payload stages that can be used whenever we don't have enough space to use within certain vulnerability, but would still like to execute a certain payload on the target system.
Q on Github
The Q Metasploit Exploit Pack is a collection of modules gathered across time, which were not accepted into the main Metasploit trunk. Currently the Q trunk only contains two auxiliary modules and four post modules, which we'll look into in the rest of the article.
To use the Q exploit modules, we could download the individual modules manually and include them in the system's Metasploit modules path, but there's a better way. First we need to clone the repository as follows:
# git clone https://github.com/mubix/q.git
Afterwards, the q/ directory will be created to hold all the files and folders in the git repository. We can copy the q/modules/ directory under the ~/.msf4/modules directory and run msfconsole command, which will load system modules as well as user defined modules. Alternatively we could load the modules by using the -m option with msfconsole, which would also load all the system as well as user modules. Another option of loading the directory is by using the loatpath /path/to/modules command when the msfconsole is already running.
In our case we copied the modules to the ~/.msf4/modules/ directory and run msfconsole as follows:
# msfconsole4.4 [-] WARNING! The following modules could not be loaded! [-] /root/.msf4/modules/post/linux/q/passwd-shadow-ssh-jacker-shell.rb: SyntaxError compile error /root/.msf4/modules/post/linux/q/passwd-shadow-ssh-jacker-shell.rb:76: syntax error, unexpected $end, expecting kEND [-] /root/.msf4/modules/auxiliary/gather/netcrafting.rb: SyntaxError compile error /root/.msf4/modules/auxiliary/gather/netcrafting.rb:69: syntax error, unexpected ')' ______________________________________________________________________________ | | | 3Kom SuperHack II Logon | |______________________________________________________________________________| | | | | | | | User Name: [ security ] | | | | Password: [ ] | | | | | | | | [ OK ] | |______________________________________________________________________________| | | |______________________________________________________________________________| =[ metasploit v4.4.0-release [core:4.4 api:1.0] + -- --=[ 903 exploits - 492 auxiliary - 153 post + -- --=[ 250 payloads - 28 encoders - 8 nops msf >
The Metasploit was loaded successfully (note the msf>), but some modules within the Q exploit pack were not loaded successfully. We can see that passwd-shadow-ssh-jacker-shell.rb and netcrafting.rb didn't compile correctly. We looked up the code for the two modules and corrected the mistakes made by the module author. In the passwd-shadow-ssh-jacker-shell.rb module, there's one end directive missing on the line 73, which terminates the else statement. After adding it, the file should compile successfully; if you're trying to compile it with ruby passwd-shadow-ssh-jacker-shell.rb, you should note that the error about not being able to load msf/core is normal, since those files are not in the system path (but they can be loaded by the Metasploit just fine). The netcrafting.rb module contains additional comma on the line 68; after removing the comma, the module should also compile successfully.
After the mistakes are corrected, we should be able to load Metasploit without any errors, which can be seen in the output below:
# msfconsole4.4 _---------. .' ####### ;." .---,. ;@ @@`; .---,.. ." @@@@@'.,'@@ @@@@@',.'@@@@ ". '-.@@@@@@@@@@@@@ @@@@@@@@@@@@@ @; `.@@@@@@@@@@@@ @@@@@@@@@@@@@@ .' "--'.@@@ -.@ @ ,'- .'--" ".@' ; @ @ `. ;' |@@@@ @@@ @ . ' @@@ @@ @@ , `.@@@@ @@ . ',@@ @ ; _____________ ( 3 C ) /|___ / Metasploit! ;@'. __*__,." |--- _____________/ '(.,...."/ =[ metasploit v4.4.0-release [core:4.4 api:1.0] + -- --=[ 903 exploits - 493 auxiliary - 154 post + -- --=[ 250 payloads - 28 encoders - 8 nops
After that, we should be able to load modules present in the Q exploit pack just fine.
The Ripecon Module
An example of loading the auxiliary module ripecon.rb in category gather is presented below:
msf > use auxiliary/gather/ripecon msf auxiliary(ripecon) > show options Module options (auxiliary/gather/ripecon): Name Current Setting Required Description ---- --------------- -------- ----------- KEYWORD yes Keyword you want to search for (ex. Microsoft, Google) OUTFILE no A filename to store the results of the module Proxies no Use a proxy chain RHOST 193.0.6.142 yes The IP address of the RIPE apps server RIPE-GRSSEARCH-URI /whois/grs-search yes Path to the RIPE webservice RIPE-SEARCH-URI /whois/search yes Path to the RIPE GRS webservice RPORT 443 yes Default remote port VHOST apps.db.ripe.net yes The host name running the RIPE webservice
We can use the ripecon module to query the apps.db.ripe.net database to get more information about a certain company. Let's set the keyword to Google and run the module:
msf auxiliary(ripecon) > run [*] RIPEcon: Retrieving sources... [*] Standard search results: [-] https://apps.db.ripe.net:443/whois/search?source=ripe&source=apnic&source=afrinic&source=test& - Failed to connect or invalid response [*] GRS search result: Query Results ============= Name Value ---- ----- descr "Google" LLC inetnum 108.170.192.0 - 108.170.255.255 inetnum 108.177.0.0 - 108.177.127.255 descr 12-05894 inetnum 142.250.0.0 - 142.251.255.255 descr 1600 Amphitheatre Parkway inetnum 172.217.0.0 - 172.217.255.255 inetnum 173.194.0.0 - 173.194.255.255 inetnum 193.120.166.64 - 193.120.166.127 inetnum 195.100.224.112 - 195.100.224.127 inetnum 195.76.16.136 - 195.76.16.143 inetnum 199.87.241.32 - 199.87.241.63 inetnum 207.223.160.0 - 207.223.175.255 inetnum 209.85.128.0 - 209.85.255.255 inetnum 212.179.82.48 - 212.179.82.63 inetnum 212.21.196.24 - 212.21.196.31 inetnum 213.248.112.64 - 213.248.112.127 inetnum 213.253.9.128 - 213.253.9.191 inetnum 216.239.32.0 - 216.239.63.255 inetnum 216.58.192.0 - 216.58.223.255 inetnum 217.163.1.64 - 217.163.1.127 inetnum 46.61.155.0 - 46.61.155.255 inetnum 64.233.160.0 - 64.233.191.255 inetnum 66.102.0.0 - 66.102.15.255 inetnum 66.249.64.0 - 66.249.95.255 inetnum 70.32.128.0 - 70.32.159.255 inetnum + - 70.90.219.55 inetnum 70.90.219.72 - 70.90.219.79 inetnum 72.14.192.0 - 72.14.255.255 inetnum 74.125.0.0 - 74.125.255.255 inetnum 80.239.142.192 - 80.239.142.255 inetnum 80.239.168.192 - 80.239.168.255 inetnum 80.239.174.64 - 80.239.174.127 inetnum 80.239.229.192 - 80.239.229.255 inetnum 89.175.162.48 - 89.175.162.55 inetnum 89.175.165.0 - 89.175.165.15 inetnum 89.175.35.32 - 89.175.35.47 inetnum 92.45.86.16 - 92.45.86.31 inetnum 95.167.107.32 - 95.167.107.63 … [*] Auxiliary module execution completed
We can see that we've gotten quite some information about the Google netblock, but there are also entries in there that do not belong to Google. We can get the same information if we visit the webpage apps.db.ripe.net and click on the "Query" and "Full Text Search (GRS)" links in the menu on the right side of the page. We can see that in the picture below:
The NetcRafting Module
This modules provides us with results for all the sites, it's netblock where the site belongs to and the operating system running that web site. All we need to do is enter the company name in a variable KEYWORD and run the module. It will automatically return the results as shown below:
msf > use auxiliary/gather/netcrafting msf auxiliary(netcrafting) > set KEYWORD Google KEYWORD => Google msf auxiliary(netcrafting) > run [*] NetcRafting results: Query Results ============= Site Netblock OS ---- -------- – www.google.com google inc. linux www.google.de google inc. linux www.google.it google inc. linux www.google.fr google inc. linux www.google.co.uk google inc. linux www.google.pl google inc. linux
We had set the KEYWORD variable to Google to get the information about Google. The results have been trimmed for clarity, but we can nevertheless see that the NetcRafting module returned the sites that belong to Google. The returned sites are: www.google.com, www.google.de, www.google.it, www.google.fr, www.google.co.uk and www.google.pl, which all run the operating system Linux.
We can get the same result if we visit the webpage netcraft and search for a keyword Google as can be seen in the picture below:
There are more than 300 entries, but only seven of them have been shown in the picture above. With this query we can get more information about the domain names the company is using as well as their operating systems and the time when they have first been seen on the Internet (although this is only available on the online version of the search query, and not in a Metasploit module).
The Passwd-shadow-ssh-jacker-meterpreter Module
This is a post exploitation module that can be used on Linux systems when the session to the target machine is already set-up. It tries to download /etc/passwd, /etc/shadow and SSH keys from the target machine. It automatically finds the .ssh folder and tries to download the keys in it, but it might not be successful, because the user the session is running under might not have enough permissions. I guess this module is there just for convenience, because if we already have a session open, we can download those files manually with ease.
An example of showing the options the module uses can be seen in the output below:
msf > use post/linux/q/passwd-shadow-ssh-jacker-meterpreter msf post(passwd-shadow-ssh-jacker-meterpreter) > show options Module options (post/linux/q/passwd-shadow-ssh-jacker-meterpreter): Name Current Setting Required Description ---- --------------- -------- ----------- SESSION yes The session to run this module on.
The Openvpn_profiles_jack Module
This module is a post exploitation module that can be run on Windows. It can download OpenVPN profiles that can be imported into the OpenVPN client. This module can be used when we already have an open session, which we can interact with. I guess if we already have a session we can also do this manually with ease, so additional module is there just to make things a little easier.
An example of using and showing options the module accepts can be seen below:
msf > use post/windows/q/openvpn_profiles_jack msf post(openvpn_profiles_jack) > show options Module options (post/windows/q/openvpn_profiles_jack): Name Current Setting Required Description ---- --------------- -------- ----------- SESSION yes The session to run this module on.
Conclusion
We've seen how the Q exploit pack for Metasploit can be used together with Metasploit to provide additional modules that didn't make it into the Metasploit trunk. Currently it contains very few modules, but in time this should change if the modules will not be accepted as part of the Metasploit trunk.
Whenever we're writing a module to automate something with Metasploit or write an entirely new Metasploit module, we first need to contact the Metasploit developers to find out if the module is eligible to be included into the Metasploit trunk. Otherwise, we should add it to the Q exploit pack to make all the non-accepted modules part of the same repository.
Comments