Garbage Collector para recoger "la basura" en Metasploit

Coincidiendo con el reciente RootedLab de Metasploit, el cual se ha celebrado por quinto año, y se encuentra en un estado actualizado y mejorado, he querido compartir un script al que tengo cierto cariño. El script se denominó en su momento Garbage Collector y se puede descargar desde mi Github. La idea surgió en una conversación hace años con mi amigo Juan Garrido "Silverhack". La intención era la de hacer un módulo de post-explotación creado para, a través de una sesión de Meterpreter, poder descargar todos los archivos y carpetas de todos los usuarios de un sistema comprometido.

Figura 1: Garbage Collector para recoger "la basura" en Metasploit

En algunas ocasiones, los usuarios dejan todo tipo de documentos e información en la Papelera de Reciclaje, por lo que puede ser un punto interesante dónde buscar documentos o archivos jugosos. La papelera de reciclaje no deja de ser un punto jugoso en el disco duro y el sistema de archivos. Esta es una de las razones por las que me decidí a llevar a cabo esta pequeña utilidad dentro de Meterpreter, sobretodo, pensando en una fase de recopilación de información, una vez comprometida la máquina.

Mi "Garbage Collector" para Meterpreter

Los scripts de Meterpreter tienen 3 partes bien diferenciadas. En primer lugar, podemos encontrar la parte de “parseo” de opciones o parámetros con los que se ejecuta el script. La segunda parte es la de comprobación de que el script puede ejecutarse en un entorno o sesión sobre la que se está ejecutando, es decir, si la sesión es de un Meterpreter de Linux y el script está hecho para sacar provecho a una sesión de Meterpreter en Windows, el script puede finalizar su ejecución. En tercer lugar, la zona de ejecución. En esa zona de ejecución corre la lógica y funcionalidad del script.

Figura 2: Parte de comprobación de sistemas operativos en la sesión de Meterpreter

Como se puede ver en la imagen, la primera parte es comprobar la plataforma dónde se ejecutará el script. Si, en este caso, la plataforma no es Windows, el script finalizará. Justo después, se puede ver la asignación y explicación de los parámetros. Para ello se crea un objeto Arguments. Queda claro, que cuando ejecutemos run garbagecollector –h, se mostrará por pantalla el mensaje Help Menu y nos mostrarán la ayuda del script, ese código se encontrará en la zona de ejecución, la veremos más adelante.

Figura 3: Cuerpo principal de Garbage Collector

Los argumentos son “parseados”, como si fuera un bucle. Por cada parámetro introducido se itera con tres variables opt, idx y val. El script presenta dos parámetros funcionales: -g y –o. En el caso del parámetro –g se realizará una descarga recursiva de ficheros y carpetas que haya en la papelera de reciclaje. En el caso del parámetro –o, solo se descargarán ficheros y no carpetas. En el Github se puede encontrar el resto de funciones utilizadas para completar el script y su funcionalidad. En esta imagen, solo se muestra lo que sería el programa principal.

Probando Garbage Collector

Ahora, se muestra una prueba de concepto del script en funcionamiento. Hay que tener en cuenta que si la sesión sobre la que se lance el script está en un contexto elevado se podrá descargar las papeleras de reciclaje de todos los usuarios del sistema. En caso de que no, se puede tener algunos problemas para acceder a las papeleras de otros usuarios.

Figura 4: Ejecución de Garbage Collector en una sesión de Meterpreter

En la imagen superior, se puede ver como se recopila los ficheros y carpetas de un usuario del sistema. Se diferencia entre ficheros y carpetas. Se van descargando y serán accesibles desde la máquina del atacante, ya que estos se recogen mediante el script.

Figura 5: Ficheros descargados en la máquina Kali Linux local

Como se puede ver en las imágenes de las figuras 5 y 6, los ficheros son descargados. En este caso, existen dos usuarios en el sistema (ID 1000 e ID 1001) que tienen archivos en la papelera de reciclaje. Tal y como se puede ver se puede recuperar, tanto el contenido del fichero como el nombre de la ruta del fichero.

Figura 6: Contenido de una carpeta en la Papelera de Reciclaje

Una funcionalidad hecha que puede ayudar a la recopilación de información en la máquina en la fase de post-explotación en un Ethical Hacking, por lo que os invito a que metáis el script en vuestra mochila en el pentesting. Todavía no está en el framework oficial de Metasploit, por lo que si queréis utilizarla la tenéis en el Github.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

AURA: The heart of the 4th Platform

Ayer en Barcelona fue el día en el que lanzamos en Telefónica la que habíamos denominado, con nombre código, Cuarta Plataforma. Ésta, de la que se había hablado mucho, es una plataforma de Cognitive Intelligence en Telefónica, a la que llamamos AURA. 

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

Pero, lo mejor, es que primero veáis el vídeo de la presentación de la misma, donde explicamos en qué consisten las plataformas y cuáles son las funciones que le hemos dado a Aura, lo que internamente llamamos "Powers".  La presentación la podéis ver en varias partes.

Figura 2: Presentación de AURA

La primera de ellas es la presentación de AURA, donde utilizo Enhanced Reality por medio de Hololens. La segunda son la parte de las demos, que hago usando una app en un smartphone y Alexa Echo. Y la última son las integraciones con algunos de los partners que se han unido al ecosistema abierto que hemos creado. 

Hoy tengo un día muy complicado de trabajo, así que os dejo solo el vídeo, pero esta semana prometo contaros más detalles de la misma.

Saludos Malignos!

And the next week: MWC (Barcelona) y RootedCON (Madrid) @rootedcon @0xWord

Los domingos empieza a ser tradición que os traiga la lista de eventos para la semana que viene, pero esta va a ser muy sencilla, pues hay dos eventos muy destacados y no hay muchos más en paralelo. Como muchos ya sabéis, mañana da comienzo el Mobile World Congress en Barcelona, y para nosotros hoy por la tarde es un día importante porque tenemos el evento en el que vamos a hablar sobre la 4ª Plataforma en Telefónica.

Figura 1: And the next week...

Además, la semana que viene culmina con la RootedCON en Madrid, por lo que no podemos decir que nos falten temas interesantes a los que apuntarnos. Esta es la selección de temas que os dejo.

MWC en Barcelona

El lunes, da comienzo el MWC y ese mismo día yo daré una charla en el Ministerial Programme del Mobile World Congress. Será solo de unos 15 minutos al medio día, pero si te va bien, puedes pasarte a verla. La daré en español, ya que es con foco en latinoamérica. 

Figura 2: Speakers en el Ministerial Programme del MWC

No seré el único ponente de Telefónica hablando en el MWC, y habrá ponentes de ElevenPaths y LUCA-D3. En esta web puedes ver todas nuestras ponencias en todos los días: Conferencias de Telefónica en el Mobile World Congress 2017.

Figura 3: Speakers de Telefónica en el MWC 2017

Además, también esos días, da comienzo el Hackathon en INCIBE, que durará desde el día 27 de Febrero al día 1 de Marzo, ambos inclusive. Tienes la información sobre cómo participar en la web del mismo, pero que sepas que tendrá lugar en Barcelona.

Figura 4: Hackathon de INCIBE en 4YFN en Barcelona

El resto de la semana, ya sabes, puedes visitar los stands, e incluso venir a saludarme. Yo solo estaré el lunes y el martes por el de Telefónica donde podréis ver demos de LUCA-d3, y luego me volveré a mi querido Madrid.

RootedCON en Madrid

La RootedCON comienza el miércoles, con la cena de ponentes a la que asistiré a ver a amigos y conocidos. Luego, el jueves, viernes y sábado tienes una agenda que no te puedes perder. Vienen grandes ponentes, y este año está también Mikko Hypponen que se ha dejado caer. También estarán Paul Vixie, y grandes conferenciantes españoles como Juan Garrido "Silverhack", Raul Siles o Hugo Teso, por citar algunos de los muchos que hablan en esta edición.

Figura 5: RootedCON 20176 en Madrid ¿Te la vas a perder?

Yo participaré con una charla el viernes con un pequeño hack sorpresa que se me ocurrió, funcionó, y que hemos trabajado en secreto durante este último mes en ElevenPaths. El título lo dice todo: "It´s only Rock'n Roll but I like it". Y como va de música y del amor que yo le tengo a Spotify, voy a regalar una Subscripción Premium gratuita a Spotify por 3 años al que participe en mi charla y ponga la mejor canción de Rock en escenario. 

Figura 6: Algunos ponentes de RootedCON 2017

Eso sí, tienes que venir con un iPhone para poder ser elegible en esta demo. No, no tiene nada que ver con iPhone esta demo, es solo que me gustan los iPhone. Después, os dejaremos pública toda la información y el paper para que podáis hacerlo vosotros en casa.

Figura 7: It´s only Rock'n Roll, but I like it

Y nada más, que para esta semana ya hay bastante con estos dos pedazos de eventos en los que voy a estar involucrado. Además, en la RootedCON estará el stand de libros de 0xWord y yo y algunos otros escritores vamos a estar firmando libros. Podéis comprar ya los libros y pedir recogerlos allí, así no tendréis problemas de que se agote ninguno. Ya os pasaré cuál es el horario de firmas por si queréis que os haga una dedicatoria de las mías.

Saludos Malignos!

Cómo encontramos tu HTTP Response Splitting olvidado

Las vulnerabilidades de HTTP Response Splitting pueden ser utilizadas para hacer muchos ataques peligrosos. De hecho, están catalogadas con un nivel de criticidad alto y cuando aparecen se deben cerrar lo antes posible. La idea de una vulnerabilidad de HTTP Response Splitting es que un atacante es capaz de inyectar código en la cabecera de la respuesta HTTP y por tanto reescribir toda la página que llega al cliente. Esto se produce cuando se puede inyectar en un campo que va uno de los campos de la cabecera y el atacante decide escribir, en su inyección, campos HTTP para cambiar la respuesta por completo.

Figura 1: Cómo encontramos tu HTTP Response Splitting olvidado

Nosotros nos encontramos con uno de ellos hace poco utilizando nuestro sistema de Pentesting Persistente Faast con el que monitorizamos la seguridad de las webs haciendo pentesting 365 días al año de manera continua, y aplicando un algoritmo voraz, es decir probando todo lo que haya que probar en cada punto. La gracia en el artículo de hoy no está en la vulnerabilidad en sí, sino en cómo el sistema recursivo funcionó para localizar el bug, que ya está corregido, así que os lo cuento rápidamente hoy sábado.

Figura 2: Bug de HTTP Response Splitting detectado por Faast en un proyecto

El comienzo fue bastante sencillo. Como en cualquier proceso de Ethical Hacking, el motor de Faast tiene una fase de Discovery en la que busca en todos los lugares posibles los recursos expuestos en Internet. Por supuesto, también haciendo hacking con buscadores. En una de esas búsquedas apareció una URL que, como tantas otras, y al igual que se hace con FOCA, pasa a ser analizada por el motor de Faast.

Figura 3: Descubrimiento de una URL indexada y extracción de URLs para Spidering

El código HTML de la página de respuesta de esa URL se pasa por una serie de plugins, y uno de ellos lo que hace es, por supuesto, buscar nuevas URLs a partir de enlaces en la página. Esto es una tarea básica en cualquier pentesting. Hacer spidering a partir de una URL, tal y como se explica en el libro de Hacking Web Technologies. Nosotros, antaño, lo hacíamos con Burp y luego lo pasábamos a FOCA.

Figura 4: Proceso de Spidering con Burp

De esa URL sacamos más URLs con directorios y recursos enlazados. Y, por supuesto, cada directorio que es descubierto se pasa por una serie de plugins de forma recursiva. En búsqueda de cosas como fallos de Directory Listing, de IIS Shortname, Múltiple Choices, errores no controlados, etcétera.

Figura 5: Descubrimiento de un DWSync.xml

Una buena batería, donde también se buscan los sensitive files, tipo .DS_Store, WS_FTP.log o ficheros .listing, por poner algún ejemplo. En este caso, lo que apareció fue un DWSync.xml de los que se quedan cuando alguien sube una web usando Dreamweaver, como ya hemos hablado muchas veces.

Figura 5: Descubrimiento del fichero CGI olvidado por medio de Spidering

Esto es un leak en sí mismo, y como tal quedó reportado en el proyecto para los responsables de seguridad, pero de él sacamos nuevas URLs, como la que se puede ver en la captura del mismo.

Conclusiones

Al final, ese CGI (Common Gateway Interface) resultó ser vulnerable a HTTP Response Splitting. Un fichero que hacía mucho tiempo que se había quedado sin utilidad en la web, pero que aún estaba presente en el servidor. No lo habían limpiado, y el motor de Faast, buscando de manera persistente dio al final con él. 

Figura 6: Encadenamiento recursivo de plugins en Faast hasta llegar al HTTP Response Splitting

Si quitas algo de la web, quítalo. Este es uno de los errores más comunes que encontramos en los proyectos de pentesting persistente - como los que os dejé de Apple - y a partir de ellos se pueden localizar muchas cosas peligrosas. En este caso, un HTTP Response Splitting. Si quieres, puedes pedirnos un piloto de Faast sin compromiso para tu empresa a través de nuestra web de contacto de ElevenPaths.

Saludos Malignos!

(Cross)Browser Fingerprinting via OS & HW Level Features

El mundo del Web Browsing fingerprinting es una disciplina que se ha desarrollado mucho durante los últimos años. El poder garantizar que un usuario es un usuario concreto y que es el mismo que estuvo mirando algo en otro sitio es una pieza clave dentro del mundo de la monetización de los datos. Para ello, lo que intentan todos los investigadores de estas disciplinas es estudiar al máximo al huella digital de tu conexión.

Figura 1: (Cross) Browser Fingerprinting via HW & OS

Conocer todos los patrones de ti que te hacen ser tú y poder reconocerte bajo cualquier situación y en cualquier lugar en el que estés navegando. Los trucos para crear tu huella digital son algunos muy conocidos, otros no tantos. Desde mirar todas las características del navegador, hasta mirar el comportamiento de la batería de equipo.

Figura 2: Mozilla Firefox quitó el acceso a Battery Status desde HTML5

Tanto es así, que hasta Firefox cortó el acceso de las funciones de consulta de la batería desde HTML5. Toda información que se pueda conseguir desde el navegador puede servir para identificarte y puede convertirse en algo que utilicen para monitorizar tus movimientos a través de diferentes sitios web.

Figura 3: Cross Browser Fingerprinting via OS and HW Level Features

Cada cierto tiempo salen nuevas formas de identificar propiedades del navegador - como este trabajo con los códigos de estado HTTP -, de generar una supercookie con algún leak de información, o de hacer que la cookie sea persistente de una forma u otra. Nosotros también estuvimos jugando con esto, y publicamos un trabajo hace mucho tiempo en Informática 64 sobre cómo usar los códigos de error de algunas funciones JavaScript para identificar el navegador. Todo por identificarte de la mejor forma posible. 

Figura 4: Resumen (no actualizado) de algunas técnicas de Webbrowsing fingerprinting utilizadas

Ahora, unos investigadores han ido un poco más lejos y han creado un conjunto de pruebas aprovechando WebGL para forzar al navegador a hacer llamadas que se ejecuten directamente en el hardware.

Figura 5: Forzado de figuras con WebGL que dependen del HW y el OS

Estas pruebas de dibujo, renderización de imágenes y materiales, se ejecutan directamente en las tarjetas gráficas y se ven afectadas por el tipo de hardware que tengan en ellas y el sistema operativo que las gestiona, así como de la potencia de la CPU del equipo. Es decir, la implementación del estándar WebGL en el navegador (ya sea Google Chrome, Firefox o Microsoft Edge) no incide en los cálculos que se obtienen en cada prueba.

Figura 6: El código del (Cross) Browser fingerprinting en GitHub

Esto quiere decir que cada prueba se puede hacer desde diferentes navegadores en el mismo hardware y se obtienen los mismos resultados, lo que lleva a que el Fingerprinting de un cliente web no se haga sobre el navegador, sino sobre el hardware y que si un mismo usuario se conecta con dos navegadores distintos, al final pueda ser identificado de igual forma.

Figura 7: Proceso de identificación de "huellas digitales" por medio de tareas de rendering

Esto no quiere decir que haya que dejar de hacer el resto de los cálculos de WebBrowsing Fingerprinting - ni mucho menos - sino que añaden un conjunto de pruebas que permite a las empresas que se dedican a esto la posibilidad de generar un parámetro más en la identificación de los usuarios basado en el equipo de conexión.

Figura 8: Big Data y Privacidad

Al final, cuando te conectas a Internet, el que te puedan identificar de una forma u otro es algo ya maduro y difícil de parar y en esta charla sobre Big Data y Privacidad hablé de esto tiempo atrás, por si quieres saber más de ello.

Saludos Malignos!

Cómo hacer ataques SMBTrap a Windows con MITMf

Hoy vamos a a hablar de SMBTrap, una vulnerabilidad que se descubrió en el año 2015 y que no es más que un bug que afecta al protocolo SMB en Windows desde hace mucho tiempo atrás. En otras palabras, allá por el año 1997 se podía forzar a Windows a que enviara las credenciales a un recurso compartido. Un atacante podía poner un recurso compartido y poner un enlace en una web hacia dicho recurso lo que provocaba que las credenciales fueran enviadas, es decir, los hashes de las credenciales de Windows.

Figura 1: Cómo hacer ataques SMBTrap a Windows con MITMF

Con SMBTrap se dio una vuelta de a este concepto, y esto ocurrió en el año 2015. Existe un artículo de nuestro compañero Sergio de los Santos (@ssantosv) - autor del libro de Máxima Seguridad en Windows - que habla de esta vulnerabilidad y de cómo protegerse.

Figura 2: Paper de SMBTrap publicado por Cylance

Mediante SMBTrap se podrán enviar las credenciales de Windows hasheadas mediante un servidor SMB gracias a las redirecciones HTTP. La gente de Cylance se dio cuenta, y así lo muestra en el paper, que la API de URLMon.dll, la cual es utilizada por muchas aplicaciones hoy en día, también realizaban la operativa de enviar las credenciales gracias a las redirecciones HTTP.

Figura 3: Esquema de redirección HTPP para forzar envío de credenciales

Hoy en día, es muy común utilizar NTLMv2, lo cual no es tan débil como los antecesores, aunque siguen siendo potencialmente atacable mediante fuerza bruta o, más lógicamente, por ataques de diccionario.

Integrado con MITMf

La semana pasada hablamos de uno de los frameworks más potentes y flexibles para auditorías de red como es MITMf. Hoy vamos a ver como MITMf proporciona soporte, a través de un plugin, para poder capturar hashes de Windows a través de redirecciones HTTP. El plugin encapsula todo el proceso, pero lo que se levantará es un servidor HTTP que, ante una petición, redirigirá hacia el servicio SMB montado también por el propio plugin.

Figura 4: Ejecución de plugin smbtrap en mitmf

Como se puede ver, para invocar el plugin –smbtrap solamente hay que indicarlo al ejecutar MITMf sobre nuestro Kali Linux 2. Si leemos lo que es levantado, gracias a la ejecución del plugin, se puede leer un servidor HTTP y un servidor SMB. Si echamos un ojo a los puertos a la escucha en la máquina vemos lo comentado.

Figura 5: Servicios arrancados con el plugin de smbtrap

PoC: Sacanco provecho de todo esto

Un escenario típico para sacar provecho aquí sería utilizar técnicas como ARP Spoofing o DNS Spoofing buscando un envenenamiento de la caché ARP o caché DNS. Las peticiones que la víctima haga desde, por ejemplo, su navegador que utilice la autenticación por HTTP u otras aplicaciones que utilicen URLMon.dll.

Para este ejemplo, se realizará un ARP Spoofing y SMBTrap todo desde el propio MITMf, mostrando la flexibilidad y potencia con una sintaxis muy sencilla. La instrucción a ejecutar es:

 mitmf.py –spoof –arp –smbtrap –target [IP víctima] –gateway [IP router] –i [interfaz de red]

En este instante, cuando la víctima utilice su Internet Explorer, en el ejemplo utilizamos un Windows 7, la petición HTTP será redirigida al servidor SMB montado por el atacante. En este instante, el navegador realizará, o lo intentará, autenticarse mediante NTLMv2.

Figura 6: Ejecución de ARP Spoofing y SMBTrap con MITMf a la vez

El resultado es un robo de credenciales hasheadas de Windows. Se puede utilizar herramientas de cracking, como por ejemplo hashcat, para poder extraer la credencial en plano. En conclusión, SMBTrap está al alcance de la mano en herramientas como MITMf, lo cual hace que montar lo necesario sea realmente sencillo.

Figura 7: Hashes de credenciales capturados

Es potente utilizar este tipo de técnicas en los proyectos de Ethical Hacking, ya que la consecución de los hashes puede abrir la puerta a otras máquinas Windows o recursos de red que no estén bien fortificados. Como vemos MITMf proporciona diferentes técnicas, y cada vez más, y ayuda a poder realizar ataques y pruebas que antes costaban montar. Seguiremos viendo ataques y técnicas con este gran framework.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

Cómo sincronizar el backup de ficheros en Windows con Latch Antiransomware

Hoy en día el Ransomware sigue siendo un problema entre los usuarios de Windows ya que se ha convertido en una popular herramienta para realizar extorsiones por Internet. Para añadir una capa más de seguridad a tu sistema creamos una herramienta gratuita llamada Latch Antiransomware que te ayuda a proteger tus carpetas y documentos poniendo una protección extra aún cuando ya tienes el sistema fortificado.

Figura 1: Cómo sincronizar el backup de ficheros en Windows con Latch Antiranswomware

Al final, el ransonware que más daño hace es aquel que consigue ejecutar un programa con tus permisos de usuario - no importa si no eres administrador - y cifra todos los archivos a los que tu cuenta tiene acceso. Con Latch ARW creamos una capa de protección extra, ya que tu usuario de Windows no tiene acceso a ellos si el Latch está cerrado.

Figura 2: Funcionamiento de Latch AntiRansomware
Mañana jueves, en nuestra primera ElevenPaths Talk de 2017 vamos a dedicar una sesión completa al mundo de la lucha contra el Ransomware, para analizar en detalla su funcionamiento y ver qué medidas de protección se pueden tomar.

Figura 3: La guerra contra el Ransomware

Hoy vamos a ver un pequeño truco que hemos configurado en algunos equipos en ElevenPaths, para poder hacer las copias de documentos planificadas y al mismo tiempo tener la protección de Latch. Es decir, vamos a sincronizar un proceso con el Scheduler de Windows y el Scheduler de Latch.

Configuración del planificador de Windows

Hay que tener en cuenta que, la carpeta donde queremos hacer las copias de seguridad de los archivos está protegida por Latch ARW, tal y como se explica en este vídeo, así que si se intenta sobreescribir un fichero no se podrá porque estará bloqueado por Latch. Aquí tienes como se hace la instalación y configuración de Latch ARW para proteger carpetas en Windows.

Figura 4: Instalación y configuración de Latch ARW

Para comenzar entraremos en el administrador de tareas de nuestro equipo donde pulsaremos el botón derecho del ratón y seleccionaremos la opción “Crear una nueva tarea”, cuando esta se cree podremos ponerle el nombre que queramos, en este caso “Backup”.

Figura 5: Creación de una tarea en el planificador de Windows

Lo siguiente es configurar los “Triggers”, estos son las condiciones necesarias que deben cumplirse para que se ejecute la tarea, en este caso nuestro disparador será que el reloj del ordenador marque las 13:00 P.M. Una vez configurado el trigger deberemos seleccionar la acción que queremos que se realice cuando se cumplan las condiciones previamente establecidas. Nosotros lanzaremos un pequeño script encargado de realizar el backup de los archivos y carpetas.

Figura 6: Script en BAT que copia los ficheros de trabajo a la carpeta de backup

Cuando hayamos acabado de configurar la tarea guardaremos los cambios y estaremos listos para configurar el planificador en nuestra aplicación de Latch para controlar Latch ARW.

Configuración en la aplicación de Latch 

Abriremos nuestra aplicación de Latch, con la que ya tenemos protegidas las carpetas de las que queramos realizar el backup. Lo primero que deberemos hacer es abrir el interruptor de Latch ARW para poder acceder a todas las opciones de configuración de la carpeta.

Figura 7: Planificación de apertura del Latch para hacer la copia de seguridad

Hecho esto pulsaremos sobre la carpeta de la que queramos generar una copia de seguridad y activaremos la función de "Programar bloqueo". Ahora podremos configurar nuestro Latch para que abra su interruptor de manera automática a una determinada hora, que corresponderá a la hora a la que se ejecutara el script encargado de generar la copia de seguridad. Para terminar cerraremos el interruptor de Latch y ya estará listo

Funcionamiento del proceso

En el momento que se cumplan las condiciones horarias del trigger se ejecutara el script encargado de la realización del backup. Esto ocurrirá al mismo tiempo que se abrirá nuestro interruptor de Latch, el cual se volverá a cerrar cuando hayamos programado para que la carpeta vuelva a quedar protegida por Latch ARW.

Figura 8: Carpeta protegida por Latch ARW

Con este método podremos realizar copias de seguridad en el mismo equipo reduciendo la ventana de tiempo durante la cual están desprotegidos.

Figura 9: Se abre para la copia del nuevo fichero a la hora establecida

Puedes descargar Latch Antiransomware dese la web de ElevenPaths, donde también encontraras los pasos a seguir para llevar a cabo su instalación. En el siguiente vídeo puedes ver cómo funciona todo el proceso completo que hemos descrito en este artículo.

Figura 10: Planificar un backup protegido con Latch ARW

Autor: Sergio Sancho Azcoitia @ ElevenPaths

Think Different: Un Hostname sin Domain en los inversores de Apple

Si has entrado a leer este artículo por el título, tienes mi más sincero respeto y admiración, porque la verdad es que no sabía bien qué título poner a este artículo donde trato de contaros una pequeña anécdota que me ha llamado la atención y de la que nos ha alertado nuestro queridísimo sistema de Pentesting Persistente Faast.

Figura 1: Think different

Como sabéis, periódicamente le reportamos vulnerabilidades a Apple o Microsoft porque probamos con nuestro motor los nuevos plugins que vamos introduciendo. Escanear un dominio completo como el de Apple.com o Microsoft.com es un reto, pero gracias a la potencia de tenerlo en cloud el sistema se porta como un campeón y los chic@s de Microsoft y Apple nos lo agradecen periódicamente.

Figura 2: Agradecimiento de Apple al equipo de Faast

Entre las cosas que miramos, se encuentra el descubrimiento de servicios web, y para ello probamos muchos trucos. Esta es la historia de uno de ellos.

El dominio investor.apple.com 

En el dominio de apple.com hay un servidor web con información para los inversores que ya ha sufrido en el pasado algún que otro problemilla de seguridad. En este caso no se trata de nada similar, simplemente de una curiosidad en la gestión del hosting. Si entramos en la web vemos que hay una web normal y corriente.

Figura 3: Web de Investor.apple.com

Cuando el motor de Faast encuentra un hostname en formato FQDN, lo que intenta es averiguar si hay más hostnames en el mismo servidor, así que haciendo una sencilla consulta al servicio DNS se puede dar con otros nombres de host en la misma dirección IP.

Figura 4: nslookup a investor.apple.com

Por supuesto, como todo buen pentester, el servicio Faast prueba a localizar todas las webs en esos hostnames, obteniendo resultados diversos, como la misma web accesible por otro nombre de dominio.

Figura 5: La misma web accesible por otro hostname

O un servidor web que no atiende por ese nombre de dominio. Hasta aquí todo dentro de lo normal, como es de suponer.

Figura 6: Not Found en ese dominio

Eso sí, ya se puede ver que hay un servidor que no es de Apple, que tiene alojada una web de Apple.com, lo que abre muchas posibilidades.

El hostname sin FQDN

Como en muchas ocasiones se montan servicios en local, lo que hace nuestro querido Faast es ejecutar un plugin que busca el servicio web en ese servidor, pero utilizando el hostname local, sin utilizar el FQDN, tal y como se puede ver en la captura siguiente hecha con Burp Proxy (un poco de hacking de tecnologías web).

Figura 7: Cambiando el host a solo "investor" la web cambia
(Se ve a la izquierda en la captura)

El resultado es que aparece la web de otra empresa que está en el mismo servidor. Si utilizamos un plugin de tampering en el navegador, podemos ver la renderización completa de la web manipulando el host de la misma forma.

Figura 8: Faast alerta de una web en investor diferente a la que hay en investor.apple.com

Al final, lo que ha sucedido es que se ha extendido la superficie de exposición del dominio Apple.com, ya que, ahora hay otra web que podría tener más vulnerabilidades para conseguir llegar a un servidor del dominio Apple.com. Un truco de "discovery" que tenemos en nuestro Faast, y que nos ha dado un resultado curioso.

Saludos Malignos!