Ventajas y desventajas de rootear usando aplicaciones ("Soft Root") en comparación con otros métodos ("Hard Root")

Gracias a AndrewT que publicó un enlace en el chat Tener este trabajo de investigación como referencia en uno de los respuestas . Esta respuesta está totalmente basada en el este documento (mayo de 2015) y destaca aspectos comunes comprensibles para el usuario ( tiene mucho seguridad material relacionado para los interesados)

• ¿Cuáles son los pros y los contras, aparte de los mencionados anteriormente?

• Si un dispositivo tiene las dos opciones: el rooting basado en la aplicación y el rooting por métodos de los desarrolladores, ¿por cuál debería optar?

Respuesta: Se trata de la vulnerabilidad del malware. El uso de Root exploits es un riesgo de seguridad ENORME y eso sobrepasa cualquier otra ventaja

¿Qué es root blanda y root dura?

• root blanda : root se obtiene directamente al ejecutando una pieza de software (es decir, Root explota) - ya sea instalando directamente en el dispositivo o requiriendo adb shell a través de una conexión de PC

• root dura : root se obtiene al flashear su binario externamente a través de un paquete de actualización o una ROM

Amenaza de malware - en general

• Aunque sean legítimos, muchos métodos convenientes de Root de un solo clic operan explotando vulnerabilidades en el sistema Android. Si no se controlan con cuidado, el autor del malware puede abusar de estas vulnerabilidades para obtener privilegios Root no autorizados.

• Como se describe en el informe sobre el malware para Android Proyecto Genoma , El 36,7% ( de 1260 ) de las muestras de malware tenían incrustado al menos un exploit Root.

• Estos exploits bien diseñados no están bien protegidos, es extremadamente peligroso si caen en las manos equivocadas.

¿Quiénes son los principales proveedores de Raíces y, a grandes rasgos, cómo funciona?

¿Cuáles son los tipos de expolios de root?

El documento abarca 78 hazañas estudiadas. En general, el orden de impacto ( de la de mayor a menor ) :

• Explotaciones del kernel: Debido a su posición privilegiada, dirigirse al Kernel de Linux es natural para lograr un control total sobre un dispositivo Android- ejemplo ,TowelRoot

• Explotaciones de la biblioteca: los exploits dirigidos a las bibliotecas utilizadas por los procesos del sistema Android, o a las bibliotecas externas utilizadas para dar soporte a diferentes aplicaciones, por ejemplo el exploit ZergRush , libsysutils utilizado por el demonio Volume Manager

• Aplicación y marco de aplicación Capa de aplicación Explotaciones de root : Los exploits dirigidos a aplicaciones o servicios del sistema, en su mayoría incluyen lógicas vulnerables introducidas por setuid utilidades, aplicaciones del sistema o servicios. ejemplo es una setuid utilidad que sólo está presente en los dispositivos XoomFE que tiene una vulnerabilidad de inyección de comandos

• Kernel o controladores específicos del proveedor: Los proveedores personalizan el kernel (por ejemplo, la rama del kernel de Linux personalizada de Qualcomm) o proporcionan controladores de dispositivos específicos del proveedor para varios periféricos (por ejemplo, cámara, sonido). Este código se ejecuta dentro del espacio del kernel y su compromiso puede llevar también a un control total sobre el dispositivo.

En cuanto al número Las hazañas son como las de la figura siguiente

¿Qué tan difícil es poner las manos en el Exploit (Fuente o Binario)?

Muy fácil. Se pueden encontrar fácilmente en la búsqueda de Google, lo que hace que los autores de malware se aprovechen de este tipo de exploits. La búsqueda de 73 exploits en Google llevó a que 68 de ellos estuvieran disponibles: 46 con código fuente y 22 con binarios

¿Cómo funcionan estos exploits?

Requisitos principales para que los exploits funcionen (ordenados de más difícil a menos ) ( malware tiene muchas de estas instancias)

• Requerir las interacciones del usuario: (6 de 78 estudiados)

  • Pedir al usuario que descargue una aplicación e interrumpir manualmente la instalación
  • Pedir al usuario que arranque en la recuperación al menos una vez .
  • Pedir al usuario que ponga manualmente el dispositivo en modo "ahorro de batería". ahorro de batería".
  • Pedir al usuario que abra una aplicación específica del proveedor y pulse un botón

• Requiere adb a través de una conexión de PC: (17 de 78 estudiados). Para algunas hazañas, adb La conexión de shell es necesaria por las siguientes razones más comunes:

  • El exploit puede modificar con éxito un ajuste en local.prop que permite a Root for adb sólo la cáscara.

  • El exploit necesita escribir en un archivo propiedad del grupo shell y escribible por el grupo (no escribible por el mundo)

  • El exploit se dirige al proceso daemon adb que requiere que el proceso de ataque se ejecute con el usuario shell. Por ejemplo, el La rabia contra la jaula explota se centra en la vulnerabilidad del demonio adb que no comprueba el valor de retorno de setuid()

• Reinicia: (6 de 78 estudiados) Por lo general, muchos exploits Root requieren al menos un reinicio. Por ejemplo, un ataque de enlace simbólico permitiría a un atacante eliminar un archivo propiedad del sistema con un permiso débil, para establecer un enlace en la misma ubicación con un archivo protegido. Después de un reinicio, los scripts init correspondientes intentarían cambiar el permiso del archivo original a world-writable, lo que en realidad cambia el permiso del archivo vinculado

• Ninguno o permiso: (44 de 78 estudiados) Los exploits de esta categoría no tienen requisitos estrictos, sin embargo, algunos de ellos pueden requerir ciertos permisos de Android como READ LOGS para que el propietario del proceso sea colocado en un determinado grupo de usuarios.

¿Pueden estos exploits ser detectados por los antivirus?

Dado que los exploits Root son altamente sensibles y pueden ser aprovechados por varios malware para Android, se espera que el software antivirus en la plataforma Android pueda identificar la mayoría de ellos, incluyendo los implementados por los proveedores de Root. En general, el resultado muestra que los productos de seguridad de última generación en la plataforma Android siguen no puede hacer frente a los exploits de root de forma eficaz

Se utilizaron 4 productos antivirus representativos de Android para probar la mayor proveedor (nombre no revelado) con 167 exploits. Dado que los exploits descargados originalmente de la base de datos de los proveedores han empaquetado el código real del exploit y han empleado un mecanismo de detección de manipulaciones, el estudio elaboró 3 versiones diferentes para cada exploit:

1. La hazaña original se obtiene directamente de los servidores de los proveedores, con empaquetado y detección de manipulaciones.

2. Unpacked exploit, que expondrá toda la lógica real del exploit a productos antivirus.

3. Explotación reempaquetada con la detección de manipulaciones desactivada.

Los binarios de exploits diseñados por los grandes proveedores de Root son sorprendentemente "limpio" ya que todos los principales programas antivirus tienen dificultades para detectarlos, como muestra la siguiente tabla

Conclusión:

Simple. Aléjate de Métodos de root blanda a menos que seas capaz de afrontar las consecuencias

A petición de OP, algunos detalles del chat :

Buena pregunta, pero difícil de responder: hay que tener en cuenta algunas cosas más.

1. no es sólo "basado en la aplicación contra el USB" - e incluso su "Dificultad para desrootear" no es necesariamente la culpa de "basado en la aplicación" en general, sino más bien la de una aplicación específica que causa esa dificultad.
2. Desde el punto de vista de la seguridad: si hay una aplicación que puede rootear mi dispositivo, ¿quién dice que otra aplicación no lo haga sin mi consentimiento? Todos sabemos que hay malware por ahí que hace exactamente eso (para integrarse como aplicación del sistema, para estar protegido contra el reinicio de fábrica).
3. Sin embargo, si no hay tal aplicación (y con la esperanza de que sea porque no se puede hacer por una aplicación en este dispositivo/ROM), es mucho más difícil para tal malware. Si entonces hay un método fácil vía USB, me siento un poco más seguro :) Es bastante improbable que alguna otra aplicación consiga conectar un cable USB, descargar algo en mi ordenador y ejecutar ese combo para hacer daño.

Así que lo anterior podría contar como "basado en una contra aplicación" - pero si tal aplicación ya existe para el dispositivo en cuestión, no hay mucho que podamos hacer. Incluso si decimos que "es más seguro al revés", eso no nos protege contra el número 2. Claro que podemos comprobarlo antes de comprar un dispositivo, pero ¿quién dice que esa aplicación no aparezca al día siguiente?