16 noviembre, 2019

Passwords cracking de hashes NTLM ntds.dit de Active Directory

Antes de empezar con la parte práctica de password cracking en sistemas Windows, es recomendable un breve resumen sobre las diferencias entre los tipos de hashes de contraseñas (LM, NTHash o NTLM, NTLMv1, NTLMv2) que almacena Windows en su base de datos local SAM (Security Account Manager) o NTDS.DIT (NT Directory Services) si se trata de controladores de dominio de Active Directory.

LM Hash (Lan Manager)

Usado en sistemas Windows 2000/2003 aunque por compatiblidad pueden ser usados en versiones posteriores de Windows. LM es débil e inseguro por diseño, teniendo en cuenta la velocidad de computo de los sistemas actuales, son capaces de probar cientos de miles de contraseñas por segundo por lo que su cifrado lo hace totalmente vulnerable en ataques de fuerza bruta.

Su algoritmo convierte todo de minúsculas a mayúsculas haciendo así un ataque enfocado a este tipo de caracteres, reduciendo las posibles combinaciones y el tiempo de cálculo.

Si la contraseña es inferior a 7 caracteres se rellena con caracteres NULOS.

Si la contraseña tiene más de 7 caracteres se divide en dos bloques, en el supuesto de utilizar una contraseña de 10 caracteres el ataque de fuerza bruta se realizará para un primer bloque de 7 y otro para un segundo bloque de 3, si se utilizara una contraseña de 14 caracteres en vez de elevar exponencialmente el tiempo de ataque, simplemente se tardaría el doble de tiempo, por lo que daría igual usar una contraseña con una de 7 caracteres como de 14 que sería la longitud máxima soportada para LM.

Ejemplo de LM Hash: 35ABD1B8C5128FC8

Más información sobre LM Hash (Lan Manager):

NT Hash o NTLM (New Technology Lan Manager)

A partir de sistemas Windows 2008/Vista se usa por defecto NTLM (aunque por compatibilidad se puede seguir haciendo uso de LM).

NTLM Es la mejora de cifrado respecto a LM. NTLM diferencia entre mayúsculas y minúsculas, calcula el hash cifrando con el estándar MD4. Pero por defecto sigue almacenando las contraseñas cifradas en LM y NTLM en la misma base de datos del fichero SAM  que se encuentra en el path "C:\Windows\System32\config\SAM".

Ejemplo de NT Hash (NTLM): 4B6A9B02C6F09P9BD265F388BA951E2B

Actualmente existen varias versiones mejoradas del protocolo de autenticación desafío-respuesta. NTLMv1 y NTLMv2https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1

1. Extraer los ficheros ntds.dit y SYSTEM de un controlador de dominio

Después de una post-explotación, conseguir acceso a un sistema y una escalada de privilegios. Podemos realizar un dump de los hashes NTLM a partir del fichero ntds.dit. Este fichero es la base datos encargada de almacenar los hashes de las contraseñas de usuarios de Active Directory.

El primer paso para la extracción de hashes de contraseñas de usuarios de Active Directoy, es obtener una copia del archivo ntds.dit. El problema es que no podemos copiar este fichero sin más, ya que está constantemente en uso y bloqueado por AD.

Figura 1: Error al copiar el archivo en uso ntds.dit de un controlador de dominio.
Para copiar el fichero ntds.dit podemos usar uno de estos dos métodos.
  • Usar Volume Shadow Copies a través del comando VSSAdmin.
  • Usar el cmdlet Invoke-NinjaCopy del módulo PowerSploit.

Método 1: Servicio VSS - Volume Shadow Copy: Usando el comando VSSAdmin 

El servicio VSS (Volume Shadow Copy) o servicio de instantáneas de volumen de Windows es el encargado de crear backups a modo de instantáneas temporales. Se puede usar el comando vssadmin para la gestión de este servicio de instantáneas. De modo que después se puedan copiar de un volumen de instantánea en el que no estará constantemente en uso por AD.

