02 diciembre 2013

Actualidad del malware en Android (1 de 3)

A finales de octubre tuve la oportunidad de participar como ponente en el taller "Seguridad para vivir conectado: Entornos móviles, Nubes y nuevas formas de conexión" que tuvo lugar en la séptima edición de ENISE.

El enfoque que di a la charla consistía en analizar cómo se encontraba la actualidad del malware en Android comparándola con lo que mostré en la ponencia del año anterior[1]. Analicé la situación actual del malware en el Google Play, las vulnerabilidades más recientes en el sistema operativo, aplicaciones y dispositivos, e hice finalmente una pequeña demostración de cómo de fácil puede resultar realizar una campaña de malware en dicho sistema (apoyándome en temas tratados en otras ponencias).

Veamos un resumen de los temas planteados...

1. Estadísticas del malware en Android

Si nos apoyamos en el tercer informe anual (2013) sobre amenazas en entornos móviles publicado por la empresa Juniper Networks[2] observamos como el malware en en estos entornos se ha cuatriplicado con respecto al año pasado (concentrándose prácticamente en dispositivos Android), manteniéndose el fraude mayoritariamente a través del envío de mensajes SMS de tarificación especial y cómo uno de los motivos de esta situación se encuentra en la desactualización del software de los dispositivos.

Figura 1 - Informe sobre amenazas en entornos móviles publicado por Juniper Networks
Si bien soy de los que opinan que este tipo de informes hay que "cogerlos con pinzas", pueden servirnos para hacernos una idea global del estado actual de las amenazas en el ecosistema Android. De él podríamos sacar la fácil conclusión de que Android (¡y sus usuarios!) sigue siendo un sistema operativo muy cómodo para el malware, ofreciendo un binomio esfuerzo-beneficio muy interesante para los (ciber)delincuentes.

Relacionado con este tema, en septiembre se publicó un informe[3] redactado por el FBI y el Departamente de Seguridad Nacional de EEUU en el que se indicaban las amenazas principales a las que se ven expuestos dispositivos con Android y el porqué de dicha situación.

También aproveché para comentar la presentación que realizó Adrian Ludwig, jefe de seguridad de Android, en la conferencia Virus Bulletin de Berlin. Si bien la información que dió resultó interesante, muchos matices son claramente discutibles. En el blog de Eleven Paths Sergio de los Santos (@ssantosv) publicó en su día un post muy interesante sobre este tema; así que sólo me queda recomendaros su lectura[4] :)

Figura 2 - Capas de seguridad en Android (presentación de Adrian Ludwig en Virus Bulletin 2013)

2. Seguridad en Jelly Bean/Kit Kat (4.1+)

Si observamos las distintas actualizaciones de Android (Jelly Bean), podemos resumir las medidas de seguridad que ha ido implementando Google en las siguientes:
  • Cuando un usuario instala una aplicación desde fuentes externas (es decir, sin utilizar Google Play), se le da la posibilidad que dicha aplicación sea escaneada y le notifica si se detecta un comportamiento malicioso (pudiendose bloquear su instalación). Aun así, ya se ha demostrado en múltiples ocasiones que la efectividad de Bouncer (sistema de detección de aplicaciones maliciosas de Google) es cuestionable, por lo que la utilidad de esta funcionalidad es claramente limitada (si bien, es recomendable que un usuario "normal" la tenga activada).
  • Si una aplicación intenta realizar el envío de un SMS a un número de tarificación especial, se le pedirá confirmación previamente al usuario (evitándose la situación de envío incontrolado de mensajes SMS existente en versiones anteriores -el usuario únicamente se enteraba del fraude una vez que le llegaba la factura-).
  • Si un usuario intenta acceder mediante ADB al dispositivo, se solicitará que previamente autorice dicha conexión, por lo que el usuario tendrá que poder desbloquear el teléfono para validar el acceso (evitándose el acceso a dispositivos evadiendo el código de bloqueo).
  • Se ha implementado SELinux (aunque su configuración varía en función de la versión de Android en el dispositivo).
  • Al igual que en sistemas iOS (presente desde hace tiempo), se ha incluido la gestión granular de los permisos de las aplicaciones. En dicho panel de configuración (que no está accesible por defecto) es posible revocar permisos a aplicaciones y controlar cuándo ésta hace uso de los que tiene habilitados.
Desde la página web de Android podéis acceder a los listados con todas las medidas de seguridad que se han ido implementando versión a versión (4.2, 4.3, 4.4).

3. Estado actual del malware en Google Play

Cuando apareció en escena Bouncer publicamos Yago Jesús (@YJesus) y yo en este mismo blog un estudio[5] de la eficacia de dicho sistema frente al malware que se intentaba distribuir a través de Google Play. No creo que sorprendiera a nadie la nula efectividad que demostró tener el sistema, por lo que únicamente creaba una falsa sensación de seguridad sin aportar un verdadero valor añadido al market oficial de Android.

Desde hace unos meses Sergio de los Santos lleva analizando y publicando en Twitter muchos casos de malware en el Google Play, no sólo el número de descargas de dichas aplicaciones maliciosas sino también controlando su tiempo medio de vida y los posibles grupos de (ciber)delincuentes detrás de las mismas. Os recomiendo que le sigáis para estar al día sobre este tema y controlar cómo evolucionan realmente los mecanismos de seguridad que se implementan en Google Play. Algunos de los casos que relataba son los siguientes:
  • Uso de técnicas de infección "de siempre" que se utilizan también en Android (p.e FakeAV)
  • Aplicaciones simples (p.e fondos de pantalla) que solicitan permisos extraños como grabación de audio y video, que tienen entre 500 y 1000 descargas y un tiempo de vida superior a la semana.
  • Desarrolladores especializados en crear aplicaciones-copia con contenido malicioso (usurpando nombres de aplicaciones legítimas) cuyas cuentas permanecen activas durante más de tres meses.
Figura 3 - Tuit de Sergio de los Santos sobre malware en Google Play

4. ¿Es Android un sistema operativo seguro?

Durante el Gartner Symposium / ITxpo, Eric Schmidt realizó unas declaraciones que no dejaron a nadie indiferente e incluso arrancaron alguna carcajada entre el público[6]. También provocó reacciones entre personalidades del mundo del hacking de dispositivos móviles como es el caso de Charlie Miller que publicó el siguiente tuit:

Figura 4 - Tuit de Charlie Miller sobre las declaraciones de Eric Schmidt en el Gartner Symposium / ITxpro

Lejos de querer entrar en el debate sin sentido de qué plataforma es la más segura, os animo a que saquéis vuestras propias conclusiones al finalizar esta serie de posts y analicéis si los escenarios planteados serían posibles en iOS (y, porqué no, que otros escenarios contrarios se os ocurren).

En el próximo post hablaremos sobre las vulnerabilidades más importantes que aparecieron en Android desde julio de 2013 (varias de ellas se presentaron en la Blackhat/DEFCON).

Información de interés relacionada con el post:

----------------------

Artículo cortesía de Luis Delgado.

9 comments :

María García dijo...

He leído por ahí q no es recomendable actualizar a KitKat porque trae problemas de seguridad. ¿Es cierto?

Luis Delgado dijo...

Uno de los fallos que se detectó era que en la actualización no gestionaba correctamente los dispositivos cifrados y, si introducías una clave errónea, el proceso la aceptaba igualmente y, por tanto, perdías todos los datos. Por lo tanto actualiza sin miedo y no te equivoques al introducir la contraseña :P -aunque supongo que ya lo habrán solucionado, de ahí que el despliegue sea escalonado-

Si te refieres al caso de la vulnerabilidad "Master Key", instalate la aplicación de Bluebox para tenerla controlada o, si tienes rooteado el teléfono, aplica el parche y listo :)

María García dijo...

Gracias por responder tan bien y rápido. :)
El teléfono no lo tengo rooteado por si los bichos. Lo de la "Master Key" ya ni recuerdo qué era, pero sé que era algo antiguo y no sé si sigue presente en la 4.3, que es la que yo tengo. En todo caso, me instalé el Bluebox en su día.
Lo de que si me equivoco de contraseña pierdo los datos, me da miedito porque a veces me equivoco por eso de tener una distinta en cada sitio. Aunque sería tirar de salva y ya está. Supongo de todos modos que a lo mejor sí que lo han solucionado ya. Bueno, pues allá voy y me actualizo.

Mojarrison dijo...

En el caso de dispositivos rooteados, con las mínimas apps (siempre verificadas), ¿qué posibilidades tenemos de infectarnos con algún tipo de malware?

Luis Delgado dijo...

Realmente, si haces un uso normal/razonable del dispositivo, no deberías tener problemas (al menos a nivel de aplicaciones maliciosas como tal, otra cosa son el resto de posibles vectores -vulnerabilidad de navegadores, webviews, etc-).

En las próximas entregas veremos más ejemplos y de ahí podrás sacar tus propias conclusiones. Aun así, riesgo siempre habrá pero con un uso responsable de los dispositivos (y sentido común) por norma general es suficiente (si fueramos extra paranoicos, apaga y vámonos...)

María García dijo...

El problema (según creo) es que, una vez que te haya caido el bicho, puede hacer mucho más daño si el dispositivo está rooteado por tiene más permisos. Es como tener permisos de administrador o superusuario en otros sistemas. Si no me equivoco.

Luis Delgado dijo...

Efectivamente, mantener el teléfono "rooteado" es un riesgo que en la mayoría de los casos no está justificado :)

María García dijo...

Entiendo que se justifica (en mi opinión) si tienes un modelo de esos que no actualizan y lo rooteas para poder instalarte una rom tipo Cyanogen. Creo que es mejor tenerlo rooteado y con la última versión que sin rootear y con una versión no actualizada que pueda tener vulnerabilidades.

Luis Delgado dijo...

Estoy de acuerdo en lo de tener el móvil actualizado, pero tienes la opción de "des-rootearlo" (ojo, no soy usuario de Cyanogen y no se si ello afectaría al funcionamiento normal del dispositivo, no creo) que es lo que hacía yo con mi terminal anterior (en el día a día no usaba nada que requiriera ser root, y para otros temas tengo dispositivos de "desarrollo")
Aun así, cada uno tiene sus preferencias y adapta su dispositivo y el riesgo a correr al uso que le quiera dar al mismo.