Hacer Copias de Seguridad: Regla número 1 de tu plan de seguridad informática

Desde que tengo uso de razón, los sistemas informáticos han existido y han tenido fallos. Desde esos archiconocidos pantallazos azules en Windows, hasta fallos en el sistema de arranque, pasando corrupciones en el sistema de archivos o actualizaciones que hacen que algunos programas dejen de funcionar. Sin contar aquellos que se convierten también en fallos de seguridad. Bugs. Muchos bugs.

Figura 1: Hacer Copias de Seguridad.

Regla número 1 de tu plan de seguridad informática

Esto provoca que cuando nos vemos afectados por uno de esos fallos, corremos el riesgo de tener una perdida de información y, si tenemos que repetir un trabajo, de tiempo y dinero. El tiempo se pierde porque se nos borra el trabajo no guardado, además de que hay que pararse a arreglar el fallo. Por otro lado, la perdida de información que puede provocar, por ejemplo, una corrupción del sistema de archivos hace que podamos perder archivos importantes que tuviéramos en el sistema, como fotos familiares, contratos, o documentos que no están almacenados en ningún otro sitio.

Por todo esto, se inventaron las copias de seguridad o backups. Hace muchos años. Y así podemos tener una clon de los archivos importantes para que en caso de que ocurra algún fallo que nos haga perder información, podamos recuperarlo. Fallo del sistema. Ransomware. Rotura del hardware. Lo que sea. Pero si tenemos copias de seguridad, siempre podremos recuperar esos documentos. Regla número uno de la fortificación de un sistema para un plan de seguridad informática: Haz copia de seguridad.

Figura 2: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord

Pero ¿cómo se hace una copia de seguridad?, ¿dónde se almacenan?, ¿cómo funcionan el proceso completo de copia de seguridad y restauración?, ¿podemos confiar en ellas?, ¿que soluciones existen?, son muchas de las preguntas que nos podemos hacer, así que, lo mejor es ir por partes a la hora de responderlas.

¿Cómo se hace una copia de seguridad?

La forma de hacer una copia de seguridad cambia dependiendo del sistema operativo que utilicemos. Cambia si queremos utilizar las herramientas integradas en el propio sistema operativo o utilizar unas herramientas externas especializadas en backup. Por ejemplo, en MacOS se puede utilizar la herramienta llamada “Time Machine”, que permite generar una serie de copias de los archivos de nuestro ordenador, en la propia maquina o en un disco externo, que siempre podremos recuperar.

Figura 3: Time Machine en hacer copias de seguridad en MacOS

En sistemas Microsoft Windows, existen varios métodos de copias de seguridad. Por ejemplo podemos crear un Punto de Restauración, que nos permite en un futuro recuperar el estado completo del sistema  operativo en un punto en concreto de tiempo. Supongamos que instalamos un programa y que está funcionando mal por lo que decidimos desinstalarlo. Aún así, el sistema contendrá archivos o restos de esa instalación. Si tenemos un Punto de Restauración justo antes de instalarlo, podremos volver al momento antes de instalarlo y todo volverá a la normalidad.

Figura 4: Puntos de Restauración en Microsoft Windows

Por otro lado  también podemos crear una copia completa de un disco duro, esto permitirá tener una copia exacta del sistema, con sus archivos y programas intactos. E incluso tenerlo en espejo o redundante por hardware en RAID 1, RAID 3 o RAID 5.

También podemos hacer copias de seguridad más selectivas de documentos o archivos en discos externos en Cloud. Si eres cliente de Telefónica y tienes Movistar Fusión puedes usar Movistar Cloud que tiene almacenamiento ilimitado para ti de documentos, fotos, vídeos, etcétera y hasta podrás compartir los documentos multimedia y verlos a través de la Living App de Movistar Cloud en la televisión de Movistar + y en Movistar Home.

Figura 5: Living App de Movistar Cloud

Si no, con cualquier aplicación de cloud como Google Drive, OneDrive o Dropbox, que pueden instalarse en tu escritorio ya sean Windows o MacOS, puedes seleccionar las carpetas que quieres que se nos sincronicen con la nube - hasta que se nos llene el almacenamiento contratado -, permitiendo que cualquier cambio que hagamos reciba una copia de seguridad fuera de nuestro disco local.

¿Dónde se almacenan o se deben almacena los Backups?

Cada copia de seguridad se almacena en un sitio diferente, por defecto, dependiendo del programa que la haya realizado o del sistema operativo que se esté utilizando. Por norma general, cuando se le dice a un programa que queremos hacer una copia de seguridad, nos pedirá una ruta donde guardarla. Por supuesto, lo más aconsejado es guardarla en un disco externo o en la nube. 

Figura 6: Funcionamiento de Latch ARW

No tiene sentido que la copia de seguridad y el documento original o el sistema operativo, estén juntos, ya que si falla el sistema, la copia se pierde, algo que pasa mucho en los ataques de Ransomware, por lo que nuestros compañeros sacaron un programa llamado Latch AntiRansonware que pone protecciones a bajo nivel a las carpetas con Latch para evitar que se vean afectadas las copias en una infección aún estando en el mismo sistema operativo.

¿Cómo funcionan las copias de seguridad?

Las copias de seguridad pueden funcionar de distintas maneras, desde una copia de ficheros completa bit a bit, hasta en modo de copias de seguridad diferencial con los cambios o incrementales, donde se necesitan copias de seguridad anteriores que se van aplicando unas sobre otras. El mundo del backup profesional en la empresa es muy avanzado, y la copia de seguridad de servidores depende mucho del tipo que sea cada máquina.

En el caso de un usuario particular, dependiendo de lo que se quiera conseguir, deberemos realizar una copia puntual y completa del sistema que se haría con una copia de seguridad simple. Pero si tenemos documentos que editamos continuamente,  deberemos tener una estrategia especial para ellos, que puede ser hacer copia de los documentos en la nube de manera sincronizada o realizar una copia de seguridad diferencial del sistema operativo, en la cual solo se añadirán los cambios nuevos que hagamos, en cambio si queremos realizar copias completas pero solo de lo que se ha modificado y de lo nuevo, deberemos hacer una copia incremental, la que ira modificando la copia original actualizándola con los nuevos archivos. De esta forma tenemos tres tipos de copias de seguridad que funcionan de distinta forma. 

• Copia Simple Completa:En la copia simple completa, cada vez que hagamos una copia de seguridad deberemos guardar todos los datos de nuevo, consumiendo una cantidad de espacio muy grande.

• Copia Incremental: Que guarda los nuevos cambios que se han realizado desde que se creo la copia original, permitiendo ahorrar mucho espacio ya que no se deberá guardar todo de nuevo.

• Copia Diferencial: guarda todos los cambios que han ocurrido desde la ultima copia completa, ahorrando también bastante espacio frente a una copia simple.

Por otro lado tenemos el historial de versiones de los archivos, por ejemplo, en un documento de Word, cada cambio que hacemos en el mismo queda registrado en el historial de cambios, pudiendo restaurar un estado anterior del mismo sin problema, esto es poco conocido aunque esta muy extendido y existen herramientas como git que se basan en ello.

¿Podemos confiar en ellas?

Las copias de seguridad, son igual de confiables que el medio en el que se almacenen, es decir, si yo hago una copia de seguridad de mi ordenador y lo guardo en un “Pendrive” que llevo todo el día en la cartera, lo mas probable es que lo acabe perdiendo y por lo tanto pierda también la copia de seguridad, en cambio si yo mi copia de seguridad la tengo ordenada en la nube, con replicación en varios centros de datos distintos, solo una gran catástrofe a nivel global podría hacer que me quedara sin mi copia de seguridad.

Figura 7: La regla 3,2,1 de los Backups

Esto nos lleva a la recomendación que muchas personas dan en lo referente a copias de seguridad y es el método 3-2-1, es decir: 3 copias de seguridad en 2 tipos diferentes de almacenamiento con 1 copia, al menos, en un lugar distinto al de las otras dos. Por ejemplo, yo podría guardar mis copias de seguridad en 2 discos duros y 1 copia en la nube, de esta forma, si por algún casual se inunda mi casa, tendría la copia de seguridad en la nube intacta. Y viceversa, que las nubes también se caen.

¿Qué soluciones existen?

Afortunadamente, hay una solución para cada uno de los gustos. Como he comentado antes cada sistema operativo suele traer su propia solución de copias de seguridad, pero también existen soluciones especialistas de terceros, por ejemplo, Duplicati, una utilidad Open Source que nos permite generar de forma bastante sencilla copias de seguridad y guardarlas en almacenamientos de los mas variados, desde los destinados a consumidores finales como OneDrive o GoogleDrive hasta los mas profesionales como SharePoint o B2 de Backblaze. También se permite el cifrado de las propias copias de seguridad para tener mayor privacidad en caso de que se filtre.

Figura 8: Duplicati

Por otro lado, también tenemos otras soluciones de código cerrado, pero también gratuitas, que no nos permiten hacer copias completas del sistema operativo, pero sí de carpetas que queramos conservar, como puede ser OneDrive para escritorio o Google Drive “Backup and Sync” - que fue lo que utilizaron nuestros compañeros para crear el repositorio infinito de juegos para Macintosh en la nube -, los cuales nos permiten de forma selectiva elegir que queremos guardar.

Saludos,

Autor: Guillermo Peñarando Sánchez, Developer en Ideas Locas CDCO de Telefónica.

Contactar con Guillermo Peñarando Sánchez en MyPublicInbox

Ransomware: Unos consejos y cuidados personales para lidiar con la industria de la extorsiones

El Ransomware es un tipo de software malicioso que pretende secuestrar los datos de un sistema o de un conjunto de sistemas a cambio de un rescate. Este secuestro puede ser de datos (cifrándolos) o del sistema (inutilizándolo). Los cibercriminales detrás de las campañas de ransomware suelen pedir el rescate en un determinado plazo de tiempo y si este se cumple, y la víctima no ha pagado, se verá incrementada la cuantía del rescate, para meter urgencia en la toma de la decisión de las víctimas.

Figura 1: Ransomware: Unos consejos y cuidados personales

para lidiar con la industria de la extorsiones

En los rescates, la forma predeterminada para pagarlos, han sido las criptomonedas, y especialmente BitCoin, lo que hizo que los investigadores de ciberseguridad, como fue el caso de Yaiza Rubio y Felix Brezo, pusieran sus esfuerzos de investigación en todo el ecosistema BitCoin, BlockChain y el lista de criptomonedas creadas sobre esta tecnología.

Figura 2: BitCoin: La tecnología Blockchain y su investigación
de Felix Brezo y Yaiza Rubio

Por supuesto, los cibercriminales nunca se quedan quietos y siempre están buscando sacar tajada de lo que sea, por lo que desarrollan planes de negocio con actos delictivos como es la venta de servicio de ransomware o bien programas de ransomware que no necesitan de un entendimiento profundo del ámbito para poder utilizarlos, esto es llamado Ransomware as a Service.

Un repaso rápido a la historia del ransomware

Este tipo de ataques existe desde la década de los 80 cuando el biólogo Joseph Popp introdujo un ransomware a través de un troyano (AIDS Info Disk) que fue enviado por correo no digital. Este correo contenía un floppy disk con información sobre el SIDA. También conocido como PC Cyborg Trojan, reemplazaba el fichero AUTOEXEC.BAT y contaba las veces que se arranca el equipo, una vez llegaba a 90 inutilizaba el sistema cifrando los nombres de los ficheros de la unidad utilizando criptografía simétrica.

Figura 3: AIDS Info Disk

En 2005 apareció el primer ransomware en Internet, GPCODER. Con objetivo de sistemas Windows tuvo variantes como el GPCODE.AK que utilizaba cifrado simétrico (RC4) y asimétrico (RSA) para crifrar los ficheros. El texto que recibía el propietario del sistema le invitaba a realizar dos pagos de 100$, cada uno, a una cuenta de Liberty Reserve y el segundo a una cuenta de e-Gold.

Figura 4: Alert GPCODER.AK

Más tarde, en 2010, Krotten utilizaba un supuesto programa orientado a Windows que generaba códigos “gratuitos”, de recarga, para móviles. Pero en realidad era un ransomware que bloqueaba el sistema operativo y era casi imposible de desinstalar.

Figura 5: Navegador secuestrado con el virus de la Policía

En 2012, Reventon bloqueaba los sistemas haciendo creer al usuario que quién había realizado dicho bloqueo de navegadores y webs era la Policía, y que tuvo variantes de la NSA, el FBI y de PRISM, etcétera. Después apareció Cryptolocker en 2013 que utilizaba claves RSA de 2048-bits, seguida de su variante CryptoWall en 2014. 

En 2015 TeslaCrypt vino para afectar a los usuarios de videojuegos como Minecraft, World of Tanks y Call of Duty, entre otros, utilizando AES encryption. Petya comenzó en 2016 se replicaba a través Dropbox e impedía el arranque del sistema y su variante NotPetya en 2017, teniendo ambos un alcance global. También en 2017, Wannacry aprovechó el exploit EternalBlue para replicarse y tuvo un impacto a nivel mundial afectando a más de 150 países y replicándose en más de 200.000 sistemas.

El año siguiente, en 2018, Ryuk cambió el objetivo hacia las administraciones públicas. Más tarde en 2019 este ransomware comenzó a ser un ataque dirigido contra empresas, organizaciones, buscando maximizar el daño y el retorno económico para los cibercriminales. Ese mismo año también destacó el ransomware Crysis.

Figura 6: WannaCry

En 2020, llegó el gran paso al teletrabajo y con ello los ciberdelincuentes se frotaron las manos ya que el vector de ataque se hizo más grande. Algunos de los destacados fueron Maze, el cual provocó pérdidas de 70 millones en compañías estadounidenses, REvil que extrajo una cantidad altísima de datos privados y variantes de Ryuk. Ahora, en 2021, no paramos de ver, en las noticias, ciberataques hacia empresas, entidades públicas e incluso particulares.

Recientemente, hemos visto como algunos servicios públicos de España están caídos por un ransomware dirigido a su proveedor cloud, ASAC. También, como la red de oleoductos de Colonial se ha visto paralizada por otro ransomware y ha pagado un rescate de más de 4 millones de Euros. Por otro lado, tenemos a Qlocker que está cifrando archivos de los NAS de los usuarios de QNAP, REvil amenazando a Apple con sacar a la luz Blueprints de sus productos o alguna universidad española que han sufrido otros ataque que han entorpecido el curso académico.

Figura 7: RansomCloud O365. Secuestro de contenido del buzón de Office 365

Y ojo porque estamos seguros de que el Ransomware va a llegar a los servicios Cloud en plataformas SaaS, como ya explicaron nuestros compañeros Pablo González, Ioseba Palop y Chema Alonso con RansomCloud O365, un ataque ransomware para cifrar los contenidos de Office 365 directamente en la nube,

¿Cómo evitar o mitigar el ransomware?

Está claro que los ataques de ransomware son uno de los problemas más graves que afectan a particulares y organizaciones, y lo peor de todo es que nos estamos acostumbrando a escuchar y leer este tipo de noticias. Y por supuesto, algún día nos puede llegar de forma directa o indirecta uno de estos ataques por lo que voy a explicar unos consejos con los que podrás ponérselo más difícil a estos cibercriminales, pero que pasan todos por tener fortificado tu equipo al máximo.

Figura 8: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord

Muchos de los ataques de  ransomware empiezan con distribución a través de un ataque de Phishing o Spear Phshing vía e-mail, por lo que conviene conocer los métodos que los atacantes utilizan para no caer en ellos. Como comentamos en anteriores artículos, hay que ser coherente a la hora de revisar los mensajes que nos llegan por e-mail, y con plataformas como MyPublicInbox mucha gente está reduciendo la difusión de su dirección de e-mail, para mitigar la caída en listas de direcciones de difusión de SPAM que hagan que lleguen ataques de SPAM Phishing.

Figura 9: Protección de carpeta contra Ransomware en Windows dEfe

Por supuesto, si no has participado en un sorteo y de repente te ha tocado puedes sospechar, o bien, si no has pedido ningún paquete y te envían un mensaje diciéndote que accedas a una URL para ver el estado de tu envío, lo más probable es que el enlace sea malicioso. Esto también ocurre con las memorias USB´s o CD´s encontradas en la calle. Si no conoces de donde procede no lo insertes en tu dispositivo. Algunas buenas opciones son segmentar las redes y fortificar tu sistema, por ejemplo, restringiendo el acceso a carpetas en Windows. 

Figura 10: Funcionamiento de Latch ARW

Además, si quieres tener el control en tu mano de quién puede y quién no puede acceder a una carpeta, añade una capa más de protección sobre las carpetas con Latch ARW. Por supuesto, evita malas prácticas como dar permisos de Administrador a aplicaciones en las que no confías y mantén tu dispositivo, sistema operativo y todas las aplicaciones actualizadas.

Figura 11: Comprobación de actualizaciones de Windows

Finalmente, lo más importante, un consejo de los años 70: Haz Copias de Seguridad. Una copia de seguridad siempre puede salvarte de una situación difícil por lo que es una opción para tener en cuenta en cualquier plan de contingencia.

¡Un saludo hackers! Autor: Luis E. Álvarez, desarrollador y miembro del equipo Ideas Locas CDCO de Telefónica.

Contactar con Luis Eduardo Álvarez en MyPublicInbox

AMSITrigger v3 & Chimera: Más herramientas de ofuscación y bypass de AMSI en Windows

Ya hemos hablado de AMSI en El lado del mal en diversas ocasiones. Es un tema de mucho interés en el Ethical Hacking actual, ya que los propios sistemas EDR utilizan este tipo de solución para poder detectar situaciones anómalas que puedan ocurrir en los procesos, generalmente, en Powershell, Javascript o VBS, aunque no exclusivamente.

Figura 1: AMSITrigger v3 & Chimera. Más herramientas de

ofuscación y bypass de AMSI en Windows

Hemos visto cómo trabajar manualmente con los bypasses de AMSI y con la existencia de servicios como AMSI.fail, el cual nos permite generar diferentes tipos de códigos que pueden ayudar al pentester a hacer el bypass de AMSI. Hemos visto y trabajado con los bypasses de AMSI en nuestra herramienta iBombshell. Hemos ido explicando técnicas manuales que se pueden automatizar para trocear algunos scripts, ofuscar y hacer prueba y error para conseguir el bypass de AMSI.

Figura 2: Pentesting con Powershell 2ª Edición

En el artículo de hoy hablaremos de un par de herramientas que ayudan al pentester a encontrar y entender dónde AMSI detecta las funciones en Powershell que se quieren ejecutar. Esto es vital para poder aplicar técnicas de ofuscación para evadir la protección cuando estamos en un proyecto de hacking ético. Además, hablaremos de Chimera un script de bash que nos permite realizar esa evasión o bypass de AMSI ofuscando por completo o parcialmente el código de la función de Powershell.


Figura 3: El poder del Pentesting con Powershell
La primera herramienta que vamos a ver es AMSITrigger, la cual va por su versión v3. Esta herramienta permite leer funciones o scripts de Powershell e ir haciendo llamadas a AMSI para ver en qué líneas o instrucciones se detecta como malicioso. De esta forma el pentester tiene una visión rápida de qué debe “tocar” para que AMSI no detecte el código como malicioso.

Figura 4: AMSITrigger v3

AMSITrigger tiene diferentes opciones, las cuales pueden verse en la imagen. La idea es bastante sencilla se obtiene el fichero con el código fuente, ya sea a través de una URL o porque lo tengamos en disco y se lo pasamos al binario de AMSITrigger. La opción ‘-f’ nos permite indicar el grado de análisis que queremos realizar. Para un ejemplo sencillo y saber en qué línea del código fuente están las líneas que AMSI está detectando como malicioso tenemos que indicar la opción ‘-f 2’.

Figura 5: Opciones de AMSITrigger

Para mostrar un ejemplo rápido disponemos de un script o función de Powershell que permite hacer el bypass de UAC a través de las Environment Injection. Si indicáramos en AMSITrigger la opción ‘-u’ y la dirección URL dónde se encuentra el código, la herramienta se descargaría la función y la analizaría, sin necesidad de tener que descargarlo nosotros. Por ejemplo:

-u https://raw.githubusercontent.com/Telefonica/ibombshell/

                    /master/data/functions/bypass/uac/invoke-environmentinjection.

Como puede verse en la imagen, en la línea 21 AMSI está detectando como maliciosa esa línea. Habrá que trabajar sobre ella para evitarlo. En el caso de que AMSI no detectara ninguna línea como maliciosa, el resultado nos indicaría precisamente este hecho. Como veis es muy fácil de utilizar.

Figura 6: AMSI detecta como maliciosa la línea 21

Otro ejemplo que vamos a analizar es el de la función amsi-memory de iBombShell. Como se puede ver en la imagen, se obtiene una serie de líneas y los campos que provocan la detección por parte de AMSI. Ahora tocaría jugar con la ofuscación para lograr la no detección.

Figura 7: Ofuscación del Bypass de AMSI

Herramientas como AMSITrigger son bastante interesantes para ir conociendo en detalle el nivel de labor que tenemos por delante a la hora de cambiar un script para que no se detecte. Las medidas con las que jugar son varias, pero todas importantes e interesantes.

Chimera   

Ahora comentaremos la herramienta Chimera. Este script permite sustituir variables, nombres de funciones, comentarios, aplicar un tipo de ofuscación, sustituir tipos de datos, ofuscar direcciones IP, etcétera. Es un all-in-one. Lo mejor que tiene Chimera es que el usuario puede elegir qué tipo de ofuscación y qué grado de sustitución de elementos quiere llevar a cabo.

Figura 8: Chimera Script

En la siguiente imagen, tenemos un ejemplo sobre una función que es detectada por algunos motores AV. Decimos algunos por ser generosos. Al invocar el script con la opción ‘--all’ se ejecutan todas las sustituciones que se pueden hacer, pero también podemos ir seleccionando cuales si y cuales no.

Figura 9: Todas las sustituciones con Chimera

En estas imágenes podemos ver ejemplos de cómo actúa Chimera y cómo transforma el script original en una serie de información ofuscada no entendible y que a ojos de AMSI, seguramente, pueda pasar más desapercibida.

Figura 10: Transformación realizada

Sin duda, estas dos herramientas, cada una en su funcionalidad aportan valor al pentester y permiten saber cuando AMSI nos detecta y por qué y poder dar solución de forma automática y con ofuscación a esta detección. Dos herramientas que debemos meter en la mochila del pentester para el día a día en el Ethical Hacking.

 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

DLL Hijacking: Identificando programas vulnerables con Process Monitor

Hace unos días revisábamos lo que es una DLL y en qué consistían los ataques de DLL Hijacking. En esta ocasión, atendiendo a los conceptos explicados en el artículo anterior, vamos a comprobar cómo se puede buscar si un programa es vulnerable a este ataque y, en el próximo artículo,  cómo poder explotarlo. 

Figura 1: DLL Hijacking: Identificando programas vulnerables con Process Monitor

En este artículo de hoy en concreto vamos a trabajar con la última versión de Slack que en el momento de escribir el artículo es la 4.15.0, que es una de las aplicaciones más utilizadas en estos tiempos de teletrabajo en los equipos Windows de las empresas, y puede ser un buen objetivo para atacar en un Hacking a sistemas Windows y redes Microsoft.

Identificando oportunidades de DLL Hijacking

Para buscar un programa vulnerable a DLL Hijacking vamos a hacer uso de Process Monitor (procmon), una herramienta capaz de monitorizar en tiempo real un gran número de eventos relacionados con los procesos del sistema. Hemos visto en varios artículos cómo esta herramienta se puede utilizar para revisar los niveles de integridad de los procesos o para encontrar y explotar UAC Bypass:

- Cómo ownear Windows 7 y Windows 10 con el nuevo bypass de UAC

- Bypass de UAC en Windows 10 con DLL Hijacking vía SystemPropertiesAdvanced.exe

- Fileless 3: Otro bypass de UAC en Windows 10

Lo que nos interesa en este caso es que, seleccionando los filtros adecuados, podemos listar las DLL que un proceso intenta cargar, la rutas en la que se buscan esas DLL y si éstas se han encontrado con éxito o no en esos directorios.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Ahora que ya sabemos lo que debemos buscar, conviene recordar que la finalidad del DLL Hijacking es, generalmente, la de elevar privilegios o generar persistencia en el sistema. Esto ya nos da una pista sobre qué programas nos pueden interesar más:

• Si la intención es la de elevar privilegios parece razonable buscar programas que se ejecuten por un usuario con privilegios de administrador o servicios que se ejecuten como “NT AUTHORITY/SYSTEM”. Si se carga una DLL cuyo payload genere una shell, ésta tendrá los mismos privilegios que el usuario que levantó el proceso.

• Si lo que se pretende es generar persistencia, la estrategia sería buscar programas que se ejecuten de forma habitual (como un navegador de Internet) y programas configurados para ejecutarse automáticamente cuando se inicia el sistema. Algunos de los programas que yo he visto que con frecuencia se configuran para iniciarse con el sistema son: Microsoft Teams, OneDrive, Skype, Dropbox y Slack.

En este caso, vamos a trabajar con Slack y vamos a filtrar en procmon todas aquellas DLL que la aplicación intenta cargar, pero no encuentra en el directorio donde las busca. Para ello, tras ejecutar procmon abriremos la pestaña “filter” (ctrl+L) y añadiremos estos tres filtros:

1. Primer desplegable “Process name”, segundo desplegable “is” y “slack.exe”.
2. Primer desplegable “Path”, segundo desplegable “ends with” y “.dll”.
3. Primer desplegable “Result”, segundo desplegable “is” y “NAME NOT FOUND”.

Nuestro filtro debe quedar así:

Figura 3: Filtro para la búsqueda de DLLs no encontradas por Slack

Tras aplicar el filtro en procmon y ejecutar Slack aparecerá la lista de DLLs que cumplen estos criterios que se puede ver en la Figura 4. De todas estas DLLs las más interesantes son aquellas que se han buscado en el propio directorio de la aplicación. Ahora hay comprobar si en dicho directorio contamos con permisos de escritura, lo que en nuestro caso se cumple, para depositar ahí una DLL maliciosa.

Figura 4: Lista de DLLs no encontradas por Slack

Es importante aclarar que en este punto vamos “a ciegas”, es decir, no hemos hecho ningún análisis del binario. Para nosotros slack.exe es una caja negra; no sabemos cómo carga cada DLL, qué funciones de esa DLL utiliza o qué hará el programa si se encuentra con una DLL inválida o si no consigue importar función alguna de esa DLL.

Figura 5: Ejemplo de DLL "vacía"

Desde este momento el trabajo que nos queda por hacer es bastante manual; hay que ir comprobando para cada DLL si existe una oportunidad real de secuestro o "Hijacking". Esto puede hacerse introduciendo en el directorio de la aplicación una DLL “vacía” (sin ningún payload), tal y como aparece en la figura anterior. Basta con renombrar esa DLL vacía con el nombre de la DLL legítima a la que pretendemos suplantar.

Figura 6: Máxima Seguridad en Windows Gold Edition

Una vez hecho esto, deberíamos eliminar los filtros de procmon que habíamos creado anteriormente y crear un filtro con el nombre de la DLL con la que estamos trabajando. Si al ejecutar Slack de nuevo comprobamos en procmon que el resultado para esa DLL ha cambiado de “NAME NOT FOUND” a “SUCCESS” entonces puede haber una oportunidad para el hijacking. 

Figura 7: Resultado para USERENV.DLL antes de introducir la

DLL "vacía" en el directorio de la aplicación

También puede ocurrir que el programa no se inicie correctamente o que su ejecución se rompa. Esto es normal y no debe preocuparnos, hay que entender que está cargando una librería que no exporta ninguna función. Lo importante es detectar signos de que la DLL vacía se ha cargado. En la Figura 7 y la Figura 8 se puede ver la comparación de los resultados de procmon para USERENV.dll al introducir una DLL vacía en el directorio de la aplicación.

Figura 8: Resultados para USERENV.dll después de introducir la

DLL "vacía" en el directorio de la aplicación

El siguiente paso para descubrir si esto puede traducirse en un DLL Hijacking será introducir un payload en nuestro DLL para que se ejecute cuando Slack lo carga. Este tema es algo más complejo que simplemente introducir el código del payload en la DLL y vamos a ver el porqué en el siguiente artículo.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

Qué es una DLL y en qué consiste el DLL Hijacking

La primera vez que nos topamos con el concepto de DLL Hijacking puede resultar un poco tedioso o difícil de comprender. Es habitual acudir a tutoriales y vídeos sobre este ataque para luego replicarlo - y en El lado del mal se ha hablado muchas veces de DLL Hijacking - y comprender en qué consiste. Aunque esto es una buena idea, creo que merece la pena invertir algo de tiempo en comprender algunos fundamentos teóricos relacionados con las DLLs y la forma en la que impacta en la seguridad de Windows.

Figura 1: Qué es una DLL y en qué consiste el DLL Hijacking

Además, como los más expertos saben, esta técnica de DLL Hijacking es una de las utilizadas en esquemas de elevación de privilegios, bypass de AMSI, evadir AppLocker, y, por supuesto, para escapar del User Account Control, en proyectos de Red Team que necesitan de realizar un Hacking de Windows, por lo que hay que conocer los detalles de esta técnica para avanzar en nuestros proyectos de Ethical Hacking.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Para entender lo que es una DLL y la función que cumple vamos a prestar atención a su nombre: Biblioteca de Enlace Dinámico. Si programas en algún lenguaje compilado, como los de la familia del lenguaje de programación C, sabrás que una biblioteca no es otra cosa que un archivo que contiene código (como un conjunto de funciones) ya compilado y listo para ser usado en nuestros propios desarrollos.

