Amazon Echo es vulnerable a un ataque para ganar privilegios de administrador

11/12/2017

El dispositivo Amazon Echo es vulnerable a un ataque físico que permite a un atacante obtener una línea de comandos con privilegios de administrador en el sistema operativo Linux subyacente e instalar malware sin dejar evidencia física de la alteración. Dicho malware podría otorgar a un atacante acceso remoto persistente al dispositivo, robar tokens de autenticación del cliente y la capacidad de transmitir audio en vivo del micrófono a servicios remotos sin alterar la funcionalidad del dispositivo.

Esta vulnerabilidad se debe a dos aspectos de diseño de hardware:

  • Un conector con entradas de depuración expuestas en la base del dispositivo
  • Opciones de configuración de hardware que permiten que el dispositivo arranque desde una tarjeta SD externa

Trabajo previo                

Anteriormente, investigadores pudieron iniciar un entorno Linux genérico desde una tarjeta SD externa conectada a las entradas de depuración disponibles en la base del dispositivo Amazon Echo. Proporcionaron sus procesos, los detalles de las entradas de depuración y la imagen de la tarjeta SD de arranque disponible en Github. En su libro blanco, teorizaron sobre cómo escalar privilegios en Amazon Echo.

Ahora continuamos con su trabajo para describir cómo arrancar el firmware del Echo, instalar un sistema persistente, obtener acceso remoto a la línea de comandos de root y finalmente obtener el audio de los micrófonos que "siempre escuchan".

Obteniendo root

Al remover la base de goma del Amazon Echo aparecen 18 entradas de depuración. Al conectar las entradas UART expuestas, se puede observar el arranque del dispositivo, proporcionando información sobre su configuración.

Desafortunadamente o afortunadamente durante el arranque no se dispone de un intérprete de comandos ni un inicio de sesión, y la secuencia de arranque no se puede interrumpir.

La MCU principal de Amazon Echo es un procesador de medios digitales DM3725 de Texas Instruments con una CPU ARM Cortex-A8. Durante el arranque, estos chips tienen un proceso de arranque de tres partes. Primero, se arranca desde una ROM que realiza una configuración de hardware mínima. A continuación, se carga un gestor de arranque secundario (X-loader) desde un dispositivo de arranque en la RAM interna de la MCU. Esto inicia el dispositivo antes de cargar un tercer gestor de arranque (U-Boot) en la RAM externa y ejecutarlo. U-Boot luego carga el kernel y le otorga el control.

El Echo está configurado de forma que primero intentará arrancar desde una tarjeta SD conectada a las entradas de depuración expuestas antes que de la unidad eMMC interna. Esta configuración de orden de arranque está determinada por el estado de varias entradas de hardware en la MCU durante el arranque y no se puede cambiar sin una revisión / modificación de hardware de la placa principal.

Al formatear correctamente una tarjeta SD con X-Loader y U-Boot en la partición correcta, se puede iniciar desde esta y en una interfaz de línea de comando de U-Boot.

Como la ROM se comunica con la tarjeta SD en modo SPI y no se está iniciando el sistema operativo principal de la tarjeta, no es necesario conectar todos los adaptadores SDMMC.

La asignación de MMC a SPI es la siguiente.

  • SDMMC D0 → MISO
  • SDMMC D3 →! SS
  • SDMMC CMD → MOSI
  • SDMMC CLOCK → SCK

También se debe aplicar 3V a la entrada POWER de SDMMC y a la tarjeta SD y conectar uno de los adaptadores GND.

Durante el encendido, el dispositivo arranca desde los binarios MLO y U-Boot en la tarjeta SD. Esta implementación de U-Boot  permite interrumpir el proceso de arranque e ingresar a la interfaz de línea de comando de U-Boot. Desde aquí es posible inspeccionar los contenidos de los sistemas de archivos en la memoria interna y reconfigurar los argumentos del kernel.

Ahora se debe determinar qué partición en el eMMC interno contiene el kernel principal y el sistema de archivos. El eMMC interno contiene 8 particiones con las siguientes etiquetas:

  • xloader
  • recuperación
  • bota
  • idme
  • diag
  • main-A
  • main-B
  • datos

El sistema de archivos principal y el kernel están en main-A o main-B y cambian entre ellos en cada actualización de firmware. Solo se debe observar un sistema de archivos en una de las particiones. Si se nota un sistema de archivos en ambas particiones, entonces el dispositivo está en la mitad de una actualización de firmware y hay que reiniciar el dispositivo sin la tarjeta SD y esperar a que termine la actualización.

Sabiendo desde qué partición se desea arrancar, se configura U-Boot para que arranque desde esta partición. También se cambian los argumentos del kernel para montarlo como un sistema de archivos modificable y ejecutar /bin/sh en lugar de los scripts de inicio normales. 

Una vez que arranca, se presenta una terminal con privilegios de root sobre UART, evitando toda autenticación. En esta etapa, no se han ejecutado secuencias de comandos de inicialización y el dispositivo se reinicia constantemente. Para evitarlo se utiliza un demonio de watchdog que reinicia periódicamente un temporizador de reinicio.

El entorno ahora es estable, sin embargo, ninguno de los servicios principales se ha iniciado y el dispositivo no es completamente funcional. Sin embargo, tenemos acceso completo de lectura / escritura a todo el sistema de archivos y podemos hacer modificaciones. Con esos privilegios se puede crear un script de puerta trasera en la partición de datos (que normalmente se monta en /var) ya que se puede escribir en el funcionamiento normal.

Con la partición montada se puede agregar persistencia y agregar un script de puerta trasera al directorio /var montado. También se requiere que el script se ejecute en el arranque. Esto se puede hacer agregando la siguiente línea al final de uno de los scripts de inicialización. Por ejemplo, /etc/init.d/varlocal.sh ya que es uno de los últimos que se ejecuta y monta la partición de datos.

Una vez que la puerta trasera está instalada, se puede retirar la tarjeta SD externa y las conexiones UART, y reiniciar el Echo en su operación normal.

Durante el inicio, la secuencia de comandos de inicialización ejecuta la puerta trasera con lo que Amazon Echo debería conectarse al equipo especificado y proporcionar una terminal con privilegios de administrador.

¿Estas escuchando?

Con privilegios de administrador es posible examinar los procesos que se ejecutan en el dispositivo y los scripts que generan estos procesos. En consecuencia se pudo comprender cómo se transmiten y almacenan los medios de audio entre los procesos y las herramientas que se utilizan para crear e interactuar con estos almacenamientos intermedios de audio. Usando la aplicación 'shmbuf_tool' proporcionada por Amazon, se puede generar una secuencia de comandos que escribiría continuamente los datos del micrófono en bruto que luego son transmitidos a un servicio remoto. En el dispositivo remoto se recibe el audio del micrófono sin procesar, por lo tanto se deben analizar los datos, también se puede guardar como un archivo wav o  reproducirlo desde los altavoces del dispositivo remoto. Esta técnica no afecta la funcionalidad de Amazon Echo.

La solución

Esta vulnerabilidad ha sido confirmada en la edición 2015 y 2016 de Amazon Echo, sin embargo, la edición de 2017 no es vulnerable a este ataque físico. La mitigación implementada por Amazon fue unir el panel de entrada +3 V con el panel MOSI / CMD en algún lugar de la placa principal, esto efectivamente deshabilita las comunicaciones SPI con una tarjeta SD externa, evitando el arranque externo.

Para identificar si un dispositivo es vulnerable, puede revisar el paquete original para obtener un identificador de 2017 y un número de modelo de dispositivo que termine 02., por ejemplo: 23-002518-01. Tenga en cuenta que la edición en blanco tiene un número ligeramente diferente de 23-002517-0x.

Pensamientos finales

Obtener la terminal con privilegios administrativos en un Amazon Echo es trivial, pero requiere acceso físico, lo cual es una limitación importante. Sin embargo, los desarrolladores de productos no deben dar por sentado que sus clientes no expondrán sus dispositivos a entornos no controlados, como habitaciones de hoteles.

El Amazon Echo incluye un botón de silenciamiento físico que desactiva el micrófono en la parte superior del dispositivo o puede desactivarse cuando se discute información delicada (este es un mecanismo de conexión y no se puede modificar a través del software). Aunque el Echo plantea cuestiones de privacidad con sus micrófonos "siempre escuchando", muchos de nosotros caminamos con micrófonos rastreables en nuestros bolsillos sin pensarlo dos veces.

La retirada de productos y las modificaciones pueden ser costosas en la postproducción, por lo que se debe considerar la seguridad física durante todo el ciclo de vida del desarrollo. Los ataques físicos también deben incorporarse a las evaluaciones de seguridad tan pronto como sea posible para aumentar la seguridad del producto y ahorrar dinero al no tener que producir nuevos prototipos de hardware más adelante en el desarrollo del producto.