Meterpreter

From Embedded Lab Vienna for IoT & Security
Revision as of 18:25, 16 January 2022 by SDoiber (talk | contribs)
Jump to navigation Jump to search

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. 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.

  • 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.
  • 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.
  • 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.

TLVPacket.png

  • 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.

TLVStructure.png

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

TLVMetaTypes.png

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

Connectivity

The connection between server and client is initiated by the server (i.e. the target machine), after the Metasploit framework used an exploit to gain access to the system, which then sends a banner message to the client to signal the established connection.

MeterpreterConectivity.png

Encryption

At this point it is possible to enable encryption of the communication by issuing the command

$ initcrypt	

on the client machine. This command needs to be supplied with a cypher which the client then sends as a plaintext packet to the server via the method 'core$\_$crypto$\_$negotiate'. This includes a unique request identifier since a response is expected. This packet also needs to contain the TLV$\_$TYPE$\_$CYPHER$\_$NAME and optionally the \newline TLV$\_$TYPE$\_$CYPHER$\_$PARAMETERS. If everything works as expected the server responds with the 'core$\_$crypto$\_$negotiate' method back including the optional parameters if provided.\cite{meterpreter_documentation}

Libraries

Loading a new library is very similar in complexity and method to enabling encryption. Depending on the parameters of the

$ loadbib		

command, the employed mechanism varies. In a situation where the library is loaded from a path on the remote machine, and no uploading is taking place, the packet flow looks like this:

  • The Client transmits the request with the method 'core$\_$loadbib' which includes a TLV$\_$TYPE$\_$LIBRARY$\_$PATH TLV with the location of the remote server where the library is located.
  • The Server transmits the response 'core$\_$loadbib' back to the client. If the library was loaded successfully, the TLV$\_$TYPE$\_$RESULT parameter will be set to zero. In the other case, the response contains the exception and its data.