Esto nos permite reutilizar código optimizado, testado y bien documentado para ahorramos trabajo y no “reinventar la rueda” como se suele decir. Para hacer uso de una biblioteca, un programa llamado "linker" tiene que enlazar (o vincular) esa biblioteca con nuestro código. Este enlace puede hacerse de dos formas distintas: de forma estática (Static Linking) o de forma dinámica (Dinamic Linking).

Enlace estático (Static Linking)

En este caso el "linker" enlaza la biblioteca justo después de compilar nuestro código y como resultado de este enlazamiento se obtiene el ejecutable final. A efectos prácticos se puede entender este proceso como si el "linker" hiciese un “copia y pega” de las funciones de la biblioteca estática directamente a nuestro código.

Esta forma de enlazar una biblioteca tiene sus ventajas y sus inconvenientes. Imagina que en tu sistema están corriendo diez programas que hacen uso de una misma biblioteca. Cada uno de esos programas tendría que haberse compilado y enlazado con la biblioteca, aumentando el peso de cada ejecutable en el disco y el espacio que ocupa el proceso en la memoria. Que cada uno de estos programas cargue la misma biblioteca en memoria es algo que no parece muy eficiente, por esta razón existe el enlace dinámico.

Enlace Dinámico (Dinamic Linking)

Para solucionar esta duplicidad de bibliotecas cargadas en la memoria y obtener ejecutables más ligeros se hace uso de bibliotecas compartidas o de enlace dinámico: las famosas DLLs de Windows o los archivos .so (shared object) que tan importantes son también para la seguridad y la explotación de vulnerabilidades en GNU/Linux. 

Figura 3: Diferencias entre el enlace estático y el enlace dinámico de bibliotecas

En esencia, estas bibliotecas se cargan en un espacio propio de la memoria del sistema y pueden ser accedidas por uno o varios procesos en tiempo de ejecución. Siguiendo con el ejemplo anterior; esos diez procesos harían uso de una misma biblioteca compartida que se ha cargado una sola vez en una partición de la memoria. En la figura anterior se ve más claramente las diferencias entre estas dos formas de vinculación:

La búsqueda predefinida de DLLs en Windows

En posteriores artículos de esta serie profundizaremos más en la manera en la que se vinculan los ejecutables de Windows con las DLLs, pero de momento nos basta con saber que hay dos formas de hacerlo: mediante la vinculación implícita y la explícita.

• Vinculación implícita (Implicit linking): las DLLs se cargan en la memoria a la vez que el programa que las usa. Es decir, Windows busca las DLLs que tiene que cargar al ejecutar el programa.

Figura 4: Prototipos para LoadLibraryW y LoadLibraryExW

• Vinculación explícita (Explicit linking): en este caso el sistema carga las DLLs cuando son llamadas por el programa mientras éste se está ejecutando. Esto se consigue mediante el uso de las funciones LoadLibrary y LoadLibraryEx cuyos prototipos son los de la figura anterior.

Lo importante aquí es el parámetro lpLibFileName que reciben estas funciones y que puede hacer referencia a la ruta absoluta o también al nombre de la DLL que el sistema debe cargar. Si la DLL se vincula implícitamente o si en la vinculación explícita no se especifica una ruta en la función LoadLIbrary/LoadLibraryEx, el sistema operativo Windows se encarga de buscar la DLL siguiendo un orden preestablecido. Conocer este comportamiento de Windows es el primer paso para entender el DLL Hijacking, por eso merece la pena prestarle atención a la siguiente figura:

Figura 5: Orden de búsqueda de DLLs de Windows

Antes de buscar la DLL en los archivos del sistema Windows hace dos cosas. Primero comprueba si la DLL está ya cargada en memoria. En caso afirmativo el proceso de búsqueda, se para aquí. Después comprueba si la DLL pertenece a una lista conocida como "Known DLLs". Si está en esa lista, el sistema usará su propia copia de la DLL (incluyendo las dependencias de esa DLL). Puedes encontrar la lista de los "Known DLLs" para tu sistema en el registro:

Figura 6: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

En cualquiera de estos dos casos la DLL se vinculará con el programa y no existirá oportunidad para un ataque de DLL Hijacking. De otra forma, cuando la DLL no está cargada en memoria y no pertenece a las Known DLL Windows buscará la DLL en los directorios en el orden especificado en la figura anterior.

Figura 7: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord

De todos estos directorios los más interesantes de cara a un ataque DLL Hijacking son los sombrados en rojo: el propio directorio de la aplicación y aquellos directorios definidos en la variable del sistema %PATH%, ya que son aquellos que tienen mayor probabilidad de contar con permisos mal configurados.

¿Qué es el secuestro de DLL o DLL Hijacking?

Llegados a este punto podemos definir el DLL Hijacking como el abuso de esta búsqueda sistemática de Windows mediante la detección de permisos mal configurados en los directorios en los que se buscan las DLLs. El objetivo de un ataque de DLL Hijacking es aprovechar permisos de escritura en uno de estos directorios para depositar en él una DLL con el mismo nombre que la DLL legítima pero que contenga código malicioso. 

De esta manera el sistema encontrará y cargará esa DLL antes que la DLL legítima que se pretendía cargar. El código malicioso que se introduce en la DLL suele tener el objetivo de elevar privilegios en el sistema, si el proceso que carga esa DLL se ejecuta con privilegios altos, o de generar persistencia si es un proceso que se ejecuta frecuentemente o al iniciarse el sistema.

Figura 8: DLL Hijacking para hacer un bypass de UAC en Windows 10
Aunque el concepto es siempre el mismo, se puede hablar de diferentes variantes o técnicas de DLL Hijacking. Al buscar información sobre este ataque es probable que te encuentres con términos como DLL Sideload o Phantom DLL Hijacking:

• DLL Sideload: Cuando se cuenta con permisos de escritura en un directorio que aparece en el orden de búsqueda antes que el directorio donde se encuentra el DLL legítimo. En ese directorio se pondrá la DLL maliciosa.

• Phantom DLL Hijacking: Cuando el DLL no se encuentra en ninguno de los directorios donde se busca y se tienen permisos de escritura en alguno de estos directorios, por lo que se depositará la DLL maliciosa ahí.

Cómo protegerse del DLL Hijacking

Desde el punto de vista de un programador puedes proteger tu programa del DLL Hijacking teniendo en cuenta algunas buenas prácticas de desarrollo:

1) Usar el Full Path de la DLL en las funciones LoadLibraryW / LoadLibraryA y consultar la documentación de las funciones LoadLibraryExW / LoadLibraryExA ya que permiten usar flags para modificar el comportamiento de búsqueda de DLLs por defecto. También hay que tener en cuenta que, cuando la DLL que se va a cargar tiene dependencias, éstas dependencias van a ser buscadas por Windows mediante la búsqueda sistemática habitual incluso cuando hemos especificado el Full Path para esa DLL.

2) Siempre que sea posible se deberían usar DLL firmadas y verificar esa firma antes de cargar la DLL en la memoria. Otra opción es comprobar el hash de la DLL para evitar cargar un DLL cuya integridad ha sido comprometida.

3) No es recomendable instalar programas en la raíz de una partición (por ejemplo: “C:\”) ya que por defecto los directorios creados en la raíz conceden permisos de escritura a cualquier usuario autenticado y es fácil olvidar configurarlos correctamente.

Y, por supuesto, una vez desarrollada tu aplicación conviene analizar su comportamiento para saber si es vulnerable al DLL Hijacking. Esto mismo es lo que haremos en el siguiente artículo de la serie, junto a una demostración del ataque en una aplicación vulnerable.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

Pentesting en Active Directory: Pass-the-ticket & Mimikatz

En el lado del mal hemos hablado de mucho Ethical Hacking durante años. Hemos hablado de herramientas como Mimikatz, quizá una de las más potentes y utilizadas en el Hacking de redes Windows internamente. Técnicas como, pass-the-hash, pass-the-ticket, golden & silver ticket, que Benjamin Delpy se ha encargado de ir metiendo a su querido Mimikatz. Con Benjamin Delpy coincidimos en la Euskalhack 2018 y fue bastante emocionante poder disfrutar de sus conocimientos en el congreso y en las cenas.

Figura 1: Pentesting en Active Directory: Pass-the-ticket & Mimikatz

Hoy no voy a hablar de algo nuevo que trae Mimikatz, si no que quiero hablar de conceptos de autenticación en el Active Directory, en este caso en Windows Server 2016, y cómo podemos aplicar la técnica Pass-the-ticket. Esta técnica tiene su análoga con pass-the-hash, de la cual ya hemos hablado en el blog en más de una ocasión.

 

Figura 2: Libro de Hacking Windows

Antes de entrar en materia, quiero recordar algunos de los artículos relacionados con Mimikatz que hemos ido haciendo y viendo en su momento. Es una navaja suiza en toda regla, con más de 9 años de desarrollo y sigue dando mucha guerra. Es algo digno de admirar. Recuerdo cuando salió DCShadow y la foto del niño que quería llegar a ser un Domain Controller. Hemos visto cómo poner una Skeleton Key al Domain Controller. Con Mimikatz hemos visto cómo extraer credenciales de memoria haciendo un minidump al proceso lsass.exe. También vimos como Zerologon llegaba a Mimikatz hace unos meses.

Kerberos in a nutshell

Si nos preguntamos qué es Kerberos, lo encontramos muy bien explicado en este post de los compañeros de Tarlogic. Podemos decir que es un protocolo de autenticación utilizado, por ejemplo, en el Active Directory. La idea del protocolo es que se sirvan una serie de tickets (o "vales" en alguna traducción al castellano, en alguna documentación) para poder acceder a ciertos recursos en el dominio. Podemos decir que existen tres roles diferentes dentro del esquema de autenticación en Kerberos:

- Usuario o cliente. Éste será el que pida el ticket y tenga que autenticarse para poder acceder al recurso. 

 

- KDC o Key Distribution Center. Éste es el servicio Kerberos. Se encarga de gestionar y emitir los tickets que serán utilizados por los clientes para acceder a los recursos o servicios. 

 

- AP o servicio de aplicación. Al final es el recurso al que el cliente quiere acceder. Lo hará a través del uso de un ticket que verifique que puede acceder al recurso.

Hay una serie de elementos clave que juegan un papel fundamental en la ecuación. A continuación, os dejo un resumen de las diferentes claves:

- Del usuario: Ésta será un hash (o un derivado más bien) ntlm. 

 

- De la cuenta krbtgt: El hash ntlm de la cuenta del KDC en el Domain Controller. 

 

- Del servicio: El servicio expuesto en el dominio tendrá una cuenta de servicio o de usuario que será el que lo habrá lanzado. 

 

- De sesión: Clave obtenida entre la negociación del KDC y del cliente. 

 

- De sesión de servicio: Clave obtenida para utilizarla entre el cliente y el servicio.

Ahora hablemos de los tickets. El primer ticket que trataremos es el TGT o Ticket Granting Ticket. Lo presentaremos ante el KDC para obtener el TGS o Ticket Granting Service. El TGT será cifrado con la clave del KDC, es decir, la clave derivada de la cuenta del krbtgt. A esto volveremos más adelante. El TGS se obtiene de un TGT enviado al KDC. El TGS lo presentaremos al servicio que tiene el recurso al que queremos acceder. El TGS es cifrado con la clave de servicio.

¿Cuál es el flujo normal de todo esto?

A priori, puede parecer algo complejo, pero no es así. Vamos a intentar simplificar el proceso. Partimos de tres máquinas con las siguientes configuraciones:

- Máquina Windows 10, la llamaremos A, en la que estoy yo.

- Domain Controller, la llamaremos KDC, con Windows Server 2016.

- Máquina Windows Server 2016, la llamaremos R de recurso, que no es Domain Controller o máquina Windows 10 que tiene un servicio al que queremos acceder.

Lo primero es solicitar un ticket TGT. Para ello mi máquina A envía una petición KRB_AS_REQ a la máquina KDC. En este mensaje la máquina A envía información como un timestamp que está cifrado con una clave derivada del hash del usuario, es decir, del hash de mi contraseña de dominio. En esta petición se envía el nombre de usuario, el SPN para la cuenta krbtgt y un nonce.

Cuando el KDC recibe esto, se valida la información cifrada, para ver si la clave de dicho usuario es correcta, es decir, descifra el contenido del timestamp. El KDC va a producir la respuesta KRB_AS_REP. En esta respuesta se envían varias cosas como, por ejemplo, el nombre de usuario, el ticket TGT y unos datos cifrados con la clave del usuario.

Estos datos cifrados con la clave del usuario, al volver a la máquina A podrían ser descifrados. ¿Qué me está devolviendo el KDC? La clave de sesión, que será importante, la fecha de expiración del TGT y un nonce. El ticket suele tener una validez de 10 horas. Esto puede ser alterado, y mucho, en un ataque Golden Ticket o Silver Ticket. ¿Qué encontramos en el TGT? Encontraremos el nombre de usuario, la clave de sesión de nuevo, la fecha de expiración y el PAC. El PAC es una estructura de datos que trae información sobre los privilegios. El TGT está cifrado con la clave de la cuenta krbtgt, es decir, con el KDC.

 

Figura 3: Máxima Seguridad en Windows Gold Edition

Ahora tenemos un ticket TGT en la máquina A. Este ticket nos vale para solicitar un TGS y poder acceder al recurso dentro del Active Directory que me interese y tenga acceso, claro. Desde la máquina A a la máquina KDC enviamos una petición KRB_TGS_REQ. Esta petición contiene lo siguiente:

- El nombre de usuario y timestamp cifrados con la clave de sesión. 

 

- El TGT que nos ha enviado en el paso previo, el cual se encuentra cifrado con la clave de krbtgt, es decir, con el KDC. 

 

- El SPN y un nonce.

Si todo sigue su curso, ¿qué nos devuelve el KDC? La máquina KDC envía una respuesta KRB_TGS_REP a la máquina A. En ella encontraremos:

- El nombre de usuario. 

 

- La clave de sesión, la fecha de expiración del TGS y un nonce cifrados con la clave de sesión. 

 

- La clave de sesión de servicio (esta es importante), nombre de usuario, fecha expiración del TGS y el PAC. Todo ello cifrado con el hash de la cuenta propietaria del servicio.

Ahora tenemos el ticket TGS. Ahora solo debemos enviarlo a la máquina R, la cual es la que tiene el recurso al que queremos acceder. Desde la máquina A se hace una petición KRB_AP_REQ a la máquina R. En esta petición se envía el ticket TGS cifrado con la clave de la cuenta propietaria del servicio.

Figura 4: Esquema de funcionamiento de Kerberos

Luego el nombre de usuario y el timestamp van cifrados con la clave de sesión de servicio. Cuando esta información llega a la máquina R, se valida y se da acceso al recurso. En la imagen del artículo de Tarlogic se detalla muy bien.

Ahora: Pass-the-ticket

Tras explicar el funcionamiento básico del protocolo Kerberos, vamos a ver un ataque llamado Pass-the-ticket y que consiste en hacer algo similar al Pass-the-hash pero en un entorno de Windows Server 2016 con un Active Directory. Es decir, haremos una suplantación de usuario, en vez de utilizando el hash ntlm de la cuenta del usuario, utilizaremos un ticket Kerberos con validez y que pertenezca a dicho usuario.

Figura 5: Libro Windows Server 2016:
Administración, Seguridad y Operaciones

¿Dónde podemos encontrar estos tickets? Al final cualquier máquina de un dominio hace uso de Kerberos, por lo que los tickets se encuentran en cada una de esas máquinas. Al llegar a una máquina de dominio, comprometerla y escalar privilegios, podemos hacer uso de Mimikatz para sacar partido en el Ethical Hacking.

Figura 6: Uso de klist

Con la herramienta klist podemos ver los tickets que se encuentran almacenados en la sesión del usuario. Es decir, los que utilizara cuando quiera acceder a los recursos de una máquina del dominio. Los tickets pueden ser TGT o TGS. En el caso de tener el TGT se hará el proceso para conseguir el TGS y llegar al recurso deseado. Si utilizamos Mimikatz con su módulo sobre Kerberos tenemos muchas opciones:

- La opción ptt. Nos permitirá hacer el Pass-the-ticket. 

 

- La opción list. Nos lista los tickets que tenemos en memoria en nuestra sesión. 

 

- La opción purge. Permite eliminar tickets de memoria en nuestra sesión. 

 

- La opción tgt. Para ver qué ticket estamos usando en memoria. 

 

- La opción golden. Nos permite generar Golden Tickets y Silver Tickets, pero esto lo hablaremos en otro artículo.

Con la instrucción “sekurlsa::tickets” podemos ver los tickets que hay en memoria en la máquina, los nuestros y los de otros usuarios. Esto es bastante poderoso, ya que podemos sacarle mucho juego. Por ejemplo, hacer la suplantación de otro usuario. Con la opción “sekurlsa::tickets /export” exportaremos todos los tickets a disco, con extensión *.kirbi.

Si nos quedamos con los ficheros kirbi que contienen “*Administrador@krbtgt*” tendremos un TGT y viendo la palabra Administrador o Administrator podemos pensar que estamos de suerte. En otras ocasiones, quizá solo nos interesa utilizar otros tickets para poder llegar a ciertos recursos. No todo es ser admin.

Figura 7: Ejecución de kerberos::ptt en Mimikatz

Ahora, nos vamos con los tickets recogidos a otra máquina. Podemos usarlos en máquinas que estén o no estén en el dominio. Es decir, podemos llevárnoslo a nuestra máquina y trabajar tranquilamente. Para hacer el pass-the-ticket ejecutamos "kerberos::ptt [ticket.kirbi]". Con el ticket anterior, intentamos leer el recurso c$ del Domain Controller y obtenemos la respuesta deseada. Tenemos acceso al Domain Controller.

Figura 8: Acceso al Domain Controller conseguido

La idea del artículo es mostrar cómo funciona Kerberos y mostrar un ejemplo de ataque en el Active Directory  a Kerberos. Existen muchas posibilidades y es un mundo interesante que se debe conocer para un pentesting interno en una organización. Sin duda, interesante el mundo Kerberos y sus ataques.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González