Pentester e Intrusión en un sistema Versus Analista Forense y Detección de Intrusión (Parte I de III)

A lo largo y ancho de Internet no son difíciles de encontrar casos prácticos que explican el uso de diferentes técnicas y herramientas para aprovechar vulnerabilidades en sistemas, aplicaciones, dispositivos móviles, redes de datos, etcétera. De la misma forma, aunque en menor medida, es posible encontrar sin mucha dificultad supuestos prácticos en los que se realizan acciones de detección y análisis de distintos tipos e incidentes de seguridad.

Figura 1: Pentester e Intrusión en un sistema Versus

Analista Forense y Detección de Intrusión (Parte I de III)

En el primer caso estaríamos dentro del ámbito de la seguridad ofensiva, los red team, el pentesting y el hacking ético; y en el segundo, nos estaríamos moviendo dentro del ámbito de la seguridad defensiva, los blue team y el DFIR (Digital Forensic and Incident Response). Sin embargo, lo que no es tan fácil de encontrar son supuestos prácticos que aúnen las dos aproximaciones, es decir, supuestos prácticos en los que se realicen una serie de acciones para lograr vulnerar un sistema e inmediatamente después se analice el rastro dejado por dichas acciones en los distintos elementos o artefactos del sistema.

Ethical Hacking Didáctico

Aplicando un enfoque didáctico, son indudables las ventajas que aporta el trabajo con este tipo de casos prácticos. Desde el punto de vista ofensivo, ayuda a tomar consciencia de la mayor o menor incidencia que las acciones realizadas durante una auditoría de seguridad o test de intrusión dejan en los sistemas, lo cual redundará en una mejora a la hora de tomar decisiones durante un trabajo de este tipo.

Figura 2: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Por otro lado, desde el punto de vista defensivo, ayuda a comprender mejor el proceso por el cual han sido generadas las evidencias encontradas durante un proceso de análisis o el motivo por el cual se produce una alerta en nuestros sistemas de monitorización, esto redundará en una mayor eficiencia a la hora de analizar los artefactos de un sistema o a la hora de diseñar alertas personalizadas o indicadores de compromiso (IoCs) para nuestros sistemas de monitorización.

Durante el curso que ahora acaba, he impartido, en el CIFP Rodolfo Ucha Piñeiro de Ferrol, los módulos de Análisis forense informático y Bastionado de redes y sistemas que forman parte del nuevo Curso de especialización en ciberseguridad en entornos de las tecnologías de la información de la familia profesional de Informática y comunicaciones. Durante el transcurso del mismo, y principalmente para el primero de los módulos mencionados, he tenido que diseñar e implementar diferentes supuestos prácticos de este estilo para poder trabajar posteriormente con distintos artefactos y herramientas forenses que nos permitiesen analizar lo sucedido.

A modo de ejemplo, describo a continuación como implementar y analizar un escenario práctico sencillo sobre una máquina metasploitable 3 basada en Ubuntu Server 14.04. La utilización de máquinas de este estilo, con diferentes vulnerabilidades en los servicios que implementan, facilita mucho la tarea de preparación de un escenario ya que, sobre el mismo sistema, es posible realizar una gran variedad de acciones que tendrán distintos tipos de impacto sobre los diferentes artefactos del sistema. 

Además, es fácil encontrar abundante documentación sobre cómo explotar las vulnerabilidades que presentan. Obviamente, para ilustrar la explotación y análisis de vulnerabilidades más recientes será necesario partir de máquinas con sistemas más actuales.

Explotación de vulnerabilidades

Para realizar la intrusión utilizaremos una máquina Kali Linux situada en la misma red que la máquina objetivo. Comenzaremos realizando un escaneo con nmap sobre todos los puertos de la máquina (-p) tratando de obtener la versión del servicio que se está ejecu- tando (-sV) y estableciendo un número mínimo de paquetes enviados por segundo (--minrate 7500).

Figura 3: Servidor HTTP descubierto en puerto 3500

En este caso, vamos a aprovechar las vulnerabilidades existentes sobre el servidor de Ruby on Rails que se está ejecutando en el puerto 3500. Y haremos sobre este entorno un poco de Pentesting con Metasploit. 

Figura 4: Metasploit para Pentesters Gold Edition
de Pablo González en 0xWord

Utilizaremos para ello el exploit rails_actionpack_inline_exec de Metasploit que sacapa partido de la explotación de la vulnerabilidad con CVE 2016-2098. Primeramente, estableceremos los parámetros necesarios para ejecutar el exploit.

Figura 5: Configuración del exploit en Metasploit

Acto seguido lo ejecutamos e inmediatamente conseguimos una shell remota, pero con el usuario chewbacca que no tiene permisos de administrador.

Figura 6: Conseguido permisos de usuario

Trataremos de hacer ahora una Escalada de Privilegios que nos dé permisos de root dentro de la máquina. Para ello, primero miramos la versión de sistema operativo y el kernel de la máquina víctima.

Figura 7: Versión del kernel de la máquina víctima

Luego, haciendo una búsqueda por los exploits disponibles para dicha versión, seleccionaremos uno que nos permita una Escalada de Privilegios.

Figura 8: Búsqueda de exploits para escalada de privilegios

Una vez elegido, lo que haremos a continuación será descargar el fichero con el exploit dentro de la máquina víctima, en este caso el 37292.c, compilarlo y ejecutarlo. Lo descargaremos de https://www.exploit-db.com/download/37292:

Figura 9: Descarga del exploit de EoP que vamos a usar

Lo renombramos, compilamos y ejecutamos. Tras la ejecución vemos que hemos conseguido hacernos con privilegios de root dentro de la máquina víctima.

Figura 10: Compilación, ejecución y Elevación de Privilegios a root hecha.

Vamos a habilitar ahora un mecanismo para facilitar accesos posteriores. Ya hemos conseguido entrar pero ahora hay que conseguir la permanencia, que es otra de las fases de todo buen Ethical Hacking. Cómo conseguir tener control perdurable a lo largo del tiempo, incluso después de los reinicios y de la aplicación del parche a las vulneratilidades explotadas para conseguir el acceso inicial.

Figura 11: Pentesting con Kali Silver Edition

Para ello, vamos a mirar los usuarios que hay en el sistema y vamos a elegir uno de los que crean por defecto los servicios instalados y con los que, en teoría, no es posible iniciar una sesión interactiva. En este caso, nos fijamos en el usuario www-data. La daremos una contraseña, le indicaremos una shell de inicio y lo añadiremos al grupo sudo:

Figura 12: Usuarios disponibles en el sistema

Vamos a comprobar ahora si es posible conectarnos por SSH con dicho usuario. Lo haremos desde otra terminal de nuestra máquina Kali Linux.

Figura 13: Preparando el usuario www-data

Comprobamos cómo, efectivamente, hemos podido acceder al sistema y obtener permisos de root haciendo uso del usuario www-data que previamente hemos dejado bien preparado para poder volver a esta máquina siempre que queramos.

Figura 14: Accediendo como www-data

Y hasta aquí nuestra toma de control total de una máquina, tal y cómo lo haría un atacante de verdad. Pero toda intrusión deja rastros, y aquí no los hemos borrado pertinentemente. Esto es algo que, curiosamente, no se enseña en los cursos de test de penetración. La razón es bastante simple, cuando alguien es contratado para realizar un proyecto un Ethical Hacking no tiene porque preocuparse de que los analistas forenses lo localicen, pero los malos de verdad si que están preocupados por eso... o deberían.

En las siguientes partes vamos a ver cómo un trabajo de Análisis Forense puede descubrir todo lo que ha pasado a la hora de hacer un post-mortem de una intrusión, pero eso lo vermos en la siguiente parte de este artículo.

Saludos,

Autor: Andrés del Río

Contactar con Andrés del Río

GitHub Copilot y el debate de la Propiedad Intelectual

Ya llevo un tiempo hablándoos de Inteligencia Artificial y de algunas de sus innovadoras respuestas a problemas de la vida cotidiana y de cómo pueden afectar al futuro de nuestra sociedad. Hoy toca hablar de uno de los últimos casos polémicos en los que ha estado involucrada la Inteligencia Artificial, en este caso, de cómo GitHub Copilot ha abierto un debate acerca de si la inteligencia artificial en casos de uso como estos infringe los derechos de autor de los programadores al utilizar el código escrito por ellos para entrenarse.

Figura 1: GitHub Copilot y el debate de la Propiedad Intelectual

Si no conoces GitHub Copilot te lo presentamos brevemente. Copilot es un asistente de código diseñado para ayudar a los programadores y que funciona con Codex, un innovador sistema creado por Open AI que utiliza la inteligencia artificial para comprender el contexto del código que los programadores están haciendo para sintetizar código que coincida con el resto del programa. De hecho, Copilot es capaz de proponer a sus usuarios desde líneas de código hasta funciones completas.

Figura 2: Copilot, asistente de programación.

GitHub Copilot cuenta es de una gran velocidad, y es capaz de proponerte otras alternativas a tu código mientras escribes, además funciona como una extensión de Visual Studio Code, lo que quiere decir que podremos utilizarlo tanto en nuestro equipo como en la nube o en el entorno de desarrollo instantáneo de GitHub. Copilot también trabaja con una gran cantidad de idiomas y lenguajes de programación entre los que se encuentran Python, JavaScript, Ruby y Go, aprendidos con sus algoritmos de "Machine Learning", lo que hace que sea una herramienta capaz de orientar a la mayoría de los programadores. 

Figura 3: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández.

Como os hemos dicho antes y como su propio nombre indica, la función de esta herramienta es asistir durante la programación, aunque la herramienta pueda ofrecer interesantes alternativas para optimizar el código el programador será siempre el que tenga la última palabra. Con esto se logra ajustarse a las necesidades de cada usuario, ayudándole cuando lo necesite y dejando que escriba código de forma “tradicional” cuando quiera.

Figura 4: Funcionamiento de GitHub Copilot.

Otra de las grandes ventajas de Copilot es que ofrece la posibilidad de convertir un comentario en código. Solo hay que escribir un comentario en el que se describa la lógica deseada y esperar a que la inteligencia artificial haga su trabajo y ensamble el código por nosotros. Del mismo modo Copilot también es capaz de autocompletar patrones de código repetitivo. Esto quiere decir que si generamos un ejemplo la herramienta es capaz de generar el resto del código haciendo que solo tengamos que decidir con que partes queremos quedarnos. 

Durante la programación es común utilizar pruebas para comprobar que el software que se esta construyendo funciona correctamente y cuenta con unas bases sólidas, con GitHub Copilot es posible importar un paquete de prueba unitaria y dejar que la IA sugiera pruebas que coincidan con el código introducido para comprobar su efectividad.

Figura 5: Ejemplo de prueba para el código propuesta por Copilot.

Pero si GitHub Copilot es tan bueno, ¿por qué ha habido una creciente polémica acerca de la herramienta durante estas últimas semanas? La respuesta es sencilla, Copilot es capaz de programar gracias al código Open Source de la plataforma, código que han compartido otros programadores. Hasta aquí no hay ningún problema, el problema surgió cuando Microsoft anunció que el sistema sería de pago, lo que ha sentado mal a muchos desarrolladores. El código que ha utilizado y sigue utilizando GitHub Copilot se encuentra bajo licencias GPL, esto quiere decir que el código de la plataforma puede utilizarse para generar código derivado pero este nuevo código debe de ofrecerse bajo las mismas condiciones.

El debate de la Propiedad Intelectual

