- En una solicitud de función de IssueTracker en curso, no en un anuncio oficial de Google, un responsable principal del mantenimiento de ADB mencionó la posibilidad de restringir las conexiones locales y enlazarlas solo a
wlan0para evitar abusos - Si solo se permite
wlan0, podría dejar de funcionar no solo el ADB en el propio dispositivo que usa la dirección de loopback127.0.0.1, sino también ADB sobre VPN o Ethernet y varios entornos de desarrollo - La discusión comenzó a partir de CVE-2026-0073, que eludía por completo la autenticación de Wireless ADB, y la solicitud original buscaba permitir elegir la interfaz de escucha de ADBD para que no quede expuesto en todas las redes
- Una app maliciosa común no puede iniciar ADBD directamente ni completar por sí sola el emparejamiento de Wireless ADB o la autorización de TCP/IP, por lo que es difícil obtener privilegios de ADB sin interacción manual del usuario
- Si se bloquea permanentemente la conexión por loopback, se verán afectados Shizuku y las herramientas basadas en libadb-android, por lo que haría falta una opción configurable por el usuario para desactivar el bloqueo predeterminado incluso después de reiniciar
Discusión inicial, no anuncio oficial
- Este tema no se basa en una política confirmada ni en un anuncio oficial de Google, sino en una solicitud de función de IssueTracker en curso y en comentarios del responsable principal del mantenimiento de ADB
- El responsable mencionó la posibilidad de enlazar ADBD solo a
wlan0, la interfaz Wi‑Fi, citando casos en los que apps usaron el socket local de ADBD para elevar privilegios - En la discusión pública se debe evitar protestar sin aportar, insultar o repetir el mismo caso de uso
- Si tienes un caso de uso propio, puedes dejar una opinión concreta incluyendo tu flujo de trabajo, enlaces relacionados y posibles compromisos técnicos
- Si ese mismo caso ya fue registrado, se recomienda usar +1 y las notificaciones en lugar de repetir comentarios
- Si se acumulan comentarios de baja calidad, el issue podría bloquearse o reducirse la cantidad de retroalimentación útil y actualizaciones públicas
Las tres formas de conexión de ADB
- ADB es un protocolo que ofrece acceso a comandos con altos privilegios para desarrolladores y usuarios avanzados que prueban y administran dispositivos Android
- Sus principales formas de conexión se dividen en tres
- USB: el método original, que conecta directamente al dispositivo mediante un cable USB desde otra computadora
- ADB TCP/IP: normalmente usa el puerto
5555, transmite el tráfico en texto plano y se autentica con una ventana de aprobación YES/NO. Solo puede activarse si ya existe una conexión ADB previa - Wireless Debugging: se introdujo en Android 11 y permite emparejar una computadora con un código o código QR para establecer una conexión autenticada y cifrada. No requiere una conexión ADB previa para activarse
El ecosistema que creó el ADB en el propio dispositivo
- El uso normal de ADB conecta el ADBD del dispositivo Android con un cliente ADB en una computadora aparte, pero también hay desarrolladores que trabajan directamente desde el dispositivo sin computadora
- ADB en el propio dispositivo (On-Device ADB) no es un término oficial, sino una forma de referirse a ejecutar un cliente ADB en un emulador de terminal como Termux y conectarlo al ADBD del mismo dispositivo
- Usa ADB TCP/IP o Wireless Debugging
- Como el cliente y el servidor están en el mismo dispositivo, se usa la dirección de loopback
127.0.0.1
- Este enfoque sirve de base para proyectos open source dirigidos a desarrolladores y usuarios avanzados, como libadb-android y Shizuku
- ShizuCallRecorder es una app basada en Shizuku creada para reducir dificultades cotidianas relacionadas con una discapacidad
- Un usuario la utilizó para conservar el buzón de voz de un familiar fallecido
- La grabación de llamadas en Android fue una función muy solicitada; se impulsó oficialmente en Android 11 pero luego se canceló, y hoy existen apps de evasión cerradas o potencialmente invasivas para la privacidad
- Algunos OEM fuerzan un aviso de grabación de llamadas incluso en regiones donde no es un requisito legal
Solicitud para elegir interfaz y restricción a wlan0
- El objetivo original de la nueva solicitud de función es permitir que el desarrollador elija la interfaz de red en la que ADBD escuchará conexiones entrantes
- El contexto incluye CVE-2026-0073, que podía eludir por completo el proceso de autenticación de Wireless ADB
- Actualmente ADBD puede ser accesible desde todas las redes a las que esté conectado el teléfono, así que la función de selección de interfaz sí podría reducir la superficie expuesta
- Sin embargo, permitir solo
wlan0podría romper las siguientes configuraciones- ADB en el propio dispositivo que usa loopback
- ADB a través de VPN
- ADB a través de Ethernet
- Otros entornos de desarrollo especiales
- Incluso desarrolladores de Android han usado ADB en el propio dispositivo cuando no podían acceder a una computadora
Restricciones que una app maliciosa tendría que superar
- Aunque el ADB en el propio dispositivo puede usarse para elevar privilegios, una app maliciosa común no puede establecer la conexión por sí sola
-
Usuarios normales de Android
- Si ADB está desactivado, ADBD no se ejecuta
- Una app maliciosa tampoco tiene el permiso
WRITE_SECURE_SETTINGS, que debe otorgarse manualmente mediante ADB, así que le resulta difícil intentar un ataque con ADB
-
Desarrolladores que usan Wireless ADB en Android 11 o superior
- El usuario debe activar manualmente la depuración USB y Wireless ADB para que ADBD escuche en una interfaz de red
- Para que la app se conecte, el usuario debe obtener y proporcionar el código de emparejamiento de un solo uso desde la pantalla de configuración, así que la app no puede conectarse por sí sola
-
Desarrolladores que usan ADB TCP/IP
- El usuario debe activar la depuración USB, habilitar TCP/IP mediante ADB por USB y luego desconectar el cable
- Cuando la app intenta iniciar la conexión, aparece una ventana de autorización en pantalla, y si el usuario elige No, la conexión se rechaza
- En un estado de autenticación normal, la app no puede conectarse y atacar sin que el usuario lo note
Riesgo de vulnerabilidades y alcance del bloqueo
- En condiciones normales, una app maliciosa no puede iniciar ADBD directamente, así que la posibilidad de conexión solo aparece cuando un desarrollador está usando ADB en el dispositivo
- Si existiera una vulnerabilidad que eludiera la autenticación, como CVE-2026-0073, podría explotarse en entornos de Wireless ADB y TCP/IP
- Aun así, el usuario tendría que activar manualmente la depuración USB primero
- En el modo TCP/IP, el usuario también tendría que habilitar manualmente ADB TCP/IP
- Debe distinguirse entre bloquear por defecto las conexiones por loopback y aplicar un bloqueo permanente que el usuario no pueda desactivar
- También es posible que una app maliciosa reciba designación de administrador del dispositivo o permisos de accesibilidad mediante interacción del usuario, pero esa sola posibilidad no implica eliminar por completo esas funciones
Un punto medio que preserve la elección del usuario
- El bloqueo de loopback debería ser una configuración persistente que el usuario pueda desactivar explícitamente
- Debería mantenerse incluso después de reiniciar para que herramientas como Shizuku sigan siendo prácticas
- Si es posible, las apps de terceros no deberían poder leer el estado de la configuración, para evitar tener que cambiarla repetidamente solo para esquivar la detección por parte de apps bancarias o juegos
- Si se otorga manualmente
WRITE_SECURE_SETTINGSa una app, algunas restricciones podrían eludirse
- Lo adecuado sería permitir que el usuario desactive la función de seguridad, habilite la depuración en el propio dispositivo y, al mismo tiempo, asuma el riesgo de quedar expuesto a futuras vulnerabilidades
- Si se bloquea permanentemente el ADB en el propio dispositivo, se vería afectado un ecosistema open source de nicho como el siguiente
2 comentarios
puaj...
Opiniones de Hacker News
En general estoy a favor de las mejoras de seguridad, pero aquí parece haber muy poco beneficio real. Para que este ataque funcione, el usuario tendría que activar tanto las opciones de desarrollador como ADB remoto, así que para el 99.9% no es una vía de ataque realista, y el 0.1% restante por lo general sabe lo que está haciendo.
Cambiarlo para limitar el acceso a una interfaz o IP específica está bien, pero bastaría con permitir que los desarrolladores lo restrinjan a localhost. Da mucho la impresión de que quieren bloquear Shizuku, Canta y similares disfrazándolo como daño colateral.
disable sandboxpara ejecutar un agente en modo ilimitado, no funciona en móviles.En Firefox ni siquiera se pueden instalar extensiones sin firmar, así que hace falta Developer Edition; los sitios imponen passkeys, y hasta un solo bucket de S3 trae decenas de capas de control de acceso, identidades de servicio, IAM y OAuth. OAuth no funciona en dispositivos headless; los bancos exigen apps dedicadas en vez de TOTP; bloquean VPN; se impulsa la vigilancia con nombre real bajo el pretexto de proteger a menores; y también siguen los intentos de prohibir modelos de pesos abiertos porque supuestamente la información terminaría en China.
La seguridad se volvió un valor absoluto que siempre está por encima de la comodidad, la usabilidad, la privacidad, la posibilidad de modificar y la apertura, y la industria de seguridad informática debería avergonzarse de ello.
Este cambio no parece ser por la seguridad del usuario, sino para proteger intereses corporativos.
Al principio decían que se usara solo Safari, sin App Store, y creo que la raíz estaba en la paranoia particular de Steve Jobs, quien incluso durante su tratamiento contra el cáncer se incomodaba con que dispositivos médicos de diseño poco bello tocaran su cuerpo. La actitud de no permitir que algo “impuro” tocara un dispositivo “perfecto” se justificó después con el lenguaje de la seguridad.
En aquel entonces decían que había que evitar una situación como Windows 98, plagado de malware, pero los sistemas operativos modernos ya superaron por mucho el débil nivel de seguridad de Windows de esa época.
El objetivo de bloquear herramientas de privacidad sin root basadas en Shizuku no es la seguridad del propietario, sino la seguridad del gobierno. Las aplicaciones de entorno de ejecución confiable como el EU Digital Identity Wallet y las funciones que en el futuro se exigirán bajo el pretexto de proteger a menores dependen mucho de la premisa de que el usuario no puede manipular el dispositivo ni instalar software no autorizado. Todos sabemos cómo está resultando Intel SGX.
Restringir ADB es el siguiente paso obvio. Aunque esta propuesta no se apruebe tal cual, Google hizo que incluso tareas normales de computación personal terminen dependiendo de interfaces de desarrollador dentro del dispositivo o por USB/inalámbricas.
Es muy probable que algún día haya que entregar la identidad y pagar una cuota anual, o que se impongan restricciones serias para usar Android de forma significativa. Google no quiere que se desarrollen apps de Android fuera de canales de distribución controlados, y cuando no dio marcha atrás en cambios que prohibían el sideloading normal y legítimo, la batalla ya estaba perdida.
La advertencia de grabación de llamadas también es responsabilidad de Google. Cuando los fabricantes adoptaron el marcador de Google en lugar de sus propios marcadores, que eran mejores, eso se aplicó de forma uniforme incluso en regiones donde no había obligación legal. Es especialmente molesto en SoC MediaTek que no soportan bien la grabación mediante apps estables de terceros a nivel de hardware.
Al final es una prueba de que no poseo “mi” dispositivo, y quizá en unos años Gemini escuche y resuma las llamadas a través de una ruta de vigilancia aprobada.
Me pregunto si también se ofrecerán medios alternativos para usos legítimos. Si eliminan una función sin dar una alternativa, los desarrolladores terminan empujados a soluciones más vulnerables o, a veces, a atajos que rompen las reglas.
Esta reacción parece una gran sobrerreacción nacida de un malentendido. Yo uso ADB remoto para instalar nuevas builds de un proyecto Android en desarrollo y obtener logs, y actualmente me conecto mediante una VPN de Tailscale.
Pero con el método actual, en cada Wi-Fi público al que se conecta el dispositivo podrían quedar expuestas incluso vulnerabilidades previas a la autenticación. Si se pudiera limitar solo a la interfaz de Tailscale, en realidad sería una mejora.
El punto central de la propuesta es que al configurar ADB remoto se especifique la interfaz a la que debe enlazarse, en lugar de todas las interfaces. No dice que localhost vaya a rechazarse, y la breve propuesta de enlazarlo solo a
wlan0es claramente equivocada porque es menos confiable que una VPN, y seguramente tampoco será la dirección real de la implementación.Aunque el spam en el hilo haga que un desarrollador de Google cierre el issue e ignore el feedback, nada cambiará respecto a la situación actual. Si las críticas en sí molestan, también pueden cerrar feedback valioso, así que siéntanse libres de expresar su apoyo.
Google a veces recibe feedback de desarrolladores de apps, pero es natural que dé más peso al criterio de sus equipos internos que al de desarrolladores open source que dependen de este tipo de atajos.
El demonio ADB claramente no fue diseñado para que una app abra una sesión ADB hacia la dirección de loopback y así habilite la grabación de llamadas. Vuelve a venir a la mente https://xkcd.com/1172/.
Eso no significa que los desarrolladores estén equivocados por no gustarles el cambio. Google también agregó grabación de llamadas al marcador, así que apoya esa función en sí, pero eso no implica que el equipo de ADB no deba hacer endurecimiento de seguridad.
Cuando Google anunció por primera vez las restricciones al sideloading, dijeron “igual queda ADB”, y quienes se opusieron recibieron críticas durísimas.
Ahora incluso habrá que esperar por métodos alternativos para habilitar ADB, y Android hace mucho que ya no era más abierto que iOS. Esta tendencia va a continuar.
Como es un problema no técnico —la mentalidad de Google—, no se puede resolver con soluciones técnicas.
Aunque puedas instalar tu propio software, el dispositivo se trata como “alterado”. Si falla la atestación, no se te considera confiable y pasas a ser un ciudadano de segunda, excluido de casi todos los ámbitos de la sociedad digital: comunicaciones, banca, streaming, juegos, etc.
Ese es el futuro de Android, y GrapheneOS es la última esperanza porque algunas empresas empezaron, casi milagrosamente, a confiar en las claves de atestación de GrapheneOS. Si incluso esa esperanza desaparece, mejor comprar un iPhone.
Era algo que obviamente iba a pasar. Después, si el límite de 24 horas para el sideloading se vuelve indefinido, seguro la gente también se va a sorprender.
No hace falta que tome todo el mercado; alcanza con que haga dudar a Google o que complique legalmente la implementación. Algo parecido al rol ideal de Firefox frente a Chrome.
Que Android se cierre a este nivel es una señal de alarma grave. Están eliminando, de a poco y uno por uno, los elementos que hacían bueno a Android.
Me preocupa que pronto pase lo mismo con los sitios web. Podría terminar siendo que, para permitir que un sitio se abra en dispositivos Apple, haya que pagarle a Apple, y en dispositivos Android, a Google, una cuota mensual.
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Todavía no hay una cuota, pero Google pasa a poder decidir qué dispositivos pueden acceder a una cantidad considerable de sitios web.
Es muy probable que el contenido de la vieja web sea raspado a gran escala por empresas de IA y luego reproducido para el público a través de la nueva web.
Necesitamos Linux para smartphones. Si las operaciones bancarias pueden hacerse desde el navegador, no hace falta una app, pero los dispositivos de comunicación inalámbrica y apps importantes como Sonos y Spotify tienen que funcionar.
Hace falta una ley que obligue a que los servicios esenciales, como bancos y servicios públicos, tengan un entorno web que funcione correctamente. Si no, el duopolio actual se consolidará aún más.
Yo también debería apoyar de forma más activa eligiendo proveedores que ofrezcan servicios web.
Se puede revisar en la wiki de postmarketOS la lista de dispositivos compatibles para ver si el que ya tienes está soportado y, si es posible, contribuir a mejorar el soporte. Si no, en eBay se pueden encontrar dispositivos usados con buen estado de soporte.
Librem 5 y PinePhone tienen buen soporte, pero dispositivos Android antiguos como el OnePlus 6T pueden ofrecer mejor relación precio-rendimiento. Antes de comprar, hay que verificar si las funciones clave funcionan.
Las apps populares de Android se pueden ejecutar con Waydroid.
La alternativa de autenticación por SMS tampoco es segura y está desapareciendo; desde el punto de vista de seguridad es el camino correcto, pero faltan otros medios utilizables.