Informe específico S21sec Malware en Smartphones (II)

www.s21sec.com

Informe específico Malware en Smartphones (II)

ÍNDICE 1

INTRODUCCIÓN............................................................................................................... 3

2

SEGURIDAD EN S.O MÓVILES ...................................................................................... 4

3

2.1

ANDROID ........................................................................................................ 4

2.2

IPHONE

2.3

BLACKBERRY.................................................................................................. 7

2.4

WINDOWS PHONE ........................................................................................... 8

2.5

SYMBIAN ........................................................................................................ 9

.......................................................................................................... 6

SEGURIDAD EN MERCADO DE APLICACIONES ....................................................... 11

3.1

ANDROID ...................................................................................................... 11

3.2

SYMBIAN ...................................................................................................... 15

3.3

APPLE .......................................................................................................... 16

4

VECTORES DE INFECCIÓN Y PROPAGACIÓN .......................................................... 17

5

MEDIDAS DE SEGURIDAD ........................................................................................... 23

6

ANÁLISIS PRÁCTICO: GEMINI ..................................................................................... 24

7

SEGURIDAD DE PAGO POR MÓVIL: NFC .................................................................. 28

8

CONCLUSIONES............................................................................................................ 31

www.s21sec.com

Página: 2/32

Informe específico Malware en Smartphones (II)

1

INTRODUCCIÓN

Esta es la segunda parte del Informe sobre malware en Smartphone que se envío el pasado mes de noviembre. En dicho informe se hizo una introducción a la evolución del mercado de móviles tanto desde el punto de vista tecnológico como de la Seguridad, repasando la evolución desde el primer malware conocido destinado a este tipo de plataformas, hasta la última y más sofisticada muestra disponible. También se hizo una introducción a la seguridad de los dispositivos móviles desde diferentes ángulos, y se vio en detalle como Zeus, el más famoso de los troyanos bancarios dio el salto a esta plataforma mediante la modificación de las inyecciones de código que realiza. Este informe tiene como objeto entrar más en detalle sobre la problemática del malware en este tipo de dispositivos, orientado concretamente a los denominado teléfonos inteligentes (Smartphone), viendo algún ejemplo práctico, y reuniendo la información necesaria para realizar un análisis de la situación actual de esta problemática. Igual que en la primera parte, se ha optado por realizar una aproximación desde diversos puntos de vista para tener una perspectiva global de este fenómeno y sus consecuencias en cuanto a la seguridad y la privacidad. De manera destacable, se muestran unas recomendaciones prácticas sobre cómo protegernos de los nuevos riesgos de Seguridad que introduce este mercado. Así mismo, hay un apartado específico sobre pago por móvil, un sistema que se ha empezado a usar en diciembre del año pasado en España como experiencia piloto. En dicho apartado se evalúan los riesgos ya existentes de la tecnología usada para realizar pagos por móvil y se resaltarán unas buenas prácticas para este nuevo uso. A modo de contexto, se detalla la seguridad en estos dispositivos, los mercados de aplicaciones más activos actualmente, también se detalla un análisis práctico de una nueva muestra de malware y se finaliza el informe con las conclusiones extraídas de toda la información analizada. Durante la realización de este informe la empresa de análisis de mercados Canalys1 publicó los datos del último trimestre de 2010 sobre el mercado de Smartphone2. Dicho informe confirma un hito en dicho mercado que ya se preveía, y es que Android, se ha convertido en la plataforma líder, por delante ya de la plataforma Symbian de Nokia (que finalmente adoptará sistemas basado en Microsoft para implementar en sus próximos dispositivos). El informe de Canalys también subraya el incremento del mercado de Smartphone en el periodo analizado.

1 2

http://www.canalys.com http://www.canalys.com/pr/2011/r2011013.pdf

www.s21sec.com

Página: 3/32

Informe específico Malware en Smartphones (II)

2 SEGURIDAD EN S.O MÓVILES 2.1

ANDROID

Seguridad en aplicaciones Android tiene un modelo de seguridad único en el que pone al usuario bajo el control del dispositivo. La naturaleza abierta de la plataforma permite añadir cambios y extensiones propietarias, las cuales pueden ayudar o interferir en la seguridad del dispositivo. Android es una plataforma basada en Linux programada en Java y diseñada con sus propios mecanismos de seguridad adaptados a un entorno móvil. Combina características multitarea, gestión eficiente de memoria compartida, permisos de ficheros e identificadores de usuario Unix (UIDs). Un punto importante en el diseño de la arquitectura de seguridad de Android es que ninguna aplicación tiene permiso, por defecto, para realizar operaciones que puedan tener un impacto negativo en el sistema operativo, el usuario u otras aplicaciones. Esto incluye la lectura o escritura de datos privados del usuario (como contactos o emails), la lectura o escritura de ficheros de otra aplicación, acceso a la red, mantener el dispositivo activo, etc. Debido a que el kernel aísla las aplicaciones unas de otras, las aplicaciones tienen que compartir datos y recursos explícitamente. Esto lo hacen declarando los permisos que necesitan para usar las capacidades adicionales que no proporciona la sandbox. Las aplicaciones declaran los permisos que necesitan estáticamente y advierten al usuario a la hora de ser instaladas. Android no tiene mecanismos para gestionar los permisos dinámicamente porque esto complica la experiencia del usuario.

Android requiere que los desarrolladores firmen su código. Normalmente es suficiente con certificados auto-firmados, de tal forma que los desarrolladores no necesitan ningún permiso o asistencia externa. Uno de los motivos para esto es facilitar las actualizaciones de las aplicaciones evitando la creación de complicadas interfaces o permisos. Los

www.s21sec.com

Página: 4/32

Informe específico Malware en Smartphones (II)

desarrolladores ganan una buena reputación haciendo buenos productos; sus certificados prueban su autoría. De esta forma se consigue:   

Identificar al autor del código. Detectar si la aplicación ha cambiado. Establecer confianza entre aplicaciones.

Las aplicaciones necesitan de aprobación para hacer las cosas que el usuario espera que hagan, como usar la cámara, mandar mensajes SMS o acceder a los contactos del usuario de la aplicación. Android usa los denominados “manifest permissions” para manejar lo que el usuario le permite hacer a las aplicaciones. De esta forma se introducen los permisos que son necesarios en el fichero AndroidManifest.xml y el usuario los acepta durante la instalación. Cuando se instala nuevo software, el usuario tiene la opción de decidir si confía en él en base a los análisis de otros usuarios, la reputación del desarrollador y los permisos solicitados. Una vez instalada la aplicación, éstos no pueden ser modificados.

Dispositivo

www.s21sec.com

Página: 5/32

Informe específico Malware en Smartphones (II)

En cuanto a la seguridad física del dispositivo, Android brinda la posibilidad de definir un “passcode” o patrón de acceso, sin embargo, a la hora de escribir estas líneas, únicamente la versión 3.0 Gingerbread anunciada3 para tablets, dispondría de cifrado nativo de datos. De tal forma, las actuales versiones para smartphones (2.2.1 Froyo), no dispondrían aún de dicha posibilidad, teniendo que recurrir a aplicaciones de terceros. Lo mismo ocurriría a la hora del borrado de datos de forma remota en caso de robo o pérdida. Pero siempre existe la posibilidad de usar aplicaciones externas que amplíen esta funcionalidad. 2.2

IPHONE

Seguridad en aplicaciones Mientras que Android pone bajo el control del usuario la evaluación de los requisitos de una aplicación antes de instalarla, Apple controla todo el proceso ella misma, controlando cada una de las aplicaciones antes de ponerse a la venta en la App Store Muchos ven la aproximación de Apple como la más segura para los usuarios, aunque la opacidad del proceso hace que no se sepa qué se comprueba exactamente por parte de la compañía. Dado el número de nuevas aplicaciones escritas cada día, parece improbable que Apple, o cualquier otra compañía, pueda hacer mucho más que verificar la identidad del desarrollador y qué la aplicación haga lo que promete hacer. También podría ser fácil para cualquiera, añadir código malicioso después de que haya sido aprobada. De cualquier forma, no hay duda de que una gran cantidad de aplicaciones vetadas por Apple tenían alguna vulnerabilidad. El sistema utilizado por iPhone (iOS) está diseñado, en principio, teniendo en cuenta las necesidades básicas en cuanto a seguridad se refiere, integrándolas en su propio núcleo. Las aplicaciones deben estar firmadas digitalmente, hecho que dificulta su manipulación con fines maliciosos. Otra medida de seguridad es el “sandboxing” , esta técnica no permite que una aplicación acceda a los datos de otra. Adicionalmente, los ficheros de sistema, así como sus recursos y el propio kernel, están protegidos respecto a posibles accesos a nivel de usuario. Si una aplicación requiere acceso a los datos de otra, solamente es posible hacerlo a través del uso de una API específica proporcionada por el propio iOS. Otras de las características de seguridad implementadas en este tipo de plataformas, es la gestión de credenciales de modo seguro (tanto de aplicaciones como de servicios de red) mediante el cifrado de las mismas en el propio dispositivo. Dispositivo En el caso de la seguridad física del dispositivo, se ofrecen las siguientes posibilidades por defecto:   

Passcode Borrado remoto Borrado local

3

http://www.engadget.com/2011/02/02/android-3-0-honeycomb-can-encrypt-all-your-data-needsa-full/

www.s21sec.com

Página: 6/32

Informe específico Malware en Smartphones (II)

Además es posible establecer diferentes políticas de seguridad como pueda ser una longitud mínima del passcode, caducidad, auto bloqueo, número máximo de intentos, etc. En el caso de la versión 4 de iOS , se implementan “de serie” otras características de protección del terminal. Estas características se basan en la generación de un passcode (que debería cumplir unos requisitos mínimos en cuanto a longitud y fortaleza para ser realmente efectivo) ligado al hardware de cifrado del propio iPhone, de manera que se genera una llave digital que impide acceder a los datos del dispositivo, incluso aunque este sea comprometido. Para habilitar este mecanismo, basta con crear dicho passcode. Borrado remoto. iPhone soporta una de las características que hoy en día puede considerarse como indispensable en plataformas móviles, el borrado remoto seguro. En caso de robo o pérdida del dispositivo, su dueño puede enviar de manera remota un comando que borre de manera segura (en principio, no recuperable) los datos contenidos en el dispositivo. Borrado Local. Esta característica, permite el borrado local en el caso de que se introduzca de manera errónea la credencial de acceso al dispositivo. Por defecto, si se introduce 10 veces el passcode de manera errónea, se procede a efectuar el borrado de datos del dispositivo. Esta característica es configurable desde el propio iPhone, pudiendo aplicar políticas más severas (menos intentos).

2.3

BLACKBERRY

A nivel de comunicaciones Blackberry Enterprise Solution implementa funcionalidades criptográficas basadas en el uso de llaves simétricas. Este diseño implica tener todos los datos cifrados entre el dispositivo y el servidor Blackberry Enterprise. Solamente alguno de estos dos elementos (servidor o dispositivo) es capaz de descifrar los datos. Esta medida implica que terceras partes (incluyendo proveedores de servicio), no deberían poder acceder a la información sensible gestionada (enviada/recibida) por este tipo de dispositivos. A nivel local, se puede implementar el cifrado del contenido del dispositivo mediante políticas de seguridad implementadas en la propia plataforma. Similar al borrado local de iPhone, cuando el usuario introduce erróneamente diez veces la contraseña de acceso, se procede a borrar los datos del dispositivo de manera automática. Esta función está disponible desde el menú de ajustes , concretamente en opciones generales. Otras medidas de seguridad implementadas en este tipo de dispositivos son:     

Uso de protocolos seguros entre el dispositivo y el servidor Blackberry Enterprise Server. Cifrado a nivel local de los datos Cifrado de las llaves “maestras” en el propio dispositivo. Control de conexiones (bluetooth, inserción de tarjetas externas, etc.) Funcionalidades de borrado seguro remoto.

www.s21sec.com

Página: 7/32

Informe específico Malware en Smartphones (II)

 

 2.4

Protección contra lectura de radiación electromagnética (a partir de BB 4.2) Protección mediante la gestión de uso: permite el borrado remoto del dispositivo si no se producen determinados eventos (desbloqueo del terminal en una frecuencia de tiempo predeterminada, imposibilidad de recibir políticas remotas, etc. Estos eventos pueden ser configurados para adaptarlos a la política de seguridad de la empresa. Implementación e interacción con plataformas PKI.

WINDOWS PHONE

La plataforma de Microsoft también implementa de técnicas de “sandboxing” (aislamiento en la ejecución de aplicaciones). En este sentido, cabe destacar la nueva versión de Internet Explorer implementada en estos dispositivos que se ejecuta utilizando estas técnicas de sandboxing, hecho que debería reducir el impacto de códigos maliciosos basados en web. Windows Phone introduce en concepto de “chamber” o cámara, en el sentido que cada aplicación corre en su propio espacio delimitado y la gestión de este espacio está implementada mediante políticas de sistema, estas políticas define que características del sistema operativo pueden ser usadas por cada una de las cámaras. Windows Phone tiene definidos 4 tipos de “chambers”: 



 

TCB (Trusted Computing Base): Es la cámara con más privilegios del sistema, prácticamente permite acceso sin restricciones a la mayoría de funciones del dispositivo incluyendo la modificación de las propias políticas de seguridad. Es en este espacio donde se ejecuta el propio kernel del sistema. ERC (Elevated Rights Chamber): Similar a la anterior, pero con la diferencia de que no puede acceder ni modificar las políticas de seguridad del sistema. En principio pensada para servicios propios del dispositivo y drivers cargados en “modo usuario”. SRC (Standard Rights Chamber): La opción por defecto para las aplicaciones preinstaladas en el dispositivo. LPC (Least Privileged Chamber): Está sería la cámara para todas las aplicaciones que no son Microsoft.

En cuanto al cifrado de recursos, Windows Phone soporta un gran número de métodos de cifrado (AES, SHA1, SHA256, HMACSHA1 y HMACSHA256). A diferencia de otras plataformas, actualmente estos dispositivos no implementan técnicas de guardado seguro para las credenciales guardadas en el equipo. Una característica destacable, es la manera como Windows Mobile gestiona los recursos de almacenamiento extraíbles. Windows Mobile, bloquea la tarjeta extraíble (SDCARD) introducida en el equipo mediante el uso de una llave de 128 bits, es decir, si se extrae esa tarjeta del dispositivo, no será posible leerla desde otro equipo u ordenador. En resumen, Microsoft ha desarrollado esta plataforma no solamente con varios mecanismos de seguridad de cara al usuario, sino que permite a los desarrolladores de

www.s21sec.com

Página: 8/32

Informe específico Malware en Smartphones (II)

aplicaciones aplicar medidas de seguridad extras mediante el uso de las herramientas de seguridad Silverlight. Aunque este tipo de dispositivo está aún en las primeras versiones de su ciclo de vida, parece que se han tomado las medidas oportunas para satisfacer los requisitos de seguridad tanto de usuarios como de empresas. Es de esperar que en futuras versiones, se implementen y mejoren las medidas de seguridad implementadas en Windows Phone.

2.5

SYMBIAN

Symbian OS Platform Security se introdujo inicialmente en la versión Symbian OS 9.1 (tercera edición de la plataforma S60), desafortunadamente todas las versiones anteriores, no tienen manera de determinar el grado de confianza de las aplicaciones instaladas. La seguridad y autenticación de las aplicaciones es una de las características fundamentales introducidas con “Platform Security”. Cuando se instala una aplicación, se le asignan ciertos privilegios en función de las características de esa aplicación. Estos privilegios o características de seguridad (denominadas capabilities) son gestionadas por el kernel del propio sistema operativo y no pueden ser cambiadas una vez se ha realizado la instalación del programa. Las capabilities definen por un lado los límites y permisos de una aplicación concreta y por otro, el nivel de confianza que posee en el contexto del sistema. Normalmente, cuando más “cerca” se encuentre una aplicación del kernel, más privilegios de seguridad requerirá. Las características principales del modelo basado en capabilities incluyen: -

-

Un proceso siempre adoptará las capabilities de la aplicación que lo crea El kernel mantiene en todo momento un listado de todas las capabilities por parte de cada uno de los procesos que se están ejecutando en el dispositivo. Una librería puede cargarse en un proceso siempre que tenga asignadas capabilities similares al proceso que carga dicha librería, es decir la confianza depositada en la librería debe estar como mínimo al mismo nivel que el proceso que la carga. En la carga estática de DLL´s, las capabilities se comprueban teniendo en cuenta la unidad que realiza la carga (ya sea un proceso u otra DL). Reglas de intercomunicación segura entre procesos, es decir, comprobaciones de las características de una comunicación en ambos extremos (cliente/servidor). Parseado de introducción de datos por parte del usuario, este sería el proceso de filtrado dividido en tres fases, según la propia documentación de la plataforma:

www.s21sec.com

Página: 9/32

Informe específico Malware en Smartphones (II)

En cuanto a las medidas de seguridad de instalación de aplicaciones, estas deben ir firmadas mediante certificados digitales. La gestión y emisión de este tipo de certificados por parte de Symbian Foundation, ha demostrado no ser del todo efectiva en cuanto a criterios de seguridad se refiere, ya que es habitual ver aplicaciones maliciosas con certificados emitidos correctamente.

www.s21sec.com

Página: 10/32

Informe específico Malware en Smartphones (II)

3 SEGURIDAD EN MERCADO DE APLICACIONES En el pasado informe se hizo una introducción al modelo de Seguridad de los principales mercados de aplicaciones para dispositivos móviles. A modo de resumen se hizo una clasificación de cuan restrictivo era cada modelo y de cómo cada fabricante imponía sus propias restricciones. El hecho de no disponer de una guía central o estándar que fije unas recomendaciones y buenas prácticas a la hora de publicar apps (Aplicaciones para móviles) en los diferentes mercados existentes, unido a la idiosincrasia de cada fabricante llevan a esta heterogeneidad de modelos de publicación. Esta realidad, que puede parecer desconcertante en un principio se torna sin quererlo en una medida preventiva contra la distribución masiva de malware en el entorno móvil, en contraposición a lo que viene ocurriendo en el mercado del PC. Frente a esta diferencia de modelos y tomando como referencia lo descrito en el informe anterior, se realiza un análisis de la penetración de malware en cada mercado aprovechándose de las características para publicar apps de cada uno de ellos.

3.1

ANDROID

Como ya se ha comentado en la introducción, canalys ha publicado un informe del último cuatrimestre del 2010 sobre el mercado de Smartphone en el cual destaca el nuevo liderazgo de Android como plataforma móvil.

Dicho informe resalta así mismo el fantástico año que ha sido 2010 para el mercado de Smartphone y el desafío que queda en 2011 para seguir con este incremento. Tecnologías como procesadores dual-core, pantallas 3D y NFC (ver apartado 7) serán las próximas novedades de este mercado. Centrándonos en la plataforma Android y concretamente en su mercado de aplicaciones, en países Orientales como China no está permitido el acceso al mercado de aplicaciones

www.s21sec.com

Página: 11/32

Informe específico Malware en Smartphones (II)

oficial Android4. Por ello disponen de otro tipo de mercados de aplicaciones propios, no oficiales. Fue en este tipo de mercados donde apareció Gemini5; un nuevo troyano para Android con características propias de una Botnet. Consultar el apartado 6 para un análisis detallado de esta malware. Por su parte el mercado oficial de Android es menos permisivo que la tienda de aplicaciones iTunes de Apple, en cuanto a la publicación de una APP se refiere. El mercado Android está considerado como un canal abierto de distribución, sin procesos de pre-aprobación y con sólo una serie de comprobaciones automáticas mínimas para asegurar la adherencia al modelo de Seguridad de Google. Por ello, los creadores de malware se han aprovechado de esa ventaja para introducir aplicaciones maliciosas en él. En cuanto a los creadores de aplicaciones legítimas de Android también deberían estar alerta, porque se han visto casos de compañías que, con la excusa de llegar a un acuerdo6, han intentado introducir aplicaciones maliciosas dentro de aplicaciones legítimas, para tener acceso a todos los datos de los usuarios de dicha aplicación legítima. Los riesgos son elevados, y tanto usuarios como creadores de software deben estar alerta para mantener las aplicaciones maliciosas fuera del mercado Android. Como ya se ha comentado en el apartado 2 “Seguridad en SO Móviles”, las aplicaciones declaran los permisos que necesitan estáticamente y es responsabilidad del usuario aceptarlas, delegando así gran parte de la seguridad de las aplicaciones en el usuario. Por otra parte, Android también delega la seguridad de su mercado de aplicaciones en gran parte en los usuarios, ya que una de las medidas más efectivas en contra de las aplicaciones de dudoso contenido, en este mercado es el propio usuario. En el 2009 Google eliminó un 1% de APPs del mercado Android según un informe que Google hizo para la FTC. La mayoría de ellas fueron eliminadas por quejas de violaciones de derechos y contenido adulto. Solo una ínfima parte de ellas fueron aplicaciones maliciosas destinadas a robar las credenciales bancarias del usuario. Recientemente se ha lanzado un nuevo market de android vía web7, dicha web permite al usuario navegar, buscar e instalar apps de Android como alternativa al mercado estándar que viene de serie en los Smartphone Android. El usuario únicamente tiene que hacer login con sus credenciales de Google y la aplicación recopilará la información del dispositivo Android registrado a su nombre así como los detalles de todas las aplicaciones del market que ya tenga instaladas. Para realizar un test de este nuevo servicio, elegimos una aplicación aparentemente inofensiva, se trata de una app educativa para practicar inglés, tal y como muestra la imagen, observamos que directamente ya obtiene los datos de nuestro móvil y operador y nos informa de los permisos que necesita esta aplicación para funcionar.

4

http://www.google.com/support/forum/p/Android+Market/thread?tid=0842388ef7e42f30&hl=en

5

http://blog.mylookout.com/2010/12/geinimi_trojan/

6

http://www.reddit.com/r/Android/comments/fm3cu/spyware_company_wants_us_to_embed_their_cod e_into/ 7 https://market.android.com

www.s21sec.com

Página: 12/32

Informe específico Malware en Smartphones (II)

Paso 1 de instalación de una app vía web Uno de los aspectos más importantes del proceso de instalación de una app android son los permisos requeridos. Los usuarios de Android deberían ser especialmente cuidadosos y leer los permisos que nos solicita una app antes de su instalación. Por ejemplo, un simple juego que solicitará permisos como SEND_SMS o RECEIVE_SMS se debería considerar como sospechosa e instalarla únicamente si estamos seguros sobre su funcionalidad. Al pulsar en instalar nos informa que la aplicación se descargará en nuestro dispositivo tal y como muestra la siguiente imagen:

Paso 2 de instalación de una app vía web Y automáticamente en cuanto el móvil tenga conexión wifi o 3G la aplicación quedará instalada sin ninguna interacción en el móvil:

www.s21sec.com

Página: 13/32

Informe específico Malware en Smartphones (II)

Instalación automática en el móvil vía web En resumen, con este nuevo servicio web del mercado de aplicaciones Android es posible instalar remotamente aplicaciones con tan solo las credenciales de una cuenta Google. Lo que convierte a estas credenciales del servicio en más valiosas. No será de extrañar ver un incremento de este objetivo en los archivos de configuración Zeus lo que simplificaría todavía más los ataques que se saltan la autenticación de dos factores como Zeus-Mitmo8 del que ya hablamos en la primera parte de este informe. Otro de los aspectos a destacar en esta plataforma, es la llegada de la tecnología NFC, consultar el apartado 7. La versión 2.3 de Android tendrá soporte nativo para NFC.

8

http://securityblog.s21sec.com/2010/09/zeus-mitmo-man-in-mobile-i.html

www.s21sec.com

Página: 14/32

Informe específico Malware en Smartphones (II)

3.2

SYMBIAN

De acuerdo al último informe publicado por canalys, Symbian ha perdido el dominio del mercado de Smartphones como plataforma móvil, pasando a ocupar el segundo puesto aunque muy cerca del nuevo líder; Android. Un aspecto a tener en cuenta de esta plataforma es que su mayor mercado se encuentra en Europa. Históricamente los dispositivos Symbian han sido y son los más atacados y abusados del mercado. Casi la totalidad del malware de esta plataforma se encuentra en copias ilegales de programas válidos. La mayoría de los usuarios que se descargan juegos y aplicaciones ilegítimos son conscientes de que corren un riesgo de infectar sus dispositivos, pero el aparente beneficio bien merece la pena correr el riesgo de instalar una aplicación maliciosa sin saberlo. Irónicamente, algunos creadores de aplicaciones empeoran la situación liberando versiones de su software con código malicioso en él sin ser conscientes. Un tipo de malware común en symbian es enviar SMS a servicios Premium. Una de las características de Seguridad de las aplicaciones Symbian es la “Firma de código” en la cual mantiene 4 niveles diferentes de Seguridad: -

-

-

Abierto a todos: Se aplica a todas las aplicaciones Permitido por el usuario en tiempo de instalación: A Las aplicaciones de este grupo se le dan acceso a ciertas capacidades restringidas solo durante la instalación. Permiso a través de firma symbian: No es sencillo conseguir este nivel de acceso ya que requiere una solicitud escrita exponiendo porque la aplicación necesita dicho nivel de acceso. Permitido por el fabricante: Este es el nivel más difícil de conseguir, ya que requiere un acuerdo específico entre Symbian y el OEM.

¿Cómo es posible saltarse estos niveles para infectar la plataforma?: El hecho de que los desarrolladores puedan firmar sus propias aplicaciones hace posible que una aplicación con código malicioso sea permitida por el usuario, aún cuando este haya sido avisado de que se trate de una aplicación desconocida y pueda llevar a resultados no deseados. En la actualidad gran parte de los usuarios se saltan estas advertencias y se infectan ellos mismos con una aplicación que contienen “malware” y que ellos mismos han sido los que le han permitido su instalación. Otra posible respuesta es que no hace falta pasar por ningún procedimiento de firma de código anterior. Una aplicación con malware puede enviarse al procedimiento de firma exprés 9de symbian, y ser aprobada. Este proceso de aprobación automático escanea las aplicaciones en busca de virus con una muestra aleatoria y posteriormente en ocasiones auditado por un humano. Las posibilidades son altas de que no sea auditado por un humano, y pase el escaneo automático.

9

https://www.symbiansigned.com/app/page/overview/process

www.s21sec.com

Página: 15/32

Informe específico Malware en Smartphones (II)

3.3

APPLE

En la primera parte de este informe se indicó que el modelo del mercado de aplicaciones de Apple es el más cerrado de todos los que existen. Toda la familia de dispositivos iPhone OS (iPhone, iPod touch iPad) están diseñados para ejecutar únicamente software aprobado por Apple. Para desarrollar una app que pueda estar disponible en la iTunes App Store, se deberá aceptar un programa de acuerdo 10de licencia del desarrollador de iPhone. El hecho de que el iPhone de Apple sea menos susceptible a malware que Android, no tiene tanto que ver con que Android sea Open Source y el iPhone código cerrado, declaraciones que se hicieron hace pocos días por una compañía tecnológica. Esta característica de Apple frente a sus competidores viene determinada principalmente por sus fuertes restricciones en los términos de acuerdo de los desarrolladores de aplicaciones, y en su gran capacidad para vetar aplicaciones de su Marquet, la App Store. Como dato significativo, un 10% de las aplicaciones vetadas11 por Apple en 2009 fue por malware frente al 1% de Android, como ya se ha comentado en el apartado anterior. Dicho acuerdo al que deben adherirse todos los desarrolladores de aplicaciones para esta plataforma tiene una sección que indica lo siguiente: “cualquier aplicación desarrollada usando el SDK de Apple solamente se podrá distribuir públicamente a través de la APP Store, y Apple puede denegar una app por cualquier razón, incluso si esta cumpliera con todos los requisitos exigidos por Apple. Por lo que si un desarrollador usa el SDK y su app es denegada por Apple, se le prohíbe la distribución a través de otros mercados de la competencia. Además de las fuertes restricciones que Apple impone a los desarrolladores, se reserva el derecho a cambiar dicho acuerdo en cualquier momento pudiendo eliminar de esa forma cualquier aplicación distribuida previamente al nuevo acuerdo que se publique si esta no cumpliese con los nuevos términos. Son esas fuertes restricciones12 las que hasta ahora mantienen alejado el malware del sistema iPhone pero también a muchos desarrolladores legítimos que no están dispuestos a aceptar tan abusivas cláusulas. Este hecho sigue manteniendo al mercado del iPhone como un mercado elitista, algo que posiblemente ha tenido que ver en la nueva dominación del sistema Android por el público en general. A modo de conclusión se puede deducir que el modelo de Seguridad de Apple es una mezcla de “Seguridad por Oscuridad” junto con fuertes restricciones que impone en cuanto a las apps creadas para esa plataforma. Quedando demostradas con la aparición de gusanos como Ikee y fugas de privacidad con Storm8, MogoRoad, Aurora Faint entre otros, que no existe método infalible para evitar el malware en ninguna plataforma.

10

http://www.eff.org/files/20100127_iphone_dev_agr.pdf http://www.businessweek.com/technology/content/nov2009/tc20091120_354597.htm 12 http://www.eff.org/deeplinks/2010/03/iphone-developer-program-license-agreement-all 11

www.s21sec.com

Página: 16/32

Informe específico Malware en Smartphones (II)

4 VECTORES DE INFECCIÓN Y PROPAGACIÓN Muchos de los vectores de infección “tradicionales” utilizados para infectar teléfonos móviles, siguen siendo válidos hoy en día. Debido en parte a la aparición de nuevos servicios asociados al uso de estas plataformas, a la constante evolución de este tipo de dispositivos y a la total integración de mercados virtuales, que como se ha expuesto anteriormente, permiten la descarga e instalación de aplicaciones con el mínimo esfuerzo por parte de los usuarios, era de esperar que los cibercriminales, en su continua prospección del ecosistema virtual con el objetivo de potenciar sus campañas fraudulentas, fijaran su punto de mira en este tipo de plataformas y en la optimización de las técnicas usadas para infectar y propagar el mayor número de dispositivos posibles. Aunque algunos de estos vectores podrían catalogarse como "tradicionales" y puede existir la percepción de que técnicas pasadas no funcionarán actualmente, la realidad es que todos ellos siguen siendo válidos hoy en día. Los principales métodos de infección y propagación son: Mensajería - SMS/MMS/Correo electrónico. Durante mucho tiempo, y tal como se comento en el anterior informe sobre Smartphones, fue el principal punto de infección y propagación en este tipo de dispositivos. El principal método “tradicional” de monetización mediante este vector, es la instalación de una aplicación que realiza envíos de SMS a servicios Premium controlados por los criminales. Sin embargo, proliferan las campañas de envío masivo de este tipo de mensajes a determinados móviles, que instan al usuario a instalar alguna aplicación complementaria con fines maliciosos, visitar alguna URL que contiene una réplica de un banco o entidad legítima y en general cualquier reclamo que permita al cibercriminal conseguir información sensible sobre el usuario infectado. Otro tipo de esquemas fraudulentos que están teniendo un impacto significativo, son aquellos que instan al usuario a que se conecte a una página web determinada para cambiar las claves de acceso del banco (o excusas similares). Evidentemente, el usuario que acceda a esta página réplica , pondrá a disposición de los cibercriminales todos los datos requeridos por la web maliciosa. Es decir, un esquema de phishing clásico pero cuy reclamo se origina mediante el envío de mensajes SMS.

www.s21sec.com

Página: 17/32

Informe específico Malware en Smartphones (II)

Ejemplo Phishing vía SMS En este sentido, se destaca una campaña reciente (principios del año 2011) en el que no solamente se realizó la campaña de propagación por mail, en este caso simulando un origen de VISA, sino que la misma campaña fue lanzada simultáneamente vía SMS.

Solicitud de datos de campaña de fraude propagada mediante e-mail y SMS Aunque no relacionado con la propagación de malware en sí, una muestra de “ataque” mediante el uso de SMS se explicó en el pasado informe cuando se expuso la técnica “Curse of Silence” en las que mediante el envío de mensajes SMS a unos dispositivos concretos (todos ellos basados en Symbian), estos dejaban de estar operativos. Este año en la conferencia Shmoocon 2011 dos investigadores han demostrado técnicas similares en su presentación “SMS-o-Death” (todas ellas basadas en el envío de este tipo de mensaje) cuyo objetivo han sido tanto diferentes modelos de móviles tanto “clásicos” como Smartphones. Los resultados dejaron patente de manera práctica lo viable y peligroso que puede ser un ataque de este tipo actualmente. Siguiendo con esquemas “clásicos” utilizados hoy en día, también se han detectado esquemas de pharming (redirección mediante la manipulación de un fichero local hacia servidores réplica) aplicados a este tipo de dispositivos, un ejemplo es Ikee.B, un troyano para iPhone que mediante la manipulación de un fichero local , hacía creer al usuario que estaba yendo hacia su banco legítimo cuando en realidad estaba accediendo a un sitio fraudulento que contenía una réplica de una entidad financiera. Otro tipo de mensajería instantánea susceptibles de ser utilizados como método de infección son los mensajes MMS (Multimedia Message System) , pensados para que su contenido sea principalmente multimedia (video, imágenes y similares). La monetización de este tipo de esquemas también ha sido tradicionalmente mediante el envío de SMS desde el teléfono infectado hacia servicios PREMIUM relacionados en algún punto de la cadena con el creador de la campaña para difundir el binario principal. En este sentido , destacamos a Redbrowser (descubierto en el año 2006) y Viver.A (año 2007) y sus distintas variantes que circularon durante los años siguientes.

www.s21sec.com

Página: 18/32

Informe específico Malware en Smartphones (II)

Imágenes de Symbian.Redbrowser, Symbian.Viver.A y Android.Fakeplayer

Si bien es cierto que principalmente la principal plataforma afectada han sido teléfonos con sistemas basados en Symbian, recientemente se han detectado aplicaciones maliciosas con funcionalidades similares afectando a dispositivos mucho más actuales, basados en Android. Es el caso de SMS.AndroidOS.FakePlayer.A que, distribuido como una aplicación legítima en el propio mercado de aplicaciones para Android (Android Market) simulaba ser una aplicación gratuita para el visionado de videos, que en realidad utilizaba la técnica comentada anteriormente (envío de SMS a servicios de pago). Para la infección, es necesario que el usuario intervenga, permitiendo la opción de instalar aplicaciones provenientes de fuentes desconocidas y aceptando los permisos necesarios para ejecutar la aplicación. Aunque este tipo de interacción puede parecer que sea un obstáculo para conseguir lograr un número de infecciones significativas, la realidad es que el número de infecciones sigue siendo notable. Otra técnica de fraude muy utilizada es la de enviar mensajes SMS de manera masiva, con el reclamos de haber ganado un regalo, ya sea un premio en metálico, un coche, etc.. instan al usuario a enviar un mail para confirmar la recepción del premio, y es aquí donde se produce la segunda fase del fraude, se ha detectado operaciones en las que simplemente se le contesta al usuario indicando que pague un importe (entre 300 y 600€) en concepto de envío y trámites del seguro, o directamente se le envía como respuesta un archivo pdf (para que el usuario rellene con sus datos de envío) modificado de tal manera que cuando el usuario lo abra, este descargará un binario (normalmente del tipo troyano) a su ordenador.

Ejemplos de campañas fraudulentas iniciadas mediante el envío de mensajes SMS.

www.s21sec.com

Página: 19/32

Informe específico Malware en Smartphones (II)

Una de las máximas más divulgadas en cuanto a la seguridad en dispositivos Smartphones, es la de considerarlos exactamente igual que los propios ordenadores que se utilizan diariamente. En este sentido , debería tenerse en cuenta la integración del correo electrónico en dispositivos móviles y su importancia como posible vector de entrada ya no solo de código malicioso, sino de mensajes con finalidades fraudulentas. Aunque la protección del correo estará implementada en el propio servidor, no sería descabellado el envío de un código malicioso muy específico destinado a una plataforma móvil y que este no fuera detectado por los sistemas de seguridad “tradicionales”, así pues sería recomendable actualizar dichos sistemas para que tenga en cuenta posibles amenazas cuyo destino sean teléfonos de este tipo. Bluetooth. Este tipo de tecnología inalámbrica (formado por un conjunto de especificaciones de hardware, software y protocolos de transmisión) es usado principalmente para la transmisión de voz y datos en distancias relativamente cortas. Históricamente se han descubierto varias técnicas que permitían comprometer algunos dispositivos o dejarlos inoperativos. Es posible que ciertas vulnerabilidades puedan ser replicadas en teléfonos más modernos (es el caso del un fallo en dispositivos HTC basados en Windows Mobile , en el que una vez autenticado y conectado mediante Bluetooh, era posible acceder a cualquier fichero del dispositivo móvil). Por lo tanto , una de las recomendaciones habituales es la de deshabilitar el Bluetooth cuando este no vaya a ser utilizado y modificar las opciones del teléfono para ponerlo en modo “oculto” , es decir , que no pueda ser detectado por otros teléfonos que estén realizando rastreo de este tipo de protocolos. Es recomendable emparejar el dispositivo solamente con aquellos sistemas de nuestra confianza. Repositorios de aplicaciones (Markets). Los “markets” entendidos como repositorios de aplicaciones para un tipo de teléfono determinado, están siendo utilizados de manera activa por los cibercriminales. Aún y teniendo en cuenta las medidas de seguridad implementadas en este tipo de repositorios (comentadas anteriormente en este informe) durante los últimos años se han detectado varias aplicaciones maliciosas que han sido puestas a disposición de los usuarios en diferentes repositorios de este estilo. El modus operandi suele ser siempre prácticamente el mismo, subir una aplicación legítima modificada con una carga oculta maliciosa, o directamente subir una aplicación maliciosa , camuflando su apariencia para llamar la atención de los usuarios. A principios de este año, Android detectó más de 50 aplicaciones legítimas modificadas para incluir un componente malicioso llamado Droid Dream , encargado de enviar la información personal contenida en el teléfono a un servidor remoto, el componente instalado en las aplicaciones comprometía el sistema mediante la vulnerabilidad CVE2010-EASY Android, dándole control absoluto al cibercriminal, que podría haber instalado cualquier otro tipo de código en el dispositivo con total libertad. En los informes

www.s21sec.com

Página: 20/32

Informe específico Malware en Smartphones (II)

prelimares del incidente , se hizo una estimación aproximada de 200.000 usuarios afectados. También se han detectado aplicaciones que pretendían ser el programa “oficial” de una entidad para realizar diversas gestiones, cuando en realidad su objetivo es el robo de credenciales de la propia entidad a la que simulan pertencer. El hecho de que muchos usuarios quieran sacarle más partido a su móvil y mediante alguna técnica explicada minuciosamente en muchos sitios en Internet que permite acceso total al dispositivo y la utilización de características o recursos no oficiales, ha provocado la proliferación de mercados alternativos en los que el proceso de validación de aplicaciones no es tan estricto como sus homólogo “oficiales”, lo que facilita en muchas ocasiones la tarea de los cibercriminales de poder propagar sus aplicaciones maliciosas. Se trata de la extensión de un escenario clásico, la utilización de “warez” (programas legítimos cuyo sistema de registro o licencia has sido comprometidos y que normalmente viene acompañados de malware) y la problemática a nivel de seguidad que implica.

Este sería el caso del troyano para Android analizado posteriormente en este documento, Geimini.

Propagación mediante QRCODE. Los denominados QR-Codes son código bi-dimensionales que pueden ser leídos e interpretados por lectores específicos. Actualmente, prácticamente cualquier Smartphone, permite la instalación de aplicaciones que permiten su lectura mediante la propia cámara del teléfono y su posterior interpretación por parte de la aplicación instalada a tal efecto. El código está formado por distintos “módulos” de color negro implementados en un fondo blanco. Inicialmente creado en el año 1994, su función principal era la creación de un código de lectura rápida (como su nombre indica QR : Quick Response) .

Aunque no se han descubierto campañas que utilicen este vector como entrada de malware, cualquier punto de acceso a este tipo de dispositivos puede ser susceptible de ser utilizado como vector de infección inicial. Rossano Ferranis, un reconocido analista de seguridad, expuso recientemente el potencial de esta técnica mediante la creación de

www.s21sec.com

Página: 21/32

Informe específico Malware en Smartphones (II)

QRcodes en los que se incluyen url “acortadas” (mediante alguno de los múltiples servicios existentes) que pueden conducir hacía, por ejemplo, urls con contenido malicioso que permitieran explotar el navegador del dispositivo (en la línea de los exploit kits utilizados para comprometer ordenadores).

www.s21sec.com

Página: 22/32

Informe específico Malware en Smartphones (II)

5 MEDIDAS DE SEGURIDAD Tomando como referencia los distintos vectores de infección expuestos en el punto anterior, es posible deducir ciertas medidas de seguridad a adoptar como usuarios de este tipo de dispositivos. -

Configuración del dispositivo: En la mayoría de ocasiones, los proveedores proveen dispositivos con una configuración insegura por defecto, es necesario repasar la configuración del dispositivo y activar las medidas de seguridad que este pueda incorporar (modo oculto de Bluetooth, desactivar “servicios” innecesarios, crear patrones o contraseñas complementarias para acceder al teléfono, etc.).

-

Control de conexiones : Sería responsable tener en cuenta si el ordenador al que se conecta un Smartphone no contiene ningún código malicioso susceptible de propagarse hacia el teléfono o incluso algún programa que realice una copia de los datos del terminal sin el conocimiento del usuario. Se debe evitar la conexión de los dispositivos en plataformas que no sean de nuestra confianza (aún así, el problema puede ser inevitable, por eso es necesario complementar la seguridad del sistema con otros mecanismos).

-

Control de Instalaciones : Una de las características de este tipo de dispositivos es la posibilidad de instalar en cualquier momento una aplicación en su teléfono. Sería recomendable no instalar aplicaciones cuyo origen no sea el oficial, en cuyo caso, deben leerse las especificaciones que la aplicación necesita para ejecutarse, desconfiando automáticamente si se piden más permisos de los necesarios. También pueden tenerse en cuenta otros criterios complementarios para evaluar una aplicación, como pueden ser , su número de descargas, los comentarios de los propios usuarios, tiempo en el mercado, otras aplicaciones del mismo proveedor,etc.

-

Implementación de medidas de seguridad de terceros: De la misma manera que se aplican sistemas de seguridad en los ordenadores, hoy en día se debe hacer lo mismo en los dispositivos móviles. Los principales desarrolladores de software antivirus, ya incorporan en su inventario soluciones destinadas a este tipo de plataformas, desde productos que monitorizan las aplicaciones instaladas en base a una serie de criterios, hasta soluciones más avanzadas que permiten el borrado de la información del teléfono de manera remota. Una opción interesante, sería la de integrar el dispositivo móvil “en la nube” de manera que si se produce un robo del mismo, los datos puedan ser inmediatamente controlados por el propietario desde cualquier otro terminal u ordenador en caso de perder el dispositivo principal.

www.s21sec.com

Página: 23/32

Informe específico Malware en Smartphones (II)

6 ANÁLISIS PRÁCTICO: Gemini Como ya se comentó en el informe mensual de Diciembre, a finales del mismo mes apareció una nueva muestra de malware que afectaba a los dispositivos con Android. Es la primera vez que se encuentra malware de estas características, capaz de convertir el móvil en parte de una botnet. Hasta el momento, el malware para Android siempre realizaba alguna actividad maliciosa sencilla, como el envío de SMS a números de pago grabados en la propia aplicación. En este caso se ha dado un “salto de calidad”, evolucionando notablemente y pasando a mostrar como los dispositivos móviles pasan a ser objetivo claro de las botnets. En este caso concreto el malware se ha localizado mayormente en China. Ciertas aplicaciones eran descargadas de “google Marquet”, modificadas para la inclusión del troyano y re empaquetadas para distribuirlas con contenido malicioso. Las aplicaciones elegidas han sido mayormente juegos, entre los que destacan Monkey Jump 2, Sex positions, President vs Aliens o City Denfesy Baseball Superstars 2010. Para el análisis de estas aplicaciones se debe tener en cuenta que no se trata de la clásica aplicación de escritorio, sino que se tratarán habitualmente de aplicaciones escritas en Java y optimizadas y que viajará dentro el formato .dex de la máquina virtual de Dalvik, empaquetadas junto con otros ficheros como el fichero manifest, dentro de un contenedor .apk. En el fichero manifest se muestran, entre otras cosas, los permisos requeridos por la aplicación. Estos permisos son mostrados al usuario, que deberá aceptarlos, pero por todos es sabido que pocos serán los usuarios que no instalen una aplicación porque esta aplicación solicite ciertos permisos ya que, o no los leerá, o posiblemente no comprenderá o no valorará lo suficiente las implicaciones de conceder dichos permisos. En el caso de los juegos, es bastante llamativo como se solicita incluso permisos para la escritura y lectura de SMS, tal y como se muestra a continuación: android.permission.INTERNET android.permission.ACCESS_COARSE_LOCATION android.permission.READ_PHONE_STATE android.permission.VIBRATE com.android.launcher.permission.INSTALL_SHORTCUT android.permission.ACCESS_FINE_LOCATION android.permission.CALL_PHONE android.permission.MOUNT_UNMOUNT_FILESYSTEMS android.permission.READ_CONTACTS android.permission.READ_SMS android.permission.SEND_SMS android.permission.SET_WALLPAPER android.permission.WRITE_CONTACTS android.permission.WRITE_EXTERNAL_STORAGE

www.s21sec.com

Página: 24/32

Informe específico Malware en Smartphones (II)

com.android.browser.permission.READ_HISTORY_BOOKMARKS com.android.browser.permission.WRITE_HISTORY_BOOKMARKS android.permission.ACCESS_GPS android.permission.ACCESS_LOCATION android.permission.RESTART_PACKAGES android.permission.RECEIVE_SMS android.permission.WRITE_SMS Este troyano es capaz tanto de robar datos como de llamar a otros números de teléfono o enviar SMS a números de pago. También es capaz de descargar y ejecutar nuevas aplicaciones, aunque esto puede no pasar desapercibido para el usuario curioso, ya que la ejecución de esta nueva aplicación implicará la solicitud de los permisos que requiera, cuando el usuario no ha solicitado la instalación de ninguna nueva aplicación. La comunicación con el servidor está cifrada con DES (56 bit), y se realiza una petición cada 5 minutos, cuyo formato es: PTID=33120001&IMEI=000000000000000&sdkver=10.7&SALESID=0006&IMSI=310260 000000000&longitude=0.0&latitude=0.0&DID=2001&autosdkver=10.7&CPID=3312 Se puede observar cómo se envía el IMEI, con lo que el terminal es inequívocamente identificado, a la vez que, entre otros datos, la longitud y latitud ubicando físicamente a la víctima. Como curiosidad, se puede ver como el típico “ping” es realizado con una comunicación mucho más humana:

Los servidores a los que se conectan estas primeras muestras son los siguientes: www.widifu.com:8080

www.s21sec.com

Página: 25/32

Informe específico Malware en Smartphones (II)

www.udaore.com:8080 www.frijd.com:8080 www.islpast.com:8080 www.piajesj.com:8080 www.qoewsl.com:8080 www.weolir.com:8080 www.uisoa.com:8080 www.riusdu.com:8080 www.aiucr.com:8080 117.135.134.185:8080 Por último, la lista de comandos que se pueden enviar al terminal infectado son los mostrados a continuación, con nombres bastante clarificadores en la mayoría de las ocasiones: contactlist smsrecord deviceinfo location sms register call suggestsms skiptime changefrequency applist updatehost install uninstall showurl shell kill start smskiller dsms updateHost

www.s21sec.com

Página: 26/32

Informe específico Malware en Smartphones (II)

changeFrequency skipTime applist contactlist Para concluir con este tema, cabe recordar tres consejos básicos para el uso e instalación de aplicaciones en los dispositivos Android, que evitarán en gran medida la infección mientras no se consiga una infección automática (drive-by, SMS malformados, fallos en aplicativos de redes sociales o correo, etc.): 1. Descargar únicamente aplicaciones desde Google Marquet 2. Comprobar los permisos solicitados por la aplicación, fijándonos en que no solicite permisos no necesarios para su funcionamiento. 3. Permanecer atento y ser consciente de que existe malware para los dispositivos móviles.

www.s21sec.com

Página: 27/32

Informe específico Malware en Smartphones (II)

7 SEGURIDAD DE PAGO POR MÓVIL: NFC Entre las novedades que están incorporando los últimos modelos de Smartphone, se encuentra la tecnología NFC (Near Field Communications). Dicha tecnología, compatible con el etiquetado RFID, es un protocolo de comunicación inalámbrica que permite conectar dos dispositivos a una distancia muy corta (10 cm) sobre la banda 13.56MHz (sin necesidad de licencia). Tiene dos modos de funcionamiento; activo si genera su propio campo RF o pasivo si recibe alimentación a través del campo RF generado por otro dispositivo. En este caso los móviles con chip NFC serán dispositivos pasivos y los terminales de pago los activos. En términos llanos, esta tecnología necesita que casi se toquen el emisor y receptor NFC para su funcionamiento. Este hecho lo convierte en un sistema ideal para sistemas de identificación o pago electrónico. Visa ha iniciado las primeras pruebas de pago a través del móvil mediante la tecnología NFC en Europa13, concretamente en Turquía, y a través de un terminal iPhone. Al tratarse de una tecnología tan novedosa, el iPhone 4 no lleva incorporado un chip NFC, lo que hace necesario utilizar un accesorio, Wireless Dynamics iCarte que junto con una aplicación descargada a través de iTunes convertirán al iPhone en un monedero. Esta aplicación deberá ser cargada cada vez que se quiera hacer el pago para luego tocar el terminal de pagos con el teléfono y la compra quedará realizada, sin necesidad de PIN. En España ya existía un proyecto piloto14 entre Telefónica, la Caixa y Visa Europe para realizar pagos mediante esta tecnología en la localidad de Sitges. La Caixa es la entidad emisora de una tarjeta VISA que se coloca en la SIM del móvil de los participantes de esta prueba ofreciendo así los mismos servicios que el cliente ya tiene con sus tarjetas. Los primeros resultados de esta prueba piloto en España han arrojado unos resultados 15 de 90% de pagos realizados. Este ha sido el mayor proyecto realizado en Europa de pago mediante tecnología NFC y los resultados demuestran la gran aceptación que tendrá en el futuro. Para el funcionamiento del pago mediante tecnología NFC se necesita el trabajo conjunto de diversas entidades; instituciones financieras, comercios, proveedores de servicios, fabricantes de chips y teléfonos entre otros. Ante la inminencia de un despliegue masivo de esta tecnología, cabe preguntarnos; ¿cómo se manejará la Seguridad en un ecosistema con tan diversos actores? Afortunadamente, la industria 13

http://www.itespresso.es/visa-prueba-el-pago-a-traves-de-tecnologia-nfc-en-europe-49296.html http://www.blog.lacaixa.es/2010/06/ya-es-posible-pagar-en-sitges-con-el.html 15 http://www.ebanking.cl/medios-de-pago/caixa-telefnica-visa-implantan-xito-sistema-pago-mvil-004838 14

www.s21sec.com

Página: 28/32

Informe específico Malware en Smartphones (II)

móvil y financiera ha hecho un gran esfuerzo en definir la realización de los pagos a través de móviles con soporte NFC y asegurar la información financiera. Los teléfonos móviles con NFC se aprovechan del estándar ISO/IEC 1444316. En el proceso de pago por proximidad, existen diversas fases aplicándose diversas capas de seguridad en cada una de ellas. Pero es el teléfono móvil el que contiene la aplicación de pago y la información financiera del consumidor, se trata de las dos partes que hay que asegurar. Actualmente hay 3 opciones 17para asegurar aplicaciones y datos de manera segura en el terminal móvil: -

USIM: Tarjetas de módulo de identidad del subscriptor universal Elementos de seguridad empotrados Tarjetas de memoria SD.

Las tres opciones dependen de la presencia del “elemento seguro” en el dispositivo móvil.

Disposición del elemento seguro ¿Qué es el elemento seguro? Es un entorno dinámico donde el código de la aplicación y los datos se pueden almacenar y administrar de manera segura y donde ocurre la ejecución de las aplicaciones. Este elemento reside en chips criptográficos de alta seguridad, y actualmente se están valorando los pros y contras sobre su situación dentro del teléfono móvil tal y como se muestra en la imagen superior.

16 17

http://en.wikipedia.org/wiki/ISO/IEC_14443 http://www.smartcardalliance.org/resources/pdf/Security_of_Proximity_Mobile_Payments.pdf

www.s21sec.com

Página: 29/32

Informe específico Malware en Smartphones (II)

Independientemente de toda la tecnología necesaria para securizar este nuevo tipo de transacciones, es importante resaltar que para usar una aplicación de pago por proximidad a través del móvil, no se requiere la introducción de un PIN. Este hecho acrecienta la gravedad ya de por sí alta al perder o ser víctima de un robo de un terminal con estas características. En cuanto a la historia de ataques y debilidades de esta tecnología cabe destacar el material publicado por Collin Muliner, entre ellos, diversas herramientas 18que convertían los ataques teóricos que existían hasta entonces en ataques prácticos. Las amenazas existentes en esta tecnología, según el paper19: Security in Near Field Communication (NFC) Strenghts and Weaknesses son: -

-

-

-

Eavesdropping (snifing): Al tratarse de una tecnología wireless se muestra obvio que este tipo de amenaza le afecta. La cuestión es cómo de cerca es necesario estar para conseguir una señal RF válida. Existen multitud de parámetros que pueden afectar, pero dar una idea general de esas distancias en el paper mencionado anteriormente apuntan a 10m si el dispositivo se encuentra en modo activo (enviando datos) y 1m si el dispositivo se encuentra en modo pasivo. Man in the middle: El mayor problema de este tipo de ataque para lograr su éxito es la generación de un segundo campo RF perfectamente alineado en el mismo tiempo, algo muy difícil de conseguir. Las diferentes situaciones en que se puede lograr este ataque llevan a la misma conclusión. Es prácticamente imposible montar un ataque man-in-the-middle en un escenario real. Corrupción de datos: Se trataría de un ataque DoS ya que no permitiría al atacante modificar datos sino interferir en ellos para corromperlos a través del envío de frecuencias válidas dentro del espectro de datos en el tiempo correcto. Modificación de datos: En este tipo de ataque el objetivo es que el dispositivo que recibe los datos reciba datos válidos pero manipulados. Este tipo de ataque no es trivial y su éxito depende del tipo de codificación usada, siendo mayor la probabilidad de éxito en el caso de usar codificación Manchester.

A la vista de estos datos, la conclusión es que la tecnología NFC por sí misma no proporciona protección contra sniffers o modificación de datos pero el establecimiento de un canal seguro sobre NFC solucionaría estas debilidades. Por otra parte esta tecnología no es susceptible a ataques man-in-the-middle.

18 19

http://www.mulliner.org/nfc/ http://events.iaik.tugraz.at/RFIDSec06/Program/papers/002%20-%20Security%20in%20NFC.pdf

www.s21sec.com

Página: 30/32

Informe específico Malware en Smartphones (II)

8 CONCLUSIONES Es importante resaltar que los cibercriminales, como regla, elegirán las oportunidades más simples para acometer sus ataques. Un atacante no necesitará invertir meses en intentar descubrir vulnerabilidades ocultas, cuando lo único que necesitan es crear una simple aplicación de la que estén seguros que muchos usuarios se instalaran para obtener datos personales y financieros para realizar el fraude. Este ha sido el caso del último troyano que afectaba a la plataforma Android, analizado en el punto 6. Este troyano venía empaquetado en una serie de aplicaciones y juegos populares. Haciendo un paralelismo con el pasado (incluso siendo una tendencia en el desarrollo de malware actual para PC), el rápido crecimiento del mercado de Smartphones, especialmente el gran crecimiento de la plataforma Open Source Android significa que el elemento criminal en respuesta a esta demanda y los perfiles de uso, fijará sus objetivos en la plataforma dominante. Los últimos ataques detectados mediante la utilización de MitMo, confirman que el modelo de técnicas convergentes (infección de dos o más dispositivo para realizar un mismo esquema de fraude) seguirán siendo, por desgracia, efectivas durante bastante tiempo y posiblemente el esquema a adoptar por troyanos de otras familías menos conocidas. Actualmente ya se ha detectado en el “mercad negro virtual”, vendedores que ofrecen recursos para llevar a cabo este tipo de fraude (troyanos “tradicionales” con componentes móviles). Del mismo modo, el uso de la telefonía móvil en la empresa20 y las nuevas funcionalidades del móvil como sistema de pago, vaticinan que estos dispositivos serán cada vez más ubicuos y con acceso a información cada vez más valiosa. Este hecho pone de manifiesto la necesidad de protegerlos frente a nuevas amenazas, todavía incipientes en esta plataforma, y la necesidad de concienciar a los usuarios de la importancia de la seguridad en su utilización. NFC es una tecnología emergente que traerá muchas posibilidades y nuevas vías de usar el teléfono móvil; pago, publicidad, intercambio de datos con otros dispositivos. El éxito de la prueba piloto de pago a través de NFC en España, comentada en el apartado X, y las noticias del despliegue masivo21 de chips NFC en terminales22 móviles23 durante este año, ponen de manifiesto la llegada inminente de esta tecnología con todos los nuevos usos que todavía están por ver.

20

http://blog.s21sec.com/2011/02/dispositivos-moviles-en-la-empresa.html http://www.siliconrepublic.com/comms/item/20420-mass-deployment-of-nfcchip?utm_source=twitterfeed&utm_medium=twitter&utm_term=Irish+IT 22 http://www.mobileburn.com/news.jsp?Id=13073 23 http://www.engadget.com/2011/02/15/deutsche-telekom-rolling-out-nfc-payments-with-t-mobileusa-oth/?utm_source=engadget&utm_medium=twitter 21

www.s21sec.com

Página: 31/32

SPAIN • MEXICO • BRAZIL • UK • USA

www.s21sec.com