Varios programadores ya han expresado su malestar tanto en las redes sociales como en la propia plataforma ante el hecho de que se haya utilizado una Inteligencia Artificial para generar una rentabilidad comercial al código que ellos, y muchos otros, han compartido desinteresadamente. Esto ha abierto un gran debate acerca de como deberían aplicarse las leyes del Copyright en un caso como este. Según la OMPI (Organización Mundial de Propiedad Intelectual) las obras creativas gozan de la protección del derecho de autor si son originales, sin embargo, en la mayoría de las definiciones relativas a la originalidad se hace referencia a un autor humano, por lo tanto, a pesar de que la Inteligencia Artificial generase código no podría considerarse como un autor.

Figura 6: Organización Mundial de la Propiedad Intelectual (OMPI/WIPO).

Ante esta situación varios expertos han compartido sus distintas perspectivas acerca de las leyes de derechos de autor sobre este caso de uso de la IA. Algunos expertos se han mostrado a favor de que corporaciones como Microsoft utilicen el código abierto para su propio interés, argumentando que evitar su uso con estos fines supondría ir en contra de las bases del código Copyleft, y esto podría derivar en futuras leyes de Copyright cada vez mas restrictivas. También se ha planteado que a pesar de que la Inteligencia Artificial Copilot utilice este código abierto para generar nuevos fragmentos de código, no quiere decir que esto sea un trabajo derivado, y por lo tanto no debería de estar cubierto por las leyes de propiedad intelectual.

Por otro lado, muchos programadores no quieren que se utilice su código para entrenar a la Inteligencia Artificial Copilot. Si este es el caso, GitHub ofrece un detector de duplicación que alertaría a los usuarios de Copilot de que el código propuesto en cuestión se trataría de un duplicado de otro autor y ofrecería la posibilidad de atribuirle esa parte del código, o buscar otra opción. Esta solución planteada por la plataforma no acaba de convencer a aquellos programadores que no quieren que Microsoft utilice la IA para monetizar un trabajo que ellos han compartido de forma gratuita. 

Figura 7: Porcentaje de regurgitación de código tras un análisis de la herramienta

(aproximadamente un caso por cada 10 semanas de uso).

De hecho, en los términos de Licencia de GitHub se explica claramente que al compartir tu código a través de la plataforma se le da permiso para incluirlo en sus bases de datos e índices de búsqueda para que otros usuarios puedan acceder a él y así ayudarles en sus proyectos, pero no venderlo a terceros.

Por el momento no podemos saber cómo concluirá este debate debido a estos pequeños vacíos legales en la ley de Copyright en lo que a Inteligencia Artificial se refiere. Y tampoco sabemos que sucedería en el caso de que un programador demandase a Copilot o Microsoft por el uso de su código ya que, según GitHub, aunque el código que se comparte en la plataforma pueda ser utilizado por otros usuarios sigue perteneciendo a la persona que lo hizo. 

Sin duda alguna, este tema dará mucho que hablar durante los próximos meses e incluso podría llevar a una nueva reforma en la ley de propiedad intelectual.

 

Saludos,
 

Autor: Sergio Sancho, Security Researcher en Ideas Locas.

Contactar con Sergio Sancho en MyPublicInbox

TwLocation en Python y un viejo script en Ruby: La API de Twitter sigue dando juego con la info GPS

Éste es un tema que no es nada nuevo. La geolocalización de los tuits es algo antiguo, es más, nosotros en ElevenPaths hace unos años hicimos una herramienta que analizaba los tuits de un usuario y los posicionaba en un mapa, siempre y cuando el usuario tuviera activa la geolocalización de los tuits en su cuenta.

Figura 1: TwLocation en Python y un viejo script en Ruby:
La API de Twitter sigue dando juego con la info GPS

Aún recuerdo las pruebas con nuestras cuentas, creando alguna cuenta y configurando la geolocalización de los tuits. Todo comenzó con un script escrito en Ruby y acabo siendo un servicio interno. Quizá fueran los comienzos del departamento de ideas locas y de pruebas de concepto, pero de ello hablaré más tarde.