Crear un volumen de instantánea del disco C:
vssadmin create shadow /for=C:
copy <Nombre_Volumen_Instantanea>\Windows\System32\config\SYSTEM C:\export\SYSTEM
copy <Nombre_Volumen_Instantanea>\Windows\NTDS\ntds.dit C:\export\ntds.dit
Eliminar el volumen de la instantánea del disco C:
vssadmin list shadows
vssadmin delete shadows /shadow={Id_Instantanea}
Figura 2: Copiar los ficheros en uso ntds.dit y SYSTEM con VSSAdmin de un controlador de dominio.

Método 2: Módulo PowerSploit: Usando el cmdlet Invoke-NinjaCopy

Otra forma de copiar archivos en uso por el sistema o en este caso Active Directory es usar el cmdlet Invoke-NinjaCopy incluido en el módulo PowerSploit, este copia un archivo de un volumen NTFS sin procesar, es otra ofrma de copiar archivos bloqueados por Active Directory sin alertar a ningún sistema de monitoreo.

Instalar el módulo PowerSploit:
  • Descargamos el módulo
  • Copiamos el directorio en una de las rutas por defecto donde se almacenan los módulos de PowerShell. Podemos consultar los paths listando la variable de entorno: $Env:PSModulePath.
  • Importamos el módulo: Import-Module PowerSploit.
  • Para obtener todos los cmdlets disponibles: Get-Command -Module PowerSploit.
Invoke-NinjaCopy -path C:\Windows\NTDS\ntds.dit -Verbose -LocalDestination C:\export\ntds\ntds.dit
Figura 3: Copiar el fichero ntds.dit con Invoke-NinjaCopy de un controlador de dominio.

2. Volcado de hashes NTLM del fichero ntds.dit

Podemos volcar los hashes NTLM del fichero ntds.dit de dos formas:

Método 1: Módulo DSInternals - Usando los cmdlets Get-BootKey y Get-ADDBAccount

Instalar módulo DSInternals.
Install-Module -Name DSInternals -Force
Import-Module -Name DSInternals
Import-Module -Name ActiveDirectory
Get-BootKey lee la clave de registro de Windows del sistema de arranque SYSTEM del registro de Windows "HKEY_LOCAL_MACHINE\SYSTEM" o también puede hacerse referenciando el propio fichero SYSTEM "%systemroot%\System32\config\SYSTEM".

Podemos exportar la clave de registro o copiar el fichero SYSTEM a un directorio en el que no esté en uso con alguna de las técnicas mencionadas anteriormente en el apartado 1.

Para poder volcar los hashes NTLM de los usuarios de AD y leerlos en plain-text del fichero ntds.dit. Obtenemos la clave de registro SYSTEM con Get-BootKey y se la pasamos con el parámetro -BooKey en Get-ADDBAccount.
reg save hklm\system C:\export\system
$key = Get-BootKey -SystemHiveFilePath C:\export\system
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit
Es probable que al intentar leer el fichero ntds.dit se muestre el error "The database is not in a clean state". Hacemos uso de la utilidad de comandos esentutl para reparar la base de datos de Active Directory.
esentutl /p C:\export\ntds.dit /!10240 /8 /o
A continuación volvemos a ejecutar Get-ADDBAccount.

Figura 4: Get-ADDBAccount - Obtener información de las cuentas de usuarios de AD.
Podemos simplificar la información de salida de las cuentas de usuarios de AD redireccionándola a un fichero y obtener los hashes de contraseñas asociados a los nombres de las cuentas de AD que se corresponde al atributo -SamAccountName-.
Get-ADDBAccount -All -BootKey $key -DBPath C:\export\ntds.dit > C:\export\hashes_tmp.txt
Select-String -Path C:\export\hashes_tmp.txt -Pattern '(NTHash)|(SamAccountName:)' > C:\export\hashes.txt
Remove-Item C:\export\hashes_tmp.txt
Figura 5: Recopilación de hashes NTLM del fichero ntds.dit de las cuentas de usuarios de AD.

Método 2: Kali - Impacket-secretsdump (script en Python -secretsdump.py-)

Otra forma de realizar el volcado de hashes NTLM del fichero ntds.dit es usar un script en Python llamado secretsdump.py. Este se integra en uno de los módulos auxiliary de escaneo Impacket-secretsdump de Metasploit.

En este caso al usar el fichero de ntds.dit de forma local ejecutamos Impacket-secretsdump desde el path "/usr/share/impacket" en una terminal de Kali.
impacket-secretsdump -system /root/hashes/SYSTEM -ntds /root/hashes/ntds.dit LOCAL -outputfile /root/hashes/hashes.txt
Figura 6: Volcado de hashes NTLM del fichero ntds.dit con Impacket-secretsdump. 

3. Hashcat: Descifrado de hashes NTLM para obtener las contraseñas de usuarios de AD

Podemos descifrar hashes utilizando tres posibles técnicas.
  1. Ataque por fuerza bruta (Brute-force attack).
  2. Ataque por diccionarios o Wordlist.
  3. Ataque por tablas arcoíris (Rainbow tables).
En este caso como prueba de concepto se empleará un ataque por diccionario usando la herramienta Hashcat integrada en Kali (/usr/share/hashcat).

Una vez redireccionamos la salida de los hashes a un fichero solamente quedaría descifrar dichos hashes para obtener el valor de cadena en plain-text de las contraseñas de cuentas de usuarios de AD.
hashcat -m 1000 /root/hashes/hashes.txt /root/breachcompilation.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule --force
Donde "breachcompilation.txt" es el diccionario -fichero que contiene el wordlist- e "InsidePro-PasswordsPro.rule" será el tipo de regla utilizada para el proceso de password cracking.

En la siguiente captura vemos como se muestra el hash:contraseña. De esta manera podemos relacionar el hash con el usuario al que se corresponde a través del fichero que se creo en el apartado 2 donde se mostraba el volcado de hashes NTLM.

Figura 7: Ataque por diccionario con Hashcat - Password cracking de hashes NTLM de Active Directory.

4. Comprobar hashes NTLM ya son conocidos en bases de datos de internet

Otra forma de realizar el cracking password una vez conocemos los hashes NTLM. Sería consultar a través de varios sitios web disponibles en internet si el hash que tienen en las wordlist de estas webs hace match con el que se le referencia, si así directamente nos dará como resultado la cadena de password encontrada.

Existen multitud de webs para realizar estas comprobaciones como por ejemplo:
Figura 8: Descifrar hashes NTLM comparándolos con hashes ya conocidos en sitios webs.

5. Comprueba si ya existe el hash de tu contraseña antes de usarla

Un motivo a tener en cuenta en el momento de crear contraseñas, es comprobar si el hash de la contraseña que utilizamos o vamos utilizar ya es conocido y está público en internet. Si ya existe en alguna wordlist de los sitios webs comentados en el apartado 4. Obviamente podemos realizar esta comprobación en más sitios, las webs anteriores solo fueron un ejemplo.

Algo que nos puede dar un poco más de confianza en la fortificación de nuestras passwords, sería comprobarlas previamente generando el hash NTLM a partir de tu contraseña. Lógicamente es un pequeño extra de seguridad, no lo hace ni mucho menos más seguro. Simplemente demorarías el tiempo de un ataque por diccionario a un atacante y la facilidad de obtener una contraseña.

Algunas webs que podemos usar para la generación de hashes NTLM:
Figura 9: Generar hashes NTLM a partir de una contraseña.

Saludos!

28 septiembre, 2019

Backups: Sincronizar datos locales a un bucket de Amazon S3 usando AWSCLI en PowerShell y Bash

Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de "Backups" sino de un sistema sincronizado. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos es decir, una política de retención. En ese caso si estaríamos aplicando el concepto de backups.

Esta es una forma sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática.

Se trata de un script que realiza un push de los datos locales a una ubicación remota en Amazon S3 usando un almacenamiento en un bucket. El script lo he desarrollado tanto para PowerShell como para Bash scripting, de forma que se pueda utilizar en sistemas Windows, Linux o MacOS.

Bash Shell Script
  1. Instalación y configuración de AWSCLI Linux
  2. Modificación de variables del bash script backup-aws-S3.sh
  3. Instalación y configuración de SSMTP
  4. Desactivar alertas automáticas de cron
  5. Envío del fichero de log a una cuenta Gmail
PowerShell
  1. Instalación y configuración de AWSCLI Windows
  2. Modificación de variables del PowerShell script backup-aws-S3.ps1
  3. Definir sintaxis de directorios
  4. Envío del fichero de log a una cuenta Gmail
  5. Llamada a fichero PowerShell .ps1 desde un fichero de proceso por lotes .bat
En mi repositorio de Gihub comento en más detalle el procedimiento a seguir.
Figura 1: Envío de logs al email de los backups en AWS en un bucket S3.

PowerShell (Windows)

# Fecha y Hora
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
$fechaActual = Get-Date -uformat "%d-%m-%Y"

# Email
$usuarioEmail = "usuarioEmail@gmail.com"
$passwdEmail = "passwdEmail"
$asuntoEmail = "asuntoEmail"

# Convertir password a un string seguro
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)

# Paths
# Compatibles en sistemas Windows: "C:/pathLocal/datos/" o "C:\\pathLocal\\datos\\"
$pathLocalDatos = "C:\\pathLocal\\datos\\"
$pathRemotoBucketS3 = "s3://bucketS3/backup/"
$backupLog = "backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if (Test-Path "*backup*.log") {
    Remove-Item -Path "*backup*.log" -Recurse -Force
    }

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
Write-Output "Backup comienza: $fechaHoraActual" > $backupLog
Write-Output "# # # # # # # # # # # # # # # # # # # #`n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

Write-Output "`n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable $fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
$fechaHoraActual = Get-Date -uformat "%d/%m/%Y - %H:%M:%S"
Write-Output "Backup finaliza: $fechaHoraActual" >> $backupLog

# Body Email
$cuerpoEmail = [system.io.file]::ReadAllText($backupLog)

# Alternativas usando Get-Content
# $cuerpoEmail = Get-Content "$backupLog" | Out-String
# $cuerpoEmail = Get-Content "$backupLog" -Raw

# Envío del fichero log adjunto vía Email usando Gmail.
Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail - $fechaHoraActual" -Body "$cuerpoEmail" -Attachments "$backupLog" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail
exit

Bash (Linux y MacOS)

# Fecha y Hora
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
fechaActual="$(date +'%d-%m-%Y')"

# Email
envioEmailCuentaUsuario="emailCuentaUsuario@gmail.com"
asuntoEmail="asuntoEmail"
cuerpoEmail="cuerpoEmail"

# Paths
pathLocalDatos="/pathLocal/datos/"
pathRemotoBucketS3="s3://bucketS3/backup/"
backupLog="backup_$fechaActual.log"

# Comprobar si existen ficheros de log pasados del backup
if [ -f "*backup*.log" ];
then
    rm -f "*backup*.log"
fi

# Mostrar fecha y hora del comienzo del proceso de backup al princpio del log
echo "Backup comienza: $fechaHoraActual" > $backupLog
echo -e "# # # # # # # # # # # # # # # # # # # #\n" >> $backupLog

# Sincronizar datos locales a bucket S3 de AWS
aws s3 sync $pathLocalDatos $pathRemotoBucketS3 --sse AES256 --delete --include "*" >> $backupLog

echo -e "\n# # # # # # # # # # # # # # # # # # # #" >> $backupLog
# Mostrar fecha y hora de la finalización del proceso de backup al final del log
# Resetear la variable fechaHoraActual para obtener la hora actual hasta este momento del proceso de backup
fechaHoraActual="$(date +'%d/%m/%Y - %H:%M:%S')"
echo "Backup finaliza: $fechaHoraActual" >> $backupLog

# Elegir una opción de envío (a o b)

# a) Envío del fichero log adjunto vía Email usando el comando mail.
echo "$cuerpoEmail" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario" -A "$backupLog"

# b) Envío del contenido del fichero log en el cuerpo del Email usando el comando mail.
cat "$backupLog" | mail -s "$asuntoEmail" "$envioEmailCuentaUsuario"
Como ya comenté anteriormente en el repositorio de Github hay más información paso a paso de como implementar esta forma de sincronizar datos locales un bucket de Amazon S3.

Saludos!

04 septiembre, 2019

WMI Explorer: Restricción de las políticas de grupo GPO con filtrado WMI y Querys en SCCM

Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un filtro WMI es un conjunto de consultas WMI (se usa el lenguaje de consulta WMI/WQL) que se puede usar para apuntar a las máquinas a las que se debe aplicar una política de grupo específica.

Por ejemplo, usando el filtro WMI GPO, puede aplicar una política vinculada a una OU solo a las máquinas que ejecutan Windows 10 (una política con dicho filtro WMI no se aplicará a las computadoras con otras versiones de Windows).

¿Para qué se utilizan los filtros WMI en las GPO?

WMI se puede usar cuando varios objetos de dominio (usuarios o equipos) se encuentran en la estructura AD plana en lugar de la unidad organizativa separada, o si se necesita aplicar políticas de grupo, de acuerdo con la versión del sistema operativo, configuración de red, software instalado o cualquier otro criterio que se pueda seleccionar usando WMI. Cuando el cliente procesa dicha política de grupo, Windows verificará el cumplimiento de la consulta WMI especificada, y si se cumplen las condiciones del filtro, la GPO se aplicará en esa máquina.

Lo más habitual en el uso de filtros WMI es distinguir sistemas operativos. Para estes casos las consultas deben hacerse en base al tipo de producto y el tipo de versión del OS.

Tipo de producto:
  • ProductType 1 = Desktop OS
  • ProductType 2 = Server OS - Domain Controller
  • ProductType 3 = Server OS - No son Domain Controller

Versiones de sistema operativo:
  • Windows Server 2019, Windows Server 2016 y Windows 10 = 10.%
  • Windows Server 2012 R2 y Windows 8.1 = 6.3%
  • Windows Server 2012 y Windows 8 = 6.2%
  • Windows Server 2008 R2 y Windows 7 = 6.1%
  • Windows Server 2008 y Windows Vista = 6.0%
  • Windows Server 2003 = 5.2%
  • Windows XP = 5.1%
  • Windows 2000 = 5.0%

Algunos ejemplos.
Windows 7
select * from Win32_OperatingSystem where Version like "6.1%" and ProductType = "1"

Windows 10
select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"

Windows Server 2016
select * from Win32_OperatingSystem where Version like "10.0%" and ProductType="3"

Windows Server 2019
select * from Win32_OperatingSystem where BuildNumber >= 17763 and ProductType="3"

En la siguiente imagen se puede ver un ejemplo de filtrado WMI de una sentencia WQL para consultar la versión de OS Windows 10.

Figura 1: Creación de filtros WMI en la Group Policy Management Console.

Después de crear el filtro WMI, elegimos el filtro WMI y lo aplicamos a una GPO existente.

Figura 2: Aplicar filtro WMI a una GPO existente.

WMI Explorer Tool y como nos puede ayudar a encontrar lo que buscamos para realizar Querys en SCCM.

Después de hacer una introducción a la restricciones en las polítcas de grupo mediante filtros WMI. En esta entrada quería dar a conecer el potencial de WMI Explorer y como nos puede ayudar para encontrar los espacios de nombres, instancias, consultas, clases, propiedades, métodos, parámetros de entrada y de salida necesarios para construir sentencias específicas WQL. Aunque también podemos disponemos de una zona de scripting para VBScript y Powershell.

WMI Explorer permite también conectarse a equipos remotos de una red de dominio que tengan el servicio WMI habilitado y permisos para la administración y acceso remoto WMI control.

En mi caso hice uso de esta herramienta para extraer los namespaces y propiedades WMI para consultas sobre el servicio DNS que posteriormente usé para realizar Queys en SCCM (System Center Configuration Manager).

Un ejemplo del resultado de una consulta WQL conectándose a un equipo remoto del dominio.

Figura 3: WMI Explorer - Ejemplo de consulta WQL en equipo remoto.

Búsqueda en una máquina local de propiedades recusivamente con el criterio "DNS".

Figura 4: WMI Explorer - Búsqueda de clases, propiedades namespaces, etc. en base un criterio de búsqueda.

Métodos encontrados en una clase concreta, parametros de entrada y parámetros de salida.

Figura 5: WMI Explorer - Resultado de clases, métodos y parámetros.
Ejecución de script VBScript o Powershell en texto o command promt en referencia a la clase y métodos encontrados.

Figura 6: WMI Explorer - Ejeción de scripting VBScript o Powershell en clases y métodos WMI.

En conclusión, es una herramienta en la que de la que se puede extraer mucha información y ayudarnos en la elaboración de consultas WQL y recolección de la información ordenada de una máquina local o remota.


Saludos!

26 agosto, 2019

Compartir recursos con Samba sin usuario y sin password entre Linux y Windows

Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de configuración de Samba.

Instalación de Samba (en el caso de distribuciones basadas en Debian).
sudo apt install samba samba-client smbfs
Creamos la carpeta que vamos a compartir. Un usuario externo que tiene acceso al equipo a través de Samba, el sistema le da como nombre de usuario nobody y como nombre de grupo nogroup, por lo que hacemos propietarios de esta carpeta a los usuarios externos.
sudo mkdir /mnt/publica
sudo chmod 777 /mnt/publica
sudo chown nobody:nogroup /mnt/publica
Editamos el fichero de configuración de Samba.
/etc/samba/smb.conf
Añadimos o modificamos las siguientes directivas. Workgroup será el nombre del grupo de trabajo (en caso de no formar parte de un entorno de dominio) y permitimos el acceso a invitados.
[global]
   workgroup = WORKGROUP
   usershare allow guests = yes
Establecemos el recurso compartido.
[NombreRecursoCompartido]
   comment = Mi recurso compartido
   path = /mnt/publica
   browseable = Yes
   writeable = Yes
   public = yes

security = SHARE
  • browseable: Atravesar y navegar entre las subcarpetas del recurso compartido.
  • writeable: Escribir en el recurso compartido.
  • public: el sinónimo de "guest ok", permite el ver y acceder al recurso comapartido de manera pública.
  • security: Por defecto suele estar comentado como ";   security = user", permite que se pueda acceder sin establecer ningún nombre de usuario.

La directiva "security" es la que realmente permita un acceso tipo invitado desde cualquier otro sistema que no sea Linux ya se Windows o MacOS.

Debe colocarse sin espacios y al final del fichero de configuración smb.conf, un salto de línea después del último recurso compartido.

Aclaro que según los desarrolladores de Samba no recomiendan el uso de esta directiva por motivos de seguridad. https://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-samba-security-modes.html.

Reiniciamos el servidor Samba para aplicar los cambios.
sudo systemctl restart samba
Hago referencia a uno de mis repositorios sobre un caso práctico de esto: https://github.com/adrianlois/RaspberryPi-samba-proftpd.

Saludos!
Entradas Relacionadas