miércoles, 5 de mayo de 2010

Meterpreter

Meterpreter

De wiki.metasploit-es.com.ar

Revisión a fecha de 12:52 19 abr 2010; Hackmaf (Discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)

El siguiente manual de Meterpreter es gratuito y puede verlo desde este enlace en ingles http://www.nologin.org/Downloads/Papers/meterpreter.pdf. No se ha modificado el contenido del manual, la traducción sigue manteniendo el contenido del mismo. Este manual es propiedad de skape, simplemente nos limitamos a su traducción al Español.

Metasploit’s Meterpreter

skape

mmiller@hick.org

Last modified: 12/26/2004


Contenido

Prólogo

Resumen: Meterpreter, corto para el meta-intérprete, es un payload avanzado que se incluye en el Metasploit Framework. Su objetivo es proporcionar a los complejos y las características avanzadas que de otro modo sería tedioso para aplicar estrictamente en el montaje. La forma en que se lleva a cabo esto es permitiendo a los desarrolladores escribir sus propias extensiones en forma de objeto compartido (DLL) que pueden cargar y se inyecta en un proceso que se ejecuta en un equipo de destino después de la explotación se ha producido. Meterpreter y todas las extensiones que se carga son hechos totalmente de la memoria y nunca toque el disco, lo que les permite a ejecutar bajo el radar de Lucha contra el estándar de detección de virus.

Descargo de responsabilidad: Este documento fue escrito en el interés de la educación. El autor no puede ser responsable de cómo los temas discutidos en este documento se aplican. Las versiones de software utilizados en este documento fueron el marco de Metasploit 2,3 y Meterpreter 0.0.5.0. Versión 0.0.5.0 incluye las siguientes extensiones: Fs, Net, Proceso, y Sys. El autor desea agradecer a HD Moore, spoonm, vlad902, ladrón, Optyx, Oded, Jarkko Turkulainen, nologin, Core ST, y todos los que internamente motivados e interesados en la investigación de temas frescos. Con eso, en el show ...

Introducción

Cuando la explotación de una vulnerabilidad de software que hay ciertos resultados que son típicamente espera por un atacante. El más común de estas expectativas es que el atacante tenga acceso a un intérprete de comandos, como /bin/sh o cmd.exe que les permite ejecutar comandos en la máquina remota con la los privilegios del usuario que está ejecutando el software vulnerable. Acceso a la el intérprete de comandos en la máquina objetivo le da al atacante casi lleno de control de la máquina, limitada sólo por los privilegios del proceso de explotación. Si bien los beneficios de la intérprete de comandos son, sin duda, existe cierta margen de mejora.

Tal como está hoy, la mayoría de los exploits publicados incluyen un payload que ejecuta un intérprete de comandos. La entrada y la salida del comando intérprete en general es redireccionado a una conexión TCP que es o bien de forma proactiva o pasiva, establecido por el atacante. El algunas desventajas específicas asociados con el uso del intérprete de comandos nativas, como por ejemplo /bin/sh. Uno tal desventaja es que la ejecución del intérprete de comandos normalmente implica la creación de un nuevo proceso en la lista de tareas, con lo que el atacante sera visible durante su conexión. Incluso si la carga no se crea un nuevo proceso, la tarea existente será reemplazado por el que está siendo ejecutado. En general, la ejecución del intérprete de comandos nativos es, en función de el contexto, ya se considera como una acción de bandera roja para la mayoría de las aplicaciones y la hay una serie de basada en host Intrusion Prevention Systems (HIPS) que fácilmente detectar y prevenir tales acciones, tanto para Windows y UNIX las plataformas de derivados. Aparte de la facilidad de detección, es común que los demonios para ejecutarse en lo que se refiere como un medio ambiente *1* chroot. Este término describe la acción de cambiar la directorio raíz lógica de una aplicación que se realiza llamando a chroot sobre los derivados de UNIX. Cuando una aplicación se ejecuta en un entorno chroot que se pretende que sea imposible para la aplicación a los archivos de referencia y directorios que existen por encima de la pseudo-directorio raíz. Desde el comando intérprete normalmente existe en un directorio que está fuera del alcance de la directorio de que una solicitud se chroot para la ejecución del comando intérprete se convierte en impossible *2*.

Por último, el intérprete de comandos se limita al conjunto de comandos que se ha el acceso a, tanto internos como externos. El conjunto de comandos externos que pueden o no existir en una máquina lleva a problemas con la automatización y presenta problemas con la flexibilidad, para no mencionar estar atado a una plataforma específica o intérprete de comandos en la mayoría de los casos. Estos tres problemas que ilustran algunos de los abajo-lados a depender de un intérprete de comandos nativos y llegar a formar el razones principales para la aplicación del tema de este documento: Meterpreter. Para ese momento, meterpreter es capaz de evitar estos tres temas, debido a la forma en que se ha aplicado. En primer lugar, meterpreter es capaz de evitar la creación de la de un nuevo proceso, ya que se ejecuta en el contexto del proceso que se explota. Además, las extensiones de meterpreter, y el servidor meterpreter sí, son todos hechos totalmente de la memoria usando la técnica descrita en Biblioteca de inyección a distancia *1*. El hecho de que meterpreter ejecuta en el contexto de del proceso de explotación también le permite evitar problemas con chroot, ya que no tiene que crear un nuevo proceso. En algunos casos la aplicación que se explotados, incluso puede seguir funcionando después de meterpreter ha sido inyectada. Por último, y tal vez la mejor característica de todos, meterpreter permite un control increíble y la automatización a la hora de escribir extensiones. Las extensiones de servidor puede ser escrito en cualquier idioma que puede tener el código distribuido como un objeto compartido (DLL)forma. Este hecho hace que ya no es necesario aplicar especialmente propuesto código de posición independiente en lo que normalmente requiere de un lenguaje de bajo nivel, como de montaje. Además de resolver estas tres cuestiones, meterpreter también proporciona un conjunto predeterminado de comandos para ilustrar algunas de las capacidades del sistema de extensión. Para ejemplo, una de las extensiones, F, permite cargar y descargar archivos a y de la máquina remota. Otra extensión, Net, permite de forma dinámica puerto de la creación de adelante que son similares a SSH en que se envía al puerto localmente en la máquina del cliente, a través de la conexión meterpreter establecido, a un host de red del servidor. Esto permite a los anfitriones de gran alcance en el interior de la red del servidor que no sea directamente accesible desde el cliente. Bajo el capó la función de reenvío de puerto es simplemente construido encima de un genérico sistema de canales que permite canalizar arbitraria datos desglosados entre el el cliente y el servidor como si fuera un túnel propio. Por último, el contenido de los paquetes de meterpreter puede ser cifrado con una clave personalizada. El valor por defecto XOR cifrado es que, si bien ciertamente no segura, es sin duda capaz de hacer un buen trabajo en ofuscar la comunicación, lo que le permite evadir las firmas de IDS. Los siguientes capítulos caminar a través de los componentes técnicos de meterpreter y cómo utilizar desde la perspectiva de un cliente.

Referencia Técnica

En este capítulo se discutirá en detalle la ejecución técnica de meterpreter en su conjunto en relación con su diseño y el protocolo. Teniendo en cuenta las tres primarias del diseño los objetivos discutidos en la introducción, meterpreter tiene los siguientes requisitos:

  • 1. No debe crear un nuevo proceso
  • 2. Deben trabajar en ambientes chroot'd
  • 3. Debe permitir la extensibilidad robusta

El resultado, como se describe en la introducción, fue el uso de la memoria en la biblioteca de de la inyección y el uso del formato nativo de objetos compartidos. Por meterpreter diseño puede trabajar en varias plataformas, siempre que exista un medio por el que se repartían los objetos pueden ser cargados en la memoria *3*. Este hecho hace que sea posible tener una cliente meterpreter único que es capaz de ejecutar los módulos que están diseñados para compilar en una variedad de plataformas y arquitecturas. Un ejemplo de tal el cliente es el cliente meterpreter que está incluido en Metasploit, considerando que es implementado en Perl. En un nivel alto, meterpreter se parece a un intérprete de comandos típica. Tiene una línea de comandos y un conjunto de comandos que se puede ejecutar. La mayoría de los diferencia visible es que el cliente meterpreter puede controlar el conjunto de comandos de mediante la inyección de nuevas extensiones en el momento. Desde las extensiones pueden ser potencialmente aplicables a través de arquitecturas y plataformas, el cliente puede utilizar el meterpreter misma interfaz de cliente (y el conjunto de comandos) para controlar las extensiones sin tener en cuenta. Este hecho conduce también a la capacidad de automatizar la comunicación con y el control de de las instancias del servidor de meterpreter de una manera uniforme.

Especificaciones de Protocolo

Bajo el capó, los clientes y servidores meterpreter se comunican mediante una forma bien definida estructura de los paquetes. Con el fin de que el protocolo lo más flexible posible, había que definir de una manera que permite que se amplió sin tenerpara cambiar el análisis de paquetes y código subyacente de transmisión que se construye en meterpreter el cliente y el servidor. Al final se decidió que meterpreter se utiliza un tipo-longitud-valor, o TLV, la estructura de sus paquetes. El TLV estructura es un método por el cual arbitrariamente escrito los valores de las longitudes arbitrarias pueden se comunicarán de una manera que no requiere el código, que analiza la paquetes de entender el formato de los datos. Aunque el nombre implica que el tipo es lo primero, meterpreter pone la longitud antes de que el tipo, por lo que es Longitud de hecho-tipo-de valor como lo que respecta a la representación de datos, aunque que seguirá siendo contemplado como un TLV largo de este documento.

Estructura TLV

Estructura de Paquete

Definido TLV

Flujo de paquetes

Server Extensions

Client Extensions

Using Meterpreter

Conclusion

Command Reference

Built-in Commands

use

loadlib

read

write

close

interact

initcrypt

Extension: Fs

cd

getcwd

ls

upload

download

Extension: Net

ipconfig

route

portfwd

Extension: Process

execute

kill

ps

Extension: Sys

getuid

sysinfo

rev2self

Common API

Channel Management

channel find by id

channel get id

channel get type

channel is interactive

channel open

channel read

channel write

channel close

channel interact

Command Registration

command register

command deregister

Packet Management

packet create

packet create response

packet destroy

packet duplicate

packet get type

packet get tlv meta type

packet add tlv string

packet add tlv uint

packet add tlv bool

packet add tlv group

packet add tlv raw

packet add tlvs

packet is tlv null terminated

packet get tlv

packet get tlv string

packet get tlv group entry

packet enum tlv

packet get tlv value string

packet get tlv value uint

packet get tlv value bool

packet add exception

packet get result

packet transmit

packet transmit empty response

Encryption

remote set cipher

remote get cipher

Scheduling

scheduler insert waitable

scheduler remove waitable

scheduler run

  • 1*To conocimiento del autor, no hay soporte intrínseco para chroot capacidades de estilo en Windows
  • 2*Mientras pulsa sí existen técnicas para salir de la jaula chroot este debate está fuera de del alcance de este documento
  • 3* En el caso de que el servidor y las extensiones no se puede cargar de la memoria que debe ser

cargado y escrita en el disco, lo que les expone a la detección de posibles

No hay comentarios:

Publicar un comentario