lunes, 5 de octubre de 2020

Manipular el Puerto Origen de un Escaneo con Nmap para Tratar de Evadir el Firewall de Windows

Una configuración inadecuada sorprendentemente común, es confiar en el tráfico basándose únicamente en el número de puerto origen. Es fácil entender entonces como ocurre esto. Un administrador puede configurar un nuevo y brillante firewall, únicamente para ser inundado con reclamos de usuarios descontentos cuyas aplicaciones dejaron de funcionar. En particular DNS puede no funcionar, pues las respuestas UDP DNS desde servidores externos, no pueden ingresar hacia la red. FTP es otro ejemplo común. En las transferencias FTP, el servidor remoto intenta establecer una conexión de retorno hacia el cliente para transferir el archivo solicitado.

Las soluciones seguras a estos problemas existen, frecuentemente en la forma de un proxy a nivel de aplicación, o módulos del firewall para interpretar el protocolo. Desafortunadamente también existen soluciones más fáciles e inseguras de utilizar. Al notar una respuesta DNS proviene desde el puerto 53, y un FTP activo desde un puerto 20, muchos administrador caen en la trampa de simplemente permitir conexiones entrantes desde estos puertos. Pues frecuentemente asumen ningún atacante notará y explotará tal agujero en el firewall. En otros casos, los administradores consideran esto una medida provisional a corto plazo, hasta puedan implementar un solución más segura. Luego olvidan esta actualización de seguridad.

Administradores de red con exceso de trabajo no son los únicos quienes caen en esta trampa. Numerosos productos son entregados con estas reglas inseguras. Incluso Microsoft ha sido culpable. Los filtros IPsec entregados con Windows 2000 y Windows XP, contienen reglas explícitas permitiendo tráfico TCP y UDP desde un puerto 88 (kerberos). Los fanáticos de Apple no deberían sentirse demasiado satisfecho sobre esto, pues el firewall entregado con Mac OS X Tiger es igual de malo. Jay Beale descubrió incluso si no se tiene habilitado el recuadro “Block UDP Traffic” o Bloquear Tráfico UDP en la GUI del firewall, los paquetes proviniendo del puerto 67 (DHCP) y 5353 (Zeroconf) pasan correctamente. Otro ejemplo patético de esta configuración, es el firewall personal Zone Alarm (versiones hasta 2.1.25), permiten cualquier paquete UDP entrante con el puerto origen 53 (DNS) o 67 (DHCP).

Nmap ofrece las opciones “-g” y “--source-port” (son equivalentes) para explotar estas debilidades. Simplemente se debe proporcionar un número de puerto, y Nmap enviará los paquetes desde este puerto cuando sea posible. Nmap debe usar diferentes números de puertos, para las pruebas de detección del sistema operativo funcionen adecuadamente. La mayoría de escaneos TCP, incluyendo el escaneo SYN, soportan completamente la opción, así como el escaneo UDP.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

En primera instancia se ejecuta un “SYN Scan” contra el host.
root@kali:~# nmap -n -Pn -v 192.168.0.92
Notar como únicamente se reportan en estado abierto los puertos TCP, 80, 443, 49155, 49156, y 40159.

A continuación se realiza un “SYN Scan” contra el mismo host, pero definiendo al puerto TCP 53 como origen del escaneo.

root@kali:~# nmap -n -Pn -v --source-port 53 192.168.0.92
En los resultados obtenidos ahora se incluye; además de los puertos descubiertos con el anterior escaneo realizado; al puerto TCP 53 descubierto en estado abierto.

Fuentes:https://nmap.org/book/firewall-subversion.html

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.

domingo, 7 de junio de 2020

docker-onion-nmap o cómo escanear servicios .onion de la red Tor

docker-onion-nmap de Miles Richardson es un contenedor docker que permite escanear servicios "onion" de la red Tor. La imagen está basada en Alpine y utiliza proxychains para "wrappear" nmap. Tor y dnsmasq se ejecutan como demonio vía s6 y, como comentamos, se usa proxychains para que los escaneos de nmap vayan por el proxy SOCK de Tor en el puerto 9050. 



Además también se configura Tor a través de DNSPort para resolver anónimamente las solicitudes DNS sobre el puerto 9053, en el que dnsmasq actúa como servidor DNS de autoridad (authority.) Luego Proxychains está configurado para proxy DNS a través de la resolución local, por lo que todas las solicitudes DNS pasarán por Tor y las aplicaciones pueden resolver las direcciones .onion.

Ejemplo:
$ docker run --rm -it milesrichardson/onion-nmap -p 80,443 forohpysho2t5mjs.onion
[tor_wait] Wait for Tor to boot... (might take a while)
[tor_wait] Done. Tor booted.
[nmap onion] nmap -p 80,443 forohpysho2t5mjs.onion
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12

Starting Nmap 7.60 ( https://nmap.org ) at 2017-11-14 11:01 UTC
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:80  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:443 <--denied br="">RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Nmap scan report for forohpysho2t5mjs.onion (224.0.0.1)
Host is up (7.1s latency).

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 10.32 seconds

Uso:

Cuando el contenedor docker se inicia ejecuta Tor y dnsmasq como demonios. Después el script 'tor_wait' espera a que el proxy Tor SOCKS esté activo antes de ejecutar su comando. Por defecto, se pasan los argumentos nmap -sT -PN -n "$@", necesarios para funcionar sobre Tor (vía explainshell.com).

Por ejemplo, esto:

docker run --rm -it milesrichardson/onion-nmap -p 80,443 forohpysho2t5mjs.onion

será ejecutado como:

proxychains4 -f /etc/proxychains.conf /usr/bin/nmap -sT -PN -n -p 80,443 forohpysho2t5mjs.onion

Además del script personalizado para nmap, existen scripts de wrapping personalizados para curl y nc para usarlos a través de cadenas de proxy, en /bin/curl y /bin/nc. Para llamarlos, simplemente hay que especificar curl o nc como el primer argumento al ejecutar Docker. Por ejemplo:

docker run --rm -it milesrichardson/onion-nmap nc -z 80 forohpysho2t5mjs.onionn

Será ejecutado como:

proxychains4 -f /etc/proxychains.conf /usr/bin/nc -z 80 forohpysho2t5mjs.onion

y:

docker run --rm -it milesrichardson/onion-nmap curl -I https://forohpysho2t5mjs.onion

será ejecutado como:

proxychains4 -f /etc/proxychains.conf /usr/bin/curl -I https://forohpysho2t5mjs.onionn

Si queremos llamar a cualquier otro comando, incluido el /usr/bin/nmap original o /usr/bin/nc o /usr/bin/curl, podemos especificarlo también como el primer argumento para ejecutar docker, por ejemplo:

docker run --rm -it milesrichardson/onion-nmap /usr/bin/curl -x socks4h://localhost:9050 https://forohpysho2t5mjs.onion

Variables de entorno

Solo hay una variable de entorno: DEBUG_LEVEL. Si seteamos a "1", mostrará más información de depuración. Ejemplo:
$ docker run -e DEBUG_LEVEL=1 --rm -it milesrichardson/onion-nmap -p 80,443 forohpysho2t5mjs.onion
[tor_wait] Wait for Tor to boot... (might take a while)
[tor_wait retry 0] Check socket is open on localhost:9050...
[tor_wait retry 0] Socket OPEN on localhost:9050
[tor_wait retry 0] Check SOCKS proxy is up on localhost:9050 (timeout 2 )...
[tor_wait retry 0] SOCKS proxy DOWN on localhost:9050, try again...
[tor_wait retry 1] Check socket is open on localhost:9050...
[tor_wait retry 1] Socket OPEN on localhost:9050
[tor_wait retry 1] Check SOCKS proxy is up on localhost:9050 (timeout 4 )...
[tor_wait retry 1] SOCKS proxy DOWN on localhost:9050, try again...
[tor_wait retry 2] Check socket is open on localhost:9050...
[tor_wait retry 2] Socket OPEN on localhost:9050
[tor_wait retry 2] Check SOCKS proxy is up on localhost:9050 (timeout 6 )...
[tor_wait retry 2] SOCKS proxy UP on localhost:9050
[tor_wait] Done. Tor booted.
[nmap onion] nmap -p 80,443 forohpysho2t5mjs.onion
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12

Starting Nmap 7.60 ( https://nmap.org ) at 2017-10-23 16:34 UTC
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:443  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:80  ...  OK
Nmap scan report for forohpysho2t5mjs.onion (224.0.0.1)
Host is up (2.8s latency).

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.05 seconds

Notas

- NO se puede usar UDP en Tor
- Tor puede tardar 10-20 segundos en arrancar. Si esto es posible, otra opción es ejecutar el proxy en su propio contenedor, o ejecutarlo como el proceso principal y luego ejecutar "exec" para llamar comandos como nmap.

Proyecto: https://github.com/milesrichardson/docker-onion-nmap

 

CLOWN SAW