Figura 2: Geolocalización de Twitts de SteveWozniak con nuestra tool

Echando un ojo por Internet, he topado con una herramienta escrita en Python muy similar a lo que os comentaba. En este caso la herramienta se llama TwLocation y permite fijar unas coordenadas, un rango alrededor y el número de tuits que queremos encontrar en ese radio en tiempo real. La herramienta la vi en KitPloit y tiene una pinta interesante, pero no solo por lo que proporciona, si no por el cómo está hecha. Permite saber quién pone mensajes en Twitter con ubicación GPS activada, en un determinado rango de localización, al estilo del mapa de WatchDogs.

Figura 3: Mapa de Londres We Are Data del juego de WatchDogs

La herramienta se puede descargar desde Github y tiene unos pocos días, al menos en esta versión, subida al repositorio. El funcionamiento es sencillo, la herramienta utiliza OAuth para poder realizar peticiones a la API de Twitter.

Figura 4: TwLocation en Twitter

Cuando descargamos la aplicación de TwLocation, ésta tiene unos requisitos que se pueden encontrar en el fichero de requirements.txt. Para instalar los requisitos ejecutamos el pip install –r requirements.txt. En el fichero config.txt, encontramos la configuración de la App OAuth. En el caso de Twitter requerimos: Consumer_Key, Consumer_Secret, Access_Key y Access_Secret. Esta información se puede obtener con una cuenta de Twitter y accediendo al dominio dev.twitter.com o developer.twitter.com.

Figura 5: Instalación de TwLocation

Cuando se configura el fichero config.txt con lo necesario para poder utilizar la API de Twitter, se ejecuta con Python el script. Al arrancar el script nos solicita datos sobre latitud, longitud, el rango alrededor de ello y el número de resultados máximos que se van a obtener y almacenar en un fichero CSV.

Figura 6: Usuarios que twittean en una determinada ubicación GPS con el tiempo

En la imagen superior, se puede ver los datos introducidos y con el paso del tiempo se van recibiendo en tiempo real diferentes tuits que cumplen las condiciones de geolocalización indicadas. Por ejemplo, si fijamos un punto concreto, estaremos viendo lo que se tuitea alrededor de dicho punto. Es más, veremos quién tuitea, ya que el username también se obtiene.

Figura 7: Fichero CSV de salida

Además, la herramienta facilita la posición en un mapa a través del enlace a Google Maps. Esto es interesante para pintarlo. Esta parte tiene relación con el ‘viejo’ script de Ruby llamado Poc_Twitter.rb que en su día realicé. Al finalizar la ejecución, se obtiene un fichero CSV, el cual, como se puede ver en la imagen, proporciona los siguientes campos:

• Username
• Profile URL
• Latitude
• Longitude
• Google Maps
• Tweet

El fichero es automatizable, es decir, podríamos procesarlo con otro script para procesar la información obtenida. Como se puede entender es interesante, cuando manejamos un gran volumen de información. En el siguiente vídeo se puede ver cómo funciona TwLocation.
El viejo script ‘Poc_Twitter.rb’

Este script que data de finales de 2014 tiene bastante historia. Jugando con OAuth por aquel entonces, jugando con Twitter y con el libro Got Root en la cabeza, ya que algo aparece allí, decidí hacer una pequeña prueba de concepto. Primero, identificar si un usuario tenía la geolocalización activa. Esto es algo que la API de Twitter te indicaba a través de un campo. Rápidamente, puedes saber si un usuario tiene la geolocalización activa, y como vimos, famosos y terroristas tenían activada esta geolocalización en Twitter.

Figura 9: Tuits de un terrorista con ubicación GPS

