Esta página se ha traducido con Cloud Translation API.

Implementando Seguridad

El equipo de seguridad de Android recibe periódicamente solicitudes de información sobre cómo prevenir posibles problemas de seguridad en dispositivos Android. Ocasionalmente también comprobamos los dispositivos e informamos a los fabricantes de dispositivos y a los socios afectados sobre posibles problemas.

Esta página proporciona las mejores prácticas de seguridad basadas en nuestras experiencias, ampliando la documentación de Diseño para la seguridad que hemos proporcionado a los desarrolladores e incluye detalles exclusivos para crear o instalar software a nivel de sistema en dispositivos.

Para facilitar la adopción de estas mejores prácticas, cuando sea posible, el equipo de seguridad de Android incorpora pruebas en Android Compatibility Test Suite (CTS) y Android Lint . Alentamos a los implementadores de dispositivos a contribuir con pruebas que puedan ayudar a otros usuarios de Android (consulte las pruebas relacionadas con la seguridad en root/cts/tests/tests/security/src/android/security/cts ).

Proceso de desarrollo

Utilice las siguientes mejores prácticas en sus procesos y entorno de desarrollo.

Revisando el código fuente

La revisión del código fuente puede detectar una amplia gama de problemas de seguridad, incluidos los identificados en este documento. Android recomienda encarecidamente la revisión del código fuente tanto manual como automatizada. Mejores prácticas:

Ejecute Android Lint en todo el código de la aplicación utilizando el SDK de Android y corrija cualquier problema identificado.
El código nativo debe analizarse utilizando una herramienta automatizada que pueda detectar problemas de administración de memoria, como desbordamientos del búfer y errores uno por uno.
El sistema de compilación de Android admite muchos de los desinfectantes LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer, que se pueden utilizar para este propósito.

Usando pruebas automatizadas

Las pruebas automatizadas pueden detectar una amplia gama de problemas de seguridad, incluidos varios problemas que se analizan a continuación. Mejores prácticas:

CTS se actualiza periódicamente con pruebas de seguridad; Ejecute la versión más reciente de CTS para verificar la compatibilidad.
Ejecute CTS periódicamente durante todo el proceso de desarrollo para detectar problemas tempranamente y reducir el tiempo de corrección. Android utiliza 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 deberían automatizar las pruebas de seguridad de las interfaces, incluidas las pruebas con entradas con formato incorrecto (pruebas difusas).

Imágenes del sistema de firma

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

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

Firma de aplicaciones (APK)

Las firmas de aplicaciones desempeñan un papel importante en la seguridad del dispositivo y se utilizan para comprobar permisos y actualizaciones de software. Al seleccionar una clave para firmar aplicaciones, es importante considerar si una aplicación estará disponible solo en un único dispositivo o será común a varios dispositivos. Mejores prácticas:

Las solicitudes no deben firmarse con una clave de conocimiento público.
Las claves utilizadas para firmar aplicaciones deben administrarse de manera coherente con las prácticas estándar de la industria para el manejo de claves confidenciales, incluido un HSM que proporcione acceso limitado y auditable.
Las solicitudes no deben firmarse con la clave de plataforma.
Las aplicaciones con el mismo nombre de paquete no deben firmarse con claves diferentes. Esto suele ocurrir al crear una aplicación para diferentes dispositivos, especialmente cuando se utiliza la clave de plataforma. Si la aplicación es independiente del dispositivo, utilice la misma clave en todos los dispositivos. Si la aplicación es específica del dispositivo, cree nombres de paquetes únicos por dispositivo y clave.

Aplicaciones de publicación

Google Play ofrece a los fabricantes de dispositivos la posibilidad de actualizar aplicaciones sin realizar una actualización completa del sistema. Esto puede acelerar la respuesta a problemas de seguridad y la entrega de nuevas funciones, además de proporcionar una manera de garantizar que su aplicación tenga un nombre de paquete único. Mejores prácticas:

Cargue sus aplicaciones en Google Play para permitir actualizaciones automáticas sin necesidad de una actualización inalámbrica completa (OTA). Los usuarios no pueden descargar directamente las aplicaciones que se cargan pero no se publican, pero aún así se actualizan. Los usuarios que hayan instalado previamente la aplicación pueden volver a instalarla y/o instalarla en otros dispositivos.
Cree un nombre de paquete de aplicación que esté claramente asociado con su empresa, por ejemplo mediante el uso de una marca comercial de la empresa.
Las aplicaciones publicadas por los fabricantes de dispositivos deben cargarse en la tienda Google Play para evitar la suplantación del nombre del paquete por parte de usuarios externos. Si un fabricante de dispositivos instala una aplicación en un dispositivo sin publicarla en Play Store, otro desarrollador podría cargar la misma aplicación, usar el mismo nombre de paquete y cambiar los metadatos de la aplicación. Cuando la aplicación se presenta al usuario, estos metadatos no relacionados podrían generar confusión.

Respondiendo a incidentes

Las partes externas deben tener la capacidad de comunicarse con los fabricantes de dispositivos sobre problemas de seguridad específicos del dispositivo. Recomendamos crear una dirección de correo electrónico de acceso público para gestionar incidentes de seguridad. Mejores prácticas:

Cree una dirección security@your-company.com o similar y publíquela.
Si tiene conocimiento de un problema de seguridad que afecta al sistema operativo Android o a dispositivos Android de varios fabricantes de dispositivos, debe comunicarse con el equipo de seguridad de Android presentando un informe de error de seguridad .

Implementación de producto

Utilice las siguientes mejores prácticas al implementar un producto.

Aislar procesos raíz

Los procesos raíz son el objetivo más frecuente de los ataques de escalada de privilegios, por lo que reducir el número de procesos raíz reduce el riesgo de escalada de privilegios. CTS incluye una prueba informativa que enumera los procesos raíz. Mejores prácticas:

Los dispositivos deben ejecutar el código mínimo necesario como root. Siempre que sea posible, utilice un proceso normal de Android en lugar de un proceso raíz. El ICS Galaxy Nexus tiene sólo seis procesos raíz: vold, inetd, zygote, tf_daemon, ueventd e init. Si un proceso debe ejecutarse como root en un dispositivo, documente el proceso en una solicitud de función AOSP para que pueda revisarse públicamente.
Siempre que sea posible, el código raíz debe aislarse de los datos que no sean de confianza y se debe acceder a él a través de IPC. Por ejemplo, reduzca la funcionalidad raíz a un pequeño Servicio accesible a través de Binder y exponga el Servicio con permiso de firma a una aplicación con privilegios bajos o nulos para manejar el tráfico de red.
Los procesos raíz no deben escuchar en un socket de red.
Los procesos raíz no deben proporcionar un tiempo de ejecución de propósito general para aplicaciones (por ejemplo, una máquina virtual Java).

Aislar aplicaciones del sistema

En general, las aplicaciones preinstaladas no deberían ejecutarse con el UID del sistema compartido. Sin embargo, si es necesario que una aplicación utilice el UID compartido del sistema u otro servicio privilegiado, la aplicación no debe exportar ningún servicio, receptor de transmisión o proveedor de contenido al que puedan acceder las aplicaciones de terceros instaladas por los usuarios. Mejores prácticas:

Los dispositivos deben ejecutar el código mínimo necesario como sistema. Siempre que sea posible, utilice un proceso de Android con su propio UID en lugar de reutilizar el UID del sistema.
Siempre que sea posible, el código del sistema debe aislarse de los datos que no son de confianza y exponer IPC sólo a otros procesos confiables.
Los procesos del sistema no deben escuchar en un socket de red.

Procesos de aislamiento

Android Application Sandbox proporciona aplicaciones con la expectativa de aislamiento de otros procesos en el sistema, incluidos los procesos raíz y los depuradores. A menos que la aplicación y el usuario habiliten específicamente la depuración, ninguna aplicación debe violar esa expectativa. Mejores prácticas:

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

Proteger archivos SUID

Los programas que no sean de confianza no deberían poder acceder a los nuevos programas setuid. Los programas Setuid han sido con frecuencia la ubicación de vulnerabilidades que pueden usarse para obtener acceso de root, así que esfuércese por minimizar la disponibilidad del programa setuid para aplicaciones que no sean de confianza. Mejores prácticas:

Los procesos SUID no deben proporcionar un shell o una puerta trasera que pueda usarse 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 en todo el mundo. Cree un grupo, limite el acceso al binario SUID a los miembros de ese grupo y coloque cualquier aplicación que debería poder ejecutar el programa SUID en ese grupo.
Los programas SUID son una fuente común de rooteo de dispositivos por parte del usuario. Para reducir este riesgo, los programas SUID no deben ser ejecutables por el usuario del shell.

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

Asegurar las tomas de escucha

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

No debería haber puertos de escucha en el dispositivo.
Los puertos de escucha deben poder desactivarse sin una OTA. Esto 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 propiedad del UID del sistema no deben escuchar en ningún puerto.
Para IPC local que utiliza sockets, las aplicaciones deben utilizar un socket de dominio UNIX con acceso limitado a un grupo. Cree un descriptor de archivo para el IPC y conviértalo en +RW para un grupo UNIX específico. Cualquier aplicación cliente debe estar dentro de ese grupo UNIX.
Algunos dispositivos con múltiples procesadores (por ejemplo, una radio/módem independiente del procesador de aplicaciones) utilizan sockets de red para comunicarse entre procesadores. En tales casos, el socket de red utilizado para la comunicación entre procesadores debe usar una interfaz de red aislada para evitar el acceso de aplicaciones no autorizadas en el dispositivo (es decir, usar iptables para evitar el acceso de otras aplicaciones en el dispositivo).
Los demonios que manejan puertos de escucha deben ser robustos contra datos con formato incorrecto. Google puede realizar pruebas difusas contra el puerto utilizando un cliente no autorizado y, cuando sea posible, un cliente autorizado. Cualquier falla se archivará como error con la gravedad adecuada.

Registro de datos

El registro de datos aumenta el riesgo de exposición de esos datos y reduce el rendimiento del sistema. Se han producido múltiples incidentes de seguridad pública como resultado del registro de datos confidenciales de los usuarios por parte de aplicaciones instaladas de forma predeterminada en dispositivos Android. Mejores prácticas:

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

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

Limitar el acceso al directorio

Los directorios de escritura mundial pueden introducir debilidades de seguridad y permitir que una aplicación cambie el nombre de archivos confiables, sustituya archivos o realice ataques basados en enlaces simbólicos (los atacantes pueden usar un enlace simbólico a un archivo para engañar a un programa confiable para que realice acciones que no debería). Los directorios grabables también pueden impedir que la desinstalación de una aplicación limpie adecuadamente todos los archivos asociados con una aplicación.

Como práctica recomendada, los directorios creados por el sistema o los usuarios raíz no deberían poder escribirse en todo el mundo. Las pruebas CTS ayudan a aplicar esta mejor práctica al probar directorios conocidos.

Proteger archivos de configuración

Muchos controladores y servicios dependen de archivos de configuración y datos almacenados en directorios como /system/etc y /data . Si estos archivos son procesados por un proceso privilegiado y se pueden escribir en todo el mundo, es posible que una aplicación aproveche una vulnerabilidad en el proceso creando contenidos maliciosos en el archivo de escritura mundial. Mejores prácticas:

Los archivos de configuración utilizados por procesos privilegiados no deberían ser legibles en todo el mundo.
Los archivos de configuración utilizados por procesos privilegiados no deben poder escribirse en todo el mundo.

Almacenamiento de bibliotecas de código nativo

Cualquier código utilizado por los procesos privilegiados del fabricante de dispositivos debe estar en /vendor o /system ; Estos sistemas de archivos se montan como de solo lectura en el arranque. Como práctica recomendada, las bibliotecas utilizadas por el sistema u otras aplicaciones con privilegios elevados instaladas en el dispositivo también deberían estar en estos sistemas de archivos. Esto puede evitar una vulnerabilidad de seguridad que podría permitir a un atacante controlar el código que ejecuta un proceso privilegiado.

Limitar el acceso al controlador del dispositivo

Sólo el código confiable debe tener acceso directo a los controladores. Siempre que sea posible, la arquitectura preferida es proporcionar un demonio de propósito único que envía llamadas al controlador y restringe el acceso del conductor a ese demonio. Como práctica recomendada, los nodos del dispositivo controlador no deben poder leerse ni escribirse en todo el mundo. Las pruebas CTS ayudan a hacer cumplir esta mejor práctica al verificar casos conocidos de controladores expuestos.

Deshabilitar el BAD

El puente de depuración de Android (adb) es una valiosa herramienta de desarrollo y depuración, pero está diseñado para usarse en entornos controlados y seguros y no debe habilitarse para uso general. Mejores prácticas:

ADB debe estar deshabilitado de forma predeterminada.
ADB debe solicitar al usuario que lo encienda antes de aceptar conexiones.

Desbloqueo de cargadores de arranque

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

¿Desbloquear el bootloader?

Si desbloquea el gestor de arranque, podrá instalar software de sistema operativo personalizado en este dispositivo.

Un sistema operativo personalizado no está sujeto a las mismas pruebas que el sistema operativo original y puede hacer que su dispositivo y las aplicaciones instaladas dejen de funcionar correctamente.

Para evitar el acceso no autorizado a sus datos personales, al desbloquear el gestor de arranque también se eliminarán todos los datos personales de su dispositivo (un "restablecimiento de datos de fábrica").

Presione los botones Subir/Bajar volumen para seleccionar Sí o No. Luego presione el botón de Encendido para continuar.

Sí : desbloquea el gestor de arranque (puede anular la garantía)

No : no desbloquee el gestor de arranque ni reinicie el dispositivo.

Como práctica recomendada, los dispositivos Android desbloqueables deben borrar de forma segura todos los datos del usuario antes de desbloquearlos. No eliminar correctamente todos los datos al desbloquear puede permitir que un atacante físicamente cercano obtenga acceso no autorizado a datos confidenciales del usuario de Android. Para evitar la divulgación de datos del usuario, un dispositivo que admita el desbloqueo debe implementarlo correctamente (hemos visto numerosos casos en los que los fabricantes de dispositivos implementaron el desbloqueo incorrectamente). Un proceso de desbloqueo implementado correctamente tiene las siguientes propiedades:

Cuando el usuario confirma el comando de desbloqueo, el dispositivo debe iniciar un borrado de datos inmediato. La bandera unlocked no se debe configurar hasta que se complete la eliminación segura.
Si no se puede completar una eliminación segura, el dispositivo debe permanecer bloqueado.
Si es compatible con el dispositivo de bloque subyacente, se debe utilizar ioctl(BLKSECDISCARD) o equivalente. Para dispositivos eMMC, esto significa usar un comando de borrado seguro o recorte seguro. Para eMMC 4.5 y posteriores, esto significa usar un Borrado o Recorte normal seguido de una operación de Desinfección.
Si BLKSECDISCARD no es compatible con el dispositivo de bloque subyacente, se debe utilizar ioctl(BLKDISCARD) en su lugar. En dispositivos eMMC, esta es una operación de recorte normal.
Si no se admite BLKDISCARD , es aceptable sobrescribir los dispositivos de bloque con todos ceros.
Un usuario final debe tener la opción de solicitar que se borren los datos del usuario antes de actualizar una partición. Por ejemplo, en dispositivos Nexus, esto se hace mediante el comando fastboot oem lock .
Un dispositivo puede registrar, mediante efuses o mecanismo similar, si un dispositivo fue desbloqueado y/o vuelto a bloquear.

Estos requisitos garantizan que todos los datos se destruyan al finalizar una operación de desbloqueo. No implementar estas protecciones se considera una vulnerabilidad de seguridad de nivel moderado.

Un dispositivo que está desbloqueado se puede volver a bloquear posteriormente utilizando el comando fastboot oem lock . Bloquear el gestor de arranque proporciona la misma protección de los datos del usuario con el nuevo sistema operativo personalizado que estaba disponible con el sistema operativo del fabricante del dispositivo original (por ejemplo, los datos del usuario se borrarán si el dispositivo se desbloquea nuevamente).