Las posibilidades que ofrece Meterpreter a la hora de desarrollar módulos de post-explotación son prácticamente ilimitadas. Véanse a modo de ejemplo los módulos NBDServer.rb y Imager.rb desarrollados por R. Wesley McGrew y presentados en la Defcon 19 bajo el título “Covert Post-Exploitation Forensics With Metasploit“.

Dicho módulos permiten hacer una copia byte a byte de volúmenes físicos y unidades lógicas del equipo comprometido a través de la red; o bien montar el sistema de ficheros de dichas unidades en el equipo del atacante como si fuera un simple dispositivo más. No hace falta mencionar las posibilidades desde el punto de vista forense que ofrecen este tipo de módulos.

Gran parte de esta flexibilidad para llevar todo tipo de tareas desde una shell con Meterpreter la ofrece la extensión railgun al permitirnos cargar en runtime librerías de Windows y hacer uso de sus funciones. Al tener acceso íntegro a toda la API de Windows, las opciones de post-explotación son prácticamente inagotables.

Como aportación a la lista de módulos de post explotación forense, he desarrollado un módulo para poder recuperar ficheros eliminados desde sistemas de ficheros NTFS. De esta forma no solo podremos conseguir ficheros “existentes” en el equipo comprometido si no obtener también ficheros “eliminados” de forma insegura (en ocasiones, los más interesantes).

La idea del módulo es recorrer cada una de las entradas de la $MFT (Master File Table) e ir listando los ficheros eliminados. A medida que muestra los ficheros, añadirá un ID asociado a cada uno de ellos, el cual representará el offset de la entrada MFT de dicho fichero en disco (no es más que el número de bytes lógico a partir del cual se encuentra dicha entrada). Si posteriormente deseamos recuperar un determinado fichero especificaremos la variable FILES con dicho ID. De esta forma el módulo podrá leer la entrada correspondiente para extraer los dataruns asociados y poder así recuperar su contenido. En el caso de que el fichero sea residente extraerá directamente su contenido de la propia $MFT. A continuación un ejemplo de su uso:

Como vemos, si no especificamos la variable FILES, el módulo únicamente listará ficheros eliminados. Posteriormente, para recuperar los ficheros deseados especificamos sus IDs separados por comas. Tras ejecutar el módulo conseguiremos bajar los ficheros a nuestro loot.

Otra opción para conseguir ficheros sin necesidad de especificar su ID es mediante su extensión. Si estamos interesados únicamente en cierto tipo de ficheros podemos asignar a FILES las extensiones deseadas. Véase el siguiente ejemplo:

Téngase en cuenta que el módulo extraerá el contenido de cada uno de los clusters asociados a dicho fichero. Ya que el fichero está eliminado puede que su contenido haya sido sobreescrito o parcialmente sobreescrito por lo que es probable que consigamos un fichero corrupto (el cual puede ser interesante igualmente desde un punto de vista forense).

Es importante destacar también que el proceso de listar ficheros eliminados en un disco duro de gran tamaño (mejor dicho, con muchas entradas en su MFT) puede ser extremadamente lento; en mis pruebas alrededor de 8-10 entradas por segundo. Debido a esto, con la variable TIMEOUT podremos especificar el número de segundos que invertirá el módulo en buscar ficheros eliminados (por defecto una hora).

En el siguiente vídeo puede verse un ejemplo de su uso:

Durante la fase de post-explotación en una intrusión, tras conseguir una shell en un equipo, uno de los pasos para seguir ganando acceso a otras máquinas o dispositivos de networking es esnifar tráfico. Simplemente escuchando el tráfico que pasa por dicha máquina, aunque la misma se encuentre en un entorno conmutado, puede darnos información muy útil sobre la topología de red en la que se encuentra o las posibles vulnerabilidades que podremos explotar más adelante: nombres netbios, users/passwords en claro, paquetes ARP, CDP, DHCP, HSRP, VRRP, etc.

Para escuchar tráfico desde una shell, sin embargo, tendremos que hacer uso de herramientas externas que deberemos descargar y ejecutar en el equipo comprometido. Una buena elección es rawcap la cual permite capturar paquetes sin apoyarse en drivers de captura como WinPcap (librería libpcap para Windows utilizada por multitud de herramientas de análisis de tráfico).

Otra opción es utilizar Meterpreter desde donde podremos apoyarnos en módulos de captura sin necesidad de tocar disco. Meterpreter cuenta para ello con la extensión sniffer o el módulo packetrecorder de @Carlos_Perez aka Darkoperator, los cuales permiten generar y guardar en local el fichero pcap con el tráfico capturado.

Como una alternativa más a estas dos opciones, he creado un pequeño módulo (rpcapd_start) que permite activar el servicio rpcapd para poder capturar tráfico remotamente. No es extraño encontrarse con equipos de usuario, incluso servidores Windows, que tengan instalado WinPcap así que, que mejor forma de obtener tráfico que utilizando dicho servicio de forma remota. Como ventaja adicional no dependeremos de la sesión de meterpreter, ya que una vez activado, podremos capturar tráfico con cualquier software que soporte rpcap.

La instalación de WinPcap creará un nuevo servicio llamado rpcapd aunque el mismo se encuentra inactivo por defecto.

El módulo únicamente activará rpcapd, especificando el puerto y el modo de funcionamiento (activo o pasivo). Podremos elegir también si queremos autenticación o no.

Ya que lo más probable es que el equipo esté nateado tras un router o firewall, en la práctica, el modo más útil será el activo, en donde la máquina comprometida será la que se conecte a nosotros.

Tras levantar el servicio y en el caso de utilizar una conexión pasiva (como en el ejemplo) se añadirá una nueva regla en el Firewall de Windows bajo el nombre “Windows Service” para permitir el tráfico entrante.

Posteriormente podremos conectarnos a la máquina desde cualquier herramienta que soporte rpcap y empezar a capturar tráfico.

El módulo está ya incluido en Metasploit así que bastará con actualizarlo para su descarga

Cuando empecé a utilizar Metasploit —hace ya unos cuantos años— era bastante caótico para mi auditar una red en busca de vulnerabilidades o información relevante. No seguía una metodología determinada para llevar a cabo las fases de discovering, reconnaissance, exploitation, etc., si no que me dejaba llevar un poco por la intuición. A la larga, esto significa pérdida de tiempo y muchas veces grandes dolores de cabeza por haber obviado algún paso, olvidado algún servicio, ignorado cierta información, etc., con la que podría haber encontrado alguna vulnerabilidad mucho antes.

Metasploit es una maravilla para hacer auditorias, pero también una locura (debido al elevado número de módulos) si no sigues unas pautas en cierto orden y dedicas gran tiempo a la fase de information gathering.

La idea de esta entrada es mostrar cómo es posible automatizar algunas de estas tareas ahorrándonos mucho tiempo y garantizando seguir siempre una misma metodología sin olvidar ningún paso.

[Read more…]

A raíz del post de @chemaalonso sobre la herramienta DHCP Ack Inyector, recordé mis años en la universidad (allá por el 2005) donde ibas a la biblioteca, conectabas tu portátil y simplemente escuchando tráfico veías multitud de protocolos vulnerables o incorrectamente configurados como STP, HSRP, DTP, etc.

No solo eso, sino que no había ningún tipo de control sobre el tipo de datos que los usuarios podían enviar, por lo que, utilizando herramientas como Gobbler, dsniff, ettercap, yersinia, etc., podías llevar todo tipo de ataques man-in-the-middle. Lo curioso de todo era que la mayoría de los dispositivos de networking utilizados para gestionar todo el tráfico eran Cisco. Es decir, dispositivos más que suficientes para poder controlar y mitigar prácticamente la mayoría de esos ataques. Simplemente estaban configurados para cumplir con funciones básicas de red: enrutar tráfico, administrar VLANS, ACL, QoS, etc., pero o bien por desconocimiento o por descuido, no se les estaba sacado el provecho que realmente justificaría su adquisición.

Con el paso del tiempo me he dado cuenta de que este tipo de situación es bastante frecuente: es realmente difícil encontrar una empresa que tenga en cuenta políticas de configuración estrictas para asegurar un entorno local. Personalmente pienso que muchas organizaciones no son conscientes del daño que podría hacer un empleado descontento en un entorno local “poco controlado”. Sin llegar a utilizar herramientas sofisticadas como Loki o Yersinia, es posible desde tirar toda una red con apenas un par de paquetes y con ayuda de Scapy, hasta hacer MitM usando ARP / DHCP / VRRP / HSRP o hasta cosas mas entretenidas como conseguir un pool de shells sin mucho esfuerzo con el browser_autopwn de Metasploit y etterfilters.

[Read more…]

(N.d.E. A partir de ahora, y debido al volumen y calidad de las colaboraciones de Borja Merino, pueden encontrar todas sus entradas, futuras y pasadas, en el menú de autores ubicado en el lateral de la derecha.)

Una de las herramientas más utilizadas para analizar e identificar posibles shellcodes es libemu. La idea de esta librería, escrita en C e implementada en frameworks como Dionaea —de la que por cierto ya hablamos en el blog aquí y aquí— o PhoneyC, es emular instrucciones x86 e identificar/hookear llamadas a la API de Windows, con la que poder obtener información suficiente del código sin necesidad de llevar un análisis exhaustivo con debbugers como Inmunity u Olly.

Libemu utiliza técnicas heurísticas GetPC (Get Program Counter) para localizar shellcodes que utilizan encoders como shikata ga nai, fnstenv_mov, etc. Raro es encontrarse payloads que no utilicen algún tipo de cifrado o encoder para intentar evadir IDS/AV, por lo que esta característica lo hace realmente útil para buscar posibles shellcodes en ficheros .pcap, exploits, pdf, etc. Entender cómo funcionan estos métodos GetPC será fundamental para entender exactamente cómo trabaja libemu y saber así también cuáles son sus limitaciones y porque es incapaz de detectar determinados shellcodes. Los métodos GetPC (que vagamente se explicaron en el post “Buscando buffer overflow desde Wireshark” ) son simplemente instrucciones que ayudan a nuestro código a localizarse a si mismo dentro del espacio de direcciones del proceso. Esto es importante si lo que queremos es que nuestro código sea portable y que no dependa de direcciones ‘hardcodeadas’ (por ejemplo, cuando escribimos exploits y desconocemos en qué dirección de memoria se va a alojar nuestro payload).

[Read more…]

Estos días he estado jugando un poco con Cymothoa. Para quien no lo conozca, esta herramienta te permite inyectar un payload dentro del espacio de direcciones de un proceso, o dicho de otro modo, troyanizar un proceso en Linux. Cymothoa está desarrollada en C y se encuentra disponible en Backtrack 5 dentro de /pentest/backdoors/cymothoa. (N.d.E. A su derecha pueden observar una imagen de una Cymothoa Exigua, un parásito que se adhiere a la lengua de determinados peces, la atrofia y acaba por reemplazarla por sí mismo, como si fuese un órgano más. Si tienen curiosidad, gogleen y verán que bicho tan interesante.)

Al no encontrar mucha información sobre su funcionamiento estuve indagando un poco sobre el código para ver exactamente como trabaja. La idea de esta herramienta es sobrescribir directamente el base address de alguna de las librerías utilizadas por el proceso, siendo por defecto el “dynamic linker/loader” (/libr/ld*.so). Los payloads utilizados por Cymothoa están embebidos en el propio binario y pueden verse con el parámetro -S aunque, como veremos a continuación, podremos incorporar los nuestros sin mucho esfuerzo:

[Read more…]

Uno de los operadores que más me gusta a la hora de definir filtros con Wireshark es “matches“. Con este operador podremos extender las limitaciones que nos ofrece el resto de filtros a la hora de localizar determinados patrones en nuestros ficheros pcap. De forma parecida a “contains”, el operador “matches” nos permite buscar por determinadas cadenas de texto así como bytes con la ventaja adicional de soportar PCRE (Perl-compatible regular expression). Este operador será realmente útil a la hora de buscar gran variedad de ataques como DDOS, fuzzing, opcodes que coincidan con ciertos patrones de malware conocido, o, como veremos a continuación, exploits que se aprovechan de un stack/heap overflow.

Aunque obviamente Wireshark no es la herramienta más apropiada para detectar BO, en ocasiones en las que no tengamos a mano un Snort o los GSoC plugins vistos en la entrada anterior de Maite y nos enfrentemos a un .pcap de gran tamaño, disponer de macros que identifiquen ataques de este tipo puede ayudarnos enormemente en nuestra labor forense.

Los siguientes ejemplos representan el esqueleto típico de un buffer overflow, bien aprovechándose del RET address o del SEH (Structured Exception Handling):

payload = junk + eip + egghunter + nops + egg + shellcode
payload = string + buffer + egg + shellcode + eip + nops + egghunter
payload = junk + egg + shellcode + eip + nops + egghunter
payload = junk + eip + nops + shellcode
payload = junk + egg + shellcode + junk1 + nseh + seh + nops + egghunter + junk2
payload = nops + shellcode + nops + eip + nops + farjump + nops
payload = junk + nseh + seh + nops + shellcode + junk1

Teniendo en cuenta estos ejemplos, podríamos definir un filtro que busque por paquetes que contengan un string largo (junk) formado por 0x4141414141, 0x9090909090 (NOPs) o similares e ir jugando con diferentes longitudes de cadena. Por ejemplo:

Podemos omitir \\1 si lo que buscamos son cadenas alfanuméricas de gran longitud comúnmente empleadas por herramientas de fuzzing o por scripts para calcular el offset del return address como la generada por pattern_create.rb (Aa0Aa1Aa2Aa3A…c1Ac2Ac3Ac4A….). Puesto que dicho filtro puede generar numerosos falsos positivos podemos ir un poco más allá:

En este caso buscaríamos un buffer superior o igual a 100 seguido de lo que sea (.*), seguido de w00tw00t (generalmente utilizado como egg para definir el comienzo del shellcode) o seguido del propio código del egghunter (12 primeros bytes). Los siguientes opcodes \xeb\.\x90\x90 y \x90\x90\xeb. suelen utilizarse cuando lo que está sobrescribiendo es algún campo nSEH dentro de la cadena SEH (chain SEH). Generalmente el registro SEH será sobrescrito por alguna instrucción que permita saltar al campo nSEH (situado justamente detrás).

Dependiendo de donde se encuentre el shellcode (bien delante o bien detrás de la estructura SEH) será necesario hacer un salto positivo o negativo, de ahí que únicamente se especifique el opcode EB (short jump) sin especificar que tipo de salto y cuantos bytes se desean saltar. Al final, también se busca por opcodes x61 (popad) consecutivos, utilizados también como recurso para desplazar el registro ESP hasta el shellcode. En el siguiente ejemplo se muestra un intento de BO contra un servidor HTTP utilizando la cabecera HEAD.

Veamos otro ejemplo. En este caso crearemos un filtro que detecte un BO que utiliza un shellcode o egghunter codificado con x86/alpha_upper. Al igual que otros encoders, alpha_upper es relocalizable en memoria. Esto significa que es capaz de obtener la dirección base absoluta de su propio código, lo que le permite ejecutarse independientemente de su posición en memoria. Para poder obtener la dirección absoluta de memoria utiliza instrucciones FPU (Floating Point) junto a FSTENV.

Cuando se emplea esta técnica como GetPC (Get Program Counter), se suele utilizar una instrucción de coma flotante al inicio del decoder junto a la instrucción FSTENV PTR SS: [ESP-C] encargada de almacenar el entorno FPU en memoria. De esta forma se consigue cargar la dirección de la primera instrucción en el stack para posteriormente descargarla en algún registro (ver figura 4). Utilizando un offset realativo a esta dirección, podrá empezar a decodificar el resto del payload. Teniendo en cuenta este comportamiento, si nos fijamos en la forma que toman los payloads generados por msfencode pueden observarse ciertos patrones comunes en los primeros opcodes:

Los opcodes d9, da, db y dd forman parte de instrucciones FPU como FXCH, FFREE, FCMOVU mientras que los opcodes \xd9\x74\x24\xf4 representan FSTENV PTR SS: [ESP-C]. En el primer caso, se usa una instrucción mov, seguido de una instrucción FPU seguido de FSTENV. Puesto que el payload generado tiende a seguir alguna de estas secuencias podríamos general el siguiente filtro:

Nota: fíjese que algunos de los opcodes del principio del decoder no son alpha uppercase, es decir, están fuera del rango [\x41-\x5A,\x30-\x39]; por este motivo se especifica [.] (cualquier byte).

En el siguiente caso se muestra la vista “Follow TCP Stream” de un paquete que ha ‘matcheado’ dicho filtro. La salida muestra un intento de explotación contra un server FTP (Filezilla) en el que se utiliza un payload codificado con alpha_upper y que trata de aprovecharse del parámetro PASS.

Si quisiéramos llevar este payload a Inmunity Debugger para una análisis más exhaustivo necesitamos eliminar espacios y añadir únicamente los opcodes.

Con este output y mediante la opción binary copy ya podemos pegar y empezar a analizar el código.

Para no tener que escribir el todas las expresiones regulares cada vez que arranquemos Wireshark, podemos guardarlas desde el menú Analyze -> Display Filters.

Obviamente las formas que puede tomar un BO son muy dispares y el uso de encoders más polimórficos como shikata_ga_nai dificultarán enormemente la localización de este tipo exploits mediante firmas estáticas. El objetivo únicamente es mostrar la flexibilidad que nos proporciona “matches” gracias a PCRE para localizar gran variedad de ataques como los vistos anteriormente siempre y cuando sigan algún patrón conocido. Por ejemplo, en el análisis llevado a cabo por McAfee sobre Aurora se indicaba como el backdoor iniciaba una conexión con el puerto 443 del C&C enviando siempre un paquete con la misma secuencia: ff ff ff ff ff ff 00 00 fe ff ff ff ff ff ff ff ff ff 88 ff. Con este dato podríamos definir un filtro en busca de paquetes que utilicen dicho payload sin necesidad de utilizar un IDS como Snort o esperar a que se actualicen sus reglas.

Para acabar, indicar que actualmente el operador “matches” presenta algunos problemas cuando se emplean metacaracteres y dígitos en hexadecimal con 2 letras. Si se necesita ‘matchear’ secuencias que contengan dichos bytes es necesario parchear epan/ftypes/ftype-pcre.c activando el flag G_REGEX_RAW. También me he encontrado con problemas a la hora de crear macros con dicho operador, algo que sería bastante útil para poder especificar como parámetro la longitud del buffer. Es decir, el filtro $buffer{200} para la macro tcp matches “([\x41-\x5A,\x30-\x39,\x90]){$1}” no funcionará cuando se empleen secuencias de bytes.

Después de darle un pequeño repaso a VRRP, partimos del siguiente escenario. Nos encontramos en una LAN con un grupo VRRP formado por dos routers (A y B) con IP virtual 192.168.1.100. Como vemos en la salida el router A (configurado como Master) tiene una prioridad de 150 y una IP local de 192.168.1.5. En caso de caída, el router B tras un tiempo Master_Down_Timer, asumirá el rol de Maestro (Preemption enabled).

RouterA#show  vrrp                                                           
FastEthernet0 - Group 1                                                         
  State is Master                                                               
  Virtual IP address is 192.168.1.100                                           
  Virtual MAC address is 0000.5e00.0101                                         
  Advertisement interval is 1.000 sec                                           
  Preemption enabled                                                            
  Priority is 150                                                               
  Master Router is 192.168.1.5 (local), priority is 150                        
  Master Advertisement interval is 1.000 sec                                    
  Master Down interval is 3.414 sec      

RouterB#show  vrrp         
FastEthernet0 - Group 1                                                         
  State is Backup                                                               
  Virtual IP address is 192.168.1.100                                          
  Virtual MAC address is 0000.5e00.0101                                         
  Advertisement interval is 1.000 sec                                           
  Preemption enabled                                                            
  Priority is 100                                                               
  Master Router is 192.168.1.5, priority is 150                                 
  Master Advertisement interval is 1.000 sec                                    
  Master Down interval is 3.609 sec (expires in 3.533 sec)

[Read more…]

A día de hoy sería extraño no encontrarse con configuraciones HSRP (Hot Standby Router Protocol), GLBP (Gateway Load Balancing Protocol) o VRRP (Virtual Router Redundancy Protocol) en organizaciones de pequeño/gran tamaño y más aún en entornos críticos donde prima la disponibilidad. El motivo es evidente: la mayor parte de los equipos son configurados con un Gateway estático generalmente obtenido por medio de DHCP. En caso de que dicho Gateway deje de funcionar implicaría la pérdida de paquetes hasta que el mismo se restableciera o bien hasta que otro Gateway fuera configurado en cada uno de los equipos. Aunque existen métodos para permitir una configuración dinámica del Gateway (proxy Arp, protocolos de routing RIP/OSPF, “ICMP router discovery protocol”, etc.) estos implican una configuración más “compleja” además de producir cierto overhead en la red. Por este motivo es por el que surgieron protocolos como HSRP, GLBP o VRRP, siendo este último la versión no propietaria de los protocolos desarrollados por Cisco.

La idea de VRRP es agrupar un conjunto de routers bajo una misma IP/MAC Virtual de forma que dicho grupo sea totalmente transparente de la configuración del cliente. En este grupo, solo uno de los routers (Master Virtual Router) será el encargado de enrutar paquetes a su destino mientras que el resto correrán a modo de backup monitorizando el estado del Maestro para, en caso de caída o fallo, ser suplantado por aquel que presente mayor prioridad, proporcionando así redundancia con un delay mínimo (el tiempo de convergencia suele ser inferior a un segundo).

Toda esta lógica implica el intercambio de una serie de advertisements que conforman el protocolo VRRP y que serán totalmente transparentes a la configuración de los clientes donde únicamente tendrá que especificarse la IP virtual del router. Estos advertisements comunican el estado así como la prioridad del router maestro y son encapsulados en paquetes IP que se envían a la dirección multicast 224.0.0.18.

Aparte de proporcionar redundancia, VRRP suele ser desplegado para proporcionar balanceo de carga entre varios routers. Para ello, se configuran varios routers virtuales los cuales son configurados como Gateway para diversos grupos de máquinas. De esta forma podremos distribuir la carga de tráfico entre todos los routers virtuales además de proporcionar redundancia en caso de que alguno de ellos deje de responder. Pueden ver más información al respecto en este enlace de Cisco.

Como se comentó anteriormente las prioridades asignadas a cada router jugarán un papel importante a la hora de determinar quién asumirá el rol de Master en caso de que éste no responda durante un tiempo preestablecido (Master_Down_Timer) y donde a mayor prioridad mayor será la preferencia en elegir al nuevo maestro. El RFC correspondiente establece que a los backups se les asignara una prioridad de 1 a 254 determinando así el orden de asignación cuando el Master deje de sondear paquetes.

En el caso del router Master, éste debe tener una prioridad de 255 cuando dicho router sea configurado con la misma IP que la asignada al router Virtual (y al que se denominará “IP Address Owner”) . Es importante tener esto en cuenta ya que en este caso siempre será el router maestro independientemente del valor Preempt_Mode asignado. Pueden ver más información al respecto en este enlace de Cisco.

El router maestro será por tanto el responsable de hacer forwarding de aquellos paquetes cuya capa de enlace tengan como MAC destino la MAC del router virtual (00-00-5E-00-01-{VRID}). Además, será el encargado de responder a peticiones ARP que pregunten por la IP virtual asegurando así que los clientes sepan cómo alcanzar el router virtual.

VRRP dispone de varios mecanismos de seguridad para a) asegurar que no sea posible inyectar paquetes en un entorno VRRP desde una red externa (esto lo consigue fijando un valor TTL 255 en los advertisements y descartando aquellos con un valor inferior) y b) autenticar que los paquetes de configuración VRRP proceden de routers legítimos. En este último caso, para asegurar la autenticación es posible:

a) No usar autenticación :)
b) Configurar un password en claro.
c) “IP Authentication Header” mediante MD5.

Hechas las pertinentes presentaciones y puestos en materia, en la entrada siguiente veremos cómo aprovecharnos y explotar una configuración VRRP desatendida en donde se ha configurado alguno de los 2 primeros métodos de autenticación. En lugar de utilizar Loki o Scapy para llevar a cabo el MiM , lo que haremos será capturar, modificar y reinyectar un advertisement para hacernos pasar por el router maestro y posteriormente hacer un MIM.

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.

[Read more…]