Android se posicionó como el sistema operativo móvil más utilizado en el mundo, en gran parte debido a su calidad de sistema abierto. Los sistemas operativos más antiguos, como Symbian, Blackberry OS, Windows Mobile, con los cuales entró a competir Android a mediados de los años 2000, eran sistemas de código cerrado. Google logró cautivar a los desarrolladores ofreciendo una plataforma abierta, personalizable, con herramientas de desarrollo gratuitas.
Existe la opinión de que los sistemas abiertos son menos seguros. Si los hacker tienen acceso a los códigos fuente de los componentes del sistema operativo, entonces no tienen la necesidad de hacer ingeniería inversa en busca de vulnerabilidades. Si las aplicaciones tienen control sobre la mayoría de los recursos del dispositivo, entonces es posible que estos recursos se utilicen en perjuicio de los intereses del usuario. Uno de los grandes retos para Google ha sido mantener Android como una plataforma abierta, pero al mismo tiempo contrarrestar sus posibles desventajas en materia de seguridad.
Tim Cook dijo en VivaTech 2021 que ha habido 47 veces más incidencias de malware en Android que en iOS. Panda Security había publicado una métrica similar en 2019, indicando que los casos de malware en Android son cerca de 50 veces más frecuentes que en iOS.
En realidad, estas cifras no son tan desfavorables para Android, como podría parecer a primera vista. Estas métricas abarcan teléfonos rooteados y versiones de Android muy antiguas, en las cuales los niveles de seguridad eran mínimos. Además, si Android es tan popular entre los desarrolladores, también lo es entre los hacker y los autores de malware.
Algunos de los sistemas operativos más seguros corresponden a la familia BSD: OpenBSD, NetBSD, FreeBSD.1 Estos sistemas operativos son abiertos, pero aun así son más seguros que muchos de los sistemas operativos cerrados.
Una de las ventajas del código fuente abierto, desde el punto de vista de seguridad, es que los expertos en seguridad pueden estudiar este código. Esto no solo ayuda a identificar y corregir posibles vulnerabilidades. También permite detectar patrones de diseño que conducen a la ocurrencia de vulnerabilidades futuras.2
Permisividad vs. inseguridad
Las primeras versiones de Android tenían controles de seguridad mínimos. Las aplicaciones podían acceder a todos los datos del usuario y el teléfono. Desde el punto de vista del desarrollador esto era una gran ventaja en comparación con otros sistemas operativos, pero al mismo tiempo provocó que los fabricantes de teléfonos (Samsung, HTC, Sony, etc.) comenzaran a personalizar sus versiones de Android, eliminando las funcionalidades más peligrosas o restringiendo el acceso a las mismas.
Google también comenzó a eliminar las funcionalidades que representaban mayor riesgo. Por ejemplo, uno de los cambios polémicos fue la eliminación de la API sendRawPdu en Android 2.x, sin explicación oficial de parte de Google y sin alternativa que no implique rooteo del dispositivo. Esta API era usada por las aplicaciones para enviar SMS binarios.
La primera generación de Android permitió evidenciar un conflicto de intereses. Por una parte, Google deseaba que Android se convirtiera en la plataforma móvil más utilizado, desplazando a la competencia. Por otra parte, Google no podía permitir que los desarrolladores tuvieran control total sobre el dispositivo, ya que esto último hacía inviable el uso comercial masivo de Android.
En este punto se vuelve evidente que la vulnerabilidad original de Android se debió a su permisividad (falta de restricciones para acceder a los recursos, datos o funcionalidades sensibles), no al hecho de que el sistema fuese abierto. Esta permisividad comenzó a desaparecer en las versiones subsiguientes. Las versiones más actuales tienen niveles de permisividad comparables con los de otros sistemas operativos, no solamente móviles. Por ejemplo, Android 8 introdujo restricciones para las aplicaciones que se ejecutan en segundo plano. Estas restricciones ayudan a ahorrar el uso de batería, datos y otros recursos, por parte de los procesos que no son visibles para el usuario. Otro ejemplo de reducción de permisividad son las restricciones para el acceso a la SIM a partir de Android 2.x. Actualmente solamente las aplicaciones del sistema y las aplicaciones con privilegios de operador pueden interactuar directamente con la SIM.
Cada nueva versión de Android introduce restricciones adicionales. Esto obliga a los desarrolladores a modificar su código para adaptarse a las restricciones nuevas. En algunos casos no es posible encontrar una alternativa equivalente, como en el ejemplo de sendRawPdu mencionado más arriba. Por lo tanto, cualquier aplicación que hace uso de recursos sensibles puede volverse obsoleta en una futura versión de Android.
Diferentes sabores de Android
Por ejemplo, un teléfono de marca Samsung y otro teléfono de marca Huawei pueden tener la misma versión de Android, pero las plataformas no son idénticas. Como se mencionó más arriba, los fabricantes de teléfonos comenzaron a personalizar sus propias distribuciones, conocidas como Custom ROM, prácticamente a partir de las primeras versiones de Android.
Las versiones genéricas, publicadas y mantenidas por Google, son conocidas como AOSP (en inglés, Android Open Source Project). Estas versiones son usadas en los dispositivos producidos por Google y otros dispositivos genéricos, generalmente de bajo costo.
Las versiones personalizadas pueden incluir cambios cosméticos, ya que las primeras versiones genéricas no contaban con interfaces gráficas particularmente atractivas. Por ejemplo, los dispositivos de gama alta fabricados por HTC incluían unas mejoras de interfaz de usuario conocidas como Sense. Las versiones personalizadas también pueden incluir cambios en el kernel (núcleo) para soportar mejor el hardware del dispositivo. Esto permite mejorar el rendimiento y aprovechar mejor los recursos del dispositivo. El hardware es bastante heterogéneo, por lo que la versión AOSP no siempre logra tener compatibilidad y aprovechar el hardware de la mejor forma posible. Por ejemplo, algunos fabricantes incluyen termovisor, lector RFID, impresora, entre otros ejemplos de dispositivos que no son de uso común en los teléfonos móviles. Para soportar estas funcionalidades añadidas también puede ser necesario personalizar Android.
Las versiones personalizadas pueden ser más seguras o menos seguras. Por ejemplo, algunos operadores preinstalan aplicaciones, las cuales permiten agregar aplicaciones adicionales sin el consentimiento del usuario. Esto compromete la privacidad y seguridad del usuario. Además, estos mecanismos de instalación automática de apps pueden ser explotados para difundir malware, burlando todas las restricciones de seguridad del dispositivo.
En resumen, no todos los Android son iguales. Por lo tanto, resulta sorprendente que diferentes fuentes generalicen el concepto de seguridad en Android sin hacen un estudio comparativo de diferentes versiones y personalizaciones existentes.
Un reto para el desarrollador
El desarrollador Android puede elegir que su aplicación solamente funcione en dispositivos no rooteados con las últimas versiones de Android disponibles. Algunos desarrolladores de servicios bancarios y afines toman esta decisión para reducir los riesgos de vulnerabilidades. Ingresar al banco desde un teléfono muy viejo puede ser como acceder desde un computador público. El riesgo de comprometer la seguridad por cuenta de un programa espía puede ser muy alto.
Por otra parte, soportar una mayor variedad de dispositivos, incluyendo los más antiguos, permite alcanzar una mayor base de usuarios.
En caso de que el usuario llegue a ser víctima de fraude, la responsabilidad no va a ser del fabricante del teléfono, el sistema operativo o el operador móvil. El desarrollador de la app será señalado como responsable. Por lo tanto, es muy importante evaluar los riesgos antes de publicar la aplicación.
Referencias
- Michael W. Lucas (2013), «Absolute OpenBSD: Unix for the practical paranoid» (en inglés), 2ª ed, No Starch Press. ISBN 978-1-59327-476-4
- Amiangshu Bosu, Jeffrey C. Carver et al (2014). «When are OSS Developers More Likely to Introduce Vulnerable Code Changes? A Case Study.» (en inglés), IFIP International Conference on Open Source Systems, DOI:10.1007/978-3-642-55128-4_37
