Implementa la seguridad

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El equipo de seguridad de Android recibe solicitudes de información con frecuencia para evitar posibles problemas de seguridad en los dispositivos Android. En ocasiones, también realizamos verificaciones puntuales de los dispositivos y les informamos a los fabricantes y socios afectados sobre posibles problemas.

En esta página, se proporcionan prácticas recomendadas de seguridad basadas en nuestras experiencias, que extienden la documentación de Diseño para la seguridad que proporcionamos a los desarrolladores y que incluye detalles únicos para compilar o instalar software a nivel del sistema en dispositivos.

Para facilitar la adopción de estas prácticas recomendadas, el equipo de seguridad de Android incorpora pruebas en el Conjunto de pruebas de compatibilidad de Android (CTS) y Android Lint siempre que es posible. Recomendamos a los implementadores de dispositivos que aporten pruebas que puedan ayudar a otros usuarios de Android (consulta las pruebas relacionadas con la seguridad en root/cts/tests/tests/security/src/android/security/cts).

Proceso de desarrollo

Usa las siguientes prácticas recomendadas en tus procesos y entornos de desarrollo.

Revisa el código fuente

La revisión del código fuente puede detectar una amplia variedad de problemas de seguridad, incluidos los que se identifican en este documento. Android recomienda encarecidamente la revisión manual y automática del código fuente. Prácticas recomendadas:

• Ejecuta Android Lint en todo el código de la app con el SDK de Android y corrige los problemas identificados.
• El código nativo se debe analizar con una herramienta automatizada que pueda detectar problemas de administración de memoria, como desbordamientos de búfer y errores de un byte.
• El sistema de compilación de Android admite muchos de los validadores de LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer, que se pueden usar para este fin.

Usa pruebas automatizadas

Las pruebas automatizadas pueden detectar una amplia variedad de problemas de seguridad, incluidos algunos de los que se mencionan a continuación. Prácticas recomendadas:

• El CTS se actualiza periódicamente con pruebas de seguridad. Ejecuta la versión más reciente del CTS para verificar la compatibilidad.
• Ejecuta CTS con regularidad durante el proceso de desarrollo para detectar problemas con anticipación y reducir el tiempo de corrección. Android usa CTS como parte de la integración continua en nuestro proceso de compilación automatizado, que se compila varias veces al día.
• Los fabricantes de dispositivos deben automatizar las pruebas de seguridad de las interfaces, incluidas las pruebas con entradas con el formato incorrecto (pruebas de fuzz).

Firma imágenes del sistema

La firma de la imagen del sistema es fundamental para determinar la integridad del dispositivo. Prácticas recomendadas:

• Los dispositivos no deben estar firmados con una clave que sea conocida públicamente.
• Las claves que se usan para firmar dispositivos deben administrarse de manera coherente con las prácticas estándar de la industria para el manejo de claves sensibles, incluido un módulo de seguridad de hardware (HSM) que proporcione acceso limitado y auditable.

Firma de apps (APKs)

Las firmas de apps desempeñan un papel importante en la seguridad de los dispositivos y se usan para las verificaciones de permisos y las actualizaciones de software. Cuando selecciones una clave para usar en la firma de apps, es importante considerar si una app estará disponible solo en un dispositivo o será común en varios dispositivos. Prácticas recomendadas:

• Las apps no deben estar firmadas con una clave que sea conocida públicamente.
• Las claves que se usan para firmar apps deben administrarse de manera coherente con las prácticas estándar de la industria para el manejo de claves sensibles, incluido un HSM que proporcione acceso limitado y auditable.
• Las apps no deben estar firmadas con la clave de plataforma.
• Las apps con el mismo nombre de paquete no deben estar firmadas con claves diferentes. Esto suele ocurrir cuando se crea una app para diferentes dispositivos, en especial cuando se usa la clave de plataforma. Si la app es independiente del dispositivo, usa la misma clave en todos los dispositivos. Si la app es específica del dispositivo, crea nombres de paquetes únicos por dispositivo y clave.

Publica apps

Google Play les brinda a los fabricantes de dispositivos la capacidad de actualizar apps sin realizar una actualización completa del sistema. Esto puede acelerar la respuesta a los problemas de seguridad y la entrega de funciones nuevas, así como proporcionar una forma de garantizar que tu app tenga un nombre de paquete único. Prácticas recomendadas:

• Sube tus apps a Google Play para permitir actualizaciones automáticas sin necesidad de una actualización completa por aire (OTA). Los usuarios no pueden descargar directamente las apps que se suben, pero estas se siguen actualizando. Los usuarios que hayan instalado la app con anterioridad podrán volver a instalarla o instalarla en otros dispositivos.
• Crea un nombre de paquete de app que esté claramente asociado con tu empresa, por ejemplo, con una marca comercial.
• Las apps que publican los fabricantes de dispositivos deben subirse a Google Play Store para evitar que usuarios externos usurpen el nombre del paquete. Si un fabricante de dispositivos instala una app en un dispositivo sin publicarla en Play Store, otro desarrollador podría subir la misma app, usar el mismo nombre de paquete y cambiar los metadatos de la app. Cuando se le presenta la app al usuario, estos metadatos no relacionados pueden generar confusión.

Responde a los incidentes

Las partes externas deben poder comunicarse con los fabricantes de dispositivos para informar sobre problemas de seguridad específicos del dispositivo. Te recomendamos que crees una dirección de correo electrónico de acceso público para administrar los incidentes de seguridad. Prácticas recomendadas:

• Crea una dirección seguridad@tu-empresa.com o similar y publícala.
• Si te enteras de un problema de seguridad que afecta al SO Android o a dispositivos Android de varios fabricantes, debes comunicarte con el equipo de seguridad de Android. Para ello, envía un informe de errores de seguridad.

Implementa productos

Usa las siguientes prácticas recomendadas cuando implementes un producto.

Aísla los procesos raíz

Los procesos raíz son el objetivo más frecuente de los ataques de elevación de privilegios, por lo que reducir la cantidad de procesos raíz reduce el riesgo de elevación de privilegios. CTS incluye una prueba informativa que enumera los procesos raíz. Prácticas recomendadas:

• Los dispositivos deben ejecutar el código mínimo necesario como root. Cuando sea posible, usa un proceso de Android normal en lugar de un proceso de raíz. El Galaxy Nexus con ICS solo tiene seis procesos raíz: vold, inetd, zygote, tf_daemon, ueventd e init. Si un proceso debe ejecutarse como root en un dispositivo, documenta el proceso en una solicitud de función de AOSP para que se pueda revisar públicamente.
• Siempre que sea posible, el código raíz debe aislarse de los datos no confiables y accederse a él a través del IPC. Por ejemplo, reduce la funcionalidad de root a un servicio pequeño al que se pueda acceder a través de Binder y expón el servicio con permiso de firma a una app con privilegios bajos o sin ellos para controlar el tráfico de red.
• Los procesos raíz no deben escuchar en un socket de red.
• Los procesos de raíz no deben proporcionar un entorno de ejecución de uso general para las apps (por ejemplo, una VM de Java).

Cómo aislar apps del sistema

En general, las apps preinstaladas no deben ejecutarse con el UID del sistema compartido. Sin embargo, si es necesario que una app use el UID compartido del sistema o de otro servicio con privilegios, no debe exportar ningún servicio, receptor de emisión ni proveedor de contenido al que puedan acceder las apps de terceros que instalen los usuarios. Prácticas recomendadas:

• Los dispositivos deben ejecutar el código mínimo necesario como sistema. Cuando sea posible, usa un proceso de Android con su propio UID en lugar de volver a usar el UID del sistema.
• Siempre que sea posible, el código del sistema debe aislarse de los datos no confiables y exponer el IPC solo a otros procesos confiables.
• Los procesos del sistema no deben escuchar en un socket de red.

Aísla procesos

La zona de pruebas de aplicaciones para Android proporciona a las apps una expectativa de aislamiento de otros procesos del sistema, incluidos los procesos de raíz y los depuradores. A menos que la app y el usuario habiliten específicamente la depuración, ninguna app debe incumplir esa expectativa. Prácticas recomendadas:

• Los procesos de raíz no deben acceder a los datos dentro de carpetas de datos de apps individuales, a menos que se use un método de depuración de Android documentado.
• Los procesos de raíz no deben acceder a la memoria de las apps, a menos que se use un método de depuración de Android documentado.
• Los dispositivos no deben incluir ninguna app que acceda a datos o memoria de otras apps o procesos.

Protege los archivos SUID

Los programas no confiables no deben poder acceder a los programas setuid nuevos. Los programas setuid suelen ser la ubicación de vulnerabilidades que se pueden usar para obtener acceso raíz, por lo que debes esforzarte por minimizar la disponibilidad del programa setuid para apps no confiables. Prácticas recomendadas:

• Los procesos de SUID no deben proporcionar un shell ni una puerta trasera que se puedan usar para eludir el modelo de seguridad de Android.
• Ningún usuario debe poder escribir en los programas SUID.
• Los programas SUID no deben ser legibles ni ejecutables por todos. Crea un grupo, limita el acceso al binario SUID a los miembros de ese grupo y coloca todas las apps que deban poder ejecutar el programa SUID en ese grupo.
• Los programas SUID son una fuente común de acceso de raíz de los usuarios a los dispositivos. Para reducir este riesgo, el usuario de la shell no debe poder ejecutar programas SUID.

El verificador de CTS incluye una prueba informativa que enumera los archivos SUID. Algunos archivos setuid no están permitidos según las pruebas de CTS.

Escucha de sockets segura

Las pruebas de CTS fallan cuando un dispositivo está escuchando en cualquier puerto o interfaz. En caso de falla, Android verifica que se usen las siguientes prácticas recomendadas:

• No debería haber puertos de escucha en el dispositivo.
• Los puertos de escucha deben poder inhabilitarse sin una actualización OTA. Puede ser un cambio de configuración del servidor o del dispositivo del usuario.
• Los procesos raíz no deben escuchar en ningún puerto.
• Los procesos que pertenecen al UID del sistema no deben escuchar en ningún puerto.
• Para la IPC local con sockets, las apps deben usar un socket de dominio de UNIX con acceso limitado a un grupo. Crea un descriptor de archivo para el IPC y haz que sea +RW para un grupo UNIX específico. Todas las apps cliente deben estar dentro de ese grupo de UNIX.
• Algunos dispositivos con varios procesadores (p.ej., una radio o un módem separados del procesador de la app) usan sockets de red para comunicarse entre procesadores. En esos casos, el socket de red que se usa para la comunicación entre procesadores debe usar una interfaz de red aislada para evitar el acceso de apps no autorizadas en el dispositivo (es decir, usa iptables para evitar el acceso de otras apps en el dispositivo).
• Los demonios que controlan los puertos de escucha deben ser resistentes a los datos con errores de formato. Google puede realizar pruebas de fuzz en el puerto con un cliente no autorizado y, cuando sea posible, con un cliente autorizado. Los errores fatales se registran como errores con una gravedad adecuada.

Datos de registro

El registro de datos aumenta el riesgo de exposición de esos datos y reduce el rendimiento del sistema. Se produjeron varios incidentes de seguridad pública como resultado del registro de datos sensibles del usuario por parte de apps instaladas de forma predeterminada en dispositivos Android. Prácticas recomendadas:

• Las apps o los servicios del sistema no deben registrar datos proporcionados por apps de terceros que puedan incluir información sensible.
• Las apps no deben registrar información de identificación personal (PII) como parte del funcionamiento normal.

El CTS incluye pruebas que verifican la presencia de información potencialmente sensible en los registros del sistema.

Limita el acceso al directorio

Los directorios con permisos de escritura para todos pueden introducir debilidades de seguridad y permitir que una app cambie el nombre de archivos de confianza, los sustituya o realice ataques basados en symlinks (los atacantes pueden usar un symlink a un archivo para engañar a un programa de confianza y que realice acciones que no debería). Los directorios con permisos de escritura también pueden impedir que la desinstalación de una app borre correctamente todos los archivos asociados con ella.

Como práctica recomendada, los directorios creados por el sistema o los usuarios raíz no deben ser de escritura para todos. Las pruebas de CTS ayudan a aplicar esta práctica recomendada probando directorios conocidos.

Archivos de configuración seguros

Muchos controladores y servicios dependen de archivos de configuración y datos almacenados en directorios como /system/etc y /data. Si un proceso con privilegios procesa estos archivos y son legibles y escribibles por todos, es posible que una app aproveche una vulnerabilidad en el proceso creando contenido malicioso en el archivo legible y escribible por todos. Prácticas recomendadas:

• Los archivos de configuración que usan los procesos con privilegios no deben ser legibles por todos.
• Los archivos de configuración que usan los procesos con privilegios no deben ser de escritura pública.

Almacena bibliotecas de código nativo

Cualquier código que usen los procesos de fabricantes de dispositivos con privilegios debe estar en /vendor o /system. Estos sistemas de archivos se activan en modo de solo lectura durante el inicio. Como práctica recomendada, las bibliotecas que usan el sistema o otras apps con privilegios elevados instaladas en el dispositivo también deben estar en estos sistemas de archivos. Esto puede evitar una vulnerabilidad de seguridad que podría permitir que un atacante controle el código que ejecuta un proceso con privilegios.

Limita el acceso al controlador de dispositivo

Solo el código de confianza debe tener acceso directo a los controladores. Siempre que sea posible, la arquitectura preferida es proporcionar un daemon de un solo propósito que apunte las llamadas al controlador y restrinja el acceso del controlador a ese daemon. Como práctica recomendada, los nodos de dispositivos del controlador no deben ser de lectura o escritura para todos. Las pruebas de CTS ayudan a aplicar esta práctica recomendada, ya que buscan instancias conocidas de controladores expuestos.

Cómo inhabilitar ADB

Android Debug Bridge (adb) es una herramienta de desarrollo y depuración valiosa, pero está diseñada para usarse en entornos controlados y seguros, y no debe estar habilitada para el uso general. Prácticas recomendadas:

• ADB debe estar inhabilitado de forma predeterminada.
• ADB debe requerir que el usuario lo active antes de aceptar conexiones.

Cómo desbloquear bootloaders

Muchos dispositivos Android admiten el desbloqueo, lo que permite al propietario del dispositivo modificar la partición del sistema o instalar un sistema operativo personalizado. Los casos de uso más comunes incluyen la instalación de una ROM de terceros y el desarrollo a nivel del sistema en el dispositivo. Por ejemplo, el propietario de un dispositivo Google Nexus puede ejecutar fastboot oem unlock para iniciar el proceso de desbloqueo, que le muestra el siguiente mensaje al usuario:

Como práctica recomendada, los dispositivos Android que se pueden desbloquear deben borrar de forma segura todos los datos del usuario antes de desbloquearse. Si no se borran correctamente todos los datos al desbloquear el dispositivo, un atacante físicamente cercano puede obtener acceso no autorizado a los datos confidenciales del usuario de Android. Para evitar la divulgación de datos del usuario, un dispositivo que admita el desbloqueo debe implementarlo correctamente (vimos varios casos en los que los fabricantes de dispositivos implementaron el desbloqueo de forma incorrecta). Un proceso de desbloqueo implementado de forma correcta tiene las siguientes propiedades:

• Cuando el usuario confirma el comando de desbloqueo, el dispositivo debe iniciar una limpieza de datos inmediata. La marca unlocked no se debe establecer hasta que se complete la eliminación segura.
• Si no se puede completar una eliminación segura, el dispositivo debe permanecer en un estado bloqueado.
• Si el dispositivo de almacenamiento en bloques subyacente lo admite, se debe usar ioctl(BLKSECDISCARD) o un equivalente. En el caso de los dispositivos eMMC, esto significa usar un comando Secure Erase o Secure Trim. Para eMMC 4.5 y versiones posteriores, esto significa usar un borrado o recorte normal seguido de una operación de limpieza.
• Si el dispositivo de almacenamiento en bloque subyacente no admite BLKSECDISCARD, se debe usar ioctl(BLKDISCARD). En los dispositivos eMMC, esta es una operación de Trim normal.
• Si no se admite BLKDISCARD, se acepta reemplazar los dispositivos de almacenamiento en bloques con todos los ceros.
• Un usuario final debe tener la opción de exigir que se borren los datos del usuario antes de actualizar una partición. Por ejemplo, en dispositivos Nexus, esto se hace a través del comando fastboot oem lock.
• Un dispositivo puede registrar, a través de efuses o un mecanismo similar, si se desbloqueó o volvió a bloquear.

Estos requisitos garantizan que todos los datos se destruyan cuando se completa una operación de desbloqueo. La falta de implementación de estas protecciones se considera una vulnerabilidad de seguridad de nivel moderado.

Un dispositivo desbloqueado se puede volver a bloquear con el comando fastboot oem lock. El bloqueo del bootloader proporciona la misma protección de los datos del usuario con el nuevo SO personalizado que estaba disponible con el SO del fabricante original del dispositivo (p.ej., se borrarán los datos del usuario si se vuelve a desbloquear el dispositivo).