Saltar al contenido
Beveiligingsnieuws

SIM maliciosa: ejecutar comandos en módems de IoT móvil

malicious SIM

Una SIM maliciosa no necesita hackear el sistema desde fuera: basta con introducir una tarjeta hostil en la ranura del dispositivo. Según una investigación presentada en USENIX WOOT, la SIM puede ordenar que el módem ejecute comandos elegidos por el atacante, usando una capacidad “proactiva” definida en especificaciones de comunicaciones celulares.

El impacto potencial es especialmente preocupante en equipos con conectividad móvil: cargadores para vehículos, routers industriales y unidades de telemática. En esos escenarios, la orden enviada por la SIM puede conducir a la toma del control del dispositivo, porque el módem suele estar acoplado a un procesador que termina ejecutando instrucciones adicionales.

Qué puede hacer una SIM maliciosa en el módem

La clave no es solo que el atacante tenga el número del objetivo, sino que la tarjeta ya esté en la ranura. La investigación describe múltiples caminos para llegar a ese punto: sustitución manual, uso de un intercalador (interposer) delgado, manipulación por un operador comprometido o incluso inserción durante el proceso de producción mediante alteraciones en software o línea de fabricación.

Una vez dentro, la SIM puede aprovechar un conjunto estandarizado de comandos que el módem debe poder aceptar sin esperar a que el dispositivo “lea” datos. Entre ellos está el comando denominado RUN AT: pide al módem que ejecute un comando AT.

Los comandos AT son un lenguaje de control de módems con raíces en los años 80 (Hayes Smartmodem) y que cada fabricante amplía. Cuando el sistema soporta RUN AT, la SIM obtiene una especie de consola general para ordenar acciones a través de ese canal.

Resultados del estudio: cuántos dispositivos aceptaron la orden

Los investigadores de la Universidad de Birmingham y la firma Fuzzware evaluaron 26 teléfonos y módulos celulares buscando esta capacidad. Hallaron que 9 de ellos aceptaron el comando.

En cuanto a teléfonos, solo 3 de 18 lo aceptaron. Los modelos citados fueron: OPPO Find X5, OPPO Reno 14 F 5G y ASUS Zenfone 9. En la muestra no se incluyeron dispositivos iPhone ni Pixel entre los que aceptaron RUN AT.

Los módulos mostraron un patrón distinto: 6 de los 8 módulos celulares probados aceptaron el comando. La exposición se concentraba en hardware de tipo máquina a máquina, típico de flotas IoT conectadas a través de SIM integradas o administradas en campo.

El papel de Quectel y por qué la arquitectura agrava el riesgo

De los módulos que aceptaron la orden, cinco de seis correspondían a la marca Quectel. En varios casos, se obtuvieron de dispositivos reales que forman parte del mundo IoT: un cargador de vehículo eléctrico, un router industrial y una unidad de control de telemática de un automóvil.

Aunque cada componente pueda tener fallos “ordinarios” corregibles con parches, el estudio subraya que el problema de superficie de ataque no se explica solo por el bug. La arquitectura del lado IoT es lo que lo hace más peligroso.

En muchos módulos, existe un procesador de aplicación pequeño funcionando en paralelo al módem. Usualmente se menciona Android en un ARM Cortex-A7. Lo importante es que el sistema termina pasando comandos AT que el radio no gestiona directamente hacia ese procesador adicional. El resultado, según el documento, es una “superficie de ataque rica” frente a una SIM maliciosa.

Ejemplos concretos: desde bloqueo de red hasta ejecución de código

El informe incluye casos donde las órdenes AT terminaron en efectos graves.

1) Bloqueo de conectividad y degradación de red

En el OPPO Reno 14 F 5G (uno de los tres teléfonos que aceptaron RUN AT), el comando AT+COPS=0,,,0 forzó el teléfono a operar en 2G. Lo crítico es que el usuario no pudo revertirlo con acciones comunes: cambiar a modo avión, usar selección manual de red, conmutar datos móviles o deshabilitar la SIM. Tampoco funcionó cambiar la generación preferida en la configuración.

Además, el estudio explica que forzar una degradación a 2G puede abrir la puerta a escenarios donde la autenticación mutua no existe, haciendo posible que el atacante imponga condiciones para suplantación de estaciones base.

2) Apagado del equipo y cierre del módem

El trabajo también describe comandos adicionales capaces de apagar el teléfono y desconectar el módem. Con su herramienta de análisis, llamada CATana, los investigadores identificaron 198 comandos AT alcanzables a través de la SIM en ese modelo de OPPO.

3) Acceso a archivos y exfiltración mediante TFTP y SMTP

En un tercer caso con un módulo Quectel EG25-G, la investigación muestra cómo se pueden leer archivos arbitrarios aprovechando un demonio TFTP que corre como root y que no valida si la ruta es un enlace simbólico. Posteriormente, el material se envía usando comandos AT+QSMTP del propio módulo.

Este ejemplo requiere algo más que la SIM: el enlace malicioso debe existir previamente en el sistema del módulo. Para lograrlo, los investigadores señalan que puede insertarse vía tarjeta SD o mediante el flasheo de una partición manipulada.

Cómo se relaciona con vulnerabilidades existentes

El estudio no se limita al canal RUN AT. Antes de llegar a este trabajo, los investigadores ya habían mostrado que una SIM hostil puede hacer que un teléfono Android bloquedo abra una página web controlada por el atacante sin interacción del usuario. En su análisis se mencionan modelos como Pixel 6, 8 y 9, y que esa falla fue corregida por Google como CVE-2025-48618 en el boletín de diciembre de 2025.

Para la exposición descrita en este estudio, se asignó un seguimiento por CVE y por el ecosistema GSMA: se indica que el interfaz SIM AT activado por RUN AT figura como CVE-2026-57550 a través de Qualcomm y como CVD-2026-0122 por GSMA. Aun así, el registro público de la lista del CVE Program aún no habría aparecido.

¿Hay un parche único? No: depende del proveedor y del firmware

Los investigadores remarcan que no existe una sola solución universal. Las fallas individuales pueden corregirse con parches, pero la interfaz que expone el problema es una capacidad documentada que cada proveedor decide si habilita.

En la respuesta coordinada, Qualcomm comunicó que construyó una configuración endurecida que desactiva esa interfaz por defecto. Quectel dijo haber mitigado la parte relacionada con acceso a archivos y que sigue trabajando en el componente de la interfaz en sí.

Sin embargo, no se publicó un aviso público por parte de esos actores. Además, el portal de vulnerabilidades del fabricante de módulos requería inicio de sesión para ver información detallada.

Qué pueden hacer hoy los equipos que gestionan IoT celular

Si administras flotas de IoT con conectividad celular, el estudio recomienda un enfoque práctico: preguntar al proveedor del módulo si la capacidad RUN AT está activada en el firmware entregado y, sobre todo, si se puede deshabilitar.

Los investigadores también sostienen que, como medida de defensa, la interfaz debería endurecerse, marcarse para desuso o deshabilitarse de manera directa. Según su comunicación, las configuraciones endurecidas estarían previstas como predeterminadas en dispositivos futuros, y que los módulos afectados recibirían actualizaciones.

En el momento del informe, el equipo no confirmó si las rutas de código que manejan RUN AT se eliminaron por completo o solo se desactivaron. Además, se indica que no hay reportes públicos de ataques que ya estén explotando esta interfaz.

Incidentes y coordinación: avisos a fabricantes

Antes de la publicación, los reportes se enviaron en marzo de 2026 a múltiples actores (incluyendo Google, Oppo, Quectel, Semtech y Qualcomm) y a GSMA en mayo. Se menciona que Qualcomm y otros componentes planificaron remediaciones a través de actualizaciones de firmware.

En paralelo, se indica que Semtech confirmó el problema y planea distribuir correcciones escritas por Qualcomm. Quectel también confirmó el tema y sostuvo que la inyección de comandos ya estaba corregida en firmware más reciente, aunque sin publicar números de versiones afectados o corregidos.

Por qué esto importa: amenaza operacional en vehículos y terminales

Este tipo de exposición encaja con escenarios donde los dispositivos están desplegados por largos periodos, con acceso físico posible o con mantenimiento por terceros. En vehículos, cargadores, terminales de pago y equipos de telemática, una SIM maliciosa puede convertirse en el vector que, una vez logrado, transforma un “dispositivo conectado” en un objetivo controlable por el atacante.

El trabajo también sugiere que no es fácil medir cuántos módulos están en servicio: Quectel no publicaría actualizaciones de firmware públicamente, lo que complica verificar el alcance a escala.

Conclusión

La investigación deja una idea central: una SIM maliciosa puede aprovechar una capacidad definida en estándares para que el módem ejecute comandos AT mediante RUN AT. En algunos teléfonos aceptaron la orden y, sobre todo, en varios módulos celulares —incluidos componentes de Quectel— eso puede derivar en efectos muy serios, desde bloqueo de red hasta ejecución de código.

Para reducir el riesgo, la recomendación más directa es revisar (y exigir) que la interfaz esté endurecida o deshabilitada en el firmware del módulo, coordinando con el proveedor y planificando actualizaciones cuando existan. Aunque no se hayan reportado explotaciones en público, el tipo de dispositivo afectado y la vía de ataque física hacen que valga la pena actuar con prioridad.

Fuente: https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html