Esto no acaba aquí, si el tuit tiene coordenadas es que ese tuit iba con información GPS. Generalmente, puede que el usuario sepa que su tuit está geolocalizado y sea consciente de ello, es más, quiere que la gente vea desde dónde lo tuiteó. El problema venía cuando el usuario no es consciente de ello. Esto supone un riesgo. Por supuesto, yo hice mi script para ver si mi cuenta tenía habilitada la geolocalización y mis tuits estaban enviando demasiada información ;-)

Figura 10: Mensajes de una cuenta Twitter de un famoso con ubicación GPS

A continuación, se puede ver el comienzo del ‘viejo’ script. Como se puede ver, necesita los mismos parámetros que TwLocation.

Figura 11: Token OAuth para consultar la API de Twitter

Cuando se obtienen los tuits de la cuenta @pablogonzalezpe, en este ejemplo, se verificaba el campo geo y geo_enabled. En el caso de que estos campos fueran positivos, tendrían la localización desde dónde yo tuiteé. Al final, la suma de los tuits puede provocar un timeline de posicionamiento por dónde cualquiera sepa por dónde vas. Hay que tener cuidado con ello y comprobar si nuestros tuits están enviando nuestra ubicación.

Figura 12: Captura de tuits con ubicación GPS activada

Para finalizar, os muestro una ejecución desde una cuenta que tenía antigua y que tenía tuits geolocalizados para la prueba de concepto. Como se puede ver, es un ejemplo muy similar a lo que hemos visto con TwLocation.

Figura 13: Nuestra PoC con info similar a TwLocation

Sin duda, eran sin saberlo, los comienzos del departamento de ideas locas de CDO. Cosas que hacíamos en ElevenPaths a finales del año 2014, aunque por aquel entonces mi responsabilidad era Faast, siempre teníamos tiempo para esas pequeñas ideas locas. En el año 2016 impartí un taller sobre el uso de la API de Twitter con Python con mi amigo Alberto Sánchez, en la HoneyCON, dónde ampliamos casos con la Streaming API de Twitter. Realmente interesante. Al final un pequeño script y una pequeña idea puede dar para varias cosas, cuando poco a poco se va desarrollando y aprendiendo.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Nuevo Libro de @0xWord: Hacking con Metasploit: Advanced Pentesting #pentesting #Metasploit

Desde este fin de semana es posible adquirir el nuevo libro en 0xWord de Pablo González y Borja Merino dedicado a las técnicas avanzadas de uso de Metasploit. Con el título de "Hacking con Metasploit: Advanced Pentesting" ha cobrado forma la segunda parte del ya "Best Seller" "Metasploit para Pentesters", que va por su cuarta edición.

Figura 1: Nuevo Libro de @0xWord "Hacking con Metasploit: Advanced Pentesting"

El libro tiene un total de 264 páginas y en ellas se tocan técnicas avanzadas de pentesting, así como también el desarrollo de nuevos payloads y scripts para ampliar las funcionalidades disponibles en el framework. Tienes el libro disponible en la siguiente URL: Hacking con Metasploit. Advanced Pentesting.

Figura 2: Libro de Hacking con Metasploit: Advanced Pentesting

En palabras de los autores:

"Metasploit sigue siendo, con el paso de los años, una de las herramientas predilectas por red teams, pentesters, así como responsables de seguridad de todo tipo de compañías. La incorporación constante de nuevos exploits, payloads, módulos auxiliares y módulos de post-explotación para diversos sistemas operativos, convierten a este framework en uno de los mejores recursos para auditar el nivel de seguridad de todo tipo de entornos.

Mediante este libro el lector abordará, desde un prisma totalmente práctico, técnicas avanzadas de pentesting, el desarrollo de payloads y módulos de post-explotación, cómo evadir entornos restrictivos, modificar shellcodes, etc. Estas temáticas cubrirán muchas de las necesidades a las que se enfrentan pentesters en su día a día planteando escenarios reales y describiendo técnicas y herramientas actualmente utilizadas por expertos en seguridad. El lector podrá desarrollar sus propios módulos para automatizar todo tipo de tareas aprovechándose de la arquitectura modular utilizada por el framework.

