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.

Comments

  1. Un trabajo excelente y minucioso. Gracias.

    Saludos

  2. http://JoseMi says

    Gracias Alejandro :-)