Latch’sApp: módulo de exfiltración de datos con Latch Python en iOS #Latch #pentesting

Hace un tiempo escribí una entrada en este post acerca de el desarrollo de un módulo multiplataforma para Python y Swift con el que poder exfiltrar datos entre dispositivos con Latch'sApp. Allí, introduje la aproximación que seguimos nuestro equipo del Trabajo de Fin de Máster sobre la idea que nos propuso Pablo González para nuestro proyecto basada en Latch'sApp, junto con todo el potencial que puede generar la implementación en esas dos plataformas.

Figura 1: Latch’sApp: módulo de exfiltración de datos con Latch Python en iOS

Con ganas de seguir explorando esta idea, se me ocurrió portar el módulo de Python a una app de iOS que he estado utilizando últimamente.

Pythonista

Pythonista es un entorno de desarrollo de Python 3 y Python 2 para iOS que permite ejecutar scripts e incluye las librerías y módulos de Python más populares. Además de todo esto, la aplicación aporta soporte extra para el control de elementos de iOS como contactos, fotos, localización, elementos de interfaz y mucho más. Es, junto a Working Copy, Coda o Prompt, de las mejores herramientas para el desarrollo en iPhone e iPad. Así, teniendo un interprete de Python en iOS tan completo como este, ¿por qué no usarlo?

Una vez me puse manos a la obra, lo primero que tuve que descartar fue almacenar la clave y el secreto de Latch en una variable de entorno, ya que por desgracia Pythonista no da soporte esta funcionalidad. Por ello, tuve que optar a almacenar las claves en un archivo global para importarlas en cualquier documento. Además añadí este archivo al gitignore del proyecto para evitar que pudiese filtrarse en una subida accidental. Debido a esto, también tuve que cambiar del script de ejecución la comprobación de la variable ‘account_id’ y eliminar el proceso de obtención de ésta a través de Latch.


Figura 2 - Video de exfiltración multiplataforma con Latch
Por lo demás, el funcionamiento sigue siendo el mismo y no difiere de la ejecución en cualquier otra plataforma. Siendo muy sencillo importar el proyecto, pensé en aprovechar varias de las herramientas que ofrece Pythonista para mejorar un poco el script y darle nuevas funcionalidades.

UI en Pythonista

El módulo UI que viene incluido en la app provee componentes similares a la interfaz gráfica de Apple. Este módulo está basado en el framework UIKit, simplificando muchos de sus aspectos. Además, Pythonista ofrece una herramienta de diseño UI para configurar los elementos que queremos incluir en nuestro script, facilitando mucho el proceso de creación de una interfaz gráfica para Python en esta aplicación.

Figura 3: Herramienta de diseño UI en Pythonista

Estos elementos se almacenan en forma de diccionario al que podemos acceder a través de cualquier archivo Python que importe UI y cargue la vista. Podéis encontrar más información acerca de este módulo en su documentación.

Figura 4: Código en Python de view_script.py con Interfaz Gráfica

Una vez construida la interfaz, modifiqué el script de escritura de latch para incluir las funciones que actualizan la interfaz. Hay que recordar que si queremos ejecutar la funcionalidad a través la interfaz gráfica hay que dejar el hilo principal para actualizar los elementos gráficos de la aplicación. Para ello, el módulo UI incluye el decorador “@ui.in_backgroud” para poder tener control de los hilos de ejecución.

PoC: Let´s do it

Una vez integrada la interfaz gráfica, se me ocurrió probar las nuevas funcionalidades con la app de iOS en Swift para exfiltrar datos con Latch. Como no quería abandonar el iPad como entorno de desarrollo y pruebas, decidí convertir el proyecto de XCode en una aplicación universal, para que pudiera ejecutarse tanto en iPhone como en iPad.

Figura 5: Proyecto de XCode optimizado para iPad

Para ello solo tuve que cambiar un poco los elementos de la interfaz, que al usar AutoLayout se adaptan a cualquier formato de pantalla, e indicar en la Property list del proyecto las orientaciones de pantalla tanto para iPhone como para iPad. Teniendo todos estos cambios es posible probar la exfiltración de un mensaje entre aplicaciones en un Ipad.


Figura 6: Video de exfiltración en iPad entre dos aplicaciones, una en Python y otra en Swift
Bonus extra - extensiones en iOS

Mientras estaba escribiendo este post, encontré en la documentación de Pythonista la posibilidad de crear Extensiones y Widgets fácilmente a través de un módulo Python que aporta la app. Básicamente, el módulo appex permite detectar si la ejecución de un script se realiza a través de una extensión o widget, e incluye varias funciones para gestionar el flujo de ejecución. Por ejemplo, con ‘get_text()’ puedes acceder al texto que recoge la extensión, con ‘get_image()’ a imágenes, etcétera.

Así que, con unas pocas lineas de código, pude crear una extensión para exfiltrar cualquier texto desde cualquier parte de un dispositivo iOS a través del módulo en Python.


Figura 7: Funcionamiento de la extensión en iPad
Estos han sido los añadidos que he conseguido jugando un poco con las herramientas de desarrollo que existen en iOS. Se puede observar que poco a poco esta plataforma va incluyendo aplicaciones potentes que permiten programar desde dispositivos móviles. De nuevo vuelvo a dejar el enlace al repositorio del proyecto, por si queréis pasar a echar un ojo o ampliar funcionalidades.

Un saludo.

Autor: Lucas Fernández

Powershell Empire: Trabajando el PtH (Pass the Hash) con Mimikatz

Hace ya un tiempo, más de un año para ser exacto, trabajé bastante el tema del Pentesting con Powershell. En su día hablé de qué era Powershell Empire con su potencia en la post-explotación y algunas de las cosas que se podían hacer con él. El proyecto ha seguido avanzando y tiene cosas muy interesantes de cara a su uso en un Ehtical Hacking.

Figura 1: Powershell Empire: Trabajando el PtH (Pass the Hash) con Mimikatz

Hoy quería hablar de cómo se puede utilizar Powershell Empire, como gran herramienta de post-explotación, con el objetivo de hacer un PtH o Pass the Hash, aprovechándonos de que tenemos el hash NTLM del usuario administrador. La integración entre Metasploit y Powershell Empire es, hoy en día, sencilla gracias a la posibilidad de crear un stager de Empire en formato DLL. Metasploit dispone de payloads que permiten inyectar una DLL en el proceso de explotación de una vulnerabilidad, por lo que conseguiríamos ejecutar el agente de Powershell Empire en ese instante.

Comenzando

Vamos a empezar especificando un posible escenario. Como se puede ver en la imagen, partimos de dos agentes de Empire ejecutándose en una máquina Windows. El primer agente lo hemos llamado NoPriv, mientras que el segundo agente se ha llamado Privilege. El primero de ellos, podemos suponer, fue creado en el proceso de explotación y ejecución de código de una vulnerabilidad, siendo el código ejecutado el agente. Por otro lado, el agente llamado Privilege, puede ser consecuencia de una escalada de privilegios o, por ejemplo, un bypass de UAC, llevado a cabo desde el primer agente.

Si ejecutamos el comando agents en la consola de Powershell Empire se pueden ver los diferentes agentes de los que disponemos. Además, en el username tenemos un '*', el cual nos indica que el agente se está ejecutando en un nivel de integridad alto. El nivel de integridad también se puede consultar ejecutando sysinfo dentro de la sesión de cada agente.

Figura 2: Agentes activos y niveles de privilegio

La interacción con los agentes se realiza a través del comando 'interact'. Como podemos ver en la Figura 3, si intentamos acceder a un recurso administrativo, como es C$, ni en la sesión del agente sin privilegio, ni en la sesión del agente con privilegio se puede acceder.

Figura 3: Comando interact

Este hecho podría darse por diferentes razones como, por ejemplo:

• La máquina 10.0.0.2, la cual es un Windows 10, no tiene un usuario con la misma contraseña que el usuario con el que se ejecuta el proceso del agente.

• Realmente el agente no está elevado. En el caso de 'NoPriv' es obvio, pero en el otro caso sí que lo está.

• El agente 'Privilege' no está utilizando el Access token adecuado.

En este caso, la tercera opción comentada anteriormente es la correcta. El proceso del agente está elevado, pero no está utilizando el Access token del usuario Administrator. Por esta razón, vamos a utilizar el agente elevado para acceder a la SAM del sistema y poder sacar el hash NTLM del usuario Administrator.

Utilizamos el comando usemodule para acceder al módulo credentials/powerdump. Prácticamente, el módulo no necesita configuración, por lo que lo ejecutamos y obtenemos el contenido de la SAM.

Figura 4:  Ejecución del comando usemodule

Una vez se tiene la información de la SAM, y basándonos en el principio de localidad de que, si el Administrator de una máquina tiene como clave 'xxxxxx', el mismo usuario en la máquina de al lado, en ese departamento, tendrá la misma clave. Esto sigue ocurriendo en muchos lugares.

Mimikatz y el PtH

La integración de Mimikatz en Metasploit y en Powershell ayuda y mucho a simplificar el proceso e, incluso, a evitar la detección por parte de los antivirus. Para acceder al módulo utilizamos el comando usemodule y accedemos al módulo credentials/mimikatz/pth.

En este módulo hay que configurar algunos parámetros, aunque es realmente sencillo:

• El parámetro domain puede ser configurado como WORKGROUP, si el usuario no es de dominio.

• El parámetro ntlm debe ser configurado con el hash obtenido anteriormente del volcado de la SAM.

• El parámetro user debe ser configurado con el usuario Administrator. El nombre del usuario dependerá del idioma de la máquina.

Una vez configurado, se ejecuta el módulo y esto genera un job para que el agente lo ejecute en la máquina Windows. El resultado es algo similar a lo que se puede ver en la parte inferior, es decir, Mimikatz crea un nuevo proceso, llamado cmd.exe, con credenciales aleatorias.

Figura 5: sustitución del Access Token

Posteriormente, Mimikatz sustituye el hash en memoria por el verdadero. Al final, Mimikatz lanza el proceso cmd.exe con las nuevas credenciales asignadas, es decir, con el Access token que nos interesa. El resultado es que obtenemos un proceso, del cual tenemos el PID, y se está ejecutando como Administrator.

Figura 6: Ejecución de mimikatz y sustitución del Access Token desde Kali Linux

Ahora, necesitamos robar el token del proceso para que el agente lo pueda usar. Desde el agente 'Privilege' ejecutamos la instrucción steal_token [PID], dónde el PID será el del proceso que Mimikatz nos ha creado.

En este instante, tenemos el Access token del usuario Administrator funcional para nosotros, por lo que si ejecutamos la instrucción 'dir \\10.0.0.2\c$' que antes nos daba problemas, ahora, no los dará.

Figura 7: Acceso a recurso privilegiado

Por último, os dejamos un video para que podáis echar un ojo al proceso y veáis el potencial que tiene Powershell Empire y herramientas como Mimikatz en un entorno preparado para el Pentesting con Powershell.


Figura 8: PoC en Vídeo
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

Telefónica lanza AURA en 6 países y el nuevo Movistar Home para España: Disfruta los vídeos #HelloAura

Aún estoy con la resaca del evento de ayer, y la agenda que tengo preparada para hoy no me da mucho tiempo para escribiros cosas por aquí. Tengo muchas cosas que contaros de estos días, muchas cosas que explicar, muchos detalles para que podáis entender todo lo que hemos estado creando en Telefónica los últimos 18 meses. Ha sido mucho trabajo de mucha gente, y quiero dedicarle el detalle que merece cada parte de lo que hemos anunciado ayer, así que será en varias entradas.

Figura 1: Telefónica lanza AURA en 6 países y el nuevo Movistar Home para España: Disfruta los vídeos

Hoy solo os voy a dejar los grandes titulares con seis vídeos. Primero el vídeo completo de ayer subtitulado. Hay partes en inglés y partes en español, así que hemos subtitulado todo el evento para que sea más fácil de seguir.

Figura 2: Evento Hello AURA completo

El segundo vídeo es solo un resumen ejecutivo del evento, de un par de minutos que permite acceder a la información más relevante en poco tiempo. Para los que tengáis prisa.

Figura 3: Hello Aura en 2 minutos

El siguiente es un vídeo con nuestro querido Rafa Nadal que explica cómo funciona AURA en España desde este viernes, a través de la aplicación móvil "Movistar+ Habla!" que puedes descargar en los markets de aplicaciones. Todos los enlaces a las apps los tienes en las web de AURA.

Figura 4: Rafa Nadal y Aura

Los últimos tres, son vídeos conceptuales que explican en unos segundos algunas de las características fundamentales de nuestro nuevo "niño" Movistar Home que reinventa las comunicaciones y la TV en el hogar. Espero que os guste, y que entendáis que, al final, sigue siendo un teléfono fijo como los de siempre }:)

Figura 5: Movistar Home: La TV como nunca la habías visto antes

Figura 6: Movistar Home: Las comunicaciones por vídeo conferencia & la TV

Figura 7: Movistar Home: Las comunicaciones fijas cómo nunca antes
Saludos Malignos!

El MWC, un par de Webinars de ElevenPaths & LUCA y también un par de citas con la seguridad esta semana: La RootedCON y un Curso Online de Hacking Ético

Hoy domingo es un día importante para nosotros. A primera hora de la tarde tendremos un evento en el Auditorio del edificio de Telefónica en Diagonal Cero. Un evento en el que vamos a presentar algo en lo que hemos estado trabajando durante el último año y que esta tarde vamos a enseñar por vez primera. Este evento dará el carpetazo para nosotros, de un buen número de conferencias y charlas durante el Mobile World Congress. Yo estaré el domingo en este evento que os he dicho, el lunes en un panel en el Mobile World Congress y el martes en 4YFN en un panel sobre innovación.

Figura 1: El MWC, un par de Webinars de ElevenPaths & LUCA y también
un par de citas con la seguridad esta semana: La RootedCON y un Curso Online de Hacking Ético

Y como el tiempo apremia, hoy aprovecho para dejaros los eventos y citas de esta semana junto con un par de Webinars que han tenido lugar esta semana pasada. El primero es de nuestros compañeros en LUCA, que nos hablan y nos hacen demos de una de nuestras soluciones Big Data que implementa analítica descriptiva, predictiva y prescriptiva para ayudar a gestionar flotas de vehículos conectados.

Figura 2: LUCA Talk sobre LUCA Fleet

El segundo de los webinars es una re-edición de uno que hicimos hace ya tiempo. En él, nuestro compañero Ioseba Palop de ElevenPaths explica cómo desarrollar aplicaciones .NET integrando Latch, para añadir un pestillo de seguridad a las soluciones que desarrolles con éste lenguaje.

Figura 3: CodeTalk 4 Developers: Integración de Latch en aplicaciones .NET

Y una vez visto dos citas para esta semana en el mundo de la seguridad. La primera de ellas el Curso Online de Hacking Ético en The Security Sentinel. Una formación de 180 horas que da comienzo el día 1 de Marzo y en el que recibirás como material de apoyo los libros de 0xWord dedicados a "Ethical Hacking" y a "Pentesting con FOCA". Tienes toda la información y el temario detallado en la web del curso.

Figura 4: Curso Online de Hacking Ético

Y luego toca, la RootedCON, donde tenéis los RootedLabs los días 26, 27 y 28 de Febrero, es decir, de lunes a miércoles, para tener de jueves a sábado las charlas. Yo estoy el sábado a las 13:00 horas, pero vamos a hacer unas sesiones de firmas de libros de 0xWord, y yo estaré dos horas, en dos días para firmar libros. Esta semana os dejo el horario completo de firmas.

Figura 5: Llega ya la RootedCON

Tampoco me quiero olivdar de que, en mitad del MWC, hay una parada en Vitoria-Gasteiz, con el evento CyberGasteiz, donde además de las ponencias - en las que participan mis compañeros Felix y Yaiza de ElevenPaths y el gran Vicente Aguilera de Internet Security Auditors - podrás adquirir los libros de 0xWord. Será los días 28 de Febrero y 1 de Marzo.

Figura 6: CyberGasteiz en Vitoria

Y ahora, a disfrutad el domingo, yo voy a enfundarme el gorro y subir al escenario en unas horas para presentar esta tarde en lo que hemos estado trabajando este tiempo atrás.

Saluos Malignos!

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!

Una historia de la estrategia Data-Centric para ser Data-Driven Decisions: Parte IV "La llegada de AURA"

Cuando comenzamos a trabajar en la creación de YOT ("You On Telefónica), tal y como os contaba en la parte anterior de esta serie de artículos, diseñamos una arquitectura que permitiera construirlo con los principios que nos habíamos planteado en Telefónica. Queríamos, como más tarde expusimos durante la presentación que dimos en el Mobile World Congress el año pasado, dotar al usuario, a través de YOT, de tres "poderes".

Figura 18:  Una historia de la estrategia Data-Centric para ser
Data-Driven Decisions: Parte IV "La llegada de AURA"

No voy a centrarme mucho en explicar en detalle todos los "poderes", ya que están en el vídeo de lanzamiento que os dejo aquí incrustado, y en este artículo en el que explicaba "El negocio oculto de AURA" tras su anuncio.

Figura 19: Aura, the heart of the 4th Platform

No lo he dicho aún en este artículo, pero como os podéis imaginar todos, lo que inicialmente fue YOT se convirtió en AURA. Y no, no lo bauticé yo. Durante varios meses de trabajo, el equipo de Marca de Telefónica hizo un estudio en todos los países donde tiene presencia nuestra compañía. Hizo ejercicios de nombres, se registraron varias marcas que salieron a colación en los ejercicios de brainstroming, se trabajo el significado de cada uno de los posibles nombres puestos sobre la mesa, y después de mucho pensar y debatir, el nombre de AURA y su imagen nos convenció a todos.

He de decir, sobre el nombre - el cual adoro -, que hubo algunos compañeros que querían bautizar a nuestra pequeña AURA con el nombre de Matilde, por una referencia a los antiguos y populares anuncios en Televisión de José Luís López-Vázquez hablando de las acciones de Telefónica a Matilde. Por suerte, el equipo de marca se mantuvo firme en AURA, y yo me quedé tan contento. De hecho, en el Encuentro que tuvimos las pasadas navidades, donde hice la demo en el escenario con mi Mi Hacker hablando con AURA yo le lancé un guiño a mis compañeros que estaban a favor del nombre de Matilde.

Figura 20: Los anuncios de "Las Matildes" en los años 50

Lógicamente, para conseguir poder construir AURA, necesitábamos que la 4ª Plataforma no solo tuviera los datos normalizados como os he explicado en el artículo anterior, sino que debíamos normalizar los interfaces de ejecución. Necesitábamos una estandarización global de APIs con las que ejecutar acciones dentro de los sistemas de la casa, es decir, un API Gateway para ir de la 4ª Plataforma a los sistemas en cada país, y que permitiera desarrollar apps y casos de uso por encima.

Figura 21: Explicación de la 4ª Plataforma con piezas de construcción

Hacer entender esto a veces me resultaba complejo, así que convencí a mis compañeros de Brand Experience en CDO para hacer una explicación didáctica utilizando piezas de construcciones. Este vídeo lo hemos usado internamente para contar los conceptos fundamentales de la 4ª Plataforma, y aquí os lo he subido para que lo podáis ver en la Figura 4.

Figura 22: SmartWiFi en Chile sobre el HGU de Telefónica

Conectando los Datos y las API, desarrollar sistemas globalmente es más sencillo, y nos permite hacer cosas como gestionar los routers WiFi con una app global que se llama SmartWiFi. Aquí está la versión de Chile, que funciona contra un router que también hemos diseñado íntegramente en Telefónica, el HGU.

AURA sobre la 4ª Plataforma

Visto todo esto, el esquema con el que explico qué es AURA, nuestra Cognitive Intelligence en Telefónica, es el que hice en este dibujo que os dejo por aquí, y que he utilizado en muchas conferencias. He de decir que ese gráfico que hice, a día de hoy, decora la puerta de mi nevera con imanes. Mi Hacker y Mi Survivor ponen y quitan cosas de encima de él, pero todas las mañanas lo miro para que mi cabeza repase cómo va el proyecto completo.  Espero que lo podáis entender el esquema.

Figura 23: Esquema de piezas de cómo funciona AURA por detrás en Telefónica

Al final, AURA utiliza un bot multicanal al principio, donde se utilizan Cognitive Services para construir lo que llamamos nosotros "Natural Interaction", que una vez será hablando, otra vez será escribiendo, otras será haciendo "point & click" sobre un menú de "tiles" u opciones en una pantalla. De ahí se conecta al módulo de reconocimiento de intenciones donde se entrena a AURA para que reconozca más o menos formas de comunicarse para la misma intención.

Una vez identificada la intención, AURA, utilizando los datos de la 4ª plataforma en el Personal Data Space del usuario y la información de contexto, planifica una acción a ejecutar en los sistemas de Telefónica o de terceros, por lo que a través del API Gateway conectamos AURA globalmente en cada país - tal y como explicaba el vídeo de las piezas de construcciones -.

Si llevamos esto a un mapa, podéis ver cómo tenemos identificadas las partes de AURA con las funciones que tiene que ir realizando la IA dentro de Telefónica. Un autentico trabajo de fontanería fina en el que intervienen muchas piezas y que permite escalar los casos de uso con nuevas iteraciones del sistema.

Figura 24: Funciones en cada pieza

Por supuesto, AURA necesita día a día ir incorporando nuevos casos de uso, así que cuando se reconocen intenciones que no están siendo tratadas, lo que hacen los equipos es entrenar el sistema para que reconozca la nueva intención, hacerlo de múltiples formas, publicar las APIs necesarias para conectar el sistema en el país con la función que se necesita, y normalizar los datos en URM dentro de los Personal Data Spaces para que se pueda hacer la acción con la información necesaria.

Poco a poco, todas las piezas se han ido encajando en un mapa que os contaré en las siguientes entradas, para que tengáis una visión más completa de cómo hemos ido articulando la transformación de las tecnologías en los últimos años.

Saludos Malignos!

*************************************************************

- Data-Centric para ser Data-Driven Decisions: Parte I
- Parte II "La Estrategia de la Margarita"
- Parte III "La creación de YOT"
- Parte IV "La llegada de AURA"
- Parte V "La puesta de largo de AURA"
- Parte VI "El end-point móvil"
*************************************************************

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

Una historia de la estrategia Data-Centric para ser Data-Driven Decisions: Parte III "La creación de YOT"

Estaba claro que había que hacer más en nuestra estrategia - como os contaba en la entrada anterior - que simplemente crear caso de uso internos - a partir de ahora permitidme que los llame IUC - basados en los datos normalizados en nuestro Modelo de Referencia Unificado (URM). Había que llevar los casos de uso hasta el usuario, así que había que desarrollar más el modelo.

Figura 11: Una historia de la estrategia Data-Centric para ser Data-Driven Decisions:
Parte III "La creación de YOT"

Como os he dicho, pasé un fin de semana dándole vueltas a la cabeza, y descubrí que me faltaban varias piezas aún que unir para sacar lo máximo de lo que ya habíamos hecho con los datos. La primera de ellas era llevar el URM hasta un paso más, utilizando un concepto y un proyecto que durante un tiempo se había estado estudiando en nuestra área de Innovación en Telefónica. Dentro del área de Product Innovation había un grupo de ingenieros trabajando el concepto del Personal Data Bank.

From Personal Data Bank to Personal Data Space

La idea del PDB era poner a disposición del cliente los datos que genera en la red de Telefónica, algo que fue la semilla de la visión de que los datos pertenecen al cliente. Para ello se había estado trabajando en tres vectores en el PDB.

1) Catalogación de los datos que se generan. 

2) Almacenamiento seguro. 

3) Utilización y consumo de los datos por terceros con privacidad.

No es casual este trabajo, ya que no solo había un grupo de ingenieros trabajando en este proyecto. Desde Telefónica se lideró en 2015 la creación del Data Transparency Lab, una iniciativa que aún está activa. Esta organización, impulsada por Telefónica, Mozilla Foundation, MIT Connection Science y Open Data Institute (ODI), ha estado dando becas I+D a investigadores y desarrolladores para entender mejor el valor de los datos, tener herramientas más transparentes y entender mejor cómo proteger la privacidad de los datos. Para ello, cada año tenemos un congreso en el que debatimos sobre esto. Yo estuve en el que se realizó en el año 2015 en la Universidad de Columbia, en New York.

Speaking @ Columbia University }:)

A post shared by Chema Alonso (@chemaalonso) on Nov 24, 2016 at 11:01am PST

Del DTL han salido una buena cantidad de proyectos en estos tres últimos años, como Facebook Data Valuation Tool para entender el valor de los datos en la red social, o $herif, una herramienta que ayuda a detectar sitios que realizan "Price Discrimination" cuando detectan que una persona está a punto de comprar o comparando precios entre sitios.


Figura 13: Facebook Data Valuation Tool
Gracias a todo el trabajo realizado en el Data Transparency Lab, el trabajo que el equipo realizó en el Personal Data Bank era perfecto para construir ese concepto sobre los datos normalizados en formato URM dentro de nuestra estrategia "Data Centric", así que lo incluimos, con un nombre menos económico, y lo llamamos PDS (Personal Data Space).

Es decir, después de normalizar los datos en formato URM, debíamos construir los PDS de los clientes y ver de qué forma le dábamos el valor y el control de los mismos a los usuarios, y así fue como nació la última pieza que comenzamos a construir en septiembre de 2016, YOT.

Codename YOT: "You On Telefónica"

Como os he dicho, me pasé el fin de semana pensando cómo hacer realidad nuestra propuesta de dar control de los datos a nuestros clientes, para que pudieran sacar más partido de su Personal Data Space. Durante ese fin de semana me acordé de unas demos que había visto en primera persona sobre cómo funcionaba MS Bot Framework, y cómo se podían utilizar los Cognitive Services para interactuar con cualquier sistema, a través de múltiples canales - chatbot, app o web - utilizando Procesamiento de Lenguaje Natural (NPL).

Figura 14: La estrategia de la margarita, más los Persona Data Banks,
más YOT, como una Cognitive Intelligence para representar al usuario

Y todo encajó en mi cabeza. Con esta pieza podía construir un sistema que permitía a todos los clientes interactuar con Telefónica, utilizar sus datos, y que algo sucediera en nuestros sistemas. Y dibujé en otra pizarra cómo encajaban todas las piezas con YOT, permitiendo no solo que los datos se pudieran utilizar, sino que además se pudieran descargar y llevar fuera de Telefónica como un esquema de portabilidad - pero de esto os hablaré en un post siguiente.

La idea es que YOT sería una AI basada en motores conversacionales que haría las acciones en la red (en color rojo), que utilizaría los datos del Personal Data Bank (son las cajitas de la segunda capa de la 4P, y se explican en detalle arriba a la derecha) para atender a las necesidades de cada cliente, permitiendo que estos se enriquecieran con External Sources si fuera necesario, y que se compartieran insights con terceros, tal y como se ve arriba a la derecha. Además el PDB/PDS se podría llevar en un disquete, y se podría cargar desde un disquete. Lo del disquete es una metáfora, como podéis imaginar. Durante el lanzamiento de AURA, yo hablé de estos PDS como podéis ver en la imagen siguiente.

Ayer lanzamos la 4a Plataforma, aquí tenéis el vídeo en el que bailo con las Hololes y hablo con Aura usando una app y Alexa Echo }:) http://www.elladodelmal.com/2017/02/aura-heart-of-4th-platform.html

A post shared by Chema Alonso (@chemaalonso) on Feb 27, 2017 at 3:24am PST

No quiero dejar de pasar la oportunidad de explicar que desde el primer instante en que pensamos en la construcción del PDS, éste no solo contenía datos en plano generados, sino que se pensó como una zona donde además se generaría insights, utilizando algoritmos tradicionales de BI, algoritmos de Machine Learning e, incluso, DeepLearnig. Los insights generados con los datos del usuario también serían parte de este PDS.

Yo y mi YOT }:)

A post shared by Chema Alonso (@chemaalonso) on Sep 20, 2017 at 3:01pm PDT

Para conseguir que esto funcionara, debíamos atacar otra de las piezas fundamentales de nuestra visión. La Digitalización End-To-End (Dig e2e) para que hubiera APIs disponibles en todas las plataformas que permitieran a YOT hacer las acciones que el usuario quería. Y con esto comenzamos a construir nuestra AI - Codename: YOT - que luego cambiaría su nombre por algo que seguro que os suena a muchos.

Como podéis ver, el camino en la construcción de la Cuarta Plataforma ha sido el esfuerzo de muchos años, y es mucho más que AURA - que es solo un caso de uso de la Cuarta Plataforma y puede morir o no, pero la 4ª Plataforma seguirá - y mucho más que un Big Data - comenzamos hace casi una década a utilizar tecnologías Big Data en Telefónica.


Figura 17 : Vídeo sobre los equipos de innovación en Telefónica
Como forma de representar esto, los equipos de innovación hicimos este pequeño vídeo en el que mezclamos la innovación interna, la innovación externa, y la innovación con la 4ª Plataforma, que además de trabajar mucho intentamos hacer que sea divertido. En la siguiente parte os contaré qué es AURA. En quinta parte os contaré las tecnologías de transparencia y portabilidad, y en la última parte, todas las piezas tecnológicas juntas en un único mapa.

Saludos Malignos!

*************************************************************

- Data-Centric para ser Data-Driven Decisions: Parte I
- Parte II "La Estrategia de la Margarita"
- Parte III "La creación de YOT"
- Parte IV "La llegada de AURA"
- Parte V "La puesta de largo de AURA"
- Parte VI "El end-point móvil"
*************************************************************

Una historia de la estrategia Data-Centric para ser Data-Driven Decisions: Parte II "La Estrategia de la Margarita"

Terminaba la primera parte de esta historia con la pregunta de cómo podíamos acelerar la normalización de datos en los entornos de BigData de toda nuestra empresa, y comienza esta parte centrándome justo en esa parte. En algo que dibujé por primera vez en una servilleta de un Restaurante Tailandés en Las Tablas donde disfruté buenas cenas, y que más tarde convertí en una burda presentación. Y por supuesto, a la que puse un nombre muy curioso "La estrategia de la Margarita".

Figura 6: Una historia de la estrategia Data-Centric para ser Data-Driven Decisions:
Parte II - "La Estrategia de la Margarita"

Tal vez suene un poco raro eso de utilizar algo como una margarita para describir lo que quieres construir con tecnología, pero lo cierto es que empresas tan grandes el entorno siempre es cambiante, el avión está en marcha, y no puedes pararlo para construir en una mesa en blanco. Cada país es como un pétalo que se mueve al ritmo que se mueve la compañía. Y tienes que construir con ese ritmo, ese balanceo, y con lo que ya tienes allí. Como hacer un castillo sobre una flor. Una bonita metáfora que explica cómo hay que surfear el viento.

La estrategia de la Margarita "in a nutshell"

Tras debatir durante semanas en el verano de 2016 toda esta visión que os estoy contando, me decidí por algo que llamé "La estrategia de la Margarita". Sí, a mí también me hizo gracia el nombre. Pero me ayudó a explicar a las personas relevantes del grupo lo que necesitábamos hacer para dar un salto en la globalización de la estrategia Data-Centric de la compañía.

Como os había dicho, en muchos rincones de Telefónica llevaban años utilizándose las soluciones BigData con scripts y algoritmos de Machine Learning que se utilizaban en informes, en campañas, en acciones concretas. Tenemos datos y algoritmos corriendo en todos los rincones haciendo tareas de Analítica Descriptiva, Analítica Predictiva y Analítica Prescriptiva, pero cuando un caso de uso funcionaba muy bien en un país, casi había que hacerlo desde el principio para que funcionara en otro. Solo trasladábamos el conocimiento del algoritmo, y teníamos a compañeros viajando de país en país.

Casos muy importantes como la elección de los lugares donde se despliega una antena de comunicaciones 3G o 4G es algo que en algunos países se había estado haciendo desde hace años, evolucionando desde sistemas de puro Business Intelligence en redes anteriores, hasta la toma de decisiones con técnicas de Machine Learning que daban resultados prescriptivos, pero copiarlo de un país a otro era casi como rehacerlo. ¿Por qué? Por la normalización de los datos.

Teníamos que conseguir que los algoritmos corrieran en todos los países de la misma forma y para ello necesitábamos normalizar los datos. Mismo tipo de datos, para misma pieza de información. No importa el rincón del mundo donde se genere. Y para ello había que incentivar la normalización en los equipos de BI & BigData de cada rincón de nuestra empresa. Así que tomamos la segunda parte de nuestra estrategia Data-Centric del mapa inicial.

Figura 7: "Digital Command Centre"

Como se puede ver, en cualquier organización, el camino para ser Data-Centric consiste en un proceso muy similar. Primero hay que conseguir tener Profesionales de los Datos, es decir, Ingenieros de Datos, Analistas de Datos y Científicos de Datos, que permitan descubrir qué datos se tienen, cómo se pueden obtener, qué nos están diciendo y cómo sacar el valor a los insights que se generan.

Después se deben convertir en herramientas y procesos automáticos dentro de la compañía que formen parte del día a día de la compañía. Normalmente, scripts que se ejecutan como partes de tareas concretas que han sido escritos en Lenguaje R o en Python, para que al final se conviertan en herramientas utilizadas por los empleados de forma natural o se metan en el core de procesos automatizados que se ejecutan muchas veces, sin que ni tan siquiera los profesionales que usan las herramientas tengan que saber que lo que corre por detrás cuando hacen un clic es un algoritmo de Machine Learning o un proceso de Deep Learning.

Cuando dentro de las herramientas de trabajo que utiliza una persona de marketing, de ventas, de planificación de red, de producto, de gestión financiera, etcétera, se están utilizando tecnologías que sacan lo máximo de tus datos con algoritmos de Inteligencia Artificial, entonces estás en una situación en la que tu compañía es Data-Driven Decisions.

Nosotros en Telefónica ya teníamos muchos procesos automatizados en muchos de los rincones del grupo. Hay que tener en cuenta que como parte del proceso de aceleración de la estrategia de ser Data-Centric, en el año 2015 se adquirió la compañía española Synergic Partners, una empresa líder en el mundo de las tecnologías BigData y habíamos hecho muchos proyectos en todo el grupo, además de trabajar muchos años con los equipos de BI & BigData en las operaciones con otros partners. Así que decidimos acelerar el proceso con la creación de herramientas automatizadas e integradas en los procesos de negocio como forma de incentivar la normalización de los datos.

Figura 8: Telefónica adquiere Syngergic Partners en Noviembre de 2015

Ese gráfico que os pongo muestra un poco la idea. En cada operación - cada una de nuestras queridas Telefónicas - dejaríamos que eligieran cómo querían montar el nuevo entorno. Podrían evolucionar los entornos que ya tuvieran, o crear nuevos en instalaciones "on-premise", nubes híbridas o nubes públicas. Lo único que sería obligatorio es que los datos en estos nuevos entornos deberían estar normalizados con un modelo de datos global y común.

Este modelo, al que llamamos URM (Unified Reference Model), sería sobre el correrían las herramientas que crearíamos desde global. Estas "joyas" que pintaba yo en mi gráfico en 2016 son herramientas automatizadas que sacan utilizan algoritmos de Machine Learning y Deep Learning para integrarse en los procesos de negocio. Joyas que serían para uso interno, joyas que serían para negocio, y joyas que serían para devolver al usuario el control de sus datos. Algo que desde el principio estaba en nuestro objetivo.

Figura 9: El primer dibujo que hice yo con el PowerPoint para explicar "La estrategia de la margarita"

Por supuesto, así comenzamos a trabajar y normalizamos casos de uso para el despliegue de redes utilizando técnicas de Machine Learning, para análisis del Churn, para Analizar el valor de los servicios en los paquetes de clientes, para generación de ofertas más ajustadas, etcétera. Casos de uso internos que solo funciona con datos normalizados en formato URM.

La estrategia de la margarita se convirtió en la parte fundamental de la unidad CDO en el verano del año 2016 y un equipo se centró solo en normalizar datos con URM, mientras que otro se dedicó a la creación de casos de uso, "Las Joyas", para acelerar el proceso cuanto antes. Mientras tanto, el equipo de UX y diseño, no conforme con el diseño que había hecho yo, construyó una versión más "sexy" de "La estrategia de margarita".

Figura 10: Diapositiva de "La Estrategia de la Margarita" que se ha usado para explicar el proceso

Con esta estrategia, que seguimos desplegando hoy en día, país a país, y que nos sirve para medir los porcentajes de datos de la compañía que vamos normalizando, comenzamos a andar, pero no era suficiente por varios motivos:

1) En el grupo queríamos acelerar la construcción de una unidad B2B de BigData que completara nuestra oferta de servicios digitales de IoT, Cloud, Seguridad, Coms y NewComs, así que había que construir una unidad al estilo de ElevenPaths. 

2) Había que construir los casos de uso de para darle el control al usuario. 

3) Había que trabajar en casos de uso que se hicieran con terceros.

De hecho, cuando le presenté "La Estrategia del Margarita" al jefe un viernes por la tarde se quedó frío. Ni fu, ni fa. Le faltaban muchas cosas. Le faltaba la parte en la que los usuarios pudieran interactuar con la red. Y me fui de su despacho pensando, pensando, pensando. Me pasé todo el fin de semana pensando. Haciendo un análisis de todas las reuniones que había tenido en el último año para entender qué es lo que estaba buscando. Qué estaba en su mente y se me había escapado. Hasta que se me iluminó la bombilla.

Al lunes siguiente, cuando hago mis comités de trabajo semanales con mi equipo, llegué con la idea clara de lo que teníamos que construir para hacerlo. Había visto algo una tarde de verano días atrás y fue la pieza que me inspiró para la parte que me quedaba. Y lo metí en mi proceso. Eso que había que añadir a la estrategia es algo que llamé YoT y refiné un poco las piezas para dar con la solución completa, que fue lo que presenté a mi equipo pintando en una pizarra en mi despacho de Frozen. Dibujar, eso es sí que es algo que siempre me ha encantado: Dibujar. Os lo cuento en la próxima entrada.

Saludos Malignos!

PD: Como curiosidad, durante semanas en Telefónica, los compañeros se cruzaban conmigo y me decían "Chema, me han hablado de ella, pero yo aún no he visto tu margarita, a ver si me la enseñas".  Reconozco que la "Daisy Flower Strategy" podía haber sido bautizada con otro nombre.

*************************************************************

- Data-Centric para ser Data-Driven Decisions: Parte I
- Parte II "La Estrategia de la Margarita"
- Parte III "La creación de YOT"
- Parte IV "La llegada de AURA"
- Parte V "La puesta de largo de AURA"
- Parte VI "El end-point móvil"
*************************************************************