Si te gustó el libro “Metasploit para Pentesters” y deseas mejorar significativamente tus habilidades con Metasploit no cabe duda que éste es tu libro."

Y para que puedas conocer en detalles los contenidos del libro, os he subido por aquí el índice detallado de todos los capítulos.

Figura 3: Índice del libro Hacking con Metasploit. Parte 1

Figura 4: Índice del libro Hacking con Metasploit. Parte 2

Figura 5: Índice del libro Hacking con Metasploit. Parte 3

Saludos Malignos!

Scripteando con Meterpreter: Sacando un screenshot y algunas cosas más

Estamos en semana PRE-RootedCON y quería seguir hablando sobre el Meterpreter y los scripts que nutren a este magnífico payload. Quería hacerlo desde otro punto de vista que es la creación de estos scripts que hacen que las funcionalidades que Meterpreter nos ofrecen un pentest sean infinitas. Hace unas semanas hablamos sobre cómo funcionaba el IRB en un Meterpreter y también en Metasploit, ya que también se puede utilizar desde la consola msfconsole.

Figura 1: Scripteando con Meterpreter: Sacando un screenshot y algunas cosas más

En el artículo de hoy ampliaremos el uso del IRB del pasado artículo para ver qué tipo de acciones podemos hacer y cómo sacarle el máximo rendimiento y poder hacer nuestros primeros scripts. Sobre todo, ir cogiendo ideas para todo lo que se os pase por la cabeza hacer con una sesión de Meterpreter.

Figura 2: RootedLabs

Hoy comenzaremos con la posibilidad de crearnos nuestro propio script que nos permita capturar la pantalla de la máquina comprometida. Para ello, estudiaremos las diferentes funciones y el uso de estas para lograr nuestro objetivo. Respecto a la RootedCON, no dejes pasar la oportunidad y apúntate en estos últimos días al Lab de Metasploit que tengo el honor de impartir allí.

Los métodos para el estudio

Meterpreter dispone de un comando propio que se llama screenshot, por lo que sabemos que se puede capturar la pantalla de la máquina comprometida de manera sencilla. Ahora vamos a localizar el método que se puede utilizar para llevar a cabo esta acción desde el objeto client en el IRB de Meterpreter.

Hay una clase llamada UI, User Interface, con la que Meterpreter puede acceder a diferentes dispositivos de interacción como, por ejemplo, el teclado, el ratón o la pantalla. Si observamos la imagen podemos ver como el objeto client dispone de una serie de métodos que cuelgan de ui. En estos métodos ya podemos ver cosas interesantes como idle_time, screenshot, keyscan_start, keyscan_dump, keyscan_stop, etcétera. Ya podemos imaginar las cosas que podemos hacer con ello, y todo desde el IRB y acabar generando nuestra funcionalidad en forma de script de Meterpreter.

Figura 3: Clase UI

Vamos a hacer uso de client.ui.screenshot. Antes de generar el código, vamos a probar que tipo de salida facilita el método. Para ello lo invocamos y lo almacenamos en una variable del intérprete. Como se puede ver, la salida es un array de bytes, los cuales representa la captura de pantalla de la máquina remota.

Figura 4: Datos de la captura de pantalla

Con la opción conf.echo podemos indicarle al IRB si queremos que la salida de ejecución se muestre por pantalla. En el caso de la obtención del screenshot, no queremos ver la representación en bytes, solamente queremos que se almacene en una variable, en este caso en la variable screen. Con el método length vemos el tamaño de la captura.

Ahora, volcaremos el contenido a un fichero utilizando para ello la clase fs y file en el objeto client. Utilizaremos la instrucción client.fs.file.methods y obtenemos un listado de métodos disponibles. Descubrimos el método download, el cual nos permitirá descargar a nuestra máquina, en este caso, un Kali Linux. Hay que tener en cuenta como generamos el fichero y con qué modo de apertura. Para este ejemplo, lo abrimos con 'wb', es decir, que podemos escribir en él.

Lo primero será crear un fichero en la máquina remota con client.fs.file.new, tal y como se puede ver en la imagen. Una vez creado el fichero en remoto, utilizaremos el método client.fs.file.download para descargarlo desde la máquina comprometida hacia nuestra máquina.

Figura 5: Descarga de la captura de pantalla a fichero

Recapitulando, en la máquina Windows comprometida se debe haber creado un fichero en el escritorio del usuario. Como se puede ver en la imagen, el fichero, ahora mismo, ocupa 0 bytes, ya que aún no hemos volcado los bytes de la variable screen en el fichero. Además, si el fichero se intenta eliminar actualmente no se podrá, ya que está siendo utilizado por el proceso. En otras palabras, el fichero está abierto.

Figura 6: Primero creamos el fichero con 0 bytes

Ahora volcamos el contenido de screen al fichero mediante el uso del método write. Este método lo encontramos en client.fs.file. Una vez hecho esto, hay que cerrar el fichero con el método close.

Figura 7: Volcando los datos de la captura al fichero creado

Ahora toca descargar el fichero mediante el uso de client.fs.file.download. Realmente, existen dos métodos download y download_file. En este caso, vamos a utilizar el método download_file, el cual, si vemos el código fuente vemos que recibirá dos parámetros. ¿Dónde encuentro las declaraciones de las funciones? En este caso, podemos encontrarlo en /usr/share/metasploit-framework/lib.

Figura 8: Descarga del fichero

El fichero se llama file.rb y contiene la definición de los métodos de la clase file comentada anteriormente. Ahí podemos ver como el método necesita dos argumentos y qué tipo de argumentos necesita. Por último, ejecutamos la instrucción client.fs.file.download_file("/root/screenW7.jpg", "c:\\users\\ieuser\\desktop\\screen.jpg").

Automatizando todo: Generando el script para Meterpreter

Por último, vamos a crear un script para Meterpreter. Hay algún cambio como, por ejemplo, la no necesidad de hacer el download. ¿Por qué? Cuando hacemos el client.ui.screenshot, ya se dispone en local del array de bytes, por lo que, directamente, se puede volcar a un fichero local.

La primera parte del script, que se puede ver más abajo, comprueba si la plataforma en la que se está ejecutando el paylaod es Windows. En caso de que no, el script no se ejecuta. Si la ejecución sigue adelante, se hace el procesamiento de los argumentos que el script puede recibir. La clase Arguments se encarga de recibir un listado en formato clave-valor, dónde la clave es un valor del parámetro, en este caso será '-h' e 'i'. El valor asociado a la clave es un array con dos elementos. En el caso de '-h' se ejecutará la opción de ayuda.

Figura 8: Script del payload que automatiza la captura

La variable opts tiene el método parse, con el que se "parsea" la entrada del script. La variable args con los argumentos del script es pasada al método parse. Cuando se ejecuta el script, utilizando run myScreen -i, la variable args alberga la línea de entrada dónde se encuentra, en este caso, -i. Si el usuario ejecuta el parámetro -i, se cambiará el estado de la variable idle a true y, posteriormente, se ejecuta las instrucciones necesarias para obtener el screenshot.

Para ejecutar el script en nuestra sesión de Meterpreter, simplemente podemos ejecutar la siguiente instrucción con el comando run o, directamente, podemos introducir nuestro script en la carpeta dónde se encuentran el resto de scripts de Meterpreter, para evitar utilizar el run.

Figura 9: Ejecución del script

Sin duda, el IRB nos proporciona un mundo lleno de posibilidades para el desarrollo de funcionalidades nuevas para el framework de explotación más utilizado. Atrévete y juega con el IRB de Metasploit y Meterpreter y plasma tus ideas.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths