harbingerse7en/cve-2024-20154Análisis técnico de CVE-2024-20154, un desbordamiento de búfer basado en pila en el firmware del módem baseband MediaTek MT6769 NB-IoT, que abarca ingeniería inversa y cadena de explotación.
Clasificación: CWE-121 — Desbordamiento de búfer basado en pila
Gravedad: Crítica (boletín de MediaTek) · 8.8 Alta, Vector de ataque: Adyacente (CISA-ADP)
Tipo: Ejecución remota de código — sin interacción del usuario, sin asociación previa
Divulgación: Boletín de seguridad de MediaTek, 6 de enero de 2025 https://corp.mediatek.com/product-security-bulletin/January-2025
Objetivo analizado: Samsung Galaxy A14 SM-A145R — familia MT6769 (Helio G80), dentro de la lista de chipsets afectados de MediaTek - El firmware fue emulado en condiciones seguras.
Estado: Parcheado.
Esta fue mi primera investigación publicada sobre banda base. Vengo de un entorno muy alejado de la infraestructura de telecomunicaciones, las capas de mediación de interceptación legal, el análisis de stingray y capturadores de IMSI, y la seguridad de dispositivos embebidos — no había realizado previamente ingeniería inversa profunda de firmware en un módem celular. Quería demostrarme a mí mismo que una metodología analítica estructurada se adapta a distintos objetivos, y que la familiaridad con una plataforma específica puede reemplazarse por un rastreo riguroso de la cadena. NB-IoT destacaba porque se sitúa en una intersección genuinamente peligrosa: el protocolo está diseñado para dispositivos IoT con recursos limitados, la superficie de ataque es previa a la asociación, y la pila del módem lo procesa independientemente de lo que esté haciendo el usuario del teléfono.
Cuando se analizó el firmware parcheado y se confirmó la ausencia del patrón vulnerable, el sistema de IA utilizado para el análisis masivo del firmware antes de apuntar a funciones específicas
coincidió de forma independiente con la clase de bug reconstruida, las condiciones y la familia de firmware afectada con la descripción de CVE-2024-20154.
Las conclusiones técnicas son del propio analista.
El teléfono que llevas en el bolsillo contiene al menos dos computadoras separadas. Con la que interactúas ejecuta Android. La otra — la banda base — se ejecuta de forma completamente independiente, gestiona toda la comunicación por radio, y es casi totalmente invisible para el sistema operativo que está por encima. Android puede estar completamente parcheado. El navegador puede estar en sandbox. El usuario puede no tocar nunca un enlace malicioso. Nada de eso importa si el código vulnerable está en el firmware del módem que procesa las señales de radio antes de que el procesador de aplicaciones intervenga.
CVE-2024-20154 es exactamente ese tipo de vulnerabilidad.
Una difusión de información de sistema NB-IoT malformada hace que el firmware del módem MediaTek acepte un conteo de planificación controlado por el atacante, arrastre ese conteo a través de la ruta de configuración RRC-a-L1 sin acotarlo nunca, y finalmente lo use como límite de bucle para un bucle de escritura en pila dentro del manejador del canal de difusión NB-IoT. Cuando el conteo excede la capacidad de los arrays de destino, el bucle escribe más allá de ellos, alcanza los registros guardados en la pila y sobrescribe la dirección de retorno guardada. La función entonces restaura el valor corrupto en el registro de dirección de retorno y salta a él.
Lo que hace que la gravedad sea la que es:
La vulnerabilidad se publicó en el Boletín de Seguridad de MediaTek del 6 de enero de 2025 con una calificación de gravedad Crítica, afectando a la familia de módems LR12A entre otras. Samsung incorporó la corrección en su Versión de Mantenimiento de Seguridad de febrero de 2025.
Esta publicación no publica un exploit weaponizado y no es reproducible a partir de lo que se publica aquí. El objetivo es mostrar dónde se rompe la cadena, por qué cada capa falló en detenerlo, y qué se necesita para validar un bug de banda base de forma responsable cuando no puedes conectar un depurador al módem en vivo.
Objetivo principal: Samsung Galaxy A14 (SM-A145R). El subsistema de radio está controlado por un procesador de banda base MediaTek de la familia de chipsets MT6769 (Helio G80). La familia MT6769 está explícitamente incluida en la lista de chipsets afectados de MediaTek para CVE-2024-20154.``` AP/CP firmware: A145RXXU1AWD1 Modem software: MOLY LR12A.R3.TC10.6M.A14.PR.SP.V1.P5 Build date: 2023-04-18
El firmware de banda base no es código Android. Es un sistema embebido separado en el
subsistema de radio del SoC con su propia CPU, su propio RTOS y su propio espacio de memoria,
fuera del sandbox de procesos de Android.
### 2.2 Arquitectura del módem
El análisis del binario extraído muestra que el procesador del módem ejecuta MIPS32 con
instrucciones comprimidas MIPS16e2 en modo little-endian. MIPS16e2 es una extensión de
codificación de 16 bits para la reducción del tamaño de código embebido — consistente con el
enfoque de MediaTek para las bandas base de la generación Helio, confirmado por investigación
independiente publicada sobre bandas base de esta familia de SoC.
El sistema operativo es Nucleus RTOS, que proporciona planificación de tareas, colas de
mensajes IPC y un asignador de memoria basado en pools. No hay separación de privilegios
kernel/usuario, no hay aplicación de unidad de protección de memoria entre tareas y no hay
mecanismo de protección de pila por hardware.
Todas las direcciones en este post son direcciones virtuales, tal como se cargan en Ghidra con
base `0x90000000`.
### 2.3 Mitigaciones (observadas en la compilación analizada)
| Mitigación | Estado | Efecto |
|---|---|---|
| ASLR | Ausente | Las direcciones del firmware son estáticas y predecibles a partir de la imagen |
| Stack canary | Ausente | `SAVE`/`RESTORE` almacena registros callee-saved sin valor de guarda |
| NX / W^X | Ausente | La memoria de pila es ejecutable |
| CFI | Ausente | Las direcciones de retorno no se validan contra ninguna política |
### 2.4 Enfoque de análisis
Tres vías paralelas:
**Análisis estático.** Paquete de firmware de Samsung → extracción de la partición CP → `md1img.img` →
Ghidra (MIPS LE 32-bit, base `0x90000000`) con símbolos de ingeniería de MediaTek recuperados de
la sección de depuración del firmware usando el conjunto de herramientas `mtk_bp` de NCC Group.
**Validación dinámica.** Se utilizó Unicorn Engine (emulación MIPS32) para ejecutar rutinas
específicas del firmware de forma aislada en dos fases. La Fase 1 intentó demostrar la copia sin
restricciones de `si_count` en el contexto del canal a través del par de instrucciones nativo. La
Fase 2 ejecutó el bucle vulnerable sobre bytes reales del firmware y confirmó que las propias
instrucciones del firmware corrompen la dirección de retorno guardada. Donde la Fase 1 no pudo
ejecutarse completamente de forma nativa — porque el entorno de objetos de servicio del RTOS
requerido por la ruta de despacho CPHY no fue reconstruido — el efecto secundario se modeló
directamente y se etiquetó como tal en toda la salida.
**Validación del lado de radio.** srsRAN 4G con un loopback ZMQ — solo software, sin emisión de RF —
confirmó que el payload de prueba sobrevive a la codificación PHY de NB-IoT y a la entrega del
bloque de transporte.
---