Implementando Seguridad

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

Esta página brinda mejores prácticas de seguridad basadas en nuestras experiencias, amplía la documentación de Designing for Security que proporcionamos 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 prácticas recomendadas 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 mediante el SDK de Android y corrija los problemas identificados.
• El código nativo debe analizarse con una herramienta automatizada que pueda detectar problemas de administración de memoria, como desbordamientos de búfer y errores de apagado por uno.
• El sistema de compilación de Android es compatible con muchos de los desinfectantes LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer, que se pueden usar para este propósito.

Uso de 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 regularmente con pruebas de seguridad; ejecute la versión más reciente de CTS para verificar la compatibilidad.
• Ejecute CTS regularmente durante todo el proceso de desarrollo para detectar problemas temprano 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 mal formadas (pruebas fuzz).

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 coherente 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.

Aplicaciones de firma (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 usar para firmar aplicaciones, es importante considerar si una aplicación estará disponible solo en un solo dispositivo o será común en varios dispositivos. Mejores prácticas:

• Las solicitudes no deben estar firmadas con una clave que sea públicamente conocida.
• Las claves utilizadas para firmar aplicaciones deben administrarse de manera consistente con las prácticas estándar de la industria para el manejo de claves confidenciales, incluido un HSM que proporciona acceso limitado y auditable.
• Las aplicaciones no deben firmarse con la clave de la plataforma.
• Las aplicaciones con el mismo nombre de paquete no deben firmarse con claves diferentes. Esto ocurre a menudo cuando se crea una aplicación para diferentes dispositivos, especialmente cuando se usa la clave de plataforma. Si la aplicación es independiente del dispositivo, use 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.

Publicación de aplicaciones

Google Play brinda a los fabricantes de dispositivos la capacidad de actualizar aplicaciones sin realizar una actualización completa del sistema. Esto puede acelerar la respuesta a los problemas de seguridad y la entrega de nuevas funciones, así como proporcionar una forma 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 las aplicaciones aún 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, utilizando 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 terceros. Si un fabricante de dispositivos instala una aplicación en un dispositivo sin publicar la aplicación 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 pueden generar confusión.

Respuesta a incidentes

Las partes externas deben tener la capacidad de contactar a 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 seguridad@su-empresa.com o similar y publíquela.
• Si se da cuenta de un problema de seguridad que afecta el sistema operativo Android o los dispositivos Android de varios fabricantes de dispositivos, debe comunicarse con el equipo de seguridad de Android mediante la presentación de un informe de error de seguridad .

Implementación del producto

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

Aislamiento de procesos raíz

Los procesos raíz son el objetivo más frecuente de los ataques de escalada de privilegios, por lo que reducir la cantidad 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, use un proceso normal de Android en lugar de un proceso raíz. El ICS Galaxy Nexus tiene solo seis procesos raíz: vold, inetd, zygote, tf_daemon, ueventd e init. Si un proceso debe ejecutarse como raíz 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 son de confianza y acceder a ellos 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 uso general para las aplicaciones (por ejemplo, una máquina virtual Java).

Aislamiento de aplicaciones del sistema

En general, las aplicaciones preinstaladas no deben ejecutarse con el UID del sistema compartido. Sin embargo, si es necesario que una aplicación use 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 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 solo a otros procesos de confianza.
• Los procesos del sistema no deben escuchar en un socket de red.

Procesos de aislamiento

El Sandbox de aplicaciones de Android proporciona aplicaciones con una 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 los datos dentro de las 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.

Protección de archivos SUID

Los nuevos programas setuid no deberían ser accesibles por programas no confiables. Los programas Setuid han sido con frecuencia la ubicación de vulnerabilidades que pueden usarse para obtener acceso raíz, 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 se pueda 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 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 pueda 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 de 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 utilicen las siguientes prácticas recomendadas:

• No debe 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 de 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 locales que usan sockets, las aplicaciones deben usar 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 varios procesadores (p. ej., una radio/módem independiente del procesador de la aplicación) utilizan conectores 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 los puertos de escucha deben ser robustos contra los datos mal formados. Google puede realizar pruebas de fuzz en el puerto utilizando un cliente no autorizado y, cuando sea posible, un cliente autorizado. Cualquier bloqueo 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 las aplicaciones instaladas de forma predeterminada en los dispositivos Android. Mejores prácticas:

• Las aplicaciones o los 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.

Limitación del 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 evitar que la desinstalación de una aplicación limpie correctamente todos los archivos asociados con una aplicación.

Como práctica recomendada, los directorios creados por el sistema o los usuarios raíz no deben permitir la escritura en todo el mundo. Las pruebas de CTS ayudan a hacer cumplir esta mejor práctica al probar directorios conocidos.

Protección de archivos de configuración

Muchos controladores y servicios se basan en 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 explote una vulnerabilidad en el proceso al crear contenido malicioso en el archivo de escritura en todo el mundo. Mejores prácticas:

• Los archivos de configuración utilizados por los procesos privilegiados no deben ser legibles en todo el mundo.
• Los archivos de configuración utilizados por los procesos privilegiados no deben tener permisos de escritura en todo el mundo.

Almacenamiento de bibliotecas de código nativo

Cualquier código utilizado por los procesos del fabricante de dispositivos privilegiados 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 muchos privilegios instaladas en el dispositivo también deben estar en estos sistemas de archivos. Esto puede prevenir una vulnerabilidad de seguridad que podría permitir que un atacante controle el código que ejecuta un proceso privilegiado.

Limitación del acceso del controlador del dispositivo

Solo el código de confianza debe tener acceso directo a los controladores. Siempre que sea posible, la arquitectura preferida es proporcionar un demonio de propósito único que desvía las llamadas al controlador y restringe el acceso del controlador a ese demonio. Como práctica recomendada, los nodos del dispositivo del controlador no deben ser de lectura o escritura en todo el mundo. Las pruebas de CTS ayudan a hacer cumplir esta mejor práctica al verificar instancias conocidas de controladores expuestos.

Deshabilitar ADB

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

• ADB debe estar deshabilitado por defecto.
• ADB debe exigir al usuario que lo encienda antes de aceptar conexiones.

Desbloqueo de gestores 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 un 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, que presenta el siguiente mensaje al usuario:

Como práctica recomendada, los dispositivos Android desbloqueables deben borrar de forma segura todos los datos del usuario antes de desbloquearlos. Si no se eliminan correctamente todos los datos durante el desbloqueo, es posible que un atacante físicamente cercano obtenga acceso no autorizado a datos confidenciales de usuarios de Android. Para evitar la divulgación de datos de 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 correctamente implementado tiene las siguientes propiedades:

• Cuando el usuario confirma el comando de desbloqueo, el dispositivo debe iniciar un borrado de datos inmediato. El indicador unlocked no debe establecerse hasta después de 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 es compatible con el dispositivo de bloque subyacente, se debe usar ioctl(BLKSECDISCARD) o equivalente. Para 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 desinfección.
• Si BLKSECDISCARD no es compatible con el dispositivo de bloque subyacente, se debe usar ioctl(BLKDISCARD) en su lugar. En dispositivos eMMC, esta es una operación de ajuste normal.
• Si no se admite BLKDISCARD , es aceptable sobrescribir los dispositivos de bloque con 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 los dispositivos Nexus, esto se hace mediante el comando fastboot oem lock .
• Un dispositivo puede registrar, a través de efuses o un mecanismo similar, si un dispositivo se desbloqueó y/o se volvió a bloquear.

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

Un dispositivo que está desbloqueado puede volver a bloquearse posteriormente mediante el comando fastboot oem lock . Bloquear el cargador de arranque brinda la misma protección de los datos de 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).