Siempre se pone en cuestión la seguridad de Android frente a otros sistemas operativos para dispositivos móviles, en especial con iOS. Y no sin razón, ya que hasta la fecha Google no ha dado con la “tecla” para ofrecer una seguridad que se pueda considerar como plena.
Eso sí, no deja de intentarlo con cada una de las nuevas versiones que lanza y, Jelly Bean no es una excepción. Puede ser, que en esta ocasión, sí que se produzcan mejoras reales en el ámbito de la seguridad ya que Google ha decidido utilizar de forma plena el protocolo de seguridad ASLR, que también forma parte de iOS y diferentes versiones de Windows, incluida la destinada a los teléfonos Windows Phone. Por lo tanto, las mejoras se esperan de forma evidente.
ASLR en Jelly Bean: qué es y por qué marca la diferencia
Pero, ¿qué es ASLR y qué tiene de especial para mejorar la seguridad? Las siglas significan exactamente Address Space Layout Randomization (espacio de redireccionamiento aleatorio) y ya dejan más o menos claro lo que permite este protocolo: al redireccionar las acciones del sistema operativo de forma aleatoria, los ataque que se reciben del exterior, incluidos los de malware o en los que se intenta robar información sensible, tienen mucho más complicado realizar su función. En resumidas cuentas, al ser aleatorio –el sistema operativo sí está capacitado para encontrar rápidamente lo que busca– el proceso de “pirateo” o “exploit” es mucho menos óptimo, por lo que no se realiza o no merece la pena el esfuerzo a realizar.
En Jelly Bean, la aleatorización se extiende de forma más completa que en versiones anteriores (donde su implementación era parcial), cubriendo regiones críticas como pilas, montículos, librerías compartidas y ejecutables. Esta mayor cobertura eleva la entropía y reduce la probabilidad de éxito de técnicas como ROP.
Un ejemplo: si un ataque busca el encontrar cierto código de ejecución, por ejemplo de alguna librería del sistema, lanza rastreadores tanto para el código fuente como de la pila del sistema, pero al hacerlo de la forma habitual, no tiene retorno alguno, ya que la información que busca está en una localización no predecible. Por lo tanto, resulta ideal para uno de los mayores problemas de Android, que no es otra cosa que aplicaciones no seguras que intentan robar información de los dispositivos al ejecutarse y, el resultado, es un sistema operativo mucho más seguro. Todo ello sin ver perjudicado el rendimiento del teléfono o de la tableta.
DEP: segunda línea de defensa contra ejecución de código
También Google ha decido incluir otro protocolo de seguridad, denominado DEP (Data Execution Prevention), que tiene como acción positiva el proteger los dispositivos de ataques específicos de los hackers que buscan fallos de memoria –concretamente de los bugs producidos por el uso intensivo– neutralizándolos y dejando sin efecto el código correspondiente. DEP marca como no ejecutables ciertos espacios de memoria (por ejemplo, la pila), bloqueando técnicas clásicas de inyección de código. Por lo tanto se aumenta la seguridad, aunque en este caso sí que su ejecución retrasa en algo la comunicación entre procesador y memoria, pero apenas es apreciable. En combinación con ASLR, eleva notablemente el coste de explotación para un atacante.
Más capas y funciones de seguridad que llegan con Jelly Bean
- Verificación de aplicaciones: el sistema puede analizar y comparar apps instaladas fuera de Google Play con bases de firmas conocidas para bloquear instalaciones potencialmente maliciosas. Esta defensa reduce el riesgo del “sideloading” imprudente.
- Control de SMS premium: se introducen avisos que requieren consentimiento explícito cuando una app intenta enviar mensajes con coste, mitigando fraudes por SMShing.
- SELinux (endurecimiento del sandbox): Android adopta un control de acceso obligatorio a nivel kernel que limita lo que pueden hacer procesos comprometidos, conteniendo el impacto de vulnerabilidades.
- KeyStore y KeyChain reforzados: se facilita el uso de claves vinculadas a hardware y no exportables, mejorando la protección de credenciales y certificados de apps y del sistema.
- VPN siempre activada: opción para impedir tráfico de apps hasta establecer un túnel seguro, útil en entornos corporativos y redes no confiables.
- Restricción de setuid: la partición de sistema se monta con nosuid para procesos de apps, recortando superficie de escalada de privilegios.
- Fijación de certificados y FORTIFY_SOURCE: mejoras criptográficas y de compilación que mitigan hombre-en-el-medio y corrupción de memoria en componentes nativos.
- Perfiles restringidos (en tablets): el propietario puede crear entornos limitados por app y función, valiosos para niños, kioscos o TPV.
Reconocimiento facial: cómodo, pero úsalo con criterio
Jelly Bean ha incluido algunas otras mejoras en lo que a seguridad se refiere, como por ejemplo que el reconocimiento de caras es mejor (aunque, al no ser óptimo, hay que tener mucho cuidado con su uso). Pero, sin duda, esta es menos significativa que cualquiera de las dos anteriores.
Descargas más seguras y Store más vigilada
La seguridad no solo vive en el sistema: Google refuerza filtros y procesos de revisión en su tienda para detectar familias de malware y retirar apps dañinas. Aunque las tasas reales de impacto sobre usuarios son relativamente bajas frente al ruido mediático, los controles ayudan a frenar amenazas como troyanos SMS, adware agresivo o droppers. Cuando instalas fuera de Play, la verificación del sistema y el sentido común son clave.
Fragmentación, WebView y el papel de las actualizaciones
Por lo tanto, la mejora respecto a la versión Ice Cream Sandwich es muy grande, y mucho más evidente con las descargas de las aplicaciones de Google Play, por lo que Jelly Bean incluye mejoras que no se han promocionado en exceso, pero que son muy efectivas para los usuarios y que les harán estar mucho más seguro… aunque esto no quiere decir que se deba bajar la guardia frente a los ataques y software malicioso ya que, antes o después, se encontrará alguna forma de saltarse ASLR y tanto Windows, como iOS como Android tendrán que buscar otra forma de defenderse. Pero, hasta ese momento, la seguridad es mejor en Android 4.1 que en 4.0.
Conviene entender la fragmentación: no todos los dispositivos reciben el sistema más reciente a la vez. Google mitiga parte del problema con componentes actualizables (por ejemplo, servicios del sistema), pero ciertas vulnerabilidades de bajo nivel (como las del motor WebView en ediciones antiguas) requieren nuevas versiones del sistema. Con el paso del tiempo, algunas ediciones dejan de recibir parches; si tu fabricante ofrece una actualización, acéptala cuanto antes.
Buenas prácticas: el usuario también importa
Más allá de capas técnicas, somos nosotros los responsables del uso del dispositivo: instala apps desde fuentes confiables, revisa los permisos, evita “parches milagro” y no piratees apps (suelen venir modificadas). Las funciones de cifrado, el bloqueo de pantalla robusto y las copias de seguridad reducen el impacto si algo sale mal.
Buenos añadidos por parte de Google, pero llega un poco tarde a esta “carrera” que por ahora gana iOS de Apple, que desde hace tiempo utiliza ASLR y DEP (y algún otro protocolo como Code Signing technology). De todas formas Android va por buen camino y, no sería de extrañar, que en menos de un año se le pueda considerar totalmente seguro. Si siguen así, eso es seguro.
La combinación de ASLR, DEP y endurecimientos del sistema convierte a Jelly Bean en un Android sustancialmente más difícil de explotar, sin sacrificar fluidez. Aun así, la seguridad es un proceso: mantener el sistema y las apps al día, activar las protecciones disponibles y usar el dispositivo con cabeza es lo que realmente marca la diferencia a largo plazo.
