m33tfinder: Vulnerabilidad en Cisco Meeting Server descubierta por ElevenPaths

Yamila Levalle    13 noviembre, 2018

El 7 de noviembre, mientras celebrábamos nuestro Security Innovation Day, Cisco publicó un security advisory con CVE-2018-15446 asociado a la vulnerabilidad que hemos reportado desde nuestro equipo de Innovación y Laboratorio en ElevenPaths sobre el software Cisco Meeting Server. La vulnerabilidad permitiría a un atacante remoto obtener información e introducirse en las reuniones celebradas a través de este software. Cisco Meeting Server (anteriormente denominado “Acano”), es un software utilizado para realizar videoconferencias. Permite a los usuarios conectarse a las reuniones con diferentes clientes como Cisco Jabber, Cisco Meeting App, Skype for Business o vía WebRTC con un navegador compatible.

Durante nuestras pruebas, detectamos que de forma remota y sin autenticación previa se pueden enumerar las conferencias activas en un servidor Cisco Meeting Server. Esto proporciona gran cantidad de información por cada conferencia almacenada en el sistema, como por ejemplo: 

  • ID de conferencia
  • Nombre de conferencia
  • Dirección de vídeo
  • Conference GUID
  • Source GUID
  • Resolution GUID
  • Passcode (True or False)
  • Número de teléfono
  • Weblink

Analizando toda esta información, se puede llegar a perfilar la agenda de una compañía, temas a tratar, personas involucradas, etc. Hasta aquí, podría tratarse de un problema de obtención de información que podría utilizar el atacante para perfeccionar otros ataques. Además, también detectamos que remotamente y sin autenticación (dependiendo de la configuración del Cisco Meeting Server) es posible realizar un ataque de fuerza bruta contra el passcode en las conferencias que poseen asignado uno, sin que el servidor le detenga independientemente del número de intentos. Con el passcode obtenido ya se podría asistir a la videoconferencia correspondiente.

El atacante podría detectar (por el nombre) las conferencias sin passcode en las que se trate temas críticos como presupuestos, comités directivos, reuniones estratégicas… A partir de identificar la conferencia “objetivo”, podría ingresar el ID de conferencia y unirse a ella como invitado usando un nombre que no despierte sospechas (ingeniería social).

Detalles técnicos

Conozcamos algunos detalles de contexto. En primer lugar, un atacante podría identificar los servidores Cisco Meeting Server disponibles en Internet, por ejemplo con Shodan. Un JavaScript muy característico que permite descubrir este tipo de software podría ser:

html:»scripts/script_switcher_join_a_call.js»

Una vez identificada la URL del objetivo, el atacante podría realizar un POST request a la siguiente URL: https://[urlmeetingserver]/guestConference.sf y enviar como parámetros los ID de las potenciales conferencias. El atacante tendría que tantear enviando por ejemplo ID de conferencia: 0000, 1000, 2000, 3000 y así sucesivamente para identificar los rangos de conferencias en uso, y luego afinar. La respuesta del servidor varía de acuerdo a si el rango está en uso o no.

Si el rango no está en uso (izquierda). Si el rango está en uso (derecha) imagen
Si el rango no está en uso (izquierda). Si el rango está en uso (derecha).

Una vez identificados los rangos de conferencias válidos, el atacante podría enviar peticiciones HTTP con todos los IDs de conferencias posibles dentro del rango y un passcode vacío en los rangos identificados a https://[urlmeetingserver]/guestConference.sf para detectar las conferencias existentes. Una vez más, aprovechando las diferentes respuestas recibidas por el servidor, podemos identificar cuando una conferencia “existe” tal como se ve en la siguiente imagen.

Respuesta "success" cuando existe la conferencia en el servidor img
Respuesta «success» cuando existe la conferencia en el servidor

De acuerdo a la configuración del Cisco Meeting Server en cuestión, la técnica anterior puede devolver solamente las videoconferencias no protegidas por passcode o todas las conferencias existentes. Esto depende de la configuración del parámetro «Guest access via ID and passcode».

  • Si este se encuentra configurado en modo «legacy» se requiere primero el ID de la conferencia para unirse a ella y luego el passcode. En este caso, la técnica detallada retorna todos los meetings existentes, independientemente de si están protegidos por passcode o no.
  • Si se configura en modo «secure» se solicita ingresar tanto el ID de la conferencia como el passcode antes de permitir unirse. En este caso devuelve solamente las conferencias no protegidas por passcode (es decir, con passcode vacío) puesto que el servidor realiza la verificación de ambos datos al momento de responder si la conferencia existe o no.
Configuración del parámetro Guest Access via ID and Passcode

Probar todos los passcode que desees

Vale la pena aclarar que el passcode es un valor numérico que puede contener hasta 100 dígitos de longitud, pero generalmente se utilizan passcodes de 4 o 6 dígitos por comodidad de los usuarios que deben introducirlo para unirse a las conferencias. Debe ser numérico para poder ser ingresado desde un teléfono usando DTMF (Dual tone multi frequency).

En caso de que la conferencia tenga asignado un passcode y el parámetro «Guest access via ID and passcode» se encuentre configurado en modo “legacy”, el atacante podría realizar un ataque de fuerza bruta para obtenerlo. No existe ningún tipo de bloqueo por intentos fallidos de acceso. Esto se consigue a través de una petición POST a https://[urlmeetingserver]/guestLoginRequest.sf enviando los parámetros correspondientes a la conferencia seleccionada, donde el passcode se tomaría de una lista de passcodes a probar generada por el atacante.

Respuesta del servidor por passcode erróneo

En caso de passcode correcto, la respuesta también es «failure» porque se está realizando las consultas desde un script Python y no desde un navegador. Aun así la variable «reason» devuelve como resultado ‘unsupportedBrowser’ y no ‘invalidPasscode’ como vimos en la imagen anterior, con lo cual podemos deducir que el passcode es el adecuado. Una vez obtenido el passcode, el atacante podría emplear la ingeniería social para tener acceso a la reunión.

Acceso a la conferencia por medio del navegador en modo secure img
Acceso a la conferencia por medio del navegador en modo secure
Acceso a la conferencia por medio del navegador en modo legacy img
Acceso a la conferencia por medio del navegador en modo legacy

Protecciones de Cisco Meeting Server

Posee dos parámetros para prevenir este tipo de ataques:

  • Parámetro «Guest access via ID and passcode» con valor «secure» ya mencionado.
  • Parámetro «secret» alfanumérico que se incluye en el enlace de invitación y permite la conexión directa a la videoconferencia. Este parámetro no aumenta realmente la seguridad del Cisco Meeting Server, ya que es mostrado en el weblink de la conferencia remotamente a usuarios no autenticados como se puede apreciar en la siguiente imagen.
WebLink de la confrerencia, mostrado a usuarios no autenticados img
WebLink de la confrerencia, mostrado a usuarios no autenticados

Prueba de Concepto

Para realizar las pruebas pertinentes, en el Laboratorio de ElevenPaths desarrollamos dos pequeñas herramientas en Python, la primera m33tfinder.py que permite detectar y listar remotamente las conferencias existentes en el Cisco Meeting Server, y la segunda m33tbreak.py que permite realizar el bruteforce del passcode de la conferencia seleccionada.

Para utilizar m33tfinder lo único que se necesita es la URL del Cisco Meeting Server en cuestión. La herramienta primero encuentra los rangos de conferencias en uso, y luego por cada rango de conferencias detecta las conferencias existentes y en curso. En caso de estar configurado el Cisco Meeting Server en legacy mode, m33tfinder detecta y devuelve la información de todas las conferencias existentes en el servidor. En caso de estar configurado en secure mode m33tfinder detecta y devuelve la información únicamente de las conferencias no protegidas por passcode .

Uso de m33tfinder para detectar conferencias, tanto en legacy como en secure mode img
Uso de m33tfinder para detectar conferencias, tanto en legacy como en secure mode

Para el caso de m33tbreak lo que se necesita es la URL del Cisco Meeting Server en cuestión y el ID de la conferencia sobre la que vamos a realizar el ataque de fuerza bruta. La herramienta en primer lugar verifica que la conferencia exista y esté protegida por passcode, y luego aplica la fuerza bruta del passcode por medio de un archivo de pins, que por defecto contiene todas las combinaciones posibles de 4 dígitos aunque puede ser modificado para contener passcodes de diferente longitud.

Uso de M33tbreak para el ataque de fuerza bruta a una conferencia img
Uso de M33tbreak para el ataque de fuerza bruta a una conferencia

 Los resultados posibles de esta herramienta son dos:

Uso de M33tbreak para el ataque de fuerza bruta a una conferencia img

Contramedidas y soluciones

Tras informarles a través de los canales oficiales Cisco agradeció el reporte y con celeridad ha puesto a disposición un parche de seguridad que soluciona esta vulnerabilidad. La ha calificado como de gravedad «media», con CVSS de 5.3. La explicación oficial es la siguiente:

A vulnerability in Cisco Meeting Server could allow an unauthenticated, remote attacker to gain access to sensitive information. The vulnerability is due to improper protections on data that is returned from user meeting requests when the Guest access via ID and passcode option is set to Legacy mode. An attacker could exploit this vulnerability by sending meeting requests to an affected system. A successful exploit could allow the attacker to determine the values of meeting room unique identifiers, possibly allowing the attacker to conduct further exploits.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *