Pros y contras 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 , teniendo este trabajo de investigación como referencia en una de las respuestas . Esta respuesta se basa completamente en este documento (mayo de 2015) y destaca aspectos comunes comprensibles para el usuario (tiene mucho material relacionado con la seguridad para los interesados)

• ¿Cuáles son los pros y los contras aparte de lo anterior?

• Si un dispositivo tiene ambas opciones: enraizamiento basado en aplicaciones y enraizamiento por métodos de desarrolladores, ¿cuál debo elegir?

Respuesta: Se trata de la vulnerabilidad del malware. El uso de exploits de raíz es un riesgo de seguridad ENORME y eso pesa más que cualquier otra ventaja

¿Qué es la raíz blanda y la raíz dura?

• Raíz blanda: la raíz se obtiene directamente mediante la ejecución de una pieza de software (es decir, exploits de raíz), ya sea instalándolo directamente en el dispositivo o requiriendo adbshell a través de una conexión de PC

• Hard Root: la raíz se obtiene al flashear su binario externamente a través de un paquete de actualización o ROM

Amenaza de malware: en general

• Aunque son legítimos, muchos métodos convenientes de raíz con un solo clic funcionan al explotar vulnerabilidades en el sistema Android. Si no se controlan con cuidado, el autor del malware puede abusar de estos exploits para obtener privilegios de raíz no autorizados.

• Como se describe en Android Malware Genome Project , el 36,7 % (de 1260) muestras de malware tenían al menos un exploit de raíz integrado.

• 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íz y, en términos generales, cómo funciona?

¿Cuáles son los tipos de raíz expolits?

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

• Exploits del kernel: debido a su posición privilegiada, apuntar al kernel de Linux es natural para lograr el control total sobre un dispositivo Android, por ejemplo, TowelRoot

• Exploits de biblioteca: los exploits dirigidos a bibliotecas que utilizan los procesos del sistema Android, o bibliotecas externas utilizadas para admitir diferentes aplicaciones, por ejemplo, ZergRush exploit, libsysutils utilizados por Volume Manager daemon

• Exploits de raíz de la capa de aplicación: exploits dirigidos a aplicaciones o servicios del sistema, en su mayoría incluyen lógicas vulnerables introducidas por setuidutilidades, aplicaciones del sistema o servicios. El ejemplo es una setuidutilidad vulnerable que solo está presente en dispositivos XoomFE que tienen una vulnerabilidad de inyección de comandos.

• Kernel o controladores específicos del proveedor: los proveedores personalizan el kernel (p. ej., la rama del kernel de Linux personalizada de Qualcomm) o proporcionan controladores de dispositivo específicos del proveedor para varios periféricos (p. ej., cámara, sonido). Dicho código se ejecuta dentro del espacio del kernel y el compromiso del cual también puede conducir a un control total sobre el dispositivo.

En cuanto a los números , las hazañas son como en la figura a continuación.

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

Muy fácil. Fácilmente disponible desde la búsqueda de Google, lo que hace que sea pan comido para los autores de malware aprovechar tales vulnerabilidades. Al buscar en Google 73 exploits, 68 de ellos están disponibles: 46 con código fuente y 22 con archivos binarios.

¿Cómo funcionan estos exploits?

Principales requisitos para que funcionen los exploits (ordenados de más difícil a menos ) ( la etiqueta de malware tiene muchas de estas instancias)

• Requerir 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 inicie la recuperación al menos una vez.
  • Solicitar al usuario que ponga manualmente el dispositivo en modo de "ahorro de batería".
  • Pedir al usuario que abra una aplicación específica del proveedor y presione un botón

• Requiere adbshell a través de una conexión a PC: (17 de 78 estudiados). Para algunos exploits, adbse requiere una conexión de shell debido a las siguientes razones más comunes:

  • El exploit puede modificar con éxito una configuración en local.propla que habilita la raíz adbsolo para shell.

  • El exploit necesita escribir en un archivo propiedad de group shell y de escritura grupal (no de escritura mundial)

  • El exploit tiene como objetivo el proceso del demonio adb que requiere que el proceso de ataque se ejecute con el usuario shell. Por ejemplo, el exploit Rage Against the Cage apunta a la vulnerabilidad de la verificación faltante del demonio adb sobre el valor de retorno desetuid()

• Reiniciar: (6 de 78 estudiados) Generalmente, muchos exploits de raíz 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 permisos débiles, para configurar un enlace en la misma ubicación a un archivo protegido. Después de un reinicio, los scripts de inicio correspondientes intentarían cambiar el permiso del archivo original a escritura mundial, lo que en realidad cambia el permiso del archivo vinculado.

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

¿Pueden estos exploits ser detectados por Anti-Virus?

Dado que los exploits de raíz son muy sensibles y pueden ser aprovechados por varios programas maliciosos de Android, se espera que el software antivirus en la plataforma Android pueda identificar la mayoría de ellos, incluidos los implementados por los proveedores de raíz. En general, el resultado muestra que los productos de seguridad de última generación en la plataforma Android aún no pueden abordar las vulnerabilidades de raíz de manera efectiva.

Se utilizaron 4 productos antivirus de Android representativos para probar el proveedor más grande (nombre no revelado) que tiene 167 vulnerabilidades. Debido a que los exploits descargados originalmente de la base de datos de proveedores incluyeron el código de exploit real y emplearon un mecanismo de detección de manipulaciones, el estudio elaboró ​​3 versiones diferentes para cada exploit:

1. Exploit original obtenido directamente de los servidores de los proveedores, con empaquetado y detección de manipulaciones activados.

2. Exploit desempaquetado, que expondrá toda la lógica de explotación real a los productos antivirus.

3. Vulnerabilidad reempaquetada con detección de manipulaciones deshabilitada.

Los binarios de explotación diseñados por grandes proveedores de raíz son sorprendentemente "limpios" , ya que todos los principales programas antivirus tienen dificultades para detectarlos, como muestra la tabla a continuación.

Conclusión

Simple. Manténgase alejado de los métodos de raíz suave a menos que sea capaz de lidiar con las consecuencias

Hay algunas ventajas de rootear usando el proceso oficial.

1. Es oficialmente compatible con muchos teléfonos. Esto significa que puede usar un proceso documentado por el fabricante y herramientas de una fuente oficial o de un tercero confiable (CWM o TWRP), en lugar de tener que ejecutar una herramienta que obtuvo de un sitio web dudoso.

2. Debido a que es compatible oficialmente, la mayoría de las veces, una actualización del sistema no cambiará el proceso, por lo que no necesita buscar el método de enraizamiento "más reciente". Por el contrario, las actualizaciones de software tienden a parchear las vulnerabilidades, por lo que los métodos de explotación a menudo dejarán de funcionar después de una actualización.

3. Debido a lo anterior, después de realizar un "rooteo suave", es posible que tenga la tentación de no instalar una actualización del sistema, ya que esa actualización corrige la vulnerabilidad y detiene el funcionamiento de su método de rooteo. Con el proceso oficial, no hay razón para permanecer en una versión antigua y vulnerable.

Además de la conveniencia de un método de un solo clic (mencionado en la pregunta), existen otras ventajas de hacerlo de esa manera.

1. Desbloquear el cargador de arranque para "raíz dura" borra el teléfono, por lo que debe configurar las cosas nuevamente y restaurar los datos desde la copia de seguridad. Por lo general, el "enraizamiento suave" a través de una vulnerabilidad no necesita borrar el teléfono, y eso puede ser mucho más conveniente.

2. Debido a que el enrutamiento modifica la partición del sistema, por lo general no puede realizar una actualización OTA después: el actualizador reconoce que el sistema se modificó y se retira. Pero algunos métodos de "raíz suave" en algunos teléfonos evitan este problema, por lo que puede realizar una actualización OTA sin tener que desrootear o actualizar una nueva imagen del sistema. Esto también es un poco más fácil. De cualquier manera, aún tendrá que volver a rootear después de una actualización.

3. Dado que no tiene que desbloquear el cargador de arranque, no existe la tentación de dejarlo desbloqueado. Esto tiene el beneficio de seguridad de que las personas no pueden flashear nuevas ROM en su teléfono (por ejemplo, si se lo roban y quieren eludir el bloqueo de pantalla o la protección de restablecimiento de fábrica).

Lo que dice Beeshyams sobre la seguridad es importante, pero en mi opinión es irrelevante para la pregunta. Es bueno señalar o recordar a las personas que cada método de "enraizamiento suave" está explotando una vulnerabilidad de seguridad, y el malware podría usar la misma vulnerabilidad para instalar rootkits en su teléfono. Sin embargo, la vulnerabilidad está ahí, ya sea que la uses o no. El riesgo de seguridad proviene de la posibilidad del método de enraizamiento. Rootear su teléfono aprovechando la vulnerabilidad no lo hace más explotable o peor.

Si su teléfono puede ser rooteado por una aplicación/exploit de rooteo, entonces es vulnerable al malware. Esto es cierto de la misma manera, independientemente de si lo rooteas o qué método usas. No usar el exploit (haciendo un "rooteo duro" en su lugar, o simplemente no rooteando) no lo protegerá del malware, ni reducirá su exposición.

^{A pedido de OP, algunos detalles del chat :}

Buena pregunta, pero difícil de responder: hay algunas cosas más a considerar.

1. no se trata solo de "basado en aplicaciones versus USB", e incluso su "dificultad para desrootear" no es necesariamente culpa de "basado en aplicaciones" en general, sino 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 hace sin mi consentimiento? Todos sabemos que hay malware que hace exactamente eso (para integrarse como aplicación del sistema, para protegerse contra el restablecimiento de fábrica).
3. Sin embargo, si no existe tal aplicación (y con la esperanza de que sea porque una aplicación no puede hacerlo en este dispositivo/ROM), es mucho más difícil para dicho malware. Si hay un método fácil a través de USB, me siento un poco más seguro :) Es poco probable que otra aplicación logre conectar un cable USB, descargar algo a mi computadora y ejecutar ese combo para hacer daño.

Por lo tanto, lo anterior podría contar como "basado en una aplicación contraria", pero si dicha aplicación ya existe para el dispositivo en cuestión, no hay mucho que podamos hacer al respecto. Incluso si decimos "es más seguro al revés", eso no nos protege contra el #2. Claro, podemos verificar eso antes de comprar un dispositivo, pero ¿quién dice que una aplicación así no aparece al día siguiente?