JSDialers: Apps para Android "made in Spain" que llaman a números de pago "806" en Google Play

Ayer por la tarde, desde Eleven Paths os alertábamos de un nuevo grupo de apps para Android publicadas en Google Play que están estafando a usuarios en por medio de llamadas realizadas a números de pago "806". Hoy por la mañana aún sigue viva alguna de estas apps, así que hay que tener mucho cuidado con ellas, esto es como funcionan.

Figura 1: JSDialers, apps para Android "made in Spain" que llama a números de pago 806

En el análisis realizado desde Eleven Paths se puede ver como un grupo de 8 apps están haciendo uso de la librería Cordova de Apache que permite acceder a las funciones de los teléfonos mediante JavaScript y por lo tanto a realizar también las llamadas de teléfono, pero intentando ocultar este hecho por medio de una webview. El uso de estas librerías y este esquema ha permitido que algunas apps todavía se le cuelen a Google Play y por eso las hemos llamado JSDialers.

Figura 2: Llamada de teléfono a un número 806 que se le pasará como argumento

Las apps utilizadas en este negocio de llamadas a números 806 están ligadas a una empresa de Valencia que aparece en las condiciones de las apps, donde además se avisa a los usuarios de que pueden hacer hasta 30 minutos al mes de llamadas a ese número de teléfono. Técnicas muy del viejo estilo utilizadas por los amigos del Fraude Online.

Figura 3: Condiciones de la app con datos de la empresa y costes

Para colarse a Google Play, y que duren más tiempo, algunas de las apps han sido apps Gremlins que han mutado, lo que parece ser ya una práctica más que habitual tal y como se ha visto en los últimos casos como en el de las apps dedicadas al click fraud que detectamos hace poco.

Figura 4: Una de las apps antes simulaba ser "algo" de coches en japonés.

La lista de las apps las hemos descubierto utilizando nuestra plataforma de investigación Path 5, y como podéis ver de momento se han detectado 8 apps que hacen uso de este esquema y están publicadas bajo diferentes cuentas de desarrolladores, ninguna de ellas ligada al servicio de la empresa que tarifica las llamadas. Algunas de ellas, aún están activa en Google Play por si quieres analizarla.

Figura 5: Lista de apps de la misma familia descubiertas en Path 5

En el código fuente de algunas apps, como la analizada en el artículo de el blog de Eleven Paths se puede ver cómo se compone la llamada de teléfono y cómo se realiza la llamada.

Figura 6: Número de teléfono 806 al que está llamando esta app

Si tienes alguna de estas apps en tu sistema elimínala cuanto antes. Si tienes un MDM en tu empresa protege contra la instalación de estas apps y si te han llegado cargos a tu factura de teléfono y tenías alguna de estas apps ya sabes por qué puede haber sido. Recuerda que los teléfonos se pueden bloquear para que nunca realicen este tipo de llamadas a números de pago y que si eres amigo de markets como Mobogenie, este tipo de apps puede seguir viva por allí.

Saludos Malignos!

JavaRuleSetter: Un "firewall" para los Applets de Java

Si llevas algo de tiempo en seguridad, con certeza habrás visto cómo el mundo de los Exploits Kits o el malware han utilizado bugs de Java para conseguir la ejecución de código remotamente. Muchos de esos exploits están en los arsenales de los Metasploit de los pentesters para que estos puedan conseguir acceso a los equipos que no han tomado la precaución de mantener actualizado el framework de Java. Aún así, el riesgo de que aparezca un 0day y te afecte es muy alto, y por eso Java ha intentado poner medidas paliativas para que un administrador gestione listas blancas de sitios a los que va a permitir que ejecuten Applets de Java o no.

Figura 1: JavaRuleSetter, un "firewall" para los Applets de Java

Las medidas que actualmente se pueden aplicar para crear listas de seguridad son dos, tal y como se explica en el blog de Eleven Paths y vamos a ver cómo funcionan y cómo se pueden configurar cómodamente con JavaRuleSetter.

Deployment Rule Set y Exception Site List 

Para que nos hagamos una idea, la primera de ellas es una forma de conseguir que un Applet se ejecute automáticamente sin generar ninguna alerta por medio de la firma digital del mismo. No son sencillas de configurar ya que hay que generar un fichero XML con un formato concreto, hay que firmarlo digitalmente y ubicar los ficheros en determinadas ubicaciones, pero permiten que se hagan despliegues de aplicaciones a través de Internet por medio de Applets en modo lista blanca. Esta configuración requiere permisos de administrador en la máquina y está disponible a partir de Java 7u51.

Figura 2: Configuración de nivel de seguridad en Java y Exception Site List

La segunda de las configuraciones de seguridad es la Exception Site List, que permite indicar un conjunto de sitios de lista blanca a los que se les permitirá rebajar el nivel de seguridad. El número de alertas y las restricciones que tendrán esos Applets dependerán del nivel de seguridad que se haya elegido en la configuración de Java en el sistema. Estas configuraciones se pueden hacer a nivel de usuario y están disponibles a partir de la versión de Java en Enero de 2014. Su funcionamiento es muy similar al bloqueo de ActiveX que introdujo Internet Explorer 8 hace tiempo.

Figura 3: Árbol de decisión en la ejecución de Applets dependiendo de la configuración de seguridad

Al final, el árbol de decisión sobre la ejecución de un Applet Java hoy en día es bastante complejo, y dependiendo de la configuración del nivel de seguridad de Java, la lista de sitios de excepción y las Deployment Rule Set que se hayan configurado, el resultado a la hora de proteger el sistema contra la explotación de un ataque proveniente de un Applet malicioso puede ser muy distinto.

JavaRuleSetter

Para hacer esto mucho más sencillo, desde el laboratorio de Eleven Paths hemos publicado una herramienta llamada JavaRuleSetter que permite gestionar las listas blancas como si de un firewall se tratara. Para ello, la herramienta configura una regla por defecto en la que se activa el nivel alto o muy alto de seguridad en Java y cualquier Applet que venga a ejecutarse debe cumplir los requisitos de esos niveles o estar en la lista blanca.

Figura 4: Configuración de bloqueo de Applets en JavaRuleSetter

En este ejemplo, con la regla por defecto que activa el máximo nivel de seguridad, cualquier intento de ejecución de un Applet será bloqueado, tal y como se aprecia en la imagen siguiente donde se intenta ejecutar un Applet proveniente de Java.com.

Figura 5: Mensaje de alerta de bloqueo de ejecución de un Applet de java.com

Para conseguir que se pueda ejecutar, basta con meter una regla con la excepción para ese sitio, tal y como se ven en la imagen siguiente.

Figura 6: Adición de una regla de excepción para ejecución del Applet desde Java.com

A partir de este momento, con esta herramienta, cualquier administrador que requiera utilizar Java en su día a día, puede reducir cualquier riesgo de ataque añadiendo únicamente el permiso de ejecución de Applets Java en las URLs de los sitios con los que deban trabajar sus empleados. Por supuesto, si se quiere configurar una regla de despliegue para que no salga absolutamente ninguna alerta, se puede crear una regla en Advanced Mode para ajustar la granularidad que se quiera.

Figura 7: Configuración de una regla de despliegue en modo avanzado

La herramienta está escrita en Java - faltaría más - y por tanto es totalmente funcional en plataformas OS X y GNU/Linux, con las que el equipo de QA de Eleven Paths ha hecho las pruebas pertinentes. Esperamos que os sea de utilidad y consigáis fortificar un poco más vuestros equipos de trabajo.

Saludos Malignos!