Eventos abril

martes, 31 de marzo de 2015

Toma nota de todos los eventos de seguridad en los que participaremos y podréis encontrarnos durante el mes de abril. Si coincide alguno de ellos en tu ciudad, acércate a conocer nuestras tecnologías y a nuestros expertos:

You Win
Dentro del marco del evento, You Win, donde se darán cita jugadores y amantes de Internet, Chema Alonso dará una videoconferencia el próximo viernes 10 de abril.

Qurtuba Security Congress:
Es el primer Congreso de Seguridad en Córdoba en el que se encontrarán expertos de seguridad informática y abogados especializados en el sector de las TIC. Pablo González de ElevenPaths impartirá la charla Give me a powershell and i will move your world y un taller bajo el título Los niños y los pentesters nunca mienten: use Metasploit.
  • Cuándo: 10 y 11 de abril de 2015
  • Dónde: UCO-Facultad de Derecho y Ciencias Económicas y Empresariales, Córdoba
  • Registro totalmente gratuito

ASLAN 2015
#ASLAN2015 reunirá a expertos de la industria TIC, consultores, CIOs,...para analizar y debatir las principales tendencias en infraestructuras digitales y aplicaciones en red. Desde ElevenPaths participaremos como parte del Foro de Ciber Security. Además de la charla, Chema Alonso participará también en Paneles de Debate.
  • Cuándo: 14 y 15 de abril de 2015
  • Dónde: Palacio Municipal de Congresos de Madrid
  • Puedes registrarte online en el siguiente enlace: Registro ASLAN 2015

España y Estados Unidos - Desafíos de ciberseguridad
El próximo 14 de abril tendrá lugar el seminario de cooperación en materia de seguridad entre España y Estados Unidos, organizado por el Real Instituto Elcano. Chema Alonso participará con una charla al final del acto. Tienes más información en Fundación Consejo España - EEUU. 

Jornadas educativas en Valladolid
Se trata de unas jornadas de concienciación sobre el uso seguro de las nuevas tecnologías y buenas prácticas para navegar más seguro en la red. En estas jornadas se hablará de cómo protegerse con LatchPhishing, Rats & Bad Boys: Navegar seguro está en tu mano será la ponencia a cargo de Pablo González.
  • Cuándo: 14 de abril de 2015
  • Dónde: Las Cortes de Valladolid
  • Más información en Jornadas Educativas.

Dare2Data
Desde ElevenPaths participaremos en estas jornadas de Big Data Spain donde os contaremos un poco más sobre nuestras tecnologías Tacyt y Sinfonier, dedicadas al Big Data.
  • Cuándo: 16 de abril de 2015
  • Dónde: Madrid
  • Más información en Dare2Data

Congreso Europeo de Ingenieros Informáticos
El lunes 20 de abril tendrá lugar la «Semana Informática» simultáneamente en Madrid, Valencia y Castellón con la celebración del primer Congreso de Ingenieros Informáticos donde participará Chema Alonso con la charla Ingenieros & Hackers. Te facilitamos la lista completa de ponentes y agenda del evento.

Hackmeets A Coruña
Los primeros talleres prácticos de seguridad organizados conjuntamente por ElevenPaths y Telefónica con un enfoque totalmente nuevo: hacer "palpable" la seguridad. Cuándo: 22 y 23 de abril en la ciudad de A Coruña. Entérate de todos los detalles próximamente en la web de Hackmeets.
  • Rafa Sánchez, Analista de Seguridad en ElevenPaths, hablará y hará una demo sobre Tacyt, nuestra innovadora herramienta de ciberinteligencia de amenazas móviles.
  • Pablo González impartirá un taller sobre nuestra tecnología Faast + VMS: detección persistente y gestión del ciclo de las vulnerabilidades.
  • Fran Gómez y Mariano González de Sinfonier Project presentarán el uso de la herramienta Sinfonier a través de casos de uso aplicados al mundo de la seguridad móvil.
  • Nuestro compañero de Telefónica, Javier Soria, hablará de análisis forense informático - telemático, contará ejemplos de análisis forense en Android, iPhone/iPad, GPS Tom Tom, y explicará cómo borrar de manera segura los dispositivos en empresas cuando se cambian o destruyen.

Congreso Internet 3.0
En esta tercera edición, el Congreso Internet 3.0 estará orientado a todas aquellas personas que quieran tener éxito en sus negocios online. Los trucos, estrategias, ponencias y debates servirán para una amplia gama de sectores dentro del negocio online. Cuándo: 24 y 25 de abril en Alicante.
  • Chema Alonso participará en el Congreso de Internet 3.0 con la charla It's a Kind of Magic...or is it not?

¡Nos vemos!

El mes de la RATa en Google Play

lunes, 30 de marzo de 2015

Hace algunos días, Lukas Stefanko de ESET descubrió un nuevo sistema de administración remota para Android. Aunque ya se conocen sistemas RAT para Android, este malware tenía algo de especial. Usaba las notificaciones de Baidu Cloud Push para el envío de comandos a las víctimas. Podemos confirmar (no se hace en la noticia original) que esta RAT ha estado no solo disponible en mercados alternativos, sino también en Google Play por, al menos, un mes.

Existen diferentes tipos de RAT para Android. Dos funciones fundamentales la definen:
  • Qué y cómo puede controlar del dispositivo. 
  • Cómo recibe instrucciones la víctima.
Cómo se reciben los comandos abre un puñado de posibilidades: HTTP, SMS, Jabber, GCM (Google Cloud Messaging)... y ahora notificaciones Baidu Cloud Push. Cloud Push es un sistema en el que los desarrolladores pueden registrar usuarios. Los usuarios registrados recibirán notificaciones push en sus dispositivos (una notificación especial en la barra de tareas). Este sistema es usado por millones de apps legítimas, y Google permite el uso de CGM gratis. Este sistema ya ha sido usado para acciones maliciosas anteriormente, Cualquier desarrollador puede crear "su propio GCM", y Baidu es el popular en China. Este ha sido usado en esta ocasión para enviar comandos a la botnet. La técnica es nueva. Tan nueva, que el malware no ha sido detectado por los motores antivirus en meses.

¿Qué hace el RAT?

Infecta el sistema y queda a la espera de comandos que vendrán del servidor, que es una instancia de Baidu Cloud Push especialmente manipulada. Básicamente, la figura de abajo lo resume:

Comandos que el atacante puede enviar al dispositivo
Se muestran los comandos que el dispositivo podría recibir de Baidu. La app cuenta con los permisos necesarios para realizar las tareas, así que el dispositivo infectado queda a completa disposición del atacante.

Toda la información va a través de la ruta "/mnt/sdcard/DCIM/Camera/%file_name%" antes de ser subida al servidor de Baidu cloud storage (BCS) y eliminada del dispositivo.

No solo en los mercados alternativos

Stefanko encontró los samples en mercados alternativos, lo que resulta "normal" de alguna forma. Pero algunos de estas muestras sí que estuvieron en Google Play durante más de un mes. Con más de 50.000 descargas, las víctimas podrían seguir bajo el control del atacante.

Una de las RAT, disponibles en Google Play
Gracias a Tacyt (aunque no hemos encontrado estas muestras a tiempo) sabemos ahora que algunas muestras diferentes con el mismo comportamiento estaban disponibles en Google Play desde, al menos, noviembre de 2014. Algunas muestras, bajo el nombre de ciertos desarrolladores, fueron creadas durante noviembre de 2014 y estuvieron disponibles desde diciembre. Las apps estuvieron disponibles hasta finales de enero, cuando Google las eliminó. Parece que otras estuvieron disponibles desde septiembre hasta finales de enero, bajo otras cuentas falsas. Estas apps están todavía en otros markets. El desarrollador parece provenir de Corea del Sur.

Ha estado usando diferentes nombres y correos: "zhengcaiai", "devzhemin520", "su weiyu"... Este dominio también le pertenece: http://devzhemin.dothome.co.kr.

¿Y los antivirus?

Las muestras no han sido detectadas por al menos cinco meses:

Una de las RAT, no siendo detectada

Hasta aproximadamente el 17 de marzo, no era detectada. ESET y Avira han sido los primeros en detectarlas.

Los primeros motores que cazaban la muestra

Pocos días después, muchos otros han creado la firma para detectarlos, pero no todos los "grandes" todavía.

Más motores que detectan las muestras

Lo han llamado la RAT "cajino" por el nombre de paquete encontrado por Stefanko. Todos los nombres comenzaban con la cadena ca.ji.no.method[*] y un número. Pero el atacante también ha usado  la estructura han[*].play.app para nombrar las apps en Google Play.

Las versiones más nuevas son menos detectadas

Para las nuevas versiones, los únicos que las cazan son Avast, DrWeb y ESET, los que crearon las firmas originales. Esto muestra perfectamente la noción de "firmas de calidad" que protegen al usuario en el futuro tanto como es posible.

Conclusiones

Las RATs para Android no es que sean poco comunes, pero tampoco habituales. Además de las conclusiones del investigador de ESET, lo interesante que consideramos necesario señalar es que:
  • Se han usado nuevos métodos de comunicación.
  • Las apps no han sido detectadas ni por investigadores ni antivirus durante al menos seis meses.
  • El atacante ha estado en Google Play (el sitio predilecto para atacantes) durante al menos un mes.
  • Y seguirán consiguiendo más víctimas, porque la app todavía se encuentra en diferentes mercados.
No es habitual que se encuentren RATs en Google Play. Una de las últimas noticias al respecto es la de Dendroid, una RAT diseñada para eludir los controles de Google Play, hace un año.

Algunos hashes diferentes (además de los encontrados por ESET) son:
  • 7a131e44d731995e51b7e439082273abbbf02602
  • 48412835d0855c565f213242b0db7a26480fcc2e
  • 4c9e505f1132528c68091fa32bb1844d7cbd2687
  • 31a645973554b7c83cc0bd6fb7709ec12937c962

El atacante está distribuyendo (además de por otros mercados) la apk desde aquí: hxxp://guangzhouhan1.dothome.co.kr/music.apk, así que podrían cambiar en cualquier momento.

Sergio de los Santos
ssantos@11paths.com

The month of the RAT in Google Play

A few days ago, Lukas Stefanko from ESET discovered a new remote administration system RAT for Android. Although there are some known RATs for Android, this malware had something special. It used Baidu Cloud Push notifications for sending commands to the victims. What we can confirm (not in the original blog entry), is that this RAT has been available not only in "alternative markets", but in Google Play, undetected for more than a month.

Several kind of RATs for Android exist. There are two basic conditions that defines an RAT:

  • What and how it is able to control the infected device.
  • How the victim receives the commands.

How the victim receives the commands opens a handful of possibilities: HTTP, SMS, jabber protocol, GCM (Google Cloud Messaging)... and now Baidu Cloud Push notifications. Cloud Push is a system where developers can register users. Registered users will receive push notifications in their devices (an special notification in the task bar). This is used in millions of legitimate apps, and Google allows the use of its GCM for free. This system has been abused to push ads in the past. Any developer may create his own CGM, and Baidu has a popular one in China. This time it has been abused to push commands to this botnet. This technique is quite new. So new, the malware has not been detected by antiviruses for months.

What does the RAT do?

It infects the system so is waiting for commands from the Command and Control server, which is a specially crafted Baidu Cloud Push instance. Basically, this picture below summarizes it all.

Commands that the attacker may send to the device
It shows the commands the device may get from Baidu. The app counts with every necessary permission to perform the tasks, so the infected user is completely at the attackers disposition.

All the information goes through "/mnt/sdcard/DCIM/Camera/%file_name%" before being uploaded to the Baidu cloud storage (BCS) and removed from the device.

But... this has not only been in alternative markets

Stefanko found the samples in alternative markets, which is, in a way, "expected". But some of these samples were indeed in Google Play... for more than a month. With more than 50.000 downloads, the victims may still be under the control of the attacker.

One of the RATs, available in Google Play

Thanks to Tacyt (although we did not found these samples on time...) we now know that some different samples with the same behavior were available in Google Play from, at least, November 2014. Some samples, under a certain developer, were signed during November 2014, and were available in Google Play since December. The apps were available in the main market until late January, when Google removed them. It seems that some others were available from September until late January as well, under some other fake account. These apps are still in lots of other markets. The developer seems to be from South Korea.

He has been using different names and emails: "zhengcaiai", "devzhemin520", "su weiyu"... This domain belongs to the attacker as well: http://devzhemin.dothome.co.kr.

What about antiviruses?

The samples were not detected about five months ago, when it all started.

One of the RATs not being detected

Until March 17th approximately, it was fully undetected. ESET and Avira have been the first ones detecting them.

Some of the first engines detecting the samples

A few days later, some others have created a signature, but still not all the big players.

Some more engines detect the samples

They have named it "cajino" RAT because of the packageName that Stefanko found. They all started with ca.ji.no.method[*] and a number. But the attacker has also used han[*].play.app structure for naming the apps in Google Play.

Newer versions are less detected

For newer versions, the only ones catching them are Avast, DrWeb and ESET, the ones that created the original signatures. This perfectly shows the notion of "quality signatures" that protects the user from future versions as much as possible.

Conclusions

RATs are not "rare" in Android world, but they are not usual, either. Aside from the conclusions of the ESET researcher, the important issues to point out here are:
  • New methods to communicate have been used.
  • Apps have been undetected for researches/antiviruses for almost six months.
  • The attacker has been in Google Play (best place ever for attackers) for more than a month.
  • And it will still get more victims, because the app is still in a lot of different markets.
Is not usual to have "RATs" in Google Play. One of the last news were the detection  of Dendroid, a RAT system designed to evade Google Play filters, a year ago.

Some different hashes (aside from the ones ESET found) are:
  • 7a131e44d731995e51b7e439082273abbbf02602
  • 48412835d0855c565f213242b0db7a26480fcc2e
  • 4c9e505f1132528c68091fa32bb1844d7cbd2687
  • 31a645973554b7c83cc0bd6fb7709ec12937c962

The attacker is distributing (aside from other markets) the apk from here: hxxp://guangzhouhan1.dothome.co.kr/music.apk, so it may change in any minute.

Sergio de los Santos
ssantos@11paths.com

Control Parental con Latch

viernes, 27 de marzo de 2015

Uno de los plugins participantes en el primer concurso de plugins innovadores y de utilidad para Latch, fue el plugin de Latch para Firewall. El plugin fue desarrollado por Ignacio Cabra. Este plugin permite proteger las conexiones, tanto salientes como entrantes, con las que interactúa la máquina. Lo interesante de este plugin es que puede utilizarse como un control parental con el que evitar que los niños se conecten a sitios web inadecuados.

El plugin está disponible en Github para que cualquier persona lo pueda descargar, revisar el código e instalar y proteger sus conexiones. Nosotros pensamos en llevar a cabo un control parental básico con este plugin y como prueba de concepto realizamos este escrito. Tras la instalación del plugin se disponen de dos piezas fundamentales para el funcionamiento del mismo, la primera es el servicio core y el segundo es el cliente que se comunica con el core. El core es el que se encarga de gestionar las conexiones y verificar el estado del Latch según las reglas configuradas desde el cliente.

El uso del plugin es muy sencillo. En primer lugar hay que dar de alta una aplicación en el Área de Desarrolladores de Latch. Una vez creada la aplicación, se obtiene un AppID y un Secret. Estos datos son fundamentales, ya que el cliente Latch Firewall tiene un apartado de gestión dónde se indicarán estos parámetros. Una vez se tienen estos datos, tan sólo hay que parear la aplicación con nuestra app de Latch en el móvil.

Ventana de alta de Aplicación en Latch Firewall

Al abrir la Aplicación, encontramos un botón con el texto Latch Management, dónde podremos llevar a cabo la configuración de la herramienta. El pareo lo realizamos desde esta ventana, como puede verse en la imagen. En la pantalla principal de la aplicación, podemos encontrar un botón para añadir reglas. Cuando pulsamos en Add se debe configurar los siguientes parámetros:
  • Tipo de conexión, de entrada, salida o ambas.
  • Dirección IP origen. Si la dejamos en blanco, sería cualquier dirección IP origen. Esto puede ser útil cuando la IP es dinámica o privada.
  • Dirección IP destino.
  • Puerto origen y destino. Si dejamos el valor en 0 sería cualquier puerto.
  • Tipo de protocolo. Se puede elegir entre TCP o UDP.
  • Comentario. Algo descriptivo que nos ayudará a identificar la regla en el cliente.

Inserción de regla en la Aplicación

El Operation ID se debe introducir para indicar con qué operación de Latch se asignará esta regla. Una vez configurados todos estos campos, se puede observar en el panel central de la aplicación cliente de Latch Firewall que, la regla se ha generado correctamente.


Ventana de resumen de reglas a aplicar

Ahora, cuando un usuario, por ejemplo un niño, quiera acceder al contenido que se encuentra en esa dirección IP, no podrá acceder. Esto permite, que en este caso, el padre pueda proteger la navegación por la red de su hijo mediante reglas de Firewall. Y gracias a Latch, evitará la visualización de contenido no apropiado para su hijo. Si por el contrario, decidiera habilitar la visualización del contenido, podría hacerlo simplemente "abriendo" el pestillo.

En la siguiente imagen, podemos ver como cerrando la operación “anti-obsceno”, se evita que cualquier usuario que intente acceder a la dirección IP fijada en la regla anterior pueda hacerlo. Se pueden añadir más operaciones, cada una enlazará con una regla en el cliente. En Latch podremos habilitar algunas reglas o bloquear todas las reglas con el Latch de botón grueso.

Latch y la Aplicación de control parental

En el ejemplo, podemos ver como se bloquea solo la operación “anti-obsceno” y se notifica al usuario de Latch que se ha intentado acceder a un contenido prohibido. Es muy fácil incorporar un control parental de navegación gracias a Latch y el plugin implementado por Ignacio Cabra.

Detección de intento de acceso a un sitio prohibido

Este es sólo un ejemplo de las miles de cosas que podemos integrar con Latch. Desde ElevenPaths te damos las gracias Ignacio, por tu participación en el concurso. Es un plugin muy útil para todos aquellos que necesitan o quieren tener un control parental sobre la navegación de hijos, empleados, etc.

Pablo González

Más certificados falsos de Google: Y van tres veces en poco más de un año

miércoles, 25 de marzo de 2015

Adam Langley, el experto en SSL y criptografía residente de Google, anunciaba hace unos días que se han vuelto a emitir certificados para dominios pertenecientes a Google, pero que no son oficiales. Es necesario revocarlos y dar una explicación de cómo y por qué se han emitido, pues según se mire, puede quedarse en una anécdota o convertirse en un desastre. Pero en cualquier caso, siempre es un problema y acentúa la sospecha sobre el modelo de confianza que se arrastradesde hace tiempo. Veamos los detalles.

Qué ha pasado

Según Langley, la empresa egipcia MCS Holdings, que opera bajo la China Internet Network Information Center (CNNIC) estaba emitiendo estos certificados. Cualquiera puede emitir certificados para cualquier dominio, el problema es que en este caso, cualquier navegador va a confiar en estos en concreto porque ese certificado CNNIC viene incrustado como raíz de confianza en Windows y otros sistemas operativos. ¿Resultado? El navegador no se quejará si eres redirigido y se va a un  (por ejemplo) google.com falso.

Certificado de CNNIC entre los certificados raíz de confianza, último responsable de los certificados falsos

¿Seguro que no se quejará?

Bueno, esto no es del todo cierto. Aquí es donde empiezan a ser útiles las tecnologías de certificate pinning que están empezando a desarrollar todos los navegadores. Si la implementan, sí que se quejarían, porque recordarían que la cadena de confianza ha cambiado. En un sistema "interceptado", la cadena de confianza, en vez de apuntar al proveedor raíz de Google "habitual", ahora lo haría a la entidad China... y ante ese cambio, no dejaría pasar al usuario.

Y es bajo estas circunstancias donde el pinning como capa de seguridad adicional está demostrando ser más que útil. Porque este es un incidente muy parecido al que ocurrió en julio de 2014, también con dominios de Google y la la organización gubernamental National Informatics Centre (NIC) de India, que manejaba varias CA intermedias. También es muy similar a la situación que ocurrió con el gobierno francés en enero de 2014. De hecho, es la sexta vez desde 2011 que ocurre algo parecido y la tercera en poco más de un año.

¿Qué explicaciones se han dado?

En general, "las de siempre": se quería espiar a ciertas personas bajo control, y se dispuso un proxy intermedio. Pero se configuró mal. Cuando se pidió explicaciones al CNNIC, respondió que el acuerdo con MCS Holdings incluía simplemente creación de certificados para dominios generados por la propia MCS Holdings, o sea, el uso normal. Pero no se quedaron ahí. Al parecer han emitido certificados para otros dominios y configurado un proxy para espiar a los usuarios que pasen con él (no se sabe en qué entorno). Para colmo, la clave privada quedó en el proxy para generar nuevos dominios. Esto no está permitido. ¿Y si alguien tiene acceso a ese sistema? Las claves de generación se deben almacenar en hardware especial seguro. Pues no se aclara si a través de un robo, descuido, o si ha sido intencional, pero alguien con acceso a ese proxy ha emitido certificados para Google y probablemente otros dominios.

Certificado intermedio que emitió los certificados hoja falsos

En resumen, CNNIC confió en alguien que obviamente no estaba ni técnica ni "moralmente" capacitado para custodiar un certificado intermedio. Y ese será siempre el problema.

¿Es grave?

Detalle de uno de los certificados falsos emitidos

Es posible que esos certificados nunca hayan salido de su entorno. De lo contrario, ese sería el problema. Si han salido,en todo caso, ya hemos hablado que el pineo podría venir al rescate. Además, los certificados están revocados y Google ha emitido CRLSets actualizados para Chrome que actúan automáticamente sobre el navegador. Los CRLSets son un método "rápido" de revocación que utiliza Chrome, como ellos mismos dicen, para"situaciones de emergencia". Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca. No se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Para saber qué conjunto de CRLSets está descargando Chrome en este momento, lo más cómodo es usar este programa, creado en el lenguaje Go.

También hay que tener en cuenta que el certificado intermedio caduca en pocos días, el 4 de abril. Por último, si eres paranoico, deja de confiar en CNNIC y mueve su certificado a la parte de "no confiable". Seguro que no lo notas.

Sergio de los Santos
ssantos@11paths.com

La USAL, protegida con Latch

martes, 24 de marzo de 2015

Nos pasamos el día conectados a Internet, bien para realizar una transferencia bancaria, bien para chatear en nuestras redes sociales... y se nos olvida que nuestra identidad digital puede ser suplantada fácilmente. Lo peor es que ya no es suficiente basar nuestra seguridad sólo en contraseñas. Por eso, nace Latch, el pestillo digital que permite añadir una capa extra de seguridad a tus cuentas y servicios online "cerrándolos" cuando no los estés utilizando. 

A través de una sencilla e intuitiva app móvil, Latch protegerá tus cuentas digitales y servicios online. Con un simple toque, podrás recuperar el control de tu vida digital "abriendo" o "cerrando" el pestillo de tus identidades digitales cuando no estés conectado. Es tan fácil y seguro como echar el pestillo.


La Universidad de Salamanca, más conocida como la USAL, fue una de las primeras instituciones en integrar Latch. En muchas ocasiones han contado cómo decidieron proteger las cuentas del personal de la universidad y de sus estudiantes mediante el uso de Latch convirtiéndose en una de las primeras universidades que ofrece la seguridad adicional de Latch. Así, tanto el personal de la universidad como sus estudiantes, pueden bloquear y desbloquear las principales aplicaciones que diariamente necesitan utilizar en su día a día en la universidad como es el correo electrónico o el acceso al campus virtual, entre otros.

Todos hemos espiado alguna vez, reconócelo. Es hora de que eches el pestillo y ahora puedes hacerlo gracias a Latch. Si estudias o trabajas en la USAL, no lo dudes, no te fíes ni de tu sombra y ¡protégete con Latch!

Si a estas alturas todavía no sabes cómo proteger tu identidad con Latch, no te preocupes. Te lo hemos puesto muy fácil. Accede todas las veces que quieras y necesites a la página de información sobre Latch y al video tutorial.


Además, mañana 25 de marzo, Chema estará en las Jornadas de puertas abiertas sobre Seguridad en Internet en la USAL. Allí hablará sobre El robo de identidad en Internet, donde podréis conocer un poco más este tipo de falsificaciones y cómo proteger nuestra identidad en la red. También contará muchas de las peticiones que recibe sobre cómo espiar las cuentas de WhatsApp o Facebook de amigos, familiares y parejas.

El acto, que será entre las 10:00 y las 11:30 de la mañana, tendrá como escenario el Salón de Actos de la Facultad de Ciencias de la Universidad de Salamanca.

Si estás interesado en asistir, regístrate y toma nota sobre cómo proteger tu identidad digital con Latch.


Más apps en Google Play que suscriben a mensajes SMS premium: JSSMSers

lunes, 23 de marzo de 2015

Después de encontrar los JSDialers, deberíamos haberlo predicho. Los atacantes están usando exactamente la misma técnica que en los JSDialers para esparcir apps que suscriben a las víctimas a servicios de SMS premium. De esta forma han eludido los sistemas de protección de Google Play, y utilizado técnicas basadas en JavaScript, más dinámicas e inteligentes. Todavía no son detectadas estáticamente por los motores antivirus. Veamos cómo funcionan.

Hemos encontrado 14 apps con este mismo comportamiento en Google Play que, con diferentes pretextos, (desde chistes a recetas), subscriben al usuario a servicios de mensajes SMS premium. Aunque las apps muestran un mensaje sobre la suscripción, envían por sí mismas el SMS de conformación de suscripción de forma transparente, para que el usuario no note nada. Los atacantes han obtenido más de 100.000 descargas. No todas las descargas se traducen en suscripciones directas porque los atacantes solo funcionan bajo los operadores más importantes de España, y si el dispositivo no cumple con estos requisitos, la app funcionará normalmente.

Lo que percibe el usuario

Cuando el usuario descarga e instala estas apps, se muestra algo así.

Esto es lo que ve el usuario si pertenece al operador y país adecuado

Es cierto que el atacante está realmente avisando al usuario: se te va a suscribir, pero los mensajes de confirmación serán enviados de forma automática sin dejar rastro en el teléfono. En apps con un comportamiento parecido y analizadas previamente, el mensaje aparecido en el botón podría ser menos explícito (quizás "Aceptar" o preguntar por la edad), pero en este punto, los atacantes han usado la palabra "Suscribir", que debería alertar a las potenciales víctimas.

La app comprobará si el dispositivo pertenece al operador correcto y que viene de España. Para ese momento,  ya se han enviado dos SMS diferentes, uno para comenzar el proceso de suscripción y otro para confirmarlo, sin que el usuario note nada.

Código JavaScript para comprobar operador y país

¿Qué ocurre y cómo funciona?

Todo el programa se lanza bajo un WebView, que llama a un fichero index que viene con la propia apk. Cuando los dos SMS se envían, las apps utilizan un truco interesante. Cargan y descargan dinámicamente el "receiver" para interceptar los mensajes entrantes. Normalmente, estos receivers se declaran en el AndroidManifest.xml. ¿Por qué dinámicamente? Posiblemente para eludir los análisis estáticos. Aunque la app tenga el permiso de interceptar mensajes, una sandbox o un analista podrían pensar que el desarrollador realmente no hace uso de él, porque carece de la rutina para manejar el evento. Pero lo cierto es que lo carga solo si es necesario y cuando lo necesita. El receiver funciona cuando el dispositivo recibe el mensaje, y hace que la app los marque como "ya leídos", para que el usuario no se percate del mensaje de bienvenida al servicio de suscripción.

Receiver dinámico para manejar SMSs entrantes


¿Entonces, qué es nuevo?

Hay varias partes interesantes en estas apps.

  • Primero, el uso de JavaSCript y Cordova (el puente entre JavaScript y el apk) para enviar mensajes y evitar introducir esa parte de la lógica en la propia aplicación. Esto lleva la lógica al servidor, lo que la hace más poderosa, dinámica, y difícil de detectar.


  • Cargar el "receiver" dinámicamente, que confundirá a los análisis estáticos. El receiver se carga y descarga a su antojo bajo las circunstancias adecuadas (país y operador) lo que lo hace más sigiloso. Además, la carga o descarga se hace también por JavaScript, por lo que solo se listará si las circunstancias son las adecuadas en un análisis dinámico.

  • No utilizan el sistema "habitual" para el envío de mensajes, sino que se los proporciona directamente al SMSProvider. Esto evita que los mensajes enviados se mantengan en la carpeta de "enviados" o "salida". Las apps proporcionan el texto de los SMS directamente el proveedor del sistema operativo.

Marcando los mensajes SMS entrantes como ya leídos

Otras apps como estas

¿Quién está detrás de estas apps? Obviamente están relacionadas con los JSDialers de los que hablamos hace unas semanas. Las compañías de suscripción y dominios nos proporcionan las pistas adecuadas.

Algunas capturas de las apps que hemos encontrado gracias a Tacyt, son estas:




Algunas apps con este comportamiento
Este es el título, nombre de paquete y hash de las apps encontradas:

  • Frases celebres bonitas cortas,com.thinkking,1e8568ccc54be7a73934965e97ff7e3fd9e4fec3
  • Imagenes amor fotos frases,com.romaticpost,2d26c676bcb5a5f8599f49a5b90599b7ff93dc11
  • Phrrasesfee,com.prasesfee,ca6ac2e1bf46087455fda358870070ec269faae6
  • Statetss,com.statetss,da045796efc737d42b9e86876ec5b854289212bc
  • New mensajes navidad y frases,com.navidad.extra,18db1cfb7e7340a5476a5c6e17f1f9d596045095
  • Postales perritos fondos,com.imagepets,bbc6e386281f2b1931ff2be7812bf4de4530d3fe
  • Funnyys,com.funnyys,9fc9e237903b02a2a47701139200c9177eec16a5
  • Fotos frases amor postales,com.prasesamor,65ce3043fc249cb906b4e50a23d581d5c70819fa
  • Gatitos tiernos fondos postal,com.cattss,f68ef39f5183da0745614c68a7ae135085298b54
  • Recetas de cocina dietas Salud,com.kitchenn,7fa17bed794a59dd3d914d05535fe25a357ab1cd
  • Chistes cortos buenos,com.chistescortos,daac73a325485f882b1dcda9758b16bb5f407770
  • Chistes Picantes buenos cortos,com.chistespicanticos,dc799bcc3f1f623e211e50fbb6ececb2e64753a6
  • Laughtter,com.laughtter,f569baf1c0f12c137a09e084c879979bbcfd11e1
  • Healthyy,com.recipesmart,0dd97d056fa7559a2cdb35d45850cefd400f4d6f


Sergio de los Santos
ssantos@11paths.com

Juan Manuel Tirado
juanmanual.tirado@11paths.com

More apps in Google Play subscribing to SMS premium numbers: JSSMSers

After finding the JSDialers, we should have figured it out. The attackers are using the exact same technique as in JSDialers to spread apps that subscribe the victims to SMS premium numbers. This way they have avoided Google Play protection systems and used new techniques based on JavaScript, more dynamic and smart. They are not statically detected by antivurs engines yet. Let's see how they work.

We have found 14 apps with the same behavior in Google Play that, with different pretexts (from jokes to recipes) subscribe the user to premium SMS numbers. Although the apps show a message about the subscription, they send an SMS by themselves confirming the subscription in a transparent way, so the user does not notice anything. The attacker got more than 100.000 downloads. Not all downloads translate into direct subscriptions because the attackers only allow important carriers from Spain, and if the device does not match with these conditions, the app will act normally.

What the user perceives

When the user downloads and installs any of these apps, something like this will be shown.

This is what the users sees if it belongs to the right carrier and country

It is true the attacker is really advising the user: you are going to be subscribed, but it automatically will send the SMS leaving no trace on the phone. In previous apps like this, the button used to be less explicit (maybe "Accept" or asking for your age) but at this point, the attackers used "Subscribe" which should make the users more aware about the problem.

The app will check if the device belongs to the right carrier and comes from Spain. By now, two different SMS have been sent, one to start the subscription and another to confirm it, but the user will notice nothing.

JavaScript code to check for carrier and country

What happens and how it works?

The whole program is launched under a WebView, and calls an index file that comes with the apk itself. When the two SMSs are sent, the apps use and interesting trick. They dynamically load the receiver to intercept the incoming messages. Usually, these receivers are declared in AndroidManifest.xml. Why dynamically? Possibly to avoid static analysis. Although the app has the permission of intercepting SMSs, a sandbox or analyst will think the developer does not really use it, because it lacks any routine to manage them. But the real thing is that it loads it only if and when necessary. The receiver works when the device receives a message, and makes the app mark it as "already read" so the user does not notice any welcome message to the subscription service.

Dynamic receiver to handle incoming SMSs


So, what is new?

There are several interesting parts on these apps.


  • First, the use of JavaScript and Cordova (the bridge between JavaScript and the apk) to send messages and avoid introducing code in the app itself. This takes the whole logic to the server, what makes it more powerful, dynamic and undetected.


  • Loading the receiver dynamically, may confuse a static analysis. The receiver is only declared under the right circumstances (right carrier and country) so it makes it stealthier. Aside, the receiver is loaded (and it may be unloaded too) via the JavaScript code, so it will only be listed if all conditions are satisfied in a dynamic analysis.


  • It does not use the usual system to send messages, but gives them directly to SMSProvider. This avoids the sent messages to be kept in "sent" or "outbound" folder. It provides the SMS text directly to the operative system provider.

Marking the incoming SMS as already read

Other apps like these

Who is behind these apps? Obviously they are related to the JSDialers we talked about a few weeks ago. The subscription company and domains just give us the right answers.

Screenshots of some of the apps we have found thanks to Tacyt, are these:




Some of the apps with this behevior
This is the title, packagename, and hash of the applications found.

  • Frases celebres bonitas cortas,com.thinkking,1e8568ccc54be7a73934965e97ff7e3fd9e4fec3
  • Imagenes amor fotos frases,com.romaticpost,2d26c676bcb5a5f8599f49a5b90599b7ff93dc11
  • Phrrasesfee,com.prasesfee,ca6ac2e1bf46087455fda358870070ec269faae6
  • Statetss,com.statetss,da045796efc737d42b9e86876ec5b854289212bc
  • New mensajes navidad y frases,com.navidad.extra,18db1cfb7e7340a5476a5c6e17f1f9d596045095
  • Postales perritos fondos,com.imagepets,bbc6e386281f2b1931ff2be7812bf4de4530d3fe
  • Funnyys,com.funnyys,9fc9e237903b02a2a47701139200c9177eec16a5
  • Fotos frases amor postales,com.prasesamor,65ce3043fc249cb906b4e50a23d581d5c70819fa
  • Gatitos tiernos fondos postal,com.cattss,f68ef39f5183da0745614c68a7ae135085298b54
  • Recetas de cocina dietas Salud,com.kitchenn,7fa17bed794a59dd3d914d05535fe25a357ab1cd
  • Chistes cortos buenos,com.chistescortos,daac73a325485f882b1dcda9758b16bb5f407770
  • Chistes Picantes buenos cortos,com.chistespicanticos,dc799bcc3f1f623e211e50fbb6ececb2e64753a6
  • Laughtter,com.laughtter,f569baf1c0f12c137a09e084c879979bbcfd11e1
  • Healthyy,com.recipesmart,0dd97d056fa7559a2cdb35d45850cefd400f4d6f


Sergio de los Santos
ssantos@11paths.com

Juan Manuel Tirado
juanmanual.tirado@11paths.com

Path5 ya tiene nombre. Hola, Tacyt.

viernes, 20 de marzo de 2015

El área de Labs en ElevenPaths, situado en Málaga, es una de las piezas clave de la empresa. En perfecta coordinación con el área de Research en Madrid y del director de desarrollo en Londres, trabajamos en transformar las ideas en prototipos operativos que surgen del trabajo conjunto de todos los integrantes de la compañía.

La inquietud por replantearnos la industria y prevenir problemas actuales y futuros de seguridad, son fuertes componentes de nuestro ADN. Por eso, un día cualquiera, allá por el mes de mayo de 2014 y siguiendo una intuición, surgió la idea de analizar las apps de Android desde un punto diferente con el que pudieran complementarse y mejorar las soluciones existentes. Pero para confirmar esa intuición, era necesaria una herramienta muy ambiciosa, tanto técnica como conceptualmente.  

En realidad, supuso una novedad, puesto que pudo patentarse la idea, lo que confirmaba su carácter innovador. Nos planteamos analizar, supervisar, correlacionar, indexar... toda la información agregada en una aplicación móvil, con la premisa de que una app no es solo una app sino también sus circunstancias. Y construimos un sistema de búsqueda y correlación potente que permitiese, de verdad y no solo en el papel, aprovechar palabras tan vacías como usadas hoy ("big data", "inteligencia aplicable"...) en el sector. La intuición se confirmaba, y los descubrimientos, posibilidades e intereses se han ido sucediendo desde que presentamos el producto en octubre de 2014.

Ha llegado Tacyt, la herramienta de ciberinteligencia de amenazas móviles. 




Desde su presentación, no hemos parado de recibir elogios, consejos, ideas y críticas que hemos intentado tener en cuenta para mejorar. Algo en lo que suelen coincidir los ya clientes y las empresas que han realizado algún piloto, es que resulta tremendamente sencillo buscar, encontrar, detectar, comparar y descubrir amenazas. No es necesario ser ningún experto en Android ni seguridad móvil para comenzar a investigar. Los datos están ahí, y son de verdad accesibles a golpe de ratón. La consola será aún más intuitiva en un futuro cercano, y seguimos mejorando las herramientas adicionales para ofrecer una experiencia completa desde la que se permita una mayor integración.

Las mejores cartas de presentación han sido los análisis de malware, descubrimientos y detecciones realizadas por Tacyt en los últimos meses. Desde el destape de la botnet Shuabang, pasando por la estafa de los clickers, los JSDialers, los descargadores de apps "en diferido"... Y otras investigaciones que hemos reportado directamente a las fuerzas del orden, casas antivirus, y otras empresas de seguridad móvil para facilitar su detección. También, el interés que han mostrado compañías mucho más experimentadas en el mundo del malware en Android.

Pero Tacyt es mucho más, permite supervisar la imagen de marca en el mundo móvil, combatir el fraude por apps, estudiar tendencias, analizar escenarios y situaciones en incidentes, investigar casos... sin olvidar su parte social: crear filtros y hacerlos total o parcialmente públicos con otros usuarios, de forma que se comparte una inteligencia colectiva para favorecer los análisis, descubrimientos y detecciones...

Estamos sinceramente convencidos de que Tacyt ayuda a mejorar la seguridad móvil y que además cubre un hueco al que a las soluciones actuales les costaba llegar. No pretende sustituir tecnologías, sino hacerlas mejorar, facilitarles el trabajo... en resumen, crear un ecosistema más completo.

Firma digital de documentos con SealSign (I)

miércoles, 18 de marzo de 2015

Actualmente, todas las brechas de seguridad están atacando a la identidad de las personas, por lo que su gestión es uno de los puntos más complejos en los que trabajamos día a día en seguridad. Por eso, en ElevenPaths hemos incorporado SealSign, la plataforma para empresas de firma de documentos. SealSign nace para solucionar los posibles fraudes de suplantación de identidad.

SealSign es una plataforma empresarial, escalable, modular y completa de firma de documentos electrónicos compatible con certificados digitales, sistemas biométricos, sistemas OTP y archivo a largo plazo de documentos firmados.

Los productos de SealSign se basan fundamentalmente en la firma digital y son complementarios entre sí. Incluyen todo lo necesario para la elaboración, almacenaje y gestión de archivos firmados digitalmente:
  • Módulo Engine (DSS): Es el módulo más importante. Sin él, no funcionan los demás. Implementa el software necesario para firmar digitalmente cualquier tipo de documento, y para administrar y configurar los demás módulos. Además del propio motor de firma, incluye otros productos que pueden resultar útiles en una corporación que utilice firma digital, como por ejemplo, un gestor de sellos de tiempo, o una autoridad de validación de certificados. 
  • Módulo BioSignature (BSS): Este módulo es el que se encarga de la integración de la firma biométrica manuscrita. Es decir, incluye lo necesario para obtener un patrón biométrico del firmante (en base a una firma manuscrita en pantalla) y utilizarla luego criptográficamente para crear la firma digital. 
  • Módulo Central Key Control (CKC): Este módulo incluye una herramienta destinada a controlar de manera centralizada el uso de los certificados digitales en una organización. Para firmar digitalmente un documento, en múltiples ocasiones se utilizará un certificado digital y CKC es el módulo que gestionará todos los certificados que pueda utilizar una organización. Además añade una capa extra de autenticación a la hora de utilizar las claves privadas de los certificados y está integrada con Latch
  • Módulo eArchive (DSR): Este módulo está dirigido a facilitar la integración de un sistema seguro de custodia de documentos firmados digitalmente. Sus objetivos y funcionalidades son múltiples, pero siempre orientados a la protección de los documentos y a garantizar su veracidad. 

Módulos de SealSign

Para entender bien los productos de SealSign y su funcionamiento, es fundamental tener claros algunos conceptos utilizados por la plataforma, como firma digital, biometría y certificados digitales, de los que hablaremos más adelante.

La firma digital es la base de los productos de SealSign, y no debe confundirse con el de firma digitalizada:

  • La firma digitalizada es básicamente una firma manuscrita convertida en imagen. Para ello, se puede utilizar un simple escáner u otro hardware más sofisticado como tabletas de firma. 


Firma digitalizada. 


  • Una firma digital es un mecanismo criptográfico que certifica quién es el autor (autenticación) de un documento y que no ha existido ninguna manipulación de los datos (integridad) basándose fundamentalmente en certificados digitales o en datos biométricos del emisor (el módulo BioSignature de SealSign es el encargado de capturar los datos biométricos). El ejemplo más sencillo de uso de firma digital, se describe al utilizar el DNIe para realizar alguna gestión legal, como por ejemplo, hacer la declaración de la renta.



Esquema simple de firma digital. 


El ahorro de tiempo y la reducción de costes debido a la eliminación del papel y a sus elementos asociados (impresora, archivadores, etcétera), son algunos de los principales beneficios para su implantación. Además, la firma digital tiene la misma validez legal que la firma manuscrita, por lo que SealSign genera documentos con plena validez legal.

En próximos posts, os seguiremos contando  diversos aspectos de la biometría y de los certificados digitales, y cómo los módulos de SealSign los utilizan para conseguir firmar digitalmente un documento.

* Firma digital de documentos con SealSign (II)

SMACK TLS y el ataque FREAK

jueves, 12 de marzo de 2015

Últimamente, las vulnerabilidades sobre TLS/SSL están dando mucho de qué hablar. El pasado 23 de febrero realizábamos un repaso de las incidencias que pueden catalogar el servicio SSL/TLS de inseguro según su implementación y configuración.

En esta ocasión, os explicaremos la vulnerabilidad FREAK (Factoring RSA Export Keys) haciendo hincapié en el impacto que ha tenido, destacando la implicación de miTLS con el proyecto y la investigación de SMACK.

SMACK: State Machine AttaCKs
El proyecto de los investigadores de miTLS, se basa en analizar los comportamientos de las distintas implementaciones de SSL/TLS, gracias a esa investigación se han descubierto vulnerabilidades como SKIP-TLS o FREAK, que se explicarán más adelante.

Dado que el control del momento de la conexión se gestiona a través de una máquina de estados, este ataque se ha denominado state machine attack.

Ilustración 1: Logotipo del proyecto SMACK

La vulnerabilidad SKIP-TLS se sostiene en la mala implementación de TLS, que permite omitir algunos pasos o campos durante el saludo e intercambio de información entre cliente-servidor.

Un ejemplo de esta vulnerabilidad es la implementación en cliente de JSSE, la cual permite abreviar el saludo SSL/TLS y omitir algunos pasos esenciales para la selección del cifrado, permitiendo al atacante enviar únicamente el certificado y omitir el resto de pasos de la comunicación. En caso de que el cliente acepte la conexión, esta se realizara sin cifrado alguno, por lo que la conexión no posee autenticación, integridad ni confidencialidad.

FREAK (Factoring RSA Export Keys)
FREAK afecta a diferentes productos y está siendo más común de lo que en un principio se esperaba, a día de hoy posee múltiples CVE para los productos más conocidos como OpenSSL (CVE-2015-0204), Schannel(CVE-2015-1637) en el caso de Microsoft y la implementación de TLS de Apple(CVE-2015-2235). Dicha vulnerabilidad surgió con el miedo de EEUU de exportar cifrados que no pudiesen ser descifrados por ellos, por lo que se forzó que los cifrados EXPORT se usasen con una clave RSA igual o inferior a 512, lo que en la década del 90 era considerada una longitud robusta y suficiente.

Por otro lado, a día de hoy, se puede obtener la clave en un tiempo razonable con servicios de cloud computing, los cuales, son capaces de extraer la clave en menos de 12 horas. Un tiempo más que asumible ya que generar una clave RSA es un proceso relativamente costoso y por ejemplo mod_ssl en Apache no genera la clave RSA por cada conexión, únicamente la genera al iniciarse, lo que significa que un atacante recupera la clave RSA y una vez descifrada, puede usar la clave con todas las sesiones que quiera y suplantar la identidad del servidor hasta que este se reinicie y genere una nueva clave.

¿Cómo puede afectar esto a nivel de servidor?
Esta vulnerabilidad se resume en que si el servidor implementa alguno de los cifrados EXPORT comentados, un posible atacante podrá recuperar la clave RSA para a posteriori interceptar la comunicación entre cliente y servidor usando técnicas de tipo Man in the Middle, y dado que, el atacante es capaz de cifrar y descifrar toda la conversación, el cliente no será advertido en ningún momento, perdiendo la integridad y la confidencialidad de la información.

Comprobar el soporte de los cifrados EXPORT en el servidor se puede realizar de forma sencilla con el cliente de OpenSSL:

openssl s_client -connect domain.com:443 -cipher EXPORT

Este proceso se puede ejecutar con diferentes herramientas y scripts, por otro lado si eres cliente de Faast, en el próximo escaneo aparecerán los servidores vulnerables y a través de la evidencia podrás observar que conjuntos de cifrados se deben deshabilitar.

Ilustración 2: Evidencia de la vulnerabilidad FREAK a través de la interfaz web de Faast

¿Cómo me afecta esto como usuario?
Es importante tener claro que, a pesar de que el servidor sea vulnerable, el cliente debe tener implementados los cifrados EXPORT para poder conversar con el servidor e intercambiar la misma clave RSA que el atacante ya tiene descifrada. Si utilizas un navegador antiguo, es altamente recomendable actualizar a la última versión tanto en las aplicaciones de escritorio como en los dispositivos móviles para evitar que toda la información enviada pueda ser interceptada por un atacante.


Ilustración 3: Comprobación de FREAK en la aplicación de Google Chrome de escritorio

Ilustración 4: Google Chrome 40 en Android 5.0.1 se muestra vulnerable

Sin olvidar que, como desarrolladores, las librerías que se utilizan para hacer peticiones como wget o curl, también deben ser actualizadas para evitar ser afectadas por este tipo de problemas de seguridad.

En resumen...
En este momento el sitio web de FREAK recopila información del avance de esta vulnerabilidad en la red. En el momento de publicarse el CVE, el 12.2% de los dominios de Alexa se veían afectados, ese porcentaje va descendiendo progresivamente, aunque según las estadísticas el 36.7% de los servidores HTTPS con certificados validos tienen cifrados RSA_EXPORT y por tanto son susceptibles al ataque FREAK.

Para mitigar la vulnerabilidad al igual que paso con Poodle y los cifrados de bloques CBC y otras similares, es recomendable actualizar la versión del servidor/cliente y dejar de implementar los cifrados EXPORT.


Óscar Sánchez
oscar.sanchez@11paths.com

Buscamos "Talentums" & Ingenieros. Vente a 11Paths

martes, 10 de marzo de 2015

ElevenPaths es una compañía en constante crecimiento. Han pasado ya dos años desde nuestro nacimiento y ha sido mucho el trabajo que hemos invertido en los productos que hemos lanzado (y que seguiremos lanzando) bajo nuestra marca. Metashield, Faast, Latch y Tacyt (nuestro querido Path5, ¡ya tiene nombre!) han sido concebidos íntegramente desde ElevenPaths. A esta familia, se unieron hace ya unos meses también los productos de SealSign y SmartID.

Nuestro objetivo es seguir trabajando duro (y aumentar aún más nuestro ritmo) para seguir ofreciendo los servicios más pioneros del mercado que solucionen problemas de seguridad tanto a empresas como a personas.



Creemos y queremos que tú juegues un papel fundamental. Hoy anunciamos que se abre oficialmente nuestro proceso de contratación. En ElevenPaths creemos firmemente en que la fuerza de una empresa con foco en la innovación, se sostiene en la formación de grupos de trabajo muy heterogéneos. Por eso, buscamos múltiples perfiles en los que, si estás pensando en unirte a nosotros y a nuestra aventura, seguro que te ves reconocido. Se trata de dos procesos de selección diferenciados:

Por un lado, abrimos una oferta de becas dentro del programa Talentum de Telefónica. El perfil que se busca en este proceso corresponde con alguien que esté interesado en: Programación Tecnología móvil y, sobre todo, seguridad, ¡claro! Desde hoy mismo, puedes apuntarte al programa de becas Talentum. Para poder participar es necesario registrarse y de esta manera, acceder a la primera prueba de este proceso que será el jueves 18 de marzo de 2015, a las 16:00 horas.

Por el otro, a la hora de crear nuestro equipo, hemos contado con profesionales que comparten nuestros tres rasgos principales: la pasión por nuestro trabajo, nuestra inquietud para replantearnos la industria y las soluciones, y por último nuestra experiencia y conocimiento en diferentes campos relacionados con la seguridad. Por eso, con un perfil más Senior, queremos reforzar el equipo de ElevenPaths con los siguientes perfiles: 

  • 2 Senior Back-End Developers 
  • 1 Big Data Developer 
  • 1 Senior Front-End Developer 
  • 1 Security Manager (Operations) 
  • 2 QA engineers 1 Security Analyst (Development & Pentesting) 
  • 1 Graphic Designer 
  • 1 Senior System Engineer (experiencia en entornos DEVOPS) 

Si te reconoces en alguno de estos perfiles y te animas a conocernos, ponte en contacto con nosotros a través de la siguiente dirección de correo: wearehiring@11paths.com

 ¿Te unes?

Plugins ganadores y más hacks

jueves, 5 de marzo de 2015


El pasado 12 de febrero publicamos la lista de ganadores de la primera edición de Latch Plugins Contest, el primer concurso de plugins de Latch.

El número de plugins e integraciones que recibimos fue bastante alto y hubo algunos muy originales que nos llamaron la atención. Aunque nos gustaría publicarlos todos, hemos tenido que seleccionar los que nos han parecido más interesantes.

Por eso, hemos creado un repositorio para que podáis acceder a todos los plugins (los ganadores y los que hemos seleccionado) todas las veces que queráis. Próximamente, los incluiremos también en la web de Latch.

Primer premio – 10.000 USD 
Ganador: Carlos Rodriguez 
Plugin: Devise_latcheable
Descripción: el plugin de Latch para Ruby on Rails permite integrar Latch en el proceso de autenticación y registro de usuarios.

Segundo premio – 5.000 USD 
Ganador: Gregorio Juliana Quirós
Plugin: Latch for electronic door locks using DNIe, NFC and mobile app identification
Descripción: este plugin permite integrar Latch en cerraduras electrónicas utilizando DNIe, NFC y la identificación de aplicaciones móviles.

Tercer premio – 1.000 USD 
Ganador: Javier Pena Rendo 
Plugin: Latch Plugin for Liferay
Descripción: el plugin de Latch para Liferay permite integrar Latch en el proceso de autenticación en cualquier instancia de Liferay.

Mención especial – 200€ 
Ganador: David Garduño
Plugin: Latch Plugin for Asterisk
Descripción: el plugin de Latch para Asterik permite integrar Latch en una centralita Asterik para poder configurar el funcionamiento de las llamadas.

Plugin: CanaryLatch
Autor: Antonio Sánchez
Descripción: este Plugin permite integrar Latch en servidores de Minecraft con el Mod de Canary para controlar el acceso de los jugadores.

Plugin: Latch for Meteor Framework
Autor: Bruno Orcha García
Descripción: este Plugin permite integrar Latch en proyectos desarrollados con Meteor framework.

Plugin: OpenNebula Latch
Autor: Carlos Martín
Descripción: el plugin de Latch para OpenNebula permite integrar Latch en el proceso de autenticación y desactivación de las cuentas de OpenNebula.

Plugin: Osclass Latch
Autor: Daniel Esteban
Descripción: este Plugin permite integrar Latch en el proceso de autenticación de sitios web desarrollados con Osclass.

Plugin: Playtch – Latch4Play
Autor: cuaQea, miembros del equipo: Enrique Ismael Mendoza Robaina, Antonio Juan Querol Giner, Nerea Sainz de la Maza Doñabeitia, Iñigo Hernández Muguruza, Julio Alberto Molinera Ariza
Descripción: se trata de un módulo de Play framework que permite integrar Latch en cualquier proyecto desarrollado con esta tecnología.

Plugin: Latch for WiFi
Autor: Ezequiel Tavella
Descripción: este plugin te permite proteger con Latch puntos de acceso Wifi creados con Hostapd.

Plugin: LatchFirewall
Autor: Ignacio Cabra
Descripción: este plugin permite establecer reglas de firewall en las conexiones de una máquina Windows controladas con Latch.

Plugin: AutoLatch
Autor: Joan
Descripción: este hack a la aplicación de control de Latch para Android permite abrir y cerrar los pestillos de aplicaciones y operaciones según la ubicación GPS en la que se encuentre el usuario.

Plugin: LatchBundle
Autor: Juan Berzal
Descripción: se trata de un bundle de symfony2 que permite integrar Latch en cualquier proyecto desarrollado con esta tecnología.

Plugin: Latch LtCsSecure
Autor: Francisco Muñoz y Cristina Benavides
Descripción: la aplicación LtCsSecure permite proteger carpetas, escritura en dispositivos USB y ejecución de programas con Latch en sistemas Microsoft Windows.

A todos los que habéis participado con vuestras implementaciones e ideas, os agradecemos el esfuerzo y el cariño que habéis puesto. Nos alegra ver la cantidad de cosas que se pueden hacer con nuestra plataforma Latch y el tiempo que le habéis dedicado a construir vuestros plugins.

¡El más sincero agradecimiento del equipo de ElevenPaths!

LatchHook: Hack para poner un Latch en apps de Android (y de paso, aprender cómo funciona por dentro)

Existen diferentes escenarios en los que podría ser interesante poner un Latch a determinadas acciones en un dispositivo Android: controlar el envío de SMS; bloquear llamadas a números de teléfono de tarificación especial; limitar la instalación, desinstalación y ejecución de aplicaciones en un esquema de supervisión como parte de un MDM o control parental...

Pensando en este último caso y como prueba de concepto, hemos escrito LatchHook, un hack para Android utilizando la librería Substrate (utilizada tanto en la cocina de ROMs como para ayudar en el análisis dinámico de aplicaciones) que utilizando Latch nos permitirá bloquear la ejecución de aplicaciones en un dispositivo A desde un dispositivo B. Si bien se trata de una prueba de concepto, el objetivo a partes iguales es aplicar Latch y conocer más a fondo el sistema de control de Android.

Todo el código está disponible en este proyecto de Github. Se puede adaptar al gusto de quien lo consuma: https://github.com/nodoraiz/latchHooks

El punto de partida

Para poner en marcha el hack necesitaremos pues dos dispositivos para los dos roles: el que será observado (A) y el supervisor (B); además de una cuenta básica en Latch desde la que dar de alta una aplicación (necesitaremos el AppId y el Secret para crear el esquema de supervisión). Además, en el dispositivo A (el que será controlado) será necesario:
  • Tener root.
  • Si tenemos una versión posterior a Android 4.4 tendremos que cambiar el nivel de SELinux a permisivo, podemos utilizar SELinux Mode Changer.
  • Instalar Substrate y confirmar que está funcionando correctamente (lo podemos confirmar si vemos en la aplicación el botón para consultar la galería).
  • Instalar LatchHook. Después de instalar y para que se apliquen los hooks será necesario reiniciar el dispositivo.
  • La app de Latch debe encontrarse instalado en el dispositivo B.

La idea en imágenes

Esquema general de funcionamiento

El flujo de ejecución de la aplicación es sencillo:

  1.  Al arrancar LatchHook en el dispositivo A, se nos pedirá configurar una clave para bloquear el acceso a la configuración de las aplicaciones bloqueadas.
  2. Generamos un código de pareado en el dispositivo B para supervisar el dispositivo A.
  3. Introducir en LatchHook el AppId y Secret de la cuenta de Latch, además del código de pareado generado en B.
  4. Ya tenemos emparejados los dispositivos.
  5. Seleccionamos en LatchHook las aplicaciones que queremos que se bloqueen cuando cerremos el Latch del dispositivo B (el que controlará a A).
  6. Cuando se intente iniciar una aplicación bloqueada en el dispositivo A saltará el bloqueo de LatchHook y en B recibiremos una notificación de intento de acceso no autorizado en Latch.

Una mirada más técnica

Lo que nos permite Substrate es inyectar código en memoria sobre una clase y un método de modo que interceptaremos su llamada y podremos redefinir su comportamiento. Además de llamar al método original si así lo queremos (modificando sus parámetros originales, por ejemplo).

Como el objetivo que perseguimos es impedir que el usuario ejecute una aplicación, un buen punto de partida sería interceptar las llamadas al inicio de aplicaciones realizadas por la aplicación que haga de Launcher en el dispositivo.

Esta aplicación no difiere de cualquier otra aplicación que podamos desarrollar (salvo por tener definida su categoría como android.intent.category.HOME) y está compuesta de actividades que se encargan de arrancar otras actividades ya instaladas en el dispositivo. Así, si queremos interceptar esas ejecuciones desde el punto de vista de Substrate (clase y método), elegiremos los métodos startActivity(…) de la clase android.app.Activity:


Documentación oficial sobre las funciones startActivity

Atacando a este punto, no sólo estaremos interceptando las llamadas al arranque de actividades desde el Launcher por defecto, sino de cualquier aplicación que haga uso de estos métodos para iniciar otras actividades. Dicho esto, un diagrama representativo de lo que hará LatchHook es el siguiente:

Diagrama general de cómo funciona LatchHook

En resumen, las llamadas a los métodos nativos de startActivity serán interceptadas por el hook y evaluadas por el servicio LatchService incluido en LatchHook que se encargará de consultar el estado del pestillo y según esté, ejecutar o bloquear la actividad.

Un detalle que hay que mencionar en la solución, es la necesidad de un servicio al que poder consultar vía IPC. La razón es que cuando salte el hook, lo hará en el contexto de la aplicación que estemos interceptando, y esto tiene varias implicaciones:
  • El código que escribamos en nuestro hook estará limitado a los permisos de la app que hayamos interceptado, así que necesitamos un servicio externo que garantice a través de sus permisos el acceso a internet para consultar los servidores de Latch.
  • El código del hook se ejecuta en el contexto de la aplicación interceptada, de modo que no tendríamos acceso a las SharedPreferences de LatchHook (salvo que las definiéramos con "lectura para todos los usuarios," lo cual desde el punto de vista de la seguridad no es nada recomendable).
Si nos acercamos al código, la base del sistema es la clase Plugin, creada para envolver las funciones utilizadas para hookear con Substrate:

La clase Plugin

Heredando de la clase Plugin sólo tendremos que definir el nombre del plugin, la clase y método que queremos interceptar. Por último la acción alterada que queremos que realice. De este modo, podemos crear un hook sobre el método startActivity(Intent) de la clase Activity del siguiente modo:

Localizando startActivity

Y modificar su comportamiento para reenviar al servicio de Latch cualquier "Intent" enviado a dicho método:

Modificando startActivity

Si observamos este código más en detalle tenemos tres bloques:

  • Recepción de los parámetros por parte de Substrate. Estos son: el método invocado, la instancia sobre la que se ha invocado y el array de parámetros, que en este caso únicamente tendrá un elemento, el "Intent".
  • Un objeto Messenger que utilizaremos para el paso de mensajes con el LatchService. Una vez tengamos la respuesta del servicio se ejecutará el método handleMessage dentro del contexto de la aplicación interceptada, permitiéndonos bloquear la ejecución (contenido del if) o continuar con su ejecución normal (contenido del else)
  • Las últimas tres líneas preparan el Messenger, consultan al servicio y hacen que el método startActivity devuelva null, de modo que se hará un "drop" virtual de la llamada y no se realizará ninguna acción hasta que se tenga respuesta por parte del LatchService.

En cuanto al servicio LatchService, devolverá el estado del Latch si la aplicación es "latcheable" (ha sido seleccionada en la aplicación de LatchHook cuando se configuró):

Devolviendo el estado del Latch

Últimos consejos

La clase LatchServiceHandler se encarga de facilitar la comunicación IPC entre la aplicación hookeada y el LatchService.

El proyecto viene preparado con la clase ConfigurationManager, para poder definir un valor por defecto de AppId y Secret y así ahorrarnos el tener que escribirlo la primera vez:

Añadir aquí los valores de configuración

Los hooks incluidos en esta aplicación son sólo un ejemplo, pero a través de nuevos plugins se podrían controlar fácilmente diferentes puntos del ciclo de vida de una actividad (onCreate, onStart, onResume…), arranque de Services, la recepción de mensajes en un BroadcastReceiver…, y cargarlos en memoria desde la clase PluginManager:



Por último, recordar que aunque no sea infalible y por tanto no válido para escenarios críticos, podría ser un método válido para control de móviles de un tercero bajo muchas otras circunstancias.

Miguel Ángel García
miguelangel.garcia@11paths.com