OWASP FSTM, etapa 1: Reconocimiento y búsqueda de información

El mercado de los dispositivos IoT está cada vez más en auge: cámaras, altavoces, relojes, electrodomésticos… Pero, ¿Cómo de seguros son estos dispositivos? ¿Es sencillo analizar su seguridad? ¿Existe alguna metodología para trabajar con ellos? En esta serie de artículos te respondemos a todo ello. ¿Nos acompañas? En esta entrada inicial de la serie de artículos se presenta la primera etapa de la metodología OWASP FSTM para el análisis de firmwares.

Su objetivo es sencillo, obtener la mayor cantidad de información posible sobre el dispositivo que se desea analizar. Realizar un análisis en profundidad aportará una visión general muy precisa tanto del dispositivo como de su fabricante que será de gran utilidad en las etapas posteriores.

Cuando se realiza una auditoría de seguridad hardware a un dispositivo IoT siempre ayuda disponer de una guía de puntos clave y el porqué de estos. Seguir una metodología bien definida permite, por un lado, estandarizar los procesos de análisis y, por otro lado, aprender a identificar las etapas más importantes y a estimar mejor el esfuerzo invertido en cada una de ellas.

Empezar un análisis desde cero de un dispositivo es difícil sobre todo si se realiza siguiendo una aproximación de caja negra. En función de la naturaleza de la aplicación estudiada y la superficie de ataque existente puede parecer una tarea titánica, no obstante, gracias a la metodología OWASP FSTM el proceso de análisis se simplifica bastante.

Entender qué buscar, dónde y por qué es lo que marca la diferencia entre una buena y una mala auditoría. Sin embargo, debido a la abundancia de información existente hoy en día en Internet es necesario acotar bien la información que se desea obtener y medir adecuadamente los tiempos. Tan malo es tener poca como mucha información sobre el objetivo del análisis, si esta no está bien organizada.

OWASP FSTM y dispositivos IoT

En una auditoría de seguridad de dispositivos IoT, el reconocimiento y búsqueda de información es la etapa más delicada y suele ser de las más importantes para mejorar la tasa de éxito del investigador.

Generalmente, la búsqueda de información ayudará a familiarizarse con la tecnología, a la vez que permite el reconocimiento de las diferentes partes del sistema empotrado objeto del estudio de seguridad.

Se puede identificar un dispositivo vulnerable desde muchos puntos de vista: quizás una de las tecnologías usadas sea vulnerable (fallo en un estándar), puede que exista un defecto de configuración que exponga datos críticos, posiblemente utilice un software de terceros vulnerable… Por ello, cuanta más información seamos capaces de recopilar mejor.

Algunas de las fuentes de información más comunes se listan a continuación.

• Web del fabricante. La cantidad de información del dispositivo puede variar un montón entre fabricantes. Casi todos los fabricantes listan características técnicas, modos de empleo y uso, aplicaciones para interactuar con los dispositivos y posiblemente enlaces a otros recursos. Si tenemos suerte, este fabricante también proporcionará datasheets, firmwares, esquemáticos e incluso fotos del interior del dispositivo…
• Web del fabricante en distintas regiones del mundo. Algunos fabricantes tienen distintas páginas web para distintas regiones del mundo. Estas webs pueden estar sujetas a distintas regulaciones. Así, en algunos países, el fabricante estará obligado a compartir más información sobre su dispositivo que en otras regiones.
• Webs de otros fabricantes. Algunos productos que se analizan son diseños hechos por terceros a los que la empresa que lo comercializa solo aporta una imagen de marca. Otros, se trata de productos que se han desarrollado conjuntamente entre empresas para alcanzar volúmenes de venta mediante la unificación de mercados en distintas regiones.

A veces, fusiones o adquisiciones de empresas hacen que se hereden tecnologías que se usan bajo varias marcas comerciales. En todos estos casos, múltiples fabricantes pueden exponer información sobre productos que en su interior son o muy similares o incluso iguales. Distintos fabricantes tienen distintas políticas con respecto a su documentación, están sujetos a distintas leyes o compartirán distintos documentos por servicios que se han contratado a distintas empresas.

• Registros de certificación. Existen infinidad de entidades y compañías responsables de certificar que un dispositivo cumple una normativa técnica. Normalmente en sus informes han de documentar con detalle los procedimientos y materiales usados para asegurar el cumplimiento de esa normativa. Estos informes pueden contener información muy útil para una evaluación de seguridad.

Entre las posibilidades se encuentran fotos del interior del dispositivo, información sobre el hardware que usa, fotos de posibles prototipos o hardware de pruebas y posibles documentos de otros fabricantes o proveedores… Algunas de estas entidades pueden ser el FCC y PTCRB en los EE.UU., IC y PTCRB en Canadá, CE, GCF y RoHS en Europa y TELEC en Japón, entre muchos otros.

• Repositorios de código. Muchos de los dispositivos utilizados en el día a día usan software sujeto a licencias de código abierto. Estas licencias obligan a los fabricantes a publicar partes de su software de manera abierta o a proveer mecanismos para acceder a este código fuente. Existen muchas páginas a las que los usuarios o los fabricantes suben este código fuente. Entre otras, es interesante hacer búsquedas en Github, Gitlab, BitBucket, Sourceforge…

El fabricante puede tener sus propios repositorios o a veces servidores FTP. Si el fabricante cuenta con una nota de licencia de código abierto y no proporciona el código fuente correspondiente, se puede reclamar al fabricante que lo haga público y existen organismos que pueden interceder para ejercer este derecho.

• Foros específicos. Además de las fuentes oficiales del fabricante, es interesante tomar nota de la información que otros usuarios han recopilado. Realizar búsquedas en foros específicos es una tarea importante pero que requiere un filtrado de información más exhaustivo.

Desde el punto de vista técnico, los puntos críticos de los que se debe recopilar información son la composición general del firmware y la tecnología subyacente.

Se recomienda conocer la arquitectura de CPU soportada, la plataforma del sistema operativo, la configuración del cargador de arranque, los esquemáticos de hardware, las hojas de datos de los componentes o las líneas de código (LoC) estimadas. También localizar los repositorios del código fuente, los componentes de terceros, los registros de cambios, los registros de adecuación a distintos estándares y certificaciones, los diagramas de diseño y flujos de datos y los informes de pruebas de penetración previas y reportes de seguimiento de errores.

Nota: Es importante resaltar que el esfuerzo dedicado al análisis de cada uno de los puntos enumerados previamente dependerá en gran medida de la aplicación y de la naturaleza del sistema empotrado que se esté analizando en cada momento.

A continuación, se presentan algunos de los puntos de interés a documentar y su impacto en análisis posteriores.

Arquitectura de CPU soportada

Una de las principales tareas que se busca en este paso del análisis es conocer qué arquitectura de CPU se usa.

Si bien es cierto que la distinción entre una CPU de alto o bajo desempeño no repercute directamente en la seguridad del dispositivo, es bueno conocer que características y capacidades tiene además de conocer su arquitectura.

Esto nos permitirá en el futuro simplificar los procesos de reversing y emulación además de darnos una visión general de los posibles mecanismos de seguridad a los que nos podemos enfrentar. Posibles periféricos de interés pueden ser módulos criptográficos, TPMs, trusted execution zones… Estos módulos podrían ser utilizados para el almacenamiento de secretos o para el cifrado de parte de la plataforma.

Plataforma de sistema operativo

Una vez identificada la arquitectura de la CPU, es importante conocer la plataforma de sistema operativo que lleva nuestro dispositivo. A nivel teórico, la elección de la plataforma a utilizar debería ser transparente desde el punto de vista de la seguridad siempre que se mantenga adecuadamente y corrija las vulnerabilidades que van apareciendo con el transcurso del tiempo.

Los sistemas de código abierto suelen tener más vulnerabilidades, pero se corrigen más rápido y periódicamente. Los sistemas de código cerrado, por el contrario, tardan más tiempo en corregir los errores por término general.

A veces, plataformas como AWS IoT (Amazon Web Services), GCP IoT (Google Cloud Platform), Azure IoT y Zephyr OS (por ejemplo) facilitan los procesos de test, actualización de vulnerabilidades en el sistema base e incluso la actualización (OTA) de los mismos dispositivos empotrados…

En otros casos nos encontraremos con distribuciones particulares de Linux para dispositivos embebidos con procesos customizados para su actualización y mantenimiento.

Configuración de cargador de disco

Los arrancadores del sistema son un punto de entrada para poder evitar las capas de seguridad del sistema. En algunos dispositivos el modo de recuperación del cargador de disco, que no está protegido, permite hacer una copia de seguridad del sistema operativo con claves y certificados de acceso seguro a las plataformas donde el dispositivo puede acceder. Existen muchas alternativas:

• Uboot
• Libreboot
• Android bootloader
• CFE

Esquemáticos de hardware

Otra fuente de información muy relevante para su posterior estudio es disponer de los esquemas de diseño electrónico del dispositivo. Estos se pueden obtener a partir de fuentes oficiales (por ejemplo un repositorio del fabricante) o mediante ingeniería inversa.

El objetivo de esta información es ayudar al auditor a expandir la superficie de ataque. Para ello, se deben identificar buses donde pueda leerse información que podría estar en claro, sin cifrar y, en el mejor de los casos, manipular dichos datos para inyectar información falseada. Este tipo de acciones podría dar acceso a unas opciones que a priori no están disponibles (por ejemplo, a un menú oculto o algo similar).

Hojas de datos de los componentes

Tras conocer los esquemáticos del dispositivo es importante identificar los componentes presentes en la placa electrónica para entender mejor el diseño del dispositivo. No es necesario identificar todos los componentes, solo aquellos que a priori parezcan más interesante como las memorias rom (Flash SPI y e-MMC) y los chips de cifrado. Esta información será especialmente relevante en etapas posteriores de la metodología OWASP FSTM ya que se incrementa notablemente la superficie de ataque del dispositivo.

Líneas de código (LoC) estimadas

Cuando se han realizado de forma correcta los pasos anteriores es posible aproximar la cantidad de memoria disponible para el sistema operativo o firmware. Esto ayuda a conocer la longitud de código de un dispositivo. Hacer este ejercicio de estimación es importante de cara a seleccionar que herramientas y técnicas se deben usar posteriormente.

Un ejemplo de esto sería la posibilidad de utilizar técnicas de reversing o de fuzzing. Cuando nos encontramos frente a un binario de muy pequeño tamaño, la técnica de reversing podría tener sentido ya que inicialmente tendría una inversión de horas relativamente pequeña en comparación con la técnica de fuzzing con la que a priori no se podría juzgar si va a resultar efectiva.

Si nos encontramos ante un binario de tamaño muy grande, la inversión de horas en reversing podría ser excepcionalmente alta, mientras que montar un setup de fuzzing puede requerir poco tiempo y esperar a que arroje resultados en un plazo acotado de tiempo podría ser sensato ya que, a mayor cantidad de código, mayor es la probabilidad de encontrar un fallo.

Registros de cambios

Revisar los registros de cambios del hardware y software es una fuente de información muy fiable que ayuda a descubrir fallos o vulnerabilidades pasadas. Existen numerosos dispositivos en el mercado que no implementan políticas de actualizaciones OTA (actualizaciones por el aire), por lo que los fallos encontrados perduran en el tiempo hasta el lanzamiento de una nueva versión (dejando al dispositivo en un estado vulnerable continuo).

Es importante resaltar que los fallos de hardware (a diferencia de los de software) solo se pueden corregir con una nueva versión del producto.

Ejemplos de este tipo de fallos son el uso de librerías SSH obsoletas que permitan accesos sin autenticar al Shell de usuario (fallo de diseño software) o tener accesibles puertos de depuración como JTAG (fallo de diseño hardware).

Diagramas de diseño y flujos de datos

Otra información importante para considerar es el diseño y/o el flujo de datos que existe en el dispositivo analizado con el objetivo de entender cómo se organizan, envían y manipulan los datos. La obtención de este tipo de información se puede obtener desde la web del fabricante, presentaciones ejecutivas…

Nota: En caso de no ser capaces de recuperar esta información a partir de canales oficiales, será necesario realizar una aproximación del funcionamiento del dispositivo para identificar de una forma rápida y eficiente los vectores de entrada más relevantes para vulnerar al dispositivo.

Informes de pruebas de penetración previas

Conocer el histórico de auditorías de penetración previas ayuda a descartar caminos ya explorados y a contemplar nuevas vías de intrusión. En este sentido, siempre es recomendable estudiar vulnerabilidades previas para descartarlas rápidamente o para profundizar en su estudio. Lo mejor es tratar de ser ecuánime con el tiempo para cada vector de ataque (al menos en esta etapa de la investigación).

Tiques de seguimiento de errores

En varias plataformas de control de versiones se pueden localizar tiques de errores o adición de mejoras por analistas o desarrolladores externos. Si el sistema del dispositivo equipa una versión previa se puede estudiar el tique de error para ver qué tipo de defecto produce y si es posible su explotación…

En muchas ocasiones el código base que se utiliza para el firmware evaluado ya dispone de pruebas automáticas de seguridad gratuitas. Se recomienda descargar los repositorios de los fabricantes del hardware para estudiar estática y dinámicamente el código autogenerado. Suele tratarse de código robusto, pero nunca se sabe dónde se encontrará el hueco por el que entrar.

Conclusiones sobre OWASP FSTM

En esta entrada se ha presentado la primera etapa de la metodología OWASP FSTM y se ha puesto de manifiesto la importancia de realizar un estudio detallado de la información disponible para el dispositivo objetivo. Es recomendable utilizar herramientas y técnicas de inteligencia de código abierto como OSINT para realizar las tareas iniciales de obtención de información.

Como conclusión, desde el equipo de Innovación de Tarlogic se recomienda encarecidamente dedicar tiempo y esfuerzo a documentar y recopilar la mayor cantidad de información posible sobre el dispositivo con el objetivo de obtener una imagen clara del mismo y favorecer la consecución de las posteriores etapas de los análisis.

Referencias:

https://github.com/scriptingxss/owasp-fstm

https://cdn.worldvectorlogo.com/logos/gitlab.svg