Cuando se descubre una vulnerabilidad en Android, Google recibe la noticia y se aplica un parche para dispositivos Android. Los dispositivos Nexus suelen ser los primeros dispositivos que reciben estos parches, ya que derivan de AOSP (Android Open Source Project – El núcleo de Android, donde Google se compromete a actulaizar). El lapso de tiempo entre el conocimiento de una vulnerabilidad y el momento en que se aplica un parche a un dispositivo, puede ser importante, mas de un año y muchas veces nunca. Por ejemplo, el error Towelroot (CVE2.014-3.153) se sabe desde finales de mayo, principios de junio 2014. Este error tardo varios meses en ser parcheado en el Nexus 5. Esto deja a usuarios extremadamente vulnerables a los ataques de aplicaciones. La mayoría de los usuarios no saben que sus dispositivos son vulnerables y esta herramienta está destinado a hacer visibles las vulnerabilidades de dispositivos Android. Samsung, HTC, y todos los demás OEM mantienen versiones muy personalizadas de Android. La infraestructura de implementación de parches de fabricantes de equipos originales está en desorden. Los fabricantes de equipos originales reciben los parches de Google y pasan semanas o meses antes de aplicarlos y probarlos. Luego se envían las actualizaciones del dispositivo a la compañía que se encarga de hacerlos llegar al usuario final. Después pasan a través de otro ciclo de control de calidad de la compañía.
Android VTS (Android Vulnerability Test Suite), es una herramienta para test de vulnerabilidades de dispositivos Android, con la filosofía de la recopilación abierta de datos de vulnerabilidades y con la ayuda de lacomunidad, trata de echar un pulso sobre el estado de seguridad de Android.. Esta herramienta pretende mostrar al usuario final la superficie de ataque que es susceptible en un determinado producto. En la aplicación de estos controles se intenta minimizar o eliminar los falsos positivos/negativos, sin afectar negativamente a la estabilidad del sistema.
Las vulnerabilidades en un dispositivo pueden existir en muchas capas dentro de Android. Por ejemplo, puede existir un error en el kernel (por ejemplo, Towelroot) o puede existir en el marco específico de Android (Android Masterkeys / FakeID). Algunos de los errores del kernel a veces pueden ser difícil de comprobar, sin que pueda causar inestabilidad en el sistema. Esta implementación tiene cuidado de no incluir controles que podrían causar problemas de inestabilidad para el usuario final y por lo tanto se pueden omitir los controles que podrían causar estos tipos de problemas. El marco en el momento actual consiste en un vector de comprobaciones de vulnerabilidad, sus implementaciones concretas varían enormemente dependiendo del error.
Fuente:https://www.gurudelainformatica.es/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
