Investigador demuestra dos fallos de OxygenOS en OnePlus 15 que permiten root con app local

Un investigador en seguridad, Rasmus Moorats, ha demostrado que un OnePlus 15 con la última versión de OxygenOS puede ser tomado por completo por una aplicación maliciosa que el propietario instala voluntariamente, incluso si esa app no solicita permisos especiales. Moorats encadenó dos fallos en software propio de OnePlus para escalar privilegios hasta alcanzar root —el nivel más alto de control en un teléfono Android— y publicó sus hallazgos el 24 de septiembre después de varios meses de comunicación con la compañía. OnePlus confirmó en mayo la existencia de las dos vulnerabilidades y declaró que problemas similares afectan a más modelos suyos y a otros de OPPO, aunque no identificó cuáles.

En términos técnicos, la cadena de explotación utiliza dos servicios preinstalados de OxygenOS. El primero es AtlasService, un servicio que recopila datos de depuración y que, según Moorats, corre con privilegios de root y acepta llamadas de cualquier aplicación sin verificar la identidad de quien llama. Una petición especialmente construida alcanza una herramienta de depuración que toma texto provisto por la aplicación y lo inserta sin saneamiento en un comando del sistema. Ese error por sí solo concede privilegios root dentro de una zona del sistema llamada dumpstate; es un root funcional pero restringido. El segundo fallo es independiente y complementario: un servicio de hardware llamado olc2 que ofrece una interfaz para ejecutar comandos de shell. Su única barrera es comprobar que el llamador ya tenga privilegios root. Con la primera vulnerabilidad se obtiene ese root en dumpstate, y con la segunda se ejecuta un comando en un contexto que otorga privilegios Linux de bajo nivel, incluida la posibilidad de cargar código en el kernel. El resultado final es control a nivel del sistema sobre el dispositivo.

Es importante remarcar que el ataque es local: necesita que la aplicación maliciosa haya sido instalada y esté ejecutándose en el teléfono; no puede lanzarse remotamente a través de Internet sin interacción local. Sin embargo, las condiciones que requiere la app para iniciar la explotación son mínimas: según el investigador, no pide permisos especiales ni muestra ningún aviso al usuario, y funcionó en un teléfono de serie sin modificaciones.

Los hechos confirmados en la cronología que proporcionó Moorats son claros: la notificación inicial a OnePlus fue el 18 de abril; la compañía confirmó las fallas el 20 de mayo y, en esa comunicación, afirmó que controlaría la divulgación y que la publicación sin su consentimiento podría conllevar responsabilidad legal. OnePlus informó que programaría una corrección, pidió a Moorats que aguantara y le dio una fecha hasta la que no publicar; cuando esa fecha llegó y no hubo arreglo público, Moorats publicó el 24 de septiembre. Al momento de su divulgación no existía un CVE asignado ni un parche disponible, según su relato. Moorats también reprodujo la cadena en un OnePlus 12 Pro y estima que el problema afecta de forma general a OxygenOS 16; OnePlus y OPPO comparten una base de software que explicaría la cobertura entre marcas.

Qué se sabe con certeza y qué no: está confirmado que Moorats encontró y combinó dos fallos en servicios de OxygenOS que permiten escalar a root cuando una app maliciosa está instalada. También está confirmado que OnePlus fue informado, reconoció las fallas en mayo y advirtió sobre la divulgación. Está confirmado que, según Moorats, no hay evidencia pública de explotación en el mundo real hasta la fecha de su publicación. En lo que concierne a alcance exacto de dispositivos afectados y fechas de parche, eso sigue siendo incierto: OnePlus no ha publicado una lista de modelos ni un aviso técnico público ni ha dado un calendario de corrección verificable al momento de la divulgación.

Las consecuencias prácticas para usuarios y administradores son claras en el modelo de amenaza de este fallo: un atacante únicamente necesita convencer o engañar al propietario para que instale una aplicación localmente —por ejemplo, mediante sideloading, un paquete adjunto o un enlace para instalar fuera de tiendas oficiales— y esa app puede elevarse silenciosamente a root sin pedir permisos. Con root y capacidad para cargar código de kernel, un atacante puede instalar persistencia profunda, desactivar controles de seguridad, acceder a datos cifrados en memoria y ocultar su presencia. En entornos corporativos eso equivale a perder el control del dispositivo y potencialmente del acceso a sistemas de la empresa si el teléfono se usa para autenticación o correo.

La dificultad real de explotar esta vector está en el primer paso: la instalación de la app maliciosa. Hasta que los proveedores publiquen y desplieguen parches, la defensa más práctica y efectiva para usuarios finales es restringir la instalación de aplicaciones a fuentes de confianza. Evitar sideloading, no instalar APKs procedentes de terceros y usar tiendas oficiales con protecciones (como Google Play con Play Protect) reduce significativamente el riesgo. La cadena descrita por Moorats no prospera sin una app local instalada.

Recomendaciones concretas y comprobables para usuarios:

1) No instalar aplicaciones fuera de tiendas oficiales y, si debe hacerse, verificar el origen y la firma del APK. Deshabilite la instalación desde “orígenes desconocidos” en los ajustes del sistema cuando no sea necesaria. 2) Mantenga la depuración USB desactivada salvo que se use activamente y supervise los dispositivos conectados: la depuración abierta facilita la instalación de software no deseado. 3) Revise periódicamente las apps instaladas (ajustes → aplicaciones) y elimine todo lo que no reconozca; use herramientas de reputación como Google Play Protect. 4) Haga copias de seguridad y mantenga una imagen reciente de los datos importantes por si fuese necesario un restablecimiento de fábrica. 5) Para empresas: aplique políticas MDM que bloqueen la instalación de apps no aprobadas y restrinjan modos de desarrollador en dispositivos corporativos.

Para investigadores y profesionales de seguridad, el caso plantea además una discusión sobre prácticas de divulgación responsable. OnePlus declaró que la decisión final sobre cuándo publicar vulnerabilidades le corresponde —una postura que Moorats reproducía en su intercambio y que motivó la amenaza de acciones legales si publicaba— y que las normas europeas obligan a aceptar y corregir reportes pero no permitirían la divulgación por investigadores sin el consentimiento del fabricante. Esa interpretación legal es controvertida entre la comunidad de seguridad, que suele defender divulgaciones coordinadas con plazos razonables si el proveedor no aplica parches. Para orientación sobre buenas prácticas de divulgación existe material público de organismos como ENISA: ENISA — Coordinated Vulnerability Disclosure, y para aspectos técnicos de Android y mitigaciones de seguridad puede consultarse la documentación oficial: Android Security — source.android.com.

Finalmente, si cree que su dispositivo OnePlus u OPPO podría estar comprometido o ha instalado aplicaciones de origen dudoso, considere reinstalar el sistema desde la imagen oficial o restaurar a valores de fábrica y, de ser posible, esperar el aviso y parche del fabricante antes de volver a instalar aplicaciones fuera de la tienda oficial. También es aconsejable permanecer atento a canales oficiales de OnePlus para un aviso de seguridad y parche: la compañía dispone de una web de soporte y políticas de seguridad donde deberían publicarse actualizaciones y procedimientos de mitigación —por ejemplo, su centro de seguridad o soporte técnico— OnePlus Support & Security.

El caso subraya una realidad recurrente en dispositivos Android con capas de fabricante: cualquier código adicional que se ejecute con privilegios elevados multiplica la superficie de ataque. Hasta que los proveedores publiquen correcciones y listas de modelos afectados, la mejor defensa es la higiene digital del usuario y, para organizaciones, políticas técnicas que limiten instalaciones y privilegios.