Metasploit Forensics: Recovery deleted files (NTFS)

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

Rcapd start meterpreter module

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

Uso eficiente de Metasploit: resource scripts

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

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

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

[Read more…]

Defensas frente a ataques DHCP

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

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

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

[Read more…]

Análisis de shellcodes con scdbg / libemu

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

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

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

[Read more…]

Infección de procesos en Linux con Cymothoa

Borja Merino, ingeniero informático y colaborador habitual del blog, al que pueden seguir en su Twitter http://twitter.com/borjamerino, comienza su andadura en 2012 con una entrada sobre Cymothoa. Esperamos que les guste.

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

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

[Read more…]

Buscando buffer overflow desde Wireshark

Esta semana la cerramos con una entrada técnica a cargo de nuestro colaborador Borja Merino, ingeniero informático y especialista de seguridad, al que pueden seguir en su Twitter http://twitter.com/borjamerino. Esperamos que les guste.

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

Man in the Middle en entornos VRRP (II)

Continuamos con la segunda parte del post que publicamos ayer a cargo de Borja Merino, ingeniero informático y especialista de seguridad al que pueden seguir en su Twitter http://twitter.com/borjamerino, y en cuya elaboración ha participado activamente nuestro compañero José Luis Villalón, en la parte más práctica.

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

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

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

[Read more…]

Man in the Middle en entornos VRRP (I)

Esta entrada y la siguiente de la serie corren a cargo de Borja Merino, ingeniero informático y y especialista de seguridad, al que pueden seguir en su Twitter http://twitter.com/borjamerino, y en cuya elaboración ha participado activamente nuestro compañero José Luis Villalón, en la parte más práctica. Esperamos que les guste.

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

DNS Port Forwarding con Meterpreter

La entrada de hoy corre a cargo de Borja Merino, ingeniero informático y especialista de seguridad, al que pueden seguir en su Twitter http://twitter.com/borjamerino. Esperamos que el post les guste tanto como a nosotros.

A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotear” conexiones desde Meterpreter por medio de route es el tipo de herramientas que podemos usar a través del pívot. Esto es debido a que cualquier herramienta que use raw sockets no funcionará a través del túnel, estando limitados a conexiones TCP y UDP que realicen una “conexión completa” (connected sockets). En el caso de Nmap, por ejemplo, implica que únicamente podemos realizar escaneos de tipo TCP connect (-sT) por medio de socks4 y proxychains, pero será inútil utilizar switches como -sS (syn scan), -O (OS detection) o similares. Aunque otra opción es utilizar portforwarding (portfwd) mediante el cual mapear puertos locales con los de la víctima, estamos limitados a conexiones TCP, por lo que esto también reduce opciones a la hora de elegir herramientas que empleen UDP. En nuestro caso lo que haremos será preparar un entorno que nos ayude a “forwardear” peticiones DNS desde herramientas que hagan uso de UDP (nmap, dnsenum, etc) a través de Meterpreter.

Para ello configuraremos un Proxy DNS que intercepte peticiones DNS UDP y las redirija, en su “versión TCP”, al puerto configurado con portfwd. Ya que la mayoría de servidores DNS soportan TCP, no solamente para realizar transferencias de zona, sino para aceptar también queries en el puerto 53 (así lo especifica el protocolo DNS), podremos realizar consultas DNS con prácticamente cualquier herramienta. Lógicamente clientes DNS que empleen o soporten TCP (ej: dig +tcp) no requerirán de dicho Proxy y podrán lanzarse directamente a través de Meterpreter Lo mismo ocurre con clientes DNS que usen UDP y que utilizen la API adecuada, en cuyo caso podrá redirigir paquetes a través de Meterpreter utilizando route.

[Read more…]