Avaya Deskphone: se encontró una vulnerabilidad de una década en el firmware del teléfono


Avaya es el segundo mayor proveedor de soluciones VOIP (fuente) con una base de instalación que cubre el 90% de las compañías Fortune 100 (fuente), con productos dirigidos a un amplio espectro de clientes, desde pequeñas y medianas empresas hasta grandes corporaciones. Como parte del esfuerzo continuo de McAfee Advanced Threat Research para investigar vulnerabilidades críticas en software y hardware ampliamente implementado, decidimos echar un vistazo al Avaya 9600 series IP Deskphone. Pudimos encontrar la presencia de una vulnerabilidad de Ejecución remota de código (RCE) en una pieza de software de código abierto que Avaya probablemente copió y modificó hace 10 años, y luego no pudo aplicar parches de seguridad posteriores. El error que afecta al software de código abierto se informó en 2009, pero su presencia en el firmware del teléfono permaneció inadvertida hasta ahora. Solo se ve afectada la pila de software H.323 (a diferencia de la pila SIP que también se puede usar con estos teléfonos), y el Asesor de seguridad de Avaya (ASA) se puede encontrar aquí ASA-2019-128.

El siguiente video muestra cómo un atacante puede aprovechar este error para hacerse cargo del funcionamiento normal del teléfono, filtrar el audio de su teléfono con altavoz y potencialmente "molestar" al teléfono. El ataque actual se realiza con el teléfono directamente conectado a la computadora portátil de un atacante, pero también funcionaría a través de una conexión a la misma red que un teléfono vulnerable. Los detalles técnicos completos se pueden encontrar aquí, mientras que el resto de este artículo brindará una descripción general de alto nivel sobre cómo se encontró este error y cierta consideración con respecto a su resolución. La imagen de firmware que Avaya publicó el 25 de junioth resuelve el problema y se puede encontrar aquí. Como usuario, puede verificar si su Deskphone es vulnerable: primero determine si tiene uno de los modelos afectados (Serie 9600, Serie J100 o B189), luego puede encontrar qué versión de firmware está usando su teléfono en “Acerca de Avaya IP La pantalla del teléfono de escritorio en el menú Inicio, versión 6.8.1 y anteriores, es vulnerable cuando se utiliza un firmware H.323 (las versiones SIP no se ven afectadas).

(incrustar) https://www.youtube.com/watch?v=zW8B913R4ig (/ incrustar)

¿Qué buscan los investigadores?

Al estudiar la seguridad de los dispositivos integrados y de IoT, los investigadores generalmente tienen un par de objetivos en mente para ayudar a iniciar su investigación. En la mayoría de los casos, dos de los objetivos principales son recuperar los archivos en el sistema para estudiar cómo funciona el dispositivo y luego encontrar una manera de interactuar directamente con el sistema de manera privilegiada (más allá de lo que un usuario normal debería poder hacer). Los dos se pueden entrelazar, por ejemplo, obtener un acceso privilegiado al sistema puede permitir que un investigador recupere los archivos almacenados en él, mientras que la recuperación de los archivos primero puede mostrar cómo habilitar un acceso privilegiado.

En este caso, recuperar los archivos fue sencillo, pero obtener un acceso privilegiado requirió un poco más de paciencia.

Recuperando los archivos del teléfono

Cuando decimos recuperar los archivos del teléfono, nos referimos a buscar el sistema operativo y las diversas piezas de software que se ejecutan en él. Archivos de usuario, p. los contactos, la configuración y los registros de llamadas generalmente no son de interés para un investigador de seguridad y no se cubrirán aquí. Para recuperar los archivos, el enfoque más fácil es buscar actualizaciones de firmware para el dispositivo. Si tenemos suerte, estarán disponibles gratuitamente y no serán encriptados. En la mayoría de los casos, un firmware encriptado no aumenta la seguridad del sistema, sino que eleva la barrera de entrada tanto para los investigadores de seguridad como para los atacantes. En este caso, tenemos suerte, el sitio web de Avaya ofrece actualizaciones de firmware para sus diversas líneas de productos telefónicos y cualquiera puede descargarlas. La descarga contiene varios archivos tar (un tipo de formato de archivo). Entonces podemos ejecutar una herramienta llamada binwalk en los archivos extraídos. Binwalk es un gran diccionario de patrones que representa formatos de archivo conocidos; dado un archivo de firmware desconocido, buscará cualquier patrón conocido y, al encontrar posibles coincidencias, intentará procesarlos en consecuencia. Por ejemplo, si encuentra lo que parece un archivo .zip dentro del firmware, intentará descomprimirlo. Ejecutar esta herramienta siempre es un buen primer paso cuando se enfrenta a un archivo de firmware desconocido, ya que, en la mayoría de los casos, identificará elementos útiles para usted.

Al procesar el firmware del teléfono, extraer los archivos y ejecutar binwalk en ellos nos dio el programa que el teléfono ejecuta al inicio (el cargador de arranque), el kernel de Linux utilizado por el teléfono y un sistema de archivos JFFS que contiene todos los archivos binarios y de configuración del teléfono. Este es un gran comienzo, ya que a partir de ahí podemos comenzar a comprender el funcionamiento interno del dispositivo y buscar errores. Sin embargo, en esta etapa, estamos limitados a realizar un análisis estático: podemos ver los archivos y echar un vistazo a las instrucciones de ensamblaje de varios binarios, pero no podemos ejecutarlos. Para hacer la vida más fácil, generalmente hay dos opciones. El primero es emular todo el teléfono, o al menos alguna región de interés, mientras que el otro es obtener un acceso privilegiado al sistema, inspeccionar lo que se está ejecutando y ejecutar herramientas de depuración. Los mejores resultados se obtienen cuando combina y combina todas estas opciones de manera adecuada. En aras de la simplicidad, solo cubriremos lo último, pero ambos se utilizaron de varias maneras para ayudarnos en nuestra investigación.

Obteniendo el acceso privilegiado

En la mayoría de los casos, cuando se habla de obtener acceso privilegiado a un dispositivo IoT / embebido, los investigadores de seguridad buscan una interfaz administrativa llamada shell raíz que les permita ejecutar cualquier código que deseen con el más alto nivel de privilegio. A veces, uno está fácilmente disponible para fines de mantenimiento; otras veces se requiere más esfuerzo para acceder a él, suponiendo que uno esté presente en primer lugar. Esto es cuando entra en juego la piratería de hardware; A los investigadores de seguridad les encanta arrancar dispositivos abiertos y anular las garantías, en busca de posibles puertos de depuración, guardianes del acceso privilegiado solicitado.

Primer plano de la placa de circuito del teléfono. Puertos UART en rojo y EEPROM en azul

En la imagen de arriba, podemos ver dos puertos de depuración etiquetados como UART0 y UART1. Este tipo de punto de prueba, donde el cobre está directamente expuesto, se usa comúnmente durante el proceso de fabricación para programar el dispositivo o verificar que todo funcione correctamente. UART significa Receptor-Transmisor Asíncrono Universal y está destinado a la comunicación bidireccional. Este es el lugar más probable donde podemos encontrar el acceso administrativo que estamos buscando. Al comprar un $ 15 cable que convierte UART a USB y cables de soldadura en las almohadillas de prueba, podemos ver la información de depuración que se imprime en la pantalla cuando se inicia el teléfono, pero pronto el flujo de información de depuración se seca. Este es un comportamiento curioso, ¿por qué detener los mensajes de depuración? Por lo tanto, debemos investigar más. Al usar un desensamblador para convertir bytes sin procesar en instrucciones de la computadora, podemos echar un vistazo al código del gestor de arranque recuperado anteriormente y descubrir que durante el proceso de arranque el teléfono recupera la configuración de la memoria externa para decidir si el conjunto completo de funciones de depuración debe habilitarse en la consola serial. La memoria externa se llama EEPROM y es fácilmente identificable en el tablero, primero por su forma y luego por la etiqueta impresa en él. Las etiquetas en los componentes electrónicos se utilizan para identificarlos y recuperar su hoja de datos asociada, la documentación técnica que describe cómo usar el chip desde el punto de vista de la ingeniería eléctrica. Soldar cables directamente al chip bajo un microscopio y conectarlo a un programador (un artilugio de $ 30 llamado buspirate), nos permite cambiar la configuración almacenada en él y habilitar las capacidades de depuración del teléfono.

EEPROM listo para ser reprogramado

Reiniciar los teléfonos nos da mucha más información de depuración y, finalmente, nos saludan con el shell raíz que estábamos buscando.

Confirmación tenemos un shell raíz. Se imprimen mensajes de depuración no relacionados mientras invocamos el comando "whoami"

Caminos alternativos

El enfoque descrito anteriormente es bastante largo y solo es interesante para los investigadores de seguridad en una situación similar. Una técnica más genérica sería modificar directamente el sistema de archivos alterando el almacenamiento flash (un flash NAND en la parte posterior de la placa de circuito) como lo hicimos para la investigación anterior, y luego iniciar automáticamente un servidor SSH o un shell remoto. Otro común técnica es manipular el flash NAND mientras el sistema de archivos se está cargando en la memoria, para poner el gestor de arranque en un estado de excepción que luego permitirá al investigador modificar los argumentos de arranque del kernel de Linux. De lo contrario, para obtener acceso de shell remoto, el uso de un firmware anterior con vulnerabilidades RCE conocidas es probablemente el método más fácil de considerar; puede ser un buen punto de partida para los investigadores de seguridad y no es una amenaza para los usuarios habituales, ya que ya deberían tener el software más actualizado. A fin de cuentas, estos métodos no son un riesgo para los usuarios finales y son más que un trampolín para que los investigadores de seguridad realicen sus investigaciones.

En busca de vulnerabilidades

Después de obtener acceso a un shell raíz y la capacidad de realizar ingeniería inversa de los archivos en el teléfono, nos enfrentamos a la tarea abierta de buscar software potencialmente vulnerable. A medida que el teléfono ejecuta Linux, las utilidades habituales de línea de comandos que las personas usan para administrar sistemas Linux están disponibles para nosotros. Es natural mirar la lista de procesos en ejecución, encontrar los que tienen conexión de red, etc. Mientras hurga, queda claro que una de las utilidades, dhclient, es de gran interés. Ya se está ejecutando en el sistema y maneja la configuración de la red (las llamadas solicitudes DHCP para configurar la dirección IP del teléfono). Si lo invocamos en la línea de comando, se imprime lo siguiente:

Mostrar una pantalla de ayuda detallada que describe sus argumentos esperados es un comportamiento normal, pero un copyright de 2004-2007 es una gran señal de alerta. Una búsqueda rápida confirma que la versión 4.0.0 tiene más de 10 años y, lo que es peor, un explotar apuntarlo está disponible públicamente. El código de Dhclient es de código abierto, por lo que encontrar las diferencias entre dos versiones sucesivas es sencillo. Estudiar el código de explotación y cómo se reparó el error nos ayuda a reducir qué parte del código podría ser vulnerable. Una vez más, al usar un desensamblador, confirmamos que la versión del teléfono de dhclient es realmente vulnerable al error reportado en 2009. La conversión del exploit original para que funcione en el teléfono requiere uno o dos días de trabajo, mientras construimos la prueba de concepto demostrada en el video de arriba es cuestión de meras horas. De hecho, todas las herramientas para transmitir audio desde el teléfono a una máquina separada ya están presentes en el sistema, lo que reduce en gran medida el esfuerzo para crear esta demostración. No impulsamos la explotación más allá de la Prueba de concepto que se muestra en el video anterior, pero podemos suponer que en este punto, construir una versión armada capaz de amenazar las redes privadas es más una tarea de ingeniería de software y un atacante experto solo podría necesitar unas pocas semanas, si no días, para armar uno.

Remediación

Al encontrar la falla, notificamos de inmediato a Avaya con instrucciones detalladas sobre cómo reproducir el error y las soluciones sugeridas. Pudieron arreglar, probar y lanzar una imagen de firmware parcheada en aproximadamente dos meses. En el momento de la publicación, la solución habrá estado fuera por más de 30 días, dejando a los administradores de TI suficiente tiempo para implementar la nueva imagen. En un entorno empresarial grande, es bastante común tener primero una fase de prueba en la que se implemente una nueva imagen en los dispositivos seleccionados para garantizar que no surjan conflictos en la implementación. Esto explica por qué la línea de tiempo desde el lanzamiento del parche hasta la implementación en toda la flota puede llevar más tiempo de lo que es típico en el software de grado de consumidor.

Conclusión

IoT y los dispositivos integrados tienden a mezclarse con nuestro entorno, en algunos casos, sin garantizar una segunda reflexión sobre los riesgos de seguridad y privacidad que plantean. En este caso, con una inversión mínima de hardware y software libre, pudimos descubrir un error crítico que permaneció fuera de la vista durante más de una década. Avaya se apresuró a solucionar el problema y la amenaza que representa este error ahora se mitiga, pero es importante darse cuenta de que este no es un caso aislado y que muchos dispositivos en múltiples industrias aún ejecutan código heredado con más de una década de antigüedad. Desde la perspectiva de la administración del sistema, es importante considerar todos estos dispositivos en red como pequeñas computadoras de caja negra que ejecutan código no administrado que debe aislarse y monitorearse en consecuencia. McAfee Network Security Platform (NSP) detecta este ataque como "DHCP: desbordamiento de la longitud de la opción de máscara de subred" (ID de firma: 0x42601100), lo que garantiza que nuestros clientes permanezcan protegidos. Finalmente, para los entusiastas de la tecnología que leen esto, la barrera de entrada al pirateo de hardware nunca ha sido tan baja, con muchos recursos en línea y hardware barato para comenzar. Buscar este tipo de vulnerabilidad es un gran punto de entrada a la seguridad de la información y ayudará a hacer del mundo incrustado un lugar más seguro.





Enlace a la noticia original