Difference between revisions of "Meterpreter"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
Line 26: Line 26:
* augmentation at runtime means that Meterpreter does not have to be rebuilt
* augmentation at runtime means that Meterpreter does not have to be rebuilt
This whole process takes a few seconds to complete.
This whole process takes a few seconds to complete.
== Usage ==
Meterpreter itself was developed for Metasploit. Unsurprisingly the easiest way to use it is via this framework. It was implemented on windows but since its design makes it fully portable it may be applied to a variety of other operating systems like Linux, or Android. If used via the Metasploit framework to use an exploit on a windows target machine, one of 3 payloads can be chosen. Each of which differ in the way they establish a connection between the client, on the machine of the attacker and the server, on the machine of the target.
* \textbf{win32$\_$bind$\_$meterpreter} :This payload establishes a connection from the attacking machine to the target machine. After this is done the server gets uploaded and the connection is further used.
* \textbf{win32$\_$reverse$\_$meterperter} : This payload establishes a connection from the target machine to the attacker. After this is done the server gets downloaded from the attacker machine and the connection is again used further.
* \textbf{win32$\_$findrecv$\_$ord$\_$meterpreter} : This last payload is the most stealthy since it does not establish new connections and can bypass firewalls that way. It looks for the file descriptor that the exploit was triggered from and uses it to upload the Meterpreter server. Afterwards the same connection is used as a means of communication.
Which payload is used depends on the exploit and conditions of the environment in which it is deployed like the configuration of the firewall of the target machine. After starting up the Metasploit framework and seeing the welcome screen, pick an exploit that uses Meterpreter as a post exploitation tool. After that, select the desired payload. You could for example use \textbf{win32$\_$reverse$\_$meterperter}
After that it is required to define:
* '''RHOST''': which represents the IP of the host or client machine
* '''RPORT''': which represents the outgoing port of the host or client machine
* '''LHOST''': which represents the IP of the target or server machine
* '''LPORT''': which represent the incoming port of the target or server machine
Depending on what the attacker wants to achieve, additional libraries may be uploaded during deployment. After doing that, the help command lists the newly available commands as well.
== Functionality ==
For Meterpreter to be as expandable as it is, the underlying packet structure (parsing and transmission) had to be well defined. This lead to the choice of a Type-Length-Value structure, or TLV for short.
Another vital part of the Meterpreter payload is the connectivity and the encryption which go hand in hand. Connectivity is a base requirement since without a stable connection between attacker and target host, no exploitation can happen. It is furthermore also vital to have the possibility to encrypt the transmission to prevent the target host from identifying the outgoing transmission as something malicious.
And last but not least the libraries which are able to extend Meterpreters tool set during runtime are also a core functionality. They allow the hacker to extend the toolkit while in the middle of the exploitation process.
=== TLV or Type-Length-Value ===
This packet structure allows packets to have arbitrary lengths, and does not require for the parsing code to understand the format of the data that is received which in turn allows for all sorts of data to be sent from the server to the client. The structure of the actual package is a little bit different than the name would suggest. The correct order would be Length-Type-Value. Figure shows a visual representation of a TLV-Package.
* '''Length''' (32 bits, network byte order): The length field contains the length of the TLV including the Length, Type and Value fields
* '''Type''' (32 bits, network byte order): The type field holds the arbitrary data type which is used to indicate the format of the value.
* '''Value''' (0..n bits): The value field holds arbitrary data that is of the format specified in the Type field.
This structuring makes it possible to nest TLVs into one another to convey data that usually would be transmitted in some sort of header.
=== Structure ===
One TLV may contain zero of more TLVs in its Value field, and there are four types of packets, which indicate what type of packet is currently being transmitted or received.
The only difference between the 2 packet types with 'PLAIN' in their name ist, that even if encryption is enabled, which is optional for the other two packet types, those packets will be transmitted in plain text.
=== Defined TLVs ===
The technique of nesting TLVs in one another is also used to replace the header field of a standard IP packet. The information which is usually conveyed in such a field is still required for communication. So it is simply put into a TLV packet which is in turn nested into another TLV's 'Value' Field. This leads to a number of predefined TLVs which are used by Meterpreter. This feature may also be used for building extensions for Meterpreter. These predefined TLV's can be uniquely identified by their least, and most significant bytes. The most significant holds the meta-type information, and the least significant the unique identifier.
The meta-type information is used to validate an argument, like verifying that an argument supplied as a string is null-terminated. It is also used for parameter decoding. All meta-types are listed in table
Off of those 7 meta-types, a list of predefined TVLs have been developed which provide core functionality to Meterpreter.

Revision as of 18:06, 16 January 2022

Summary

Meterpreter is an abbreviation for Meta-Interpreter. It is an payload which is included in the Metasploit Framework. Originally it was developed for Metasploit 2.x by Matt Miller under the hacker moniker of Skape. It is used after an exploit was used to gain access to a system to further interact with it by providing an interactive shell. The way this payload operates makes it very hard to detect since it is no process itself but injected into processes which are already running on the target system. This also means that it is executed from memory only making it even harder to detect for Anti-Virus software. The payload itself is very flexible allowing for great customization for developers. Each may write their own extension in form of a shared object file (DLL-dynamic link library) which are then injected into memory.

Goals

The short version is that Meterpreter is supposed to give the attacker access to a command interpreter on the target machine which is very hard or ideally impossible to detect with forensic tools. To achieve this goal while designing Meterpreter, Miller had the following 3 requirements:

Stealthy

The payload has to be stealthy, or how he put it in the documentation: Must not create a new process. It must be very hard to detect with forensic tool after Meterpreter was used on the target system. To reach this goal, 3 sub-criteria had to be met:

  • It was designed to just reside in memory and never write on the disk.
  • It resides inside other, already existing processes. Should the process in which it currently recides finish, Meterpreter 'hijacks' another one that is currently running.
  • It uses encrypted communication.

Powerful

Having access to a command line interface on the target device is useless if the priveleges are not sufficiently elevated.\cite{offensivesecurity}\par Must work in chroot’d environments.

  • Meterpreter utilizes a channelized communication system.
  • The TLV (Type-Length-Value) protocol has few limitations.

Extensible

A useful tool does one thing and one thing well as we know. But a adaptable tool that can change, according to who uses it, what it is used for, and in what environment it is used, is arguably an excellent tool. Must allow for robust extensibility. This goal lead to the following functions:

  • Meterpreter can be augmented at runtime. This means for example that a library or extension can be loaded up to the server to gain more options.
  • augmentation at runtime means that Meterpreter does not have to be rebuilt

This whole process takes a few seconds to complete.


Usage

Meterpreter itself was developed for Metasploit. Unsurprisingly the easiest way to use it is via this framework. It was implemented on windows but since its design makes it fully portable it may be applied to a variety of other operating systems like Linux, or Android. If used via the Metasploit framework to use an exploit on a windows target machine, one of 3 payloads can be chosen. Each of which differ in the way they establish a connection between the client, on the machine of the attacker and the server, on the machine of the target.

  • \textbf{win32$\_$bind$\_$meterpreter} :This payload establishes a connection from the attacking machine to the target machine. After this is done the server gets uploaded and the connection is further used.
  • \textbf{win32$\_$reverse$\_$meterperter} : This payload establishes a connection from the target machine to the attacker. After this is done the server gets downloaded from the attacker machine and the connection is again used further.
  • \textbf{win32$\_$findrecv$\_$ord$\_$meterpreter} : This last payload is the most stealthy since it does not establish new connections and can bypass firewalls that way. It looks for the file descriptor that the exploit was triggered from and uses it to upload the Meterpreter server. Afterwards the same connection is used as a means of communication.

Which payload is used depends on the exploit and conditions of the environment in which it is deployed like the configuration of the firewall of the target machine. After starting up the Metasploit framework and seeing the welcome screen, pick an exploit that uses Meterpreter as a post exploitation tool. After that, select the desired payload. You could for example use \textbf{win32$\_$reverse$\_$meterperter} After that it is required to define:

  • RHOST: which represents the IP of the host or client machine
  • RPORT: which represents the outgoing port of the host or client machine
  • LHOST: which represents the IP of the target or server machine
  • LPORT: which represent the incoming port of the target or server machine

Depending on what the attacker wants to achieve, additional libraries may be uploaded during deployment. After doing that, the help command lists the newly available commands as well.

Functionality

For Meterpreter to be as expandable as it is, the underlying packet structure (parsing and transmission) had to be well defined. This lead to the choice of a Type-Length-Value structure, or TLV for short. Another vital part of the Meterpreter payload is the connectivity and the encryption which go hand in hand. Connectivity is a base requirement since without a stable connection between attacker and target host, no exploitation can happen. It is furthermore also vital to have the possibility to encrypt the transmission to prevent the target host from identifying the outgoing transmission as something malicious. And last but not least the libraries which are able to extend Meterpreters tool set during runtime are also a core functionality. They allow the hacker to extend the toolkit while in the middle of the exploitation process.

TLV or Type-Length-Value

This packet structure allows packets to have arbitrary lengths, and does not require for the parsing code to understand the format of the data that is received which in turn allows for all sorts of data to be sent from the server to the client. The structure of the actual package is a little bit different than the name would suggest. The correct order would be Length-Type-Value. Figure shows a visual representation of a TLV-Package.

  • Length (32 bits, network byte order): The length field contains the length of the TLV including the Length, Type and Value fields
  • Type (32 bits, network byte order): The type field holds the arbitrary data type which is used to indicate the format of the value.
  • Value (0..n bits): The value field holds arbitrary data that is of the format specified in the Type field.

This structuring makes it possible to nest TLVs into one another to convey data that usually would be transmitted in some sort of header.

Structure

One TLV may contain zero of more TLVs in its Value field, and there are four types of packets, which indicate what type of packet is currently being transmitted or received.

The only difference between the 2 packet types with 'PLAIN' in their name ist, that even if encryption is enabled, which is optional for the other two packet types, those packets will be transmitted in plain text.

Defined TLVs

The technique of nesting TLVs in one another is also used to replace the header field of a standard IP packet. The information which is usually conveyed in such a field is still required for communication. So it is simply put into a TLV packet which is in turn nested into another TLV's 'Value' Field. This leads to a number of predefined TLVs which are used by Meterpreter. This feature may also be used for building extensions for Meterpreter. These predefined TLV's can be uniquely identified by their least, and most significant bytes. The most significant holds the meta-type information, and the least significant the unique identifier. The meta-type information is used to validate an argument, like verifying that an argument supplied as a string is null-terminated. It is also used for parameter decoding. All meta-types are listed in table

Off of those 7 meta-types, a list of predefined TVLs have been developed which provide core functionality to Meterpreter.