A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotear” conexiones desde Meterpreter por medio de route es el tipo de herramientas que podemos usar a través del pívot. Esto es debido a que cualquier herramienta que use raw sockets no funcionará a través del túnel, estando limitados a conexiones TCP y UDP que realicen una “conexión completa” (connected sockets). En el caso de Nmap, por ejemplo, implica que únicamente podemos realizar escaneos de tipo TCP connect (-sT) por medio de socks4 y proxychains, pero será inútil utilizar switches como -sS (syn scan), -O (OS detection) o similares. Aunque otra opción es utilizar portforwarding (portfwd) mediante el cual mapear puertos locales con los de la víctima, estamos limitados a conexiones TCP, por lo que esto también reduce opciones a la hora de elegir herramientas que empleen UDP. En nuestro caso lo que haremos será preparar un entorno que nos ayude a “forwardear” peticiones DNS desde herramientas que hagan uso de UDP (nmap, dnsenum, etc) a través de Meterpreter.
Para ello configuraremos un Proxy DNS que intercepte peticiones DNS UDP y las redirija, en su “versión TCP”, al puerto configurado con portfwd. Ya que la mayoría de servidores DNS soportan TCP, no solamente para realizar transferencias de zona, sino para aceptar también queries en el puerto 53 (así lo especifica el protocolo DNS), podremos realizar consultas DNS con prácticamente cualquier herramienta. Lógicamente clientes DNS que empleen o soporten TCP (ej: dig +tcp) no requerirán de dicho Proxy y podrán lanzarse directamente a través de Meterpreter Lo mismo ocurre con clientes DNS que usen UDP y que utilizen la API adecuada, en cuyo caso podrá redirigir paquetes a través de Meterpreter utilizando route.
Partamos del siguiente escenario. Conseguimos una sesión de Meterpreter en el equipo víctima con IP 192.168.100.1/24, y queremos hacer un Reverse Dns Lookup de dicha red preguntando directamente al servidor DNS interno (192.168.100.10) con el objetivo de obtener nombres de máquinas sugerentes a los que posteriormente podamos escalar el ataque. De forma gráfica podemos verlo de la siguiente forma:
Empezaremos configurando nuestro proxy DNS. En nuestro caso usaremos el proxy caché pdnsd por su facilidad de configuración e instalación. Únicamente necesitaremos modificar el fichero /etc/init.d/pdnsd con las siguientes directivas:
global {
perm_cache=1024;
cache_dir="/var/cache/pdnsd";
run_as="pdnsd";
server_ip = 127.0.0.1; // Use eth0 here if you want to allow other
// machines on your network to query pdnsd.
status_ctl = on;
paranoid=on;
query_method=tcp_only; // pdnsd must be compiled with tcp
// query support for this to work.
min_ttl=15m; // Retain cached entries at least 15 minutes.
max_ttl=1w; // One week.
Timeout=10; // Global timeout option (10 seconds).
// Don't enable if you don't recurse yourself, can lead to problems
// delegation_only="com","net";
}
/* with status_ctl=on and resolvconf installed, this will work out from the box
this is the recommended setup for mobile machines */
server {
label="resolvconf";
ip=127.0.0.1;
port=7777;
timeout=4;
interface=eth0;
interval=19m;
purge_cache=off;
}Tras guardar el fichero actualizamos los cambios en pdnsd mediante:
root@bt:~# pdnsd-ctl config /etc/pdnsd.conf Opening socket /var/cache/pdnsd/pdnsd.status Succeeded
Lo que hemos hecho es configurar un daemon DNS (pdnsd) en 127.0.0.1:53 que escuchará y reenviará peticiones DNS al socket 127.0.0.1:7777, que será donde configuraremos el forwarding con Meterpreter. La directiva query_method=tcp_only obligará a utilizar queries TCP; otras opciones son tcp_udp donde intentaría primero con tcp y en caso de vencer el timeout con udp, udp_tcp y udp_only. El siguiente paso es configurar el port forwarding desde Meterpreter:
meterpreter > portfwd add -l 7777 -L 127.0.0.1 -r 192.168.100.10 -p 53 [*] Local TCP relay created: 127.0.0.1:7777 < -> 192.168.100.10:53 meterpreter > portfwd list 0: 127.0.0.1:7777 -> 192.168.100.10:53
Nos aseguramos que nuestros daemons están escuchando correctamente:
root@bt:~# netstat -putna | grep ":53\|:7777" tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 13717/pdnsd tcp 0 0 127.0.0.1:7777 0.0.0.0:* LISTEN 1533/.ruby.bin udp 0 0 127.0.0.1:53 0.0.0.0:* 13717/pdnsd root@bt:~#
Y por último ya podemos lanzar consultas DNS con nmap (list scan) apuntando a localhost:
root@bt:~# nmap -sL 192.168.100.1-254 --dns-servers 127.0.0.1 | grep -i domainowned
Nmap scan report for rat.internal.pro.domainowned.es (192.168.100.1)
Nmap scan report for ftp.pro.domainowned.es (192.168.100.2)
Nmap scan report for felix.internal.pro.domainowned.es (192.168.100.8)
Nmap scan report for dns.internal.pro.domainowned.es (192.168.100.10)
Nmap scan report for calipso.lab.pre.domainowned.es (192.168.100.12)
Nmap scan report for ficheros.internal.pro.domainowned.es (192.168.100.13)
Nmap scan report for repo.lab.pre.domainowned.es (192.168.100.15)En el caso de no usar –dns-servers tendríamos que apuntar a localhost desde /etc/resolv.conf. También podemos usar otras tools dentro de /pentest/enumeration/dns o directamente realizar consultas a mano con un poco de bash:
root@bt:~# for ip in 192.168.100.{1..254}; do ( host $ip 127.0.0.1) done |
grep domainowned | cut -d" " -f1,5
1.100.168.192.in-addr.arpa rat.internal.pro.domainowned.es.
2.100.168.192.in-addr.arpa ftp.pro.domainowned.es.
8.100.168.192.in-addr.arpa felix.internal.pro.domainowned.es.
10.100.168.192.in-addr.arpa dns.internal.pro.domainowned.es.
12.100.168.192.in-addr.arpa calipso.lab.pre.domainowned.es.
13.100.168.192.in-addr.arpa ficheros.internal.pro.domainowned.es.Aunque Metasploit ya contiene módulos y scripts que nos permiten hacer queries DNS (ej: netenum de Carlos Perez) puede que en ciertos entornos, donde necesitamos afinar o ajustar en mayor medida consultas DNS, resulte práctico y rápido implementar dicho proxy con el cual utilizar nuestras propias herramientas.
출처 : http://hi.baidu.com/p3rlish/
댓글