ElevenPaths Black Friday

viernes, 27 de noviembre de 2015

The highly anticipated Black Friday starts at Eleven Paths with the very best desktop tools against metadata.

Friday November 27th Metashield desktop suite of products for Client and for Outlook can be exclusively yours for free for 1 year.

Use the codes Black Friday and will turn on the best technology of preventive security on your computer against leakage of metadata.


Links of products:
Engine:
Metashield Engine Stand-Alone 3.2

Client:
Metashield For Client SA 3.2

Outlook:
Metashield For Outlook SA x86 3.2
Metashield For Outlook SA x64 3.2

Black Friday 1 year free activation code:
Metashield for Client: BLACKFRIDAY27NOVMSCW
Metashield for Outlook: BLACKFRIDAY27NOVMSOU

Activation mail: metashield@support.elevenpaths.com
Do not let this chance go away.

More information on https://www.elevenpaths.com/es/tecnologia/metashield/index.html
Youtube: https://youtu.be/QBhISm4QTik

* 27 November one day special offer.

ElevenPaths Black Friday

El esperadísimo Black Friday arranca en ElevenPaths de la mano de las mejores herramientas desktop contra los metadatos.

Este viernes 27 de noviembre la suite desktop de los productos Metashield for Client y Metashield For Outlook pueden ser tuyos gratis de manera exclusiva durante 1 año.

Usa los códigos Black Friday y podrás poner en marcha la mejor maquinaria de seguridad preventiva en tu equipo contra la fuga de metadatos.


Links de descarga de los productos:
Engine:
Metashield Engine Stand-Alone 3.2

Client:
Metashield For Client SA 3.2

Outlook:
Metashield For Outlook SA x86 3.2
Metashield For Outlook SA x64 3.2

Codigo Black Friday de activación 1 año gratis:
Metashield for Client: BLACKFRIDAY27NOVMSCW
Metashield for Outlook: BLACKFRIDAY27NOVMSOU

Correo de activación: metashield@support.elevenpaths.com
No dejes escapar esta oportunidad Black Friday ElevenPaths.

Más informacion en https://www.elevenpaths.com/es/tecnologia/metashield/index.html
Youtube: https://youtu.be/QBhISm4QTik

* Promoción valida únicamente el 27 de noviembre.

Una visión más detallada de SandaS

miércoles, 25 de noviembre de 2015

SandaS es el producto que hemos desarrollado en ElevenPaths para dar respuesta a los retos a los que se enfrentan quienes tienen la responsabilidad de gestionar la seguridad lógica de una organización.

El primer reto para la gestión de la seguridad es detectar los incidentes de seguridad en el menor tiempo posible. Las herramientas básicas para este objetivo son los SIEM (Security Information and Event Management), que recogen la información de los sistemas y las herramientas de seguridad, la normalizan y la correlan para detectar dichos incidentes. El mantenimiento y operación de un SIEM es una actividad que requiere una constante atención y ajuste para que sea eficaz.

SandaS CA es el módulo de SandaS que se integra con el SIEM y lo complementa con:
  • Procesamiento de la información que recibe el SIEM con un conjunto de algoritmos propios que permiten detectar actividades que pueden pasar desapercibidas para estos. Estos algoritmos no sólo procesan la información obtenida localmente, sino que añaden información agregada de todos los clientes así como información externa procedente de nuestras fuentes de ciberseguridad para conseguir mayor fiabilidad en la detección.
  • Generación de las correspondientes alertas, que son inyectadas al SIEM para un tratamiento unificado de las mismas.
  • Recolección de las alertas del SIEM, tanto por su correlación nativa como las generadas por SandaS, para su tratamiento automatizado mediante el módulo SandaS RA.
  • Recolección de datos agregados que se mostrarán en el Dashboard en forma de indicadores y métricas.

SandaS CA se instala típicamente en la misma red local del SIEM, ya que requiere acceso directo a este. Dispone de un SDK de integración para construir los conectores que permiten la integración con el SIEM, y ya hay conectores desarrollados para los SIEMs de Alienvault, HP Arcsight e Intel Security.

Una vez detectado un incidente, el siguiente paso es categorizarlo de una forma homogénea, asignarle una criticidad acorde con la que le da cliente según los elementos y el a los que afecta, notificar a los actores relevantes para su tratamiento y resolución, y ejecutar acciones de resolución o remediación. Para cubrir de forma automática toda esa actividad se ha creado SandaS RA.

SandaS RA implementa un flujo de procesamiento que recoge las alertas y notificaciones en general, y en función de los parámetros de la alerta y de reglas definidas por el usuario (un operador del SOC) le asigna una categoría y una criticidad. Las alertas repetidas son agrupadas, para evitar repetir las siguientes fases sin necesidad. A continuación se realizan los procesos de notificación que se hayan configurado para esa alertas, que pueden consistir en la apertura de un caso en el sistema de ticketing del SOC y/o el sistema de ticketing del cliente, el envío de correo con plantillas configurables o avisos por SMS. También se pueden lanzar acciones automáticas de resolución o remediación, como bloqueos de IPs o URLs en los cortafuegos, IPS o proxy web del cliente, cuando están gestionados desde el mismo SOC.

Sandas RA cuenta con interfaces para la integración con los sistemas de notificación y con los conectores que implementan las acciones de respuesta. Las alertas ya categorizadas y en su caso la información de los tickets creados para el seguimiento de los incidentes son enviadas a nuestra plataforma de Seguridad Global, basada en tecnologías de Big Data con productos como Sinfonier, nuestra tecnología para la detección de ciberamenazas basada en el procesamiento de información en tiempo real, para su almacenamiento y visualizar toda esa información relevante tanto para el cliente como para la propia operación en un portal (SandaS Dashboard), que muestra en tiempo real información relevante de seguridad: alertas, incidencias, tickets, SLAs y KPIs.


Con todos estos componentes, SandaS permite agilizar y dar una visibilidad completa de la gestión que realiza un SOC en las tareas de monitorización de la seguridad de una organización, y se convierte en el pilar para la prestación de los servicios de seguridad gestionada.

Enrique Díaz
SandaS Technical Lead

Cómo funciona Server Side Request Forgery (en FaasT)

martes, 24 de noviembre de 2015

La detección de ataques de "Server Side Request Forgery", o comúnmente llamados "SSRF" es una de las muchas novedades que han sido implementadas en Faast durante los últimos seis meses. Este tipo de vulnerabilidades se da cuando un atacante tiene la habilidad de hacer que el servidor objetivo inicie una nueva conexión contra otro equipo, independientemente de si al equipo remoto al que se conecta se encuentra dentro o fuera de su red interna.

En la mayoría de los casos en donde un ataque de "SSRF" adquiere un mayor nivel de criticidad es en los entornos en los que a través de ésta técnica es posible conectarse a equipos en la red local y que de otro modo sería imposible acceder a ellos desde una red externa.

Esquema de ataque SSRF

Este ataque no solo aplica a conexiones HTTP, sino que puede ser combinado con otro tipo de ataques como "XML External Entities", o incluso extrapolado a otro tipo de protocolos como conexiones de SQL Server en las que mediante la modificación de la cadena de conexión es posible acceder a servidores SQL localizados en la red local. En 2010 ya se habló por primera vez de este último ataque ("CSPP – Connection String Parameter Pollution") junto con la combinación con un "SSRF".

En cuanto a la detección de este tipo de vulnerabilidades, no resulta trivial debido a que podemos encontrar este error en diversos entornos y/o protocolos, e incluso algunos de ellos no muestran una alteración en la respuesta a la solicitud, por lo que la única forma de "cazarlos" es en base a un sistema que detecte la conexión saliente.

Para ello, en Faast hemos implementado un sistema de detección que se basa en un servicio externo (desarrollado por ElevenPaths) accesible desde cualquier localización. De este modo, el plugin de detección de "SSRF" de Faast realizará diversas inyecciones y modificaciones de los parámetros de entrada del servidor objetivo que se va a auditar, para tratar de forzar que éste realice una conexión contra nuestro sistema. Si nuestros servidores reciben respuesta, podremos las vulnerabilidades "SSRF".

Diagrama de detección de vulnerabilidades SSRF

Como se ve en el gráfico, la primera operación que realiza Faast es el envío del paquete especialmente formado para tratar de forzar una conexión desde el objetivo hasta el servicio de "SSRF". Si esta conexión se realiza, el servicio de "SSRF" notificará a Faast de la actividad y ésta será mostrada en el panel de vulnerabilidades.


Reporte de vulnerabilidad

En próximos artículos abordaremos otros tipos de vulnerabilidades explotadas por Faast, así como otras técnicas combinadas de explotación que realiza para poder sacarle todo el beneficio posible a las vulnerabilidades encontradas.

Quick and dirty script in Powershell to check certificate fingerprints

lunes, 23 de noviembre de 2015

Malware is using signed binaries to attack Windows systems. Malware needs it to get into the roots of the operative system. So attackers steal or create their own certificates. Everything counts to "look good" for the users and machines. Sometimes, when a signed malware is discovered, you may wonder if any of the binaries in your machine is signed with that certificate. This is a simple powershell script to get that.

Script in powershell

With Powershell, retrieving the fingerprint of the certificate is quite easy. Just a few lines of code. Since most of the suspected machines will be Windows and all modern versions are able to use Powershell, this a simple solution. Just add the certificate fingerprint you are searching for in your computer, tell the program where to start from, and that is all.



To use it, just create your txt file with some fingerprints. For example, these are the fingerprints for the certs used in TheFlame (2012) and WildNeutron (2015) operations respectively.

‎1D190FACF06E133E8754E564C76C17DA8F566FBB
0D859141EE9A0C6E725FFE6BCFC99F3EFCC3FC07

We have uploaded the code to our Github. Whatever good idea you may have to improve it, just share it with us in our community.

Please note this is "quick and dirty" code with both practical and educational purposes.

Autenticación fuerte con FIDO y Mobile Connect (y II)

viernes, 20 de noviembre de 2015

En ElevenPaths llevamos trabajando ya algún tiempo en Mobile Connect, una iniciativa que permite a los usuarios autenticarse en sus servicios online usando su teléfono móvil. Los usuarios pueden conectarse a sus servicios sin passwords, simplemente usando su móvil, independientemente del canal que utilice para acceder al servicio. En el capítulo de hoy os contamos cómo es la experiencia de usuario y cómo funciona a través de FIDO y Mobile Connect. Veamos cómo.

Experiencia de usuario
La FIDO Alliance dispone de dos conjuntos de especificaciones que se corresponden con dos experiencias de usuario:
  • UAF (Universal Authentication Framework) o experiencia de usuario sin contraseña: El usuario en esta experiencia registra el dispositivo en el servicio usando el mecanismo de autenticación en el dispositivo local, por ejemplo con su huella dactilar. Una vez registrado, el usuario siempre que necesite autenticarse en el servicio online, solo tendrá que utilizar su huella dactilar. El usuario no tendrá que insertar ninguna password en ningún momento. Además esta experiencia permite combinar varios mecanismos de autenticación como la huella dactilar + PIN.

  • U2F (Universal Second Factor) o experiencia de usuario con segundo factor. Esta experiencia permite a los servicios incrementar la seguridad de la infraestructura de acceso con password, añadiendo un segundo factor. En este caso el usuario se accede con su usario y password como siempre. El servicio le mostrará al usuario que debe presentar un segundo factor. Este segundo factor permite al servicio usar contraseñas más simples sin comprometer la seguridad.


¿Qué hace que FIDO sea diferente?
FIDO es diferente a otras especificaciones porque separa el protocolo de autenticación entre el cliente y el servidor de la verificación local del usuario que se hace en el dispositivo de autenticación.
Este protocolo permite a los servicios integrarse de una vez y de forma universal con todos los dispositivos de autenticación que cumplan el estándar, garantizando la privacidad del usuario y de una forma segura.

Por otro lado, FIDO proporciona un conjunto de estándares para definir en el cliente una interfaz común y mecanismos para permitir a cualquier dispositivo de autenticación integrarse en este cliente de manera sencilla, como si de un “plugin” se tratara.

El cliente puede venir preinstalado en el cliente, bien en el propio OS o en el navegador. Los diferentes dispositivos de autenticación (biométricos, basados en PIN, etc.) se conectan al cliente mediante una interfaz también estandarizada por las especificaciones FIDO.

Mobile Connect y FIDO
Mobile Connect admite varios tipos de autenticadores, con diferentes niveles de seguridad y son los servicios online los que deciden el tipo de autenticador que requieren para acceder a sus servicios. De esta manera, vemos que Mobile Connect comparte muchos objetivos con FIDO:
  • Objetivo 1: conseguir que los procesos de autenticación sean más simples y seguros
  • Objetivo 2: proporcionar mecanismos de autenticación de doble factor
  • Objetivo 3: definir un framework donde sea sencillo incorporar nuevos autenticadores a modo de plugins, siendo sencillo incorporar autenticadores que ofrezcan distintos niveles de seguridad, tanto existentes como nuevos que puedan surgir en el futuro.

El beneficio de integrar FIDO en Mobile Connect es entonces obvio, pues permitiría incluir cualquier autenticador compatible con la especificación para ser utilizado como mecanismo de autenticación Mobile Connect.

Pero no olvidéis que Mobile Connect no es sólo la autenticación sino que va más allá proporcionando atributos de identidad a través de OpenID Connect. Estos atributos pueden proporcionar información contextual sobre el usuario que unido a la autenticación permite al servicio online obtener una seguridad aún mayor.

Así que si tienes la suerte de tener un Samsung S6, sabed que su sensor de huella dactilar es compatible con FIDO y en breve podréis usarlo en Mobile Connect para conectaros a vuestros servicios online.

* Autenticación fuerte con FIDO y Mobile Connect (I)

También te puede interesar:
* Mobile Connect: el nuevo estándar en autenticación digital
* Introducing Mobile Connect - the new standard in digital authentication
* How Telefónica collaborates with the GSMA to define a project use case scenarios using lean startup”?

Cristina Díaz
cris.diaz@11paths.com

Juan Fabio García
juanfabio.garcia@11paths.com

Miguel García
miguel.garcialongaron@11paths.com


Autenticación fuerte con FIDO y Mobile Connect (I)

miércoles, 18 de noviembre de 2015

Hoy en día la mayoría de los servicios utilizan un modelo de autenticación fuerte para autenticar a sus usuarios. Los bancos, por ejemplo, usan diferentes técnicas de autenticación fuerte para autenticar a sus clientes y autorizar las operaciones bancarias. La autenticación fuerte es una manera de asegurar que la persona que se identifica en un sistema es quien dice ser y se basa en tres factores básicos:
  • Algo que tiene: credencial, OTP, tarjeta magnética
  • Algo que sabe: clave, PIN, preguntas sobre tú identidad
  • Algo que se es: huella dactilar, reconocimiento facial, iris, voz o incluso tu firma.
Hablamos de autenticación fuerte cuando un sistema usa al menos dos de los tres factores básicos, de modo que si uno de los factores se encuentra comprometido todavía existe un segundo factor que le garantiza la seguridad. Sin embargo, las técnicas de autenticación fuerte utilizadas hoy en día carecen en muchos casos de la usabilidad necesaria. Véase el ejemplo de las tarjetas de coordenadas.

¿Qué es FIDO?
La FIDO (Fast IDentity Online) Alliance es un consorcio de más de 150 empresas que pretende reanalizar y rediseñar la autenticación de los servicios online creando estándares abiertos. El objetivo de esta alianza es afrontar el problema no sólo de los usuarios a la hora de crear y recordar sus contraseñas, sino también eliminar la falta de interoperabilidad que actualmente existe entre los distintos mecanismos de autenticación fuerte. El consorcio incluye compañías de envergadura como Google, Microsoft y Samsung. Microsoft anunció que su nuevo Windows 10 tendrá soporte a FIDO. Y en el caso de Samsung, su terminal Samsung Galaxy S6 incorpora un sensor de huella dactilar compatible también con FIDO. Los miembros de la FIDO Alliance comparten tecnología y colaboran en la elaboración de estándares para conseguir que los métodos de autenticación fuerte sean interoperables, más seguros, privados y más fáciles de usar que las passwords. El propósito de FIDO es conseguir que sus especificaciones engloben una amplia gama de tecnologías de autenticación, incluyendo las biométricas como las huellas dactilares, el iris etc., pero también otros mecanismos de autenticación existentes como TPMs, USB security tokens o smart cards.  

¿Cómo funciona FIDO?
Las especificaciones de FIDO utilizan un modelo centrado en el dispositivo. La idea fundamental que persigue la alianza es separar el protocolo de autenticación del mecanismo de verificación de la identidad del usuario. De esta manera, estandarizando el protocolo de autenticación, se consigue garantizar la interoperabilidad, dejando la verificación del usuario como algo intrínseco al propio dispositivo de autenticación. Los protocolos de autenticación definidos utilizan como base la criptografía asimétrica. Durante la fase de registro, el dispositivo de autenticación genera una clave privada, y envía la pública al servidor, junto con el identificador del usuario. Previo a la generación de la clave, el dispositivo de autenticación verifica al usuario mediante la huella dactilar, un PIN o algún otro mecanismo.
Para autenticar al usuario, el dispositivo firma un reto que le envía el servidor con la clave privada que generó durante el registro. Previo a la firma del reto, el dispositivo podrá verificar localmente la identidad del usuario mediante un botón, un PIN, biometría o incluso una combinación de ambas.
Tanto en el registro como en la autenticación, la información biométrica o el PIN usado en la verificación local del usuario nunca abandona el dispositivo de autenticación local. Otra característica importante de FIDO es que está diseñado para garantizar la privacidad del usuario. Los protocolos están definidos de manera que no proporcionan ningún tipo de información sobre el usuario que permita a uno o varios servicios colaborar y hacer un seguimiento del usuario a través de los servicios. En el próximo capítulo veremos qué hace que FIDO sea diferente y su integración con Mobile Connect.

* Autenticación fuerte con FIDO y Mobile Connect (II) 

Cristina Díaz
cris.diaz@11paths.com
Juan Fabio García
juanfabio.garcia@11paths.com
Miguel García
miguel.garcialongaron@11paths.com

Todo lo que vimos en Security Innovation Day 2015 (IV): el nuevo enfoque de la seguridad gestionada

martes, 17 de noviembre de 2015

Externalizar la seguridad de una organización está a la orden del día motivado por la creciente complejidad de las amenazas y riesgos de seguridad a la que se están expuestas las organizaciones. El reto es la confianza. Por eso, desde ElevenPaths queremos dar transparecia para generar confianza y facilitar la gestión de la seguridad gestionada de una organización sin perder la perspectiva de negocio.

Con SandaS aportamos una visión global end-to-end de cualquier incidente de seguridad detectado, desde el momento en el que se esté produciendo, incorporando algoritmos propios que detectan incidentes que pasan desapercibidos para otras herramientas de seguridad del mercado, hasta la adopción de medidas que mitiguen o remedien el incidente aportando una respuesta automática, permitiendo que veas con tus propios ojos (y casi hasta tocar) la seguridad gestionada de tu organización.

Con SandaS GRC aportamos la perspectiva de negocio, que nos va a permitir conocer cuál es el impacto de los incidentes de seguridad en el negocio:
  • Gobierno Corporativo: asociando impactos en activos tecnológicos con su impacto en el negocio y mostrando dicho impacto de forma visual.
  • Gestión de riesgos: permitiendo la identificación, análisis, evaluación y tratamiento de los riesgos.
  • Cumplimiento regulatorio: facilitando el seguimiento de cada una de las fases del cumplimiento de diferentes normas y políticas.



Por si os habéis quedado con ganas de más, en nuestra web hemos publicado todos los materiales del evento para que podáis descargar las presentaciones de las diferentes sesiones o verlos en vídeo en el canal de YouTube del Security Day Innovation 2015 todas las veces que queráis. Si además, quieres o necesitas más información sobre alguno de nuestros productos no dudes en ponerte en contacto con nosotros vía el formulario de la web de ElevenPaths.

No te pierdas el resto de la serie de todo lo que vimos en Security Innovation Day 2015, aquí puedes leer los primeros capítulos:
» Todo lo que vimos en Security Innovation Day 2015 (I): Siente el poder de las alianzas
» Todo lo que vimos en Security Innovation Day 2015 (II): tu móvil, tu identificador único
» Todo lo que vimos en Security Innovation Day 2015 (III): Decisiones de seguridad para salvar tu negocio

Próximamente iremos publicando el resto de capítulos de todo lo que presentamos en nuestro Security Innovation Day 2015, ¡no te lo puedes perder!

ElevenPaths' SandaS team

Estudio: Sobreexposición de credenciales de Amazon en apps

lunes, 16 de noviembre de 2015

Cada vez más frecuente el desarrollo de aplicaciones móviles que interactúan con servicios comunes en entornos de movilidad como Amazon Simple Storage Service (S3), Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) o Amazon Mobile Analytics.

Para interactuar con estos servicios, las apps necesitan comunicarse con ellos y autenticarse con algún tipo de credencial (habitualmente basado en tokens). Hemos identificado prácticas de programación inseguras en forma de gestión incorrecta de credenciales de acceso, que podrían permitir a un atacante modificar el comportamiento de las apps afectadas.

Gestión de identidades en Amazon AWS

Los desarrolladores de apps móviles necesitan sus propias claves de acceso para realizar llamadas programáticas a los servicios Amazon. Pueden usar el AWS Command Line Interface (AWS CLI) , los SDKs de AWS, o llamadas HTTP directas usando las APIs para servicios individuales de AWS.

Esto último es lo más común en las comunicaciones de las apps. Desde la consola de administración de Amazon, se pueden crear, modificar, ver o rotar las claves de acceso, conocidas como access key y secret key. Estas claves de acceso son válidas para interactuar de forma programática con el contenido o servicios ofrecido por Amazon. Las apps que hagan uso de este contenido, deberán por tanto conocer las claves de acceso.

Aunque existen métodos más adecuados, algunos programadores incrustan esta información en la propia app. Si el acceso es de solamente de lectura, esto puede resultar en una mala práctica de programación, pero no en un problema de seguridad necesariamente. Sin embargo, si los permisos están mal establecidos, existe la posibilidad de controlar el contenido. Si además las contraseñas son accesibles por cualquiera que analice la aplicación, un atacante podría modificar ese contenido que más tarde será usado por la app.

Si no se toman las medidas necesarias a la hora de establecer los permisos de acceso de las API keys, cualquiera con acceso a las claves podría no solo tener acceso a la información, sino modificarla.
Las claves de acceso pueden ser introducidas en una app a través de un archivo de credenciales que se encuentra dentro del APK, en texto claro. Así, resulta más fácil la gestión y mantenimiento de la app. Este fichero se genera a través del AWS CLI. Por defecto su nombre es AWSCredentials.properties, y su formato similar al que se adjunta bajo estas líneas:
Ejemplo (falso) de credenciales

Mediante el uso de Tacyt, la herramienta de ciberinteligiencia de apps móviles de ElevenPaths, se ha buscado cuántas apps en los diferentes markets monitorizados contienen un fichero de este tipo, realizándose una comprobación posterior de la naturaleza de las credenciales asociadas.

Búsqueda en Tacyt de APKs con este tipo de ficheros

Nuestra base de datos, compuesta por 4.5 millones de apps, hemos localizado 1.635 ficheros APK que contienen un archivo de este tipo en el momento de redacción del presente informe. Esas 1.635 corresponden a apps y además versiones diferentes de esa misma app (hashes) almacenadas en nuestra base de datos. Las apps únicas (independientemente de su versión, y atendiendo a nombre de paquete único) son en realidad 478 apps diferentes repartidas en diferentes markets.

Se ha realizado un pequeño estudio comprobando en qué situación se encuentran las credenciales encontradas y qué peligro representan.

Análisis de los datos

Tras el análisis de las apps que contenían ficheros que potencialmente podrían suponer un problema de seguridad, este es el resultado obtenido:
  • De todas las apps estudiadas, 102 ya no se encuentran en el market oficial y han sido retiradas. Aunque hayan sido retiradas, siguen suponiendo un problema, puesto que las apps permanecen en los dispositivos instalados, además de que las credenciales no dejan de ser válidas por ello.
  • Hemos encontrado 478 apps diferentes que contienen credenciales válidas. 408 de ellas en Google Play.
  • Sin embargo, el número de claves de acceso diferentes encontrado en todos los markets no es excesivamente alto: 63. Esto quiere decir, que varias de esas 63 credenciales se encuentran repartidas entre las diferentes apps. En otras palabras: muchos desarrolladores supuestamente diferentes comparten cuentas de AWS válidas. En concreto, dos credenciales diferentes se comparten en 523 y 196 versiones diferentes de las apps. Solo hay 26 credenciales únicas que no son compartidas y que se encuentran en una única app.
  • De los 63 encontrados, 37 access key siguen siendo operativas, lo que significa que permiten realizar el proceso de autenticación de forma correcta. Las access key válidas compartidas siguen la siguiente distribución. De entre las válidas, una se encuentra repartida en 523 versiones diferentes de diferentes apps.
  • De ellos, hemos podido obtener los permisos (ACL) de 26 credenciales.
  • 22 claves de acceso mantenían FULL CONTROL con esas credenciales. Esto significa que se podía leer, escribir e incluso modificar algún contenido alojado en Amazon. El resto, permitían la escritura, con lo que a efectos prácticos, también supone un problema de seguridad.
  • Las credenciales encontradas en Google Play están repartidas entre 408 apps diferentes. A su vez, muchos desarrolladores aparentemente distintos comparten credenciales. Llama la atención una misma credencial presente en 74 developers diferentes, cada uno con sus respectivas apps.

De los 74 desarrolladores en Google Play que comparten credencial, cabe destacar que la mayoría parecen ser empresas de publicación de revistas y medios de comunicación en general, algunos bastante conocidos. Esto hace pensar que las apps de estas empresas han sido desarrolladas por un mismo equipo, que ha reutilizado de alguna manera parte de los recursos, entre ellos, la infraestructura en la nube y con ella las credenciales de acceso. Este cruce de credenciales compartidas entre apps diferentes que cargan contenido alojado en un tercero, abre una ventana de ataque interesante, dependiendo de los permisos de las credenciales.

Es necesario matizar que no todas las apps que contienen credenciales tienen por qué hacer uso de ellas. Puede suponer simplemente una mala práctica por disponer de los permisos adecuados, lo que implica que, aunque suponga una exposición de información sensible, en la práctica no abre ninguna brecha de seguridad ni posibilidad de ataque contra los usuarios de la app o los desarrolladores.

El informe completo está colgado aquí:



Research: On the overexposure of Amazon credentials in mobile apps

The development of mobile applications that interact with common services in mobility environments such as Amazon Simple Storage Service (S3), Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) or Amazon Mobile Analytics is becoming more frequent.

To interact with these services, apps need to communicate with them and authenticate with some kind of credential (usually based on tokens). We have identified unsafe programming practices in the form of poor management of login credentials, which could allow an attacker to modify the behavior of the affected apps.

Identity management in Amazon AWS

Mobile app developers need their own access keys to programmatically call Amazon Services. They can use the AWS Command Line Interface (AWS CLI)  , AWS SDKs or direct HTTP calls using APIs for AWS individual services.

The latter is more common in apps communications. From the Amazon Management Console, access keys, known as access keys and secret keys can be created, modified, viewed or rotated. These access keys are valid to programmatically interact with the contents or services offered by Amazon. Apps that use these contents must therefore know the access keys.

Although there are more appropriate methods, some programmers embed this information in the app itself. If access is read-only, this can result in a bad programming practice, but not necessarily in a security problem. However, if permissions are poorly established, contents could be controlled. If, in addition, access keys are accessible by anyone analyzing the application, an attacker could modify those contents that later on would be used by the app.

If necessary measures are not taken when setting access permissions of the API keys, anyone with access to the keys could not only access the information, but modify it.

However, access keys can also be introduced into an app through a credentials file located within the APK, in clear text. This way, apps are easier to manage and maintain. This file is generated with the AWS CLI. Its default name is AWSCredentials.properties, and its format is similar to the following:
(Falso) example of credentials
With Tacyt , ElevenPaths’ Cyber intelligence Tool for mobile apps, we have searched how many apps in the different monitored markets contain a file of such type, subsequently verifying the nature of the associated credentials.

First seach in Tacyt for APKs with this kind of files

At the time of writing this report, we found 1,635 APK files containing a file of this type in our database, formed by 4.5 million apps. Those 1,635 files correspond to apps and also to different versions of those same apps (hashes) stored in our database. Unique apps (regardless of their version, and on the basis of unique package name) are actually 478 different apps distributed over different markets.

We have studied the situation of credentials and if they represent any risk.

Data analysis

These are the results obtained after analyzing the apps containing files that could potentially pose a security problem:
  • Of all studied apps, 102 are no longer in the official market and have been removed. Although removed, they still to pose a problem, since the apps remain in the installed devices, and furthermore, credentials do not stop being valid even so.
  • We have found 478 different apps containing valid credentials. 408 of them in Google Play.
  • However, the number of different access keys found in all markets is not too high: 63. This means that several of those 63 credentials are distributed between different apps. In other words, many seemingly different developers share valid AWS accounts. In particular, two different credentials are shared in 523 and 196 different versions of the apps. There are only 26 unique credentials that are not shared and that are found in a sole app.
  • 37 of the 63 access keys found remain fully operational, which means they allow the correct performance of the authentication process. The valid access keys shared have the following distribution. Among the valid access keys, one is distributed in 523 different versions of different apps.  
  • Of these access keys, we have obtained permissions (ACL) from 26 credentials. 
  • 22 access keys kept FULL CONTROL with those credentials. This means that some contents hosted on Amazon could be read, written and even edited.The rest of them allowed Write, which for practical purposes also poses a security problem.
  • The credentials found on Google Play are distributed over 408 different apps. In turn, many seemingly different developers share credentials. It is interesting to see how there is a single credential present in 74 different developers, each one with their respective apps.
Of the 74 credential-sharing developers on Google Play, it should be noted that most of them seem to be magazine publishing companies and media in general, some of them quite known. This suggests that these companies’ apps have been developed by the same team, which has somehow reused part of the resources, including the infrastructure in the cloud and, with it, the access credentials. This exchange of shared credentials between different apps that load contents hosted on a third party opens an interesting attack window, depending on the credentials permissions.

It is necessary to clarify that not all apps containing credentials have to use them. It can simply constitute a "bad practice" if using the appropriate permissions, which means that, even if it involves exposure of sensitive information, in practice it does not open any security breach or attack possibility against app users or developers.


The Android Trojan preinstalled in Amazon Tablets is in Google Play as well

viernes, 13 de noviembre de 2015

Researchers from Cheetah Mobile have found Trojans preinstalled in some cheap Amazon tablets, very hard to remove. But, here in ElevenPaths we have found that a version of this Trojan is present right now in Google Play hidden as a HTML 5 games application. The malware has been dubbed "Cloudsota".

The app, still in Google Play, made by the same band of "Cloudsota".
 
The Trojan found by Cheetah Mobile, is preinstalled in tablets, restores itself after reboots if deleted, hijacks the browser homepage and downloads apps from some servers to install them silently if the device is rooted (which, in these tablets, is very likely). We found a very similar behavior in a Google Play app, downloading apps from the same servers and with quite similar code. What we can be sure is that is made by the same people behind this Cloudsota. Although maybe with enough changes to be able to get in the official market.

How it works

Once the apps found by Cheetah were analyzed, thanks to Tacyt, we found a strong correlation with just one out of 4.6 million apps in our database. It has been in Google Play since August 2015. This app, when booting or if a user is present (unlocks the screen), calls a method called "b" inside the  com.android.ThreeTyCon.c class, that visits this site hxxp://union.dengandroid.com/getconfig and sends some interesting information.

JSon sent to the server before being encoded
After sending some encoded personal information (email, MAC, if the device is rooted or not, etc) it finally downloads (with some encoding as well) a dex file called business.dex. We guess the file may be different depending on this information previously sent.

The code to download and use business.dex
This business.dex is terribly offuscated, and contains most of the malicious code. Business.dex is as well programmed to download different versions of business_X.dex (the X depends on the configuration in the device) that we suppose that makes its behavour quite unpredictable.

If busybox util is found in the device, it tries to load libraries, install and uninstall apps... This is done just before business.dex is downloaded, we guess this is for uninstalling any antivirus the user may have just before downloading the (even more) malicious code, that is more likely to be detected.

Triying to uninstall code

As far as we know, the app itself or the business.dex does not contain code to survive and install itself after reboot or hijack the homepage, but it definitely could, as we can see some references in the code. 

It may hijacks the homepage
  
Aside, it shares with Cheetah samples, the use of a very particular library libshellcmd.so.
 
It uses libshellcmd.so, shared with Cloudsota


The app in Google Play is detected by some antiviruses. But most of them do not detect the app because of this behavior, but because of it containing some Airpush SDK code. Airpush was considered a potentially unwanted adware SDK long time ago by the antiviruses. It is interesting as well that the app has been downloaded 5.000 and 10.000 times, but only 3 votes have been given.

Too many downloads for so few votes...

That make us think about some time of artificial boost with unreal downloads made by the same developers to enhance searching position.

Sergio de los Santos
ssantos@11paths.com

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

El troyano preinstalado en tablets baratas de Amazon también está en Google Play

Investigadores de Cheetah Mobile han encontrado troyanos preinstaldos en algunas tablets baratas de Amazon, muy difíciles de eliminar. Aquí, en ElevenPaths, hemos encontrado una versión de este troyano presente ahora mismo en Google Play y escondida bajo una aplicación de juegos HTML5. Este malware ha sido bautizado como "Cloudsota".

La app, todavía en Google Play, realizada por la misma banda que "Cloudsota"
 
El troyano encontrado por Cheetah Mobile, se encuentra preinstalado en las tablets, es capaz de instalarse de nuevo después de un reinicio si se ha borrado, secuestra la página de inicio del navegador y descarga apps de servidores para instalarlas silenciosamente si el dispositivo está rooteado (algo con bastante posibilidades en las tabletas donde viene preinstalado)  Hemos encontrado un comportamiento muy similar en una app de Google Play, que descarga otros APK desde los mismos servidores, y cuyo código se asemeja bastante. De lo que estamos seguros, por varios indicios, es que está creado por la misma banda que Cloudsota, aunque quizás con más "cuidado" para poder entrar en el market oficial.

Cómo funciona

Una vez analizamos las apps encontradas por Cheetah, gracias a Tacyt, encontramos una fuerte correlación con solo una de las 4.6 millones de aplicaciones que tenemos en la base de datos. Esta app ha estado en Google Play desde agosto de 2015. Cuando se inicia o detecta la presencia de un usuario (desbloquea la pantalla), llama a un método "b" dentro de la clase com.android.ThreeTyCon.c que visita el sitio hxxp://union.dengandroid.com/getconfig y envía información interesante.

JSon enviado al servidor antes de ser codificado
Después de enviar esta información personal codificada (email, MAC, si el dispositivo está rooteado o no, etc) finalmente descarga (también codifica la petición HTTP) un fichero DEX llamado business.dex. Suponemos que este fichero puede ser diferente dependiendo de la información enviada previamente.

El código para descargar y usar business.dex

Este business.dex se encuentra bastante ofuscado, y contiene buena parte del código y la lógica maliciosa. Business.dex está también programado para descargar diferentes versiones de business_X.dex (la X depende de la configuración del dispositivo) que suponemos que hace al comportamiento global bastante impredecible.

Si la utilidad busybox se encuentra en el dispositivo, intenta cargar librerías, instalar y desinstalar apps... Esto se hace justo antes de que business.dex sea descargado, suponemos que para desinstalar un potencial antivirus que el usuario pudiera mantener instalado y eliminarlo antes de descargare el (todavía más) código malicioso que podría ser detectado con mayor probabilidad.


Intentando desinstalar código

Hasta donde sabemos, la aplicación por sí misma o business.dex no contiene código para instalarse de nuevo si se borra, o secuestrar la página de inicio, pero parece que podría, puesto que vemos varias referencias en el código.

It may hijacks the homepage
  
Además, comparte con las muestras obtenidas por Cheetah, el uso de una librería muy particular llamada libshellcmd.so.
 
Utiliza libshellcmd.so, librería compartida con Cloudsota

La app en Google Play (com.cz.gamenavigation) es ya detectada por varios antivirus. Pero muchos no la detectan por este comportamiento, sino porque contiene código perteneciente al uso del SDK Airpush. Airpush se considera potencialmente adware dañino desde hace mucho por los antivirus. Resulta interesante también que la app ha sido descargada entre 5.000 y 10.000 veces, pero solo se le ha dado tres votos.

Demasiadas descargas para tan pocos votos...

Esto nos hace pensar en alguna especie de "tirón artificial" con descargas no reales y llevadas a cabo de forma automática por el mismo equipo que ha desarrollado la aplicación, consiguiendo así mejorar su posición de búsqueda en el market.

Sergio de los Santos
ssantos@11paths.com

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

III Meetup Sinfonier: Ciberterrorismo

jueves, 12 de noviembre de 2015

No podíamos despedir el año sin tratar un tema tan interesante como es el terrorismo en la red. Pero, ¿realmente sabemos lo que significa? ¿cómo se mitiga? ¿Qué diferencias hay respecto del terrorismo que siempre hemos conocido? Trataremos de dar respuesta a estas y otras preguntas a lo largo de tres intervenciones de 20 minutos en el Tercer MeetUP de Sinfonier sobre Ciberterrorismo.
  • Cuándo: 19 de noviembre
  • Dónde: Telefónica Flagship Store - C/Gran Vía 28, Madrid
Contaremos con profesionales de primer nivel que anunciaremos en los próximos días. Nos acompañarán representantes del principal Think Tank de ciberseguridad de nuestro país. Hasta aquí podemos leer.




Y esto no es todo. No podíamos despedir el año sin un concurso. Por eso, si te atreves a desarrollar un módulo para Sinfonier, participa en el concurso Sinfonier Commnunity 2015 y desarrolla una tipología innovadora y de utilidad que tenga aplicación para entornos de Smart Cities, Economía Digital e Identidades Digitales.

Si eres un desarrollador o analista de inteligencia, ¡haz lo que mejor sabes y cobra por ello! Participa y gana 3.000 USD. ¡Inscríbete ahora!



Ransomware para Linux… algunas aclaraciones y reflexiones

miércoles, 11 de noviembre de 2015

A estas alturas, ya se ha oído hablar bastante del nuevo "ransomware para Linux" que secuestra páginas web alojadas en servidores Linux, y pide un rescate (un bitcoin en este caso) por ellas. La información que se ha dado merece, cuando menos, algunas aclaraciones y una reflexión.

Lo interesante es la filosofía

Se ha dado por hecho que a las páginas web que utilicen el sistema de comercio electrónico Magento han sido las atacadas. Magento es una tienda en PHP, que (como muchísimos otros gestores en PHP) tuvo un problema de seguridad que permitía la ejecución de PHP arbitrario, lo que equivale casi (si el administrador no ha tomado las medidas adecuadas) a la ejecución de código, al menos con los permisos del servidor web. Una rápida búsqueda hace pensar que sí, existen muchos sitios con Magento afectados… pero también Joomlas, Wordpress, Imagevues… cualquier programa vulnerable en PHP. La razón es simple: la vulnerabilidad y la carga del malware (el payload) como es costumbre, son independientes.

Lo "normal" es que los atacantes usen "dorks" de búsqueda de sitios PHP vulnerables y programan scripts para intentar aprovechar vulnerabilidades conocidas. Una vez que saben que pueden ejecutar PHP, el sitio es prácticamente suyo. Desde ahí, habitualmente, suben phishing, envían spam, realizan un "deface", alojan contenido ilegal… etc. Esto lo hace cualquier atacante de perfil bajo, "desde siempre". La novedad aquí por tanto no es que se ataque a Linux o PHP. Eso se hace todos los días. El foco de atención debería ponerse sobre la filosofía del ataque: en vez de aprovechar las capacidades del servidor, han preferido secuestrar su contenido.

Igual ocurrió en Windows. En vez de infectar los sistemas con más adware, ralentizarlo, usarlo como bot, robar credenciales… los atacantes comprobaron en 2010 que secuestrarlo podía ser más rentable. Y de qué manera. Ya lo habían intentado tímidamente en ocasiones anteriores, pero fue ese año cuando se abrió una era. No cambió la forma en la que el malware llegaba al sistema, sino qué hacía una vez en él y cómo enfocaba su rentabilidad. De hecho, resultaba técnicamente más simple en muchos sentidos con respecto a lo que se venía haciendo hasta entonces.

Por tanto, sobre Linux.Encoder.1, es interesante que esté programado para Linux, pero solo porque el atacante sabe que su cuota de éxito será mayor ahí. Bien podría poder haberlo hecho para cualquier plataforma, no supondría demasiado problema. Eso no es la novedad real.

Aviso para el administrador, no para el visitante de la web
(este fichero no queda visible por defecto para ser mostrado por el servidor)


De hecho, vemos aquí algunos ejemplos de sitios afectados. Parece que varios de ellos, ya estaban previamente comprometidos y alojaban shells en PHP (síntoma de un compromiso de "perfil bajo"). Esto quiere decir que fueron víctimas de esos bots que buscan sitios aleatorios en PHP vulnerables previamente, y que ya estaban en manos de atacantes antes de que les este malware cifrara su web.

Ejemplo de sitio cifrado, pero que ya alojaba una shell
Un ejemplo cualquiera de página cifrada
Sería interesante realizar un pequeño forense a esas máquinas para saber de dónde vino el ataque. Parece que no tenía capacidad de gusano (lanzar nuevos ataques desde la propia víctima), por tanto, podría dar una pista de los atacantes, si no se ocultaban a través de una red de anonimato.

¿Importa la detección?

Por supuesto, el malware no era detectado por los sistemas antivirus tradicionales por firma. Pero no importa demasiado. No parece habitual que administradores de Windows, y muchos menos de Linux, pongan en producción un sistema operativo protegido en tiempo real por antivirus. Como mucho, lanzarán cada cierto tiempo un análisis estático. Además, no es la forma más correcta de defenderse. El malware entra en el servidor no porque no se defienda adecuadamente contra el malware, sino porque acepta comandos de cualquiera. En el mundo de los servidores, más que un antivirus, es todavía mucho más razonable invertir en parchear el sistema y mantenerlo a salvo de los fallos más obvios. O centrar los esfuerzos en impedir que un acceso por web acabe con el control del servidor y ejecute comandos peligrosos.

Un cambio de filosofía

El ransomware ya se probó en los primeros años de la década pasada, cuando el malware no estaba profesionalizado. Pequeños intentos aislados que no tuvieron mucho éxito. Pero el boom sufrido en los últimos tiempos, primero con los bloqueadores de sistema y ahora con el malware que cifra archivos, supuso un importante cambio de filosofía. Se podía ganar aún más dinero con el malware. Ya disponían de un buen montón de usuarios vulnerables, plataformas profesionalizadas y buena distribución… pero no todo era el malware bancario. También estaba la extorsión. Qué descubrimiento. Esto parece especialmente preocupante. Los atacantes también tienen un buen montón de servidores vulnerables repartidos por el mundo y los aprovechan. ¿Y si deciden que esta nueva aproximación es más rentable que los ataques a servidores web que se vienen realizando hasta ahora? ¿Podemos asistir a una nueva moda en la que los servidores y páginas sean cifradas en vez de "desfiguradas"? ¿En las que se pida un rescate en vez de instalar una shell en PHP o un mailer?

Nunca se sabe. Aunque pueda existir un buen mercado, parece que el perfil de víctima no sería tan interesante (igual que no lo es el usuario de escritorio de sistemas operativos que no sean Windows). Además, la cura contra este problema es:
  • Una copia de seguridad actualizada, que es algo más probable (en contraste con el usuario de escritorio o administrador de red) que hayan hecho los dueños… o los administradores del hosting (aquí la responsabilidad puede que se diluya entre el responsable del contenido de la página y los responsables de la plataforma en la que está alojada)
  • Parchear el sistema contra vulnerabilidades conocidas. Si los administradores no lo han hecho, estamos seguros de que ya tienen otros problemas, puesto que es una puerta abierta al mundo que, seguro, ya es explotada habitualmente.
Todo es cuestión de coste y beneficio, y quizás un servidor comprometido con posibilidades más "dinámicas" (alojamiento de phishing, warez, spam, etc.) y usable a largo plazo  sea más rentable que cifrarlo. Usado de esta forma es un "valor seguro", mientras que la destrucción del propio servidor y reclamación de un rescate es un todo o nada, que puede salir bien (pagan) o no.

Dicen que pagan el 3% de los casos de Windows. F-Secure afirma que estos atacantes han podido ganar 12.000 euros en un mes (11.934 específicamente). Estos cálculos son arriesgados. ¿En qué se basan? No se menciona. Si buscamos en Google páginas posiblemente afectadas y todavía accesibles o cacheadas, obtenemos algo más de 12.000 resultados (aunque podrían ser más, pues Google está olvidando rápidamente). De ellos, la mayoría parecen reales, pero muchos son dobles entradas en el buscador de un mismo dominio, por lo que no cuentan.

Limpiando la salida con una búsqueda más afinada, podríamos hablar de (siendo generosos) 10.000 sitios afectados (curiosamente, muchísimo dominio europeo). El atacante pedía un solo bitcoin, que valora en 420 dólares (precio de primeros de noviembre).

Si respetamos el precio, suponemos 10.000 afectados y hablamos de un 1% de víctimas que llegan a pagar, tenemos 100 afectados y 42.000 dólares. Para que salgan los cálculos de F-Secure, tendríamos que suponer que, no un 1%, sino aproximadamente un 0,30% de esos 10.000 sitios han pagado. ¿Es real este dato? Quién sabe. Frente al dato estimado para Windows (el 3% de los infectados pagan), implica que los administradores de páginas son 100 veces menos propensos a pagar… Seguro que son menos propensos, pero no sabemos cuánto. De hecho, igual de irrelevante que la plataforma, aquí los números absolutos también lo son desde el punto de vista de qué nos depara el futuro. Importa la rentabilidad en términos relativos.

Lo único que nos permitirá saber si es rentable o no será si asistimos a nuevos ataques. En esta versión han cometido errores de bulto, como por ejemplo una mala implementación que permite descifrar los archivos sin necesidad de pagar, basándose en la fecha del primer archivo infectado. Esto ya lo hicieron en los primeros tiempos los atacantes "tradicionales" de ransomware de escritorio. Pero afinaron. Si en el futuro se observan nuevos ataques con malware mejorado, es que el ratio de víctimas que han pagado, sea cual sea, merece la pena. Así de simple.

Sergio de los Santos
ssantos@11paths.com

Metashield Management Console (MMC). El control con mayúsculas

martes, 10 de noviembre de 2015

Metashield Protector es nuestra solución contra la fuga de información sensible y tratamiento de metadatos. Su versión de licencias con consola, Metashield Management Console, está diseñada para administrar la cuenta de una organización aplicando políticas de seguridad comunes en el tratamiento de metadatos.

Muchas organizaciones disponen de grandes parques informáticos y no pueden invertir esfuerzos en complejos procesos de implementación, formación y educación. ¿Cómo podrían evitar la fuga de información sensible de su entorno corporativo? ¿Cómo podrían evitar que fuera el usuario final el responsable del tratamiento de la información oculta que sale de la organización?

Esta tarea se puede ceder a la Metashield Management Console que se encarga de gestionar y aplicar las políticas de tratamiento metadata predefinidas por la organización sobre su estructura informática.

 
Dashboard de Metashield Management Console

La consola de Metashield Protector está integrada sobre un servicio web, permitiendo a un administrador la toma de control sobre las herramientas de tratamiento de metadatos evitando la responsabilidad final de su uso por parte del usuario. Ya no habrá que preocuparse por los metadatos de los archivos cuando se envían por correo electrónico, o decidir qué metadatos habilitar en un archivo que almacenamos en un repositorio. Todo es automático.

Además, Metashield Management Console permite realizar una administración y gestión centralizada de todas las soluciones de seguridad de Metashield ProtectorTodo es muy simple. De esta manera, por ejemplo, podríamos reutilizar las licencias de un equipo en caso de avería o sustitución (puesto que van asociadas a la máquina), permitiendo un ahorro en costes en entornos que cambian con frecuencia.

Gracias a su dashboard estadístico de resultados en tiempo real podremos realizar una completa configuración de metadatos, extensiones de archivos, tareas, perfiles y su aplicación a nivel corporativo.

Incluye también la posibilidad de integración con Latch. Se proporciona así un segundo factor de seguridad de acceso, controlado desde un smartphone, que permite habilitar o bloquear las credenciales del administrador. Un sistema de alertas en tiempo real que notifica vía móvil de los intentos de acceso a la Consola.

Metashield Management Console integrada con Latch

En resumen, una completa consola de gestión web para evitar las fugas de datos, perfecta y complementaria en cualquier proyecto DLP, EndPoint Security o ENS.

Desde ElevenPaths, buscamos simplificar la labor de los administradores de sistemas automatizando los procesos y limitando la responsabilidad final de los usuarios. Metashield Protector, contribuye positivamente en las políticas de seguridad de una organización.

Antonio Bordón
antonio.bordon@11paths.com

Latch y el Internet de las Cosas: Integración con Arduino (y VI)

lunes, 9 de noviembre de 2015

Tenemos ya todo casi todo lo necesario para hacer funcionar nuestro proyecto. Hemos preparado Arduino con conexión WiFi (y solucionado los problemas pertinentes), se ha estudiado la API y de Latch y se ha programado nuestra propia versión. Toca preparar la salida física con el aparato escogido (en este caso un timbre). Veamos cómo.

Conexión IoT: entrada y salida al mundo real

Sin duda alguna, el punto fuerte de Arduino está en su manejo de las entradas y salidas con el mundo real. Ya sean digitales o analógicas, dispone de una amplia variedad de funciones software y complementos hardware para su manipulación. Podemos encontrar en Internet todo tipo de ejemplos. La integración propuesta, solo necesita una entrada para detectar cuando se llama al timbre (Knock!), y una salida para activar el propio timbre (Bell), en función del estado del Latch.

En este caso, tanto la entrada como la salida se encuentran en el mundo real que funciona con la tensión de suministro eléctrico, 220 voltios AC o 110 voltios AC dependiendo del país, por lo que hay que adoptar las precauciones necesarias para evitar cualquier tipo de riesgo con estas tensiones.

El manejo con Arduino de salidas que actúen a la tensión de suministro es muy frecuente, por lo que hay numerosos módulos y ejemplos disponibles, generalmente utilizando relés u otros mecanismos que proporcionen un cierto aislamiento. La detección de la tensión de suministro como entrada es menos habitual, pero tampoco entraña ninguna dificultad obtenerla en condiciones de seguridad.

En ambos casos es recomendable emplear opto-acopladores que proporcionan un aislamiento completo entre la tensión de suministro y la electrónica del Arduino. Mediante un foto-transistor se detecta presencia de tensión de suministro en la entrada (INPUT), y con el conjunto de un foto-triac y un triac de potencia, se habilita el paso de esta hacia la salida (OUTPUT).

Conexión de detección y salida a 220v AC 

Según esta disposición, el circuito solo recibe la tensión de suministro a través de la entrada (INPUT) mientras se esté pulsando el interruptor del timbre, por lo que Arduino nunca podrá hacerlo sonar activando la salida (OUTPUT) si no se está pulsando el interruptor al mismo tiempo.

El código completo y funcional a modo de ejemplo está publicado en el repositorio de GitHub: https://github.com/latchdevel/latch-arduino. Se puede apreciar que la entrada (Knock!) se atiende a través de una interrupción dispuesta a tal efecto. La salida (Bell) permanece desactivada mientras haya conexión a la red y solo si se ha realizado la sincronización de tiempo inicial. Se activa solo tras la consulta del estado del Latch. Apenas se percibe porque el tiempo de respuesta es inferior a 500 milisegundos. El montaje realizado a modo de demostración presenta este aspecto:

Montaje de ejemplo

Y para recordar cómo funciona, aquí podemos ver de nuevo el vídeo que lo muestra… y demuestra.


Os animamos a usar la comunidad de ElevenPaths como foro para comentar mejoras, ideas, o cualquier otro invento que se os ocurra.

* Latch y el Internet de las Cosas: Integración con Arduino (I)
* Latch y el Internet de las Cosas: Integración con Arduino (II)
Latch y el Internet de las Cosas: Integración con Arduino (III)
Latch y el Internet de las Cosas: Integración con Arduino (IV)
Latch y el Internet de las Cosas: Integración con Arduino (V)


Jorge Rivera
jorge.rivera@11paths.com

SandaS GRC en las Delegaciones Comerciales Loterías y Apuestas del Estado

viernes, 6 de noviembre de 2015

La seguridad es una de las principales preocupaciones actuales y ya forma parte de la agenda de los gobiernos y de las empresas de todo el mundo. Internet y el uso de las nuevas tecnologías cambian constantemente, requiriendo una gran agilidad e innovación en el desarrollo de soluciones de seguridad capaces de identificar, prevenir y gestionar el riesgo.

Por eso, desde ElevenPaths creemos indispensable un proceso de gestión de la seguridad integral que permita identificar y gestionar los riesgos clave tanto desde el punto de vista de seguridad como de cumplimiento normativo y regulatorio. Con este propósito, nace SandaS GRC, fruto de la adquisición de la plataforma Gesconsultor, líder del mercado en Gobierno TI, Gestión del Riesgo y Cumplimiento Normativo que enriquece el portfolio de servicios de seguridad gestionada tal y como ya os contamos en el post ¿Me va a creer usted a mí o a sus propios ojos? El dilema de la seguridad gestionada.

Bajo el marco de nuestro evento anual de innovación y seguridad, Security Innovation Day 2015, compartimos el testimonio de Pilar y Javier, quiénes nos contaron de primera mano su experiencia con la herramienta SandaS GRC. Ellos son los responsables de Delegaciones Comerciales de Loterías y Apuestas del Estado cuya misión es la de prestar todos los servicios que Loterías necesita de los puntos de venta finales, de los sistemas técnicos de Loterías del Estado, e incluso, de los propios participantes en las apuestas.

Se enfrentaban a un reto: certificar toda la red de Delegaciones, un total de 50 distribuidas por toda España, tanto en Seguridad de la Información (ISO 27001) como en Calidad (ISO 9001) en un tiempo récord y sin experiencia previa en estos temas. SandaS GRC les ayudó a conseguir su objetivo permitiéndoles también mantener actualmente el sistema con un mínimo esfuerzo, incorporar requisitos de Continuidad de Negocio y tener una Visión Global de su seguridad gracias a los cuadros de mando con indicadores.



¿Cómo les ayudó SandaS GRC a cumplir su objetivo?:
  • Modelando fácilmente el negocio gracias a su mecanismo de drag & drop incorporado en el módulo de arquitectura empresarial, basado en los estándares de referencia TOGAF9.1 y Archimate. Con SandaS GRC también podríamos realizar una importación de los activos en el caso de que la organización los tuviese previamente inventariados.
  • Centralizando todos los elementos comunes y el control de la progresión de todas las Delegaciones. SandaS GRC dispone de un módulo de gestión de proyectos Kanban incorporado en la propia plataforma que permite dar soporte a todos los procesos de una forma fácil, centralizada y muy visual.
  • Proporcionando una visión unificada del riesgo, teniendo además la certeza de que se cumplen los estándares internacionales gracias a su motor de riesgo basado en ISO 31000 con pleno soporte a marcos como ISO 27005, NIST SP 800-30 o COBIT 5 for Risk.
  • Mediante el uso de las guías y asistentes que ayudan al cumplimiento de todos los requisitos de cada uno de los marcos normativos soportados.

Para más información: 

Apps en Google Play que instalan un servidor HTTP como backdoor en tu Android

jueves, 5 de noviembre de 2015

Trend Micro ha descubierto un problema muy intereasnte con un SDK llamado Moplus que, literalmente, funciona como un backdoor para dispositivos Android. Los problemas son que este SDK pertenece a Baidu (el buscador Chino más importante); que se usa no solo en sus apps sino en las de terceros; y que algunas de las apps afectadas están en estos momentos en Google Play, con millones de descargas. Encontrar dispositivos vulnerables es tan sencillo como escanear una red y enviar comandos HTTP. Además de la investigación de Trend Micro, hemos descubierto otras apps en Google Play y algunas curiosidades.

El SDK se llama Moplus. Además de sus "funcionalidades oficiales", establece un servidor HTTP local (el conocido nanoHttpd), que escucha en diferentes puertos, depende de la app y la versión del SDK (probablemente el puerto 6259). Si nos conectamos a ese puerto, no se sirve ningún contenido  (documentRoot apunta a data/data/apkName\files\local_http_server)… pero permite a un atacante enviar peticiones POST con comandos.

Definiendo el puerto donde escuchará el servidor
Y eso es todo. Cualquier atacante podría enviar comandos al puerto a través de peticiones HTTP POST sin autenticación. Una de las versiones más débiles que hemos visto es utilizar la cabecera "remote-addr" en 127.0.0.1 como método único de validación. Otros parece que necesitan que el referer case con esta expresión regular:

^http[s]?:\\/\\/[^\\/]+(\\.baidu\\.com|\\.hao123\\.com|\\.hiapk\\.com|\\.91\\.com)(:\\d+)?(\\/.*|)$";

Si funciona, ejecutará las órdenes y devolverá un JSON con la respuesta (siempre y cuando los permisos en la app lo permitan, cosa que la mayoría de las que hemos visto hacen).

¿Qué comandos soporta?

Quedan muy claros observando esta pieza de código:

Código con los comandos aceptados
Permite la descarga de ficheros, y la subida de cualquier fichero también. Devuelve la lista de apps instalada, insertar un nuevo contacto... en dispositivos rooteados, incluso se permitiría la instalación de un apk diferente de forma silenciosa.

Código para añadir contactos de forma remota
Parte del código para subir ficheros
Trend Micro contactó con Baidu, y este creó una nueva versión que elimina los comandos potencialmente peligrosos de la lista. También están reemplazando de los markets las apps afectadas.
 
¿Qué hemos encontrado?

Trend Micro habla de miles de apps afectadas. Con Tacyt, encontramos varias usando el SDK y todavía disponibles en Google Play. Algunas con hasta 5 millones de descargas y no relacionadas con Baidu.

Una variante del código con los comandos que se admiten
Estos son algunos de los packageNames vistos en Google Play (aunque habrá más, seguro) y que complementan a los ya publicados por Trend Micro (hasta ahora):
  • com.qiyi.video.market
  • com.nd.android.launcher91
  • com.ivodani.comicsisland.activity
  • com.qyer.android.jinnang
  • com.pad.comicsisland.activity
  • com.cubic.choosecar
No hemos podido confirmar que los comandos remotos funcionen igual en todas ellas. Lo que es seguro es que contienen el código del backdoor, pero puede que necesiten algún cambio en la fórmula de comunicación para usar esta puerta trasera. Deberían ser revisadas individualmente para estar seguros (o incluso si es que funcionan).

Una de las más sencillas de comprobar, es la popular Baidu Maps. No esta, sino su versión previa 8.7.0.

En la imagen, usamos este plugin de Chrome para inyectar comandos POST. El resultado, (insertar un contacto de forma remota) se muestra también en la figura. Como se puede ver, el icono de Baidu Maps está en la barra de notificación del teléfono.

Añadiendo contactos con un comando POST
Merece la pena mencionar que, muchas de las apks avistadas con el código, confían en dos ficheros clases.dex diferentes. Esto significa que, una vez ejecutado, la app podría cargar classes2.dex (o cualquier nombre) desde su código "principal". Habitualmente es este segundo fichero .dex el que contiene el código del backdoor.


Una app que contiene un segundo fichero "dex
Esto no es nuevo. Mucho malware/adware in Google Play usa este truco para intentar eludir las detecciones. Puede que descarguen el .dex de otro sitio, o lo lleven dentro, pero resulta interesante comprobar que las capacidades de este SDK Moplus suelan encontrarse en este segundo fichero .dex.

Además, uno de los puntos más interesantes es que Mobo Launcher, relacionado con el conocido market Mobogenie, contiene el código del backdoor también, y este sí es popular incluso fuera de China. Está en Google Play desde finales de 2014. De hecho, es la app más antigua en el market principal con esta versión del backdoor, hasta donde sabemos.

Algunas de las apps detectadas en Tacyt
Aunque no hemos podido hacerlo funcionar y enviarle un comando que no devuelva un error (todavía no estamos seguros de qué falla) el servidor nanoHttp se levanta, y el código para recibir comandos se encuentra presente en la app... por lo que hay razones más que suficientes para no fiarse de esta app. Un análisis más en profundidad podría permitir saber cómo funciona y, a un atacante, aprovechar el fallo.

Por supuesto, existen otros APKs fuera de Google Play (aptoide, mobogenie...) con este backdoor también.

La parte buena es que la mayoría de estos programas ya son detectados por varios motores, no solo por esta razón, pero detectados, en todo caso.

Sergio de los Santos
ssantos@11paths.com
@ssantosv

Juan Manuel Tirado
juanmanuel.tirado@11paths.com