Telefónica y Data Warden ofrecen conjuntamente servicios de ciberseguridad avanzada

martes, 31 de enero de 2017


Ciudad de México, 31 de enero, 2017. El World Economic Forum, vuelve a incluir este año 2017 los ciberataques y las fugas de información en su informe anual sobre los 5 principales riesgos globales, lo que pone de relieve la probabilidad e impacto que pueden tener estos ataques en nuestra economía y en nuestra vida diaria.

México ocupa el segundo lugar de América Latina en número de ciberdelitos, sólo por debajo de Brasil, informó Mariano Moral, Vicepresidente B2B de Telefónica México durante la firma del convenio de colaboración que acordó la operadora de telecomunicaciones y Data Warden para brindar servicios de ciberseguridad a diferentes empresas.

El directivo explicó que las empresas son una de las principales víctimas de estos delitos y tardan en promedio 6 meses en reestructurar su información. Tan sólo en el rubro de pymes, una de cada cinco empresas sufre algún tipo de ciberataque al año, de las cuales más de la mitad se va a quiebra después de 6 meses del ilícito.

Mediante el acuerdo de Telefónica y Data Warden, que integrará el resguardo de la información de los corporativos, se contempla la fusión y ampliación de los servicios de ciberseguridad y seguridad gestionada que cada una de las empresas comercializaba por separado y que a partir de ahora ofrecerán de forma conjunta a sus clientes.

Como parte de este convenio, ambas empresas lanzarán de forma conjunta el sistema ZoneWard, un servicio gestionado para la automatización y control de los servicios básicos de red y seguridad contra filtración de información. ZoneWard se despliega en la nube de Telefónica y permite gestionar de forma centralizada los servicios que se entregan a los clientes a través de los recursos del Centro de Operaciones de Seguridad de Telefónica México (SOC).

Nuestros Centros de Operaciones de Seguridad (SOC) son centros de excelencia que reúnen plataformas innovadoras, procesos operativos y profesionales de la seguridad que ofrece protección en tiempo real frente a amenazas nuevas y conocidas, permitiendo a las organizaciones reducir los riesgos, reforzar su posición de seguridad y aumentar la flexibilidad empresarial.

“Con estas acciones buscamos reforzar nuestra posición en el mercado con un socio que complementa nuestras capacidades en el área de seguridad, rubro en el que estamos apostando a nivel global y local”, puntualizó el Vicepresidente de B2B de Telefónica México. Agregó que “el objetivo es resolver las necesidades de las empresas en materia de seguridad informática, sin importar si son pequeñas, medianas o grandes”. 

Por su parte Jesús Navarro, CEO de Data Warden, destacó “estamos encantados con la alianza ya que nos permite sumar capacidades para ofrecer un servicio completo a nuestros clientes que les ayuda a proteger y dar continuidad a su negocio.  Esta alianza coloca a ambas empresas en una posición estratégica sumamente competitiva, con una oferta ágil e innovadora que combina el portafolio de servicios gestionados y capacidades globales de Telefónica, con la amplia experiencia y capacidad en servicios especializados de seguridad informática que posee Data Warden.”.

Con esta alianza, Data Warden se une al programa global de alianzas en ciberseguridad de Telefónica que cuenta con los principales fabricantes y empresas de ciberseguridad a nivel mundial para proteger las infraestructuras y la información de nuestros clientes.

Pedro Pablo Pérez, CEO de ElevenPaths, la unidad de Ciberseguridad de Telefónica, señaló que la compañía aportaría a la alianza todas las capacidades de inteligencia digital desarrolladas en los últimos tiempos. “La alianza provee un vehículo de colaboración para compartir información crítica y mejorar la identificación de las amenazas más avanzadas”, dijo.

Una investigación de ElevenPaths junto con Kaspersky destapa varias apps maliciosas en Google Play

lunes, 30 de enero de 2017

Kasperksy ha hecho pública una investigación conjunta realizada por ElevenPaths y su equipo GReAT (Global Research and Analysis Team) en la que se desvela cómo están operando las últimas campañas de apps fraudulentas en Google Play que suscriben a usuarios a números de tarificación especial. Se analiza qué tipo de aplicación utilizan para llamar la atención de las potenciales víctimas, qué tácticas de difusión han utilizado, el código e incluso la infraestructura y paneles de gestión usados.


Hace algunos años era bastante sencillo subir un "dialer" (o algún tipo similar de aplicación maliciosa) a Google Play, pero ahora subir estas aplicaciones es cada vez más difícil ya que se han mejorado los mecanismos de detección. Esto ha provocado que muchos grupos se centren en otros repositorios de aplicaciones no oficiales aunque, esto no quiere decir que los repositorios oficiales estén exentos de estas amenazas. De hecho, no hace tanto, un grupo español consiguió subir con éxito una aplicación no oficial del conocido programa de televisión "Gran Hermano".


Su éxito de aparecer en Google Play se basa en usar un viejo truco. En primer lugar, subieron una versión limpia que por supuesto pasó los controles de seguridad de Google Play. Algunos días después, actualizaron la aplicación añadiendo nuevas funcionalidades, entre ellas la suscripción a servicios de pago. Este truco es extremadamente simple pero ha resultado ser muy provechoso, ya que la aplicación permaneció alrededor de dos meses disponible en Google Play (desde mediados de Septiembre hasta mediados de Noviembre de 2015).

Esta app utilizaba técnicas interesantes y novedosas para gestionar la suscripción fraudulenta y monetizar la infección de víctimas.
 
Este grupo de "programadores" también han intentado algo similar empleando otras fuentes de difusión además de Google Play. Uno de los servicios web usados por esta aplicación exponía un panel de control que mostraba información sobre los "usuarios". En septiembre de 2016, volvieron a intentarlo en Google Play de nuevo, siempre con el reclamo del popular programa de televisión.


Este grupo ha tenido bastante éxito subiendo aplicaciones a Google Play, utilizando un tema atractivo como puede ser el programa de televisión "Gran Hermano". España y Polonia han sido dos países tradicionalmente objetivo de este tipo de aplicaciones. Sin embargo, no habíamos visto en estos últimos años ningún grupo que fuera capaz de subir aplicaciones en repositorios legítimos con tanta facilidad. Este tipo de aplicaciones cuyas funcionalidades se encuentran muy cerca de la frontera entre lo que se consideraría un negocio legítimo y una actividad fraudulenta ponen a prueba a los sistemas de detección automática. Esto ocasiona que dichas aplicaciones lleguen a estar disponibles en Google Play, aunque acaben por ser retiradas algún tiempo más tarde.



Todos los detalles técnicos en las entradas en inglés y castellano:

* https://securelist.lat/blog/moviles/84533/expensive-free-apps/
* https://securelist.com/blog/mobile/77083/expensive-free-apps/

Vuelve ElevenPaths Talks: la serie de webinars sobre ciberseguridad

viernes, 27 de enero de 2017



A partir del próximo jueves 23 de de Febrero ElevenPaths lanzamos la Tercera Temporada de la serie de webinars sobre temáticas de interés en el mundo de la ciberseguridad. Las sesiones serán quincenales y el horario escogido serán las 15.30 (GMT+1). Los Talks tendrán una duración de unos 50 minutos, divididos entre 10 minutos de comentarios sobre noticias interesantes  relacionadas con la temática del webcast30 minutos de debate entre dos de nuestros CSAs (Chief Security Ambassadors) y un invitado especial y 10 minutos sobre consejos de herramientas de seguridad. Todas las sesiones se realizarán en castellano a través de la plataforma GotoWebinar, en la que podrás comentar y preguntar en directo a nuestros expertos. Posteriormente se publicarán en nuestro canal de Youtube



No pierdas la ocasión de saber todo sobre el mundo de la seguridad informática y de lo que está por venir de la mano de nuestros CSAs. A continuación, os dejamos el listado por fechas de los webinars y el tema que será expuesto:
  • 23 de febrero  de 2017. La Guerra Contra el Ransomware por Claudio Caracciolo y Pablo San Emeterio.
  • 9 de marzo de 2017. La Red Bajo Ataque por Arsene Laurent y Claudio Caracciolo.
  • 23 de marzo de 2017. Data Access Control y De-Duplication en Cloud Computing por Diego Espitia y Jorge Rivera.
  • 6 de abril de 2017. Quebrando Aplicaciones por Pablo San Emeterio y Diego Espitia.
  • 20 de abril de 2017. Jugando con Apps de Mensajería por Gabriel Bergel y Claudio Caracciolo.
  • 11 de mayo de 2017. Asegurando los Host (modo paranoico) por Arsene Laurent y Gabriel Bergel.
  • 25 de mayo de 2017. Criptografía, Criptomoneda y Otras hierbas por Jorge Rivera y Rames Sarwat.
  • 8 de junio de 2017. ¿Es Posible Prevenir el Fraude? por Diego Espitia y Rames Sarwat.
  • 22 de junio de 2017. A la Pesca de las Víctimas por Gabriel Bergel y Arsene Laurent.
  • 6 de julio de 2017. PinPay y Seguridad en Micro Pagos por Jorge Rivera y Pablo San Emeterio.
  • 20 de julio de 2017. Diferencias entre NOC, SOC y CyberSOC por Pablo San Emeterio y Gabriel Bergel.
  • 10 de agosto de 2017. Seguridad Defensiva vs Seguridad Ofensiva por Claudio Caracciolo y Jorge Rivera.
  • 24 de agosto de 2017. Inteligencia Artificial y Machine Learning por Diego Espitia y Rames Sarwat.
  • 7 de septiembre de 2017. Asegurando Sistemas Industriales por Gabriel Bergel y Arsene Laurent.
  • 21 de septiembre de 2017. Fog / Edge / Cloudlet Computing por Arsene Laurent y Claudio Caracciolo.
  • 12 de octubre de 2017. Gestión de Monitoreo y Alerta por Pablo San Emeterio y Diego Espitia.
  • 26 de octubre de 2017. La Inevitable Evolución de la Seguridad Gestionada por Jorge Rivera y Rames Sarwat.
  • 9 de noviembre de 2017. La Cara Oculta de la Esteganografía por Pablo San Emeterio y Arsene Laurent.
  • 23 de noviembre de 2017. Seguridad en Sistemas de Telefonía Móvil por Claudio Caracciolo y Rames Sarwat.
  • 7 de diciembre de 2017. Open Data… mucho para ver por Gabriel Bergel y Diego Espitia.
  • 21 de diciembre de 2017. Las Fuerzas de Seguridad y el CiberCrimen por Jorge Rivera y Arsene Laurent.
Os esperamos para que nuestros CSA os enseñen lo más novedoso en el mundo de la tecnología y ciberseguridad. Recuerda que tienes una cita el próximo 23 de febrero en horario de 15.30 (GMT+1).



¿Te perdiste la primera y segunda temporada de ElevenPaths Talks? 

Los webinars que realizamos anteriormente ElevenPaths Talks tuvieron una gran acogida y para que no os perdáis ninguno de ellos los tenéis todos disponibles en Youtube en la Playlist de ElevenPaths Talks Primera Temporada y ElevenPaths Talks Segunda Temporada.

Tu aportación es muy valiosa y nos ayuda a entender tus necesidades, conocer mejor tus preocupaciones, comentarios, opiniones y curiosidades. Habla con nuestros expertos en la Comunidad de ElevenPaths. 


Más información próximamente en:
talks.elevenpaths.com

Inteligencia colectiva, prospectiva y su aplicación en la ciberseguridad

jueves, 26 de enero de 2017


Una amplia mayoría de los lectores de este blog así como los seguidores de otros canales de ElevenPaths son perfiles con cierto background técnico y con inquietud por estar al día sobre la evolución de la ciberseguridad. ¿Creíais que todo este conocimiento que poseéis lo íbamos a dejar pasar por alto?

Corroboramos diariamente que los humanos no estamos capacitados para decidir perfectamente. Ni tampoco para determinar exactamente qué es lo va a pasar sobre un determinado asunto a corto plazo y, aún menos, a largo. De hecho, el científico Francis Galton, en una de sus investigaciones, solicitó a los asistentes a una feria de ganado que estimasen el peso de una res. Entre los participantes había expertos ganaderos, carniceros y público en general. Pero, para su sorpresa, el criterio de la multitud resultó ser prácticamente perfecto acertando, con muy poca desviación, el peso real de la res.

Un análisis eficiente que cuente con las fuentes de información adecuadas puede ayudarnos a entender los orígenes de los problemas. También nos permite evaluar aquellas cuestiones más relevantes para la seguridad en el futuro. Esto es conocido como prospectiva. Atendiendo a los estudios de Galton, los seres humanos anticipamos imperfectamente y sufrimos fracasos notables como resultado. Aunque nos duela, debemos ser conscientes de que el conocimiento perfecto es inalcanzable y os hemos querido preguntar a través de nuestra cuenta de Twitter sobre cuál será la evolución más probable de los acontecimientos más notables de 2016.

Estimaciones de nuestra audiencia

La guerra mediática entre Fuerzas y Cuerpos de Seguridad y empresas tecnológicas ha destapado en 2016 numerosos problemas en cuanto a compartición de información. Sin embargo, según la opinión de nuestra audiencia, parece que continuará la misma tónica en 2017 debido a que no se tiene mucha confianza en que los fabricantes lleguen a poner las medidas suficientes. Asimismo tampoco se tiene muy claro que vayan a poner las medidas suficientes para evitar ataques como los perpetrados contra la empresa Dyn.

Figura 1. Encuesta sobre compartición de información y medidas de seguridad en fabricantes.

En 2013 se hizo pública la fuga de información de Adobe. No debió ser suficiente, ya que el año 2016 ha sido el de las fugas de información afectando principalmente al sector sanitario, seguido por el del entretenimiento, las redes sociales y el gubernamental. Sin ninguna duda, nuestro público opina que seguiremos utilizando las contraseñas como método de autenticación. De la misma manera, parece que continuará la tendencia respecto al crecimiento del número de familias de este tipo de malware.

Figura 2. Encuesta sobre brechas de seguridad y ransomware.
Por otro lado, las estadísticas muestran que se utilizará la rivalidad entre países para ampliar las jurisdicciones y así realizar sus investigaciones pudiendo hackear cualquier equipo del mundo, independientemente de su ubicación. Asimismo nuestro público opina que la Administración española requiere una modificación de la ley para adquirir el talento que necesitan en ciberseguridad. Y, por último, se tiene muy claro que en 2017 los grupos terroristas aumenten la sofisticación de sus ataques ya que es muy fácil acceder a dichas capacidades.


Figura 3. Encuesta sobre nuevas jurisdicciones y captación del talento.


Figura 4. Encuesta sobre adaptación de capacidades por parte de grupos terroristas.
La mayoría de este tipo de proyectos prospectivos están enfocados a determinar con una mayor precisión la evolución de los principales acontecimientos mundiales. De hecho, la Comisión Europea invirtió en 2015 cierto presupuesto para desarrollar herramientas de inteligencia colectiva y ponerlas a disposición de todo el mundo a través de Github. En los próximos post sobre inteligencia colectiva veremos cómo desplegar estas herramientas y si podrían tener su propia aplicación en el mundo de la ciberseguridad.

Yaiza Rubio
Intelligence Analyst at ElevenPaths


Migración de Google Authenticator a Latch en Wordpress

martes, 24 de enero de 2017

Tras la implementación de la nueva función TOTP en Latch, podremos utilizar la aplicación para proteger muchas de nuestras cuentas como se demostró anteriormente con Gmail, Outlook y Amazon. 

Hoy os enseñaremos cómo realizar una migración de Google Authenticator a Latch en Wordpress. Para ello tienes que tener la última aplicación de Latch Android o Latch para iPhone (incluido Latch para Apple Watch). Para poder aprovechar esta alternativa tendremos que disponer de un plugin que permita el uso de TOTP como doble factor de autenticación en Wordpress.

En el siguiente vídeo puedes ver cómo funciona.


Preparación de Wordpress y su plugin

En nuestro caso utilizaremos el plugin Two Factor, ya que este plugin guarda nuestra “private key” en la base de datos sin utilizar ningún cifrado. Para instalarlo iremos al apartado “plugins” de nuestra cuenta y seleccionaremos “Añadir nuevo”, usaremos el buscador para encontrar el plugin y lo instalaremos y activaremos.


Una vez tengamos el plugin instalado iremos a “Tu cuenta” en el menú de usuarios, bajaremos hasta encontrar el apartado “Two-Factor options”. A continuación seleccionaremos las segunda opción y pulsaremos sobre “show options” al instante aparecerá un código QR y debajo de él una clave privada (en la cual se especifica que es la clave utilizada por Google Authenticator y Authy), esta clave será la que hará posible la migración del servicio, sin embargo para realizar esta migración obtendremos directamente la seed desde la base de datos de Wordpress. Una vez hayamos instalado el plugin abriremos nuestro terminal e iniciaremos sesión en nuestro servidor mysql, lo siguiente que haremos será entrar en Wordpress y acceder a su base de datos , a continuación buscaremos el apartado _two_factor_totp_key, donde estará nuestra seed para generar el servicio en nuestra aplicación de Latch.




Migración a Latch Cloud TOTP

Arrancamos nuestra app de Latch con la última versión, donde disponemos de la funcionalidad Cloud TOTP. Nos vamos a añadir un nuevo servicio con Latch y veremos dos opciones como son 'Parear con Latch' (funcionalidad clásica) y 'Proteger con Cloud TOTP'. Debemos pulsar esta última.



Al pulsar sobre 'Proteger con Cloud TOTP', Latch nos dará las opciones ‘Escanear código QR’ e ‘Introducir manualmente’, seleccionaremos la segunda. A continuación se nos muestran en pantalla tres campos a rellenar, ‘nombre del servicio’, ‘nombre de la cuenta’ y ‘clave’. Introduciremos la private key obtenida anteriormente de la base de datos, pulsaremos sobre añadir servicio.


Para terminar con esta parte del proceso generaremos un TOTP y lo introduciremos a continuación del código QR y pulsaremos en guardar los cambios Hecho esto podremos usar Latch para iniciar sesión.

Iniciando sesión con Latch Cloud TOTP en Wordpress

Ahora, nos dirigimos al login de Wordpress e introducimos nuestro usuario y contraseña. Una vez validado esto se nos solicitará información sobre el TOTP, tal y como se puede ver en la imagen. El segundo factor de autenticación está correctamente configurado en la cuenta de Wordpress y podremos utilizar nuestro Latch.


En nuestra aplicación de Latch debemos disponer de una nueva app que tenga el mismo nombre del servicio (en este caso localhost/wordpress) y generando tokens para la cuenta de Wordpress que hayamos integrado. Hay un botón, en dicha fila, con la palabra 'Pin', la cual debemos pulsar para que nos genere un TOTP, que será válido durante un breve período de tiempo (30 segundos), tal y como nos indica el pequeño reloj que aparece junto al token.



No dudéis en configurar los segundos factores de autenticación en todas las cuentas de los servicios que utilicéis, siempre que lo soporten. Hoy en día fortalecer tu seguridad en el uso de las identidades digitales es muy importante. Latch Cloud TOTP te ofrece diversas posibilidades para proteger tus servicios y tus cuentas de una forma más sencilla y fiable.

Sergio Sancho
ElevenPaths

Nuevo Informe: Los errores más comunes a la hora de implementar HPKP, HSTS y condiciones de preload

lunes, 23 de enero de 2017

Hemos recopilado y visitado dos fuentes diferentes de dominios y páginas web, el top de Alexa de un millón de dominios y Shodan. Los resultados proceden de búsquedas realizadas en noviembre de 2016. Dentro de ese conjunto de dominios, hemos acotado la búsqueda para determinar aquellos que usan HSTS o HPKP sobre HTTPS, e incluso aquellos que combinan diferentes combinaciones en las cabeceras. Tratando de determinar no solo la cantidad sino la "calidad" de la implementación. Solo el 0,02% de los dominios más populares implementan actualmente HPKP de la forma más correcta, y solo el 0,74% hacen lo propio con HSTS. Incluso Whatsapp.com o Facebook.com comenten errores en sus implementaciones.

A continuación mostramos un extracto del informe que puede encontrarse aquí.

Número de pins

A la hora de implementar HPKP es importante respetar el número de pins requerido. A pesar de que los valores recomendados establecen usar entre 3 y 4 pins, algunos dominios usan desde un único pin (quebrantando la RFC) hasta 17, que resulta una clara irregularidad que reduce la eficiencia. Del top de un millón de dominios de Alexa, 282 de un total de 450 usan 2 o 3 pins, lo cual es correcto. Sin embargo 89 (19,8%) dominios usan uno o ninguno, lo que resulta inútil desde el punto de vista del navegador porque lo ignorará.

Número de pins del top de un millón de dominios de Alexa que usan HPKP.

Qué certificado escoger para realizar los pins

A la hora de usar HPKP, la elección del certificado apropiado es una decisión importante. Los administradores pueden usar cualquier pin en la cadena del certificado (root, intermediate o leaf) pero esta decisión afectará directamente a la usabilidad y también al grado de seguridad tanto desde su punto de vista como del usuario. Debe alcanzarse también un balance y equilibrio entre seguridad y mantenimiento a la hora de efectuar el pinning.
  • Pinning del certificado raíz (root) ofrece menos seguridad, pero a su vez es el mecanismo más sencillo para el administrador a la hora de lidiar con HPKP. Esto significa que, mientras que el proveedor no cambie su CA, no se requerirán cambios adicionales, por tanto, será necesario un menor mantenimiento. Aunque, si un atacante obtiene un certificado falso de la misma CA, el navegador no detectaría la diferencia ya que el root sigue siendo el mismo.
  • Pinning del certificado intermedio (intermediate) es la mejor opción, probablemente. El atacante debería obtener un certificado de la misma CA subordinada (sub CA) a la raíz para lograr un ataque “perfecto”. El administrador, por otro lado, puede cambiar su certificado hoja (leaf) mientras que proceda de la misma entidad subordinada sin cambio adicional a la hora de modificar los pins.
  • Pinning del certificado hoja (leaf) es la opción más segura, pero también la más arriesgada. Si el certificado expira por alguna razón o si cambia (concretamente la clave pública), incluso si ha sido emitido por la misma CA o una subordinada, el administrador tiene que modificar los pins o usar el de respaldo. Por otro lado, un atacante no podría crear un certificado válido (salvo que la clave privada haya sido robada) si desea diseñar un escenario “perfecto” para un ataque MiTM.
Por tanto, hemos comprobado sobre qué certificados realizan los administradores el pinning, y estos son los resultados. La mayoría de ellos (73,65%) usan el certificado intermedio.
Pinning de certificados en la cadena de confianza del top de un millón de dominios de Alexa usando HPKP.


Reutilización de pins

La reutilización de pins entre los distintos dominios no es una práctica incorrecta. Considerando que la mayoría de los pins usados en HPKP son intermedios y se han fijado sobre sub CAs, es absolutamente normal compartir algunos pins entre los dominios. Pero este proceso supone cierto riesgo. Desde el punto de vista del atacante, conociendo las sub CAs o incluso las CAs raíz que poseen pins, esto podría permitirle planificar un APT específico para ese dominio. Por ejemplo, si un dominio emite su certificado intermedio con una determinada sub CA y realiza el pinning de este certificado, un atacante podría obtener un certificado hoja “rogue” para ese dominio emitido por la misma sub CA, produciendo un escenario MiTM perfecto, ya que el navegador no mostrará ningún mensaje de advertencia. Por tanto, desde el punto de vista del atacante, si puede determinar si el pinning del dominio se ha realizado sobre el certificado intermedio, y además, cual es la sub CA concreta, esto permitiría conocer con mucha mayor precisión el objetivo a alcanzar. Además, si el atacante quiere maximizar su alcance, éste intentaría obtener un certificado “rogue” firmado por esta sub CA más “popular”.

El siguiente mapa representa qué certificados (y sus pines) están pineados a más dominios. Esta lista solo muestra los primeros 25. Ya que el protocolo permite saber solo el pin y no el propio certificado, es necesario realizar un "unhash" para conocerlo. Hemos recogido varios millones de certificados y hemos calculado su hash para compararlos con los pines asociados a los dominios. Los resultados muestran cómo el certificado intermedio de Comodo es el certificado más fijado (klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=). Éste posee pins a 40 dominios diferentes de Alexa y Shodan.
Mapa de reutilización de pins. Haz clic para aumentar.

Precarga

Para evitar el problema del TOFU (Trust on first use), se introdujo el mecanismo de “precarga" (preloading). Este trabajo de precarga funciona como una CA raíz incrustada en el navegador. Básicamente es una lista de dominios dispuesta a ser accesible con HSTS desde el primer momento. Esta lista está mantenida por Google y para pertenecer a ella hay que cumplir con ciertas condiciones como son:
  • Tener una cadena de certificados válida y redirigir de HTTP a HTTPS en el mismo host (por supuesto).
  • Servir todos los subdominios usando HTTPS. WWW es obligatorio si existe en el servidor DNS.
  • Servir la cabecera HSTS vía HTTPS con estas propiedades:
    • max-age de al menos 18 semanas (10886400 segundos).
    • includeSubDomains debe ser incluida.
    • preload debe ser incluida.
    • En caso de proporcionar una redirección adicional del sitio HTTPS, se debe usar obligatoriamente la cabecera HSTS (en vez de la que posea la página a la que redirige).
Si todas esas condiciones se cumplen, el propietario del dominio podría solicitar la inclusión en la lista de Google aquí: htstpreload.appspot.com y el dominio podrá eventualmente ser incluido en ella. Esta página web permite también comprobar si un dominio satisface o no esas condiciones. Existen un total de 18197 dominios precargados en la lista Chromium (compartida con Firefox). A fecha de diciembre de 2016, solo 2056 dominios del top de un millón de Alexa están en esa lista.
Estado de la precarga del top de un millón de dominios de Alexa

Funcionalmente, htstpreload.appspot.com proporciona una API pública que permite comprobar las “razones” de por qué un dominio específico debe ser precargado o no. Hemos contrastado el top de un millón de dominios en Alexa con dicha API y la lista de dominios con precarga habilitada, para saber si estos dominios precargados cumplen o no con las condiciones. Para ejecutar este proceso cada dominio se visita en tiempo real y se comprueban los posibles errores. Resulta muy interesante comprobar que, de esos 2056 dominios precargados del top de Alexa, 662 contienen errores, que, estrictamente hablando, no deberían ser precargados. Incluso hemos detectado que, 67 de esos 2056 precargados que están incluidos en la lista, no contienen ni siquiera la directiva de precarga en la cabecera, lo cual viola una de las condiciones de pertenencia. Whatsapp.com y Facebook.com son ejemplos de dominios que no cumplen las condiciones de precarga, pero pertenecen a esta lista.

Muestra del error a la hora de comprobar Facebook contra la API del sistema de preload



Conclusiones

Aunque los protocolos HSTS y HPKP supuestamente deben proveer una capa adicional de seguridad a las comunicaciones HTTPS, su implementación no se ha generalizado. A nivel de servidor, muchos de los dominios más relevantes de Internet ni siquiera los implementan. Además, entre el reducido número de dominios que lo usan, existe un número significante con errores de implementación, incluso pasando por alto las recomendaciones de las respectivas RFCs. Esta situación muestra tanto el bajo índice de adopción de éstos como, de alguna manera, la malinterpretación de cómo aprovechar completamente las ventajas que proporcionan estos protocolos. Algunas de las figuras más interesantes de nuestro informe son:
  • De Alexa, hemos recopilado 632648 dominios HTTPS, y 901958 dominios HTTP. Hemos recogido 30886979 dominios HTTPS (puerto 443) y 45330802 dominios HTTP (puerto 80). Un total de 76217781) de Shodan.
  • Solo el 1,9% de los dominios en Shodan usan HSTS correctamente sobre HTTPS, mientras que solo un 5,35% de Alexa lo hacen.
  • 4717 (apenas un 0.74%) del top de un millón de dominios de Alexa usando HTTPS (632648) implementan HSTS de la forma más correcta.
  • 175 del top de un millón de dominios de Alexa (apenas el 0,02%) usando HTTPS (632648) implementan HPKP de la mejor forma posible.
  • 20% del top de dominios de Alexa usando HPKP sobre HTTPS usan uno o ningún pin, que resulta inútil desde el punto de vista del navegador ya que lo ignorará. La mayoría de ellos (un 73,65%) usan el certificado intermedio para el pinning.
  • 17% de los dominios de Alexa que implementan HPKP usan un valor max-age erróneo o que se ignorará.
  • El pin más usado (un certificado de Comodo) fija 40 dominios diferentes de Alexa y Shodan.
  • Hay un total de 18197 dominios precargados en la lista de Chromium (compartida con Firefox). A fecha de diciembre de 2016, solo 2056 dominios del top de un millón de Alexa están es esa lista.
  • De esos 2056 dominios precargados en el top de Alexa, 662 contienen algunos errores al comprobarlos contra la API oficial de precarga, por tanto, estrictamente hablando, no deberían ser precargados. Whatsapp.com y Facebook.com son ejemplos de dominios que no cumplen las condiciones de precarga obligatorias, pero pertenecen a dicha lista.
Aquí puede acceder al informe completo (en inglés).





Un hacker en Corea IV

jueves, 19 de enero de 2017

El Paralelo 38 Norte, Joint Security Area, Panmunjom o DMZ son términos con los que la mayoría de las personas no están familiarizadas, pero sin embargo era uno de los motivos principales de mi visita a Corea del Sur y una de las experiencias más extrañas que he tenido en mi vida, incluso con la nieve que marcó mi llegada al lugar.

Ubicada solo a 50 Km de Seúl, la DMZ o Zona Desmilitarizada es una franja de aproximadamente 240 km de largo por 4 km de ancho que divide la Península de Corea, separando Corea del Norte de Corea del Sur. Recibe su nombre debido a que es una zona sin actividad militar activa y (casi) sin civiles. Los 240 km corresponden al ancho de la Península y los 4 km corresponden a que, durante el armisticio de Paz, cada país debió retraer sus tropas 2 km del frente de batalla, creando una barrera neutral de 4 kilómetros de ancho sobre el paralelo 38.

El Paralelo de Corea fue el antiguo límite entre EEUU y la URSS durante la Segunda Guerra Mundial, antes de la formación de la República Democrática de Corea (Norte) y la República de Corea (Sur) en 1948, y quizás una de las zonas más calientes durante la guerra fría. Actualmente, la parte sur de la DMZ está administrada por Estados Unidos en representación de la ONU, y la parte norte está administrada por Corea del Norte. Por su parte, Panmunjom (hoy en territorio Norte) es el nombre de la villa donde en 1953 se firmó el armisticio; alberga unas pocas familias herederas de aquellas que fueron testigo de tal acto.

Aunque se considera una zona neutral, cientos de veces se han intentado incursiones militares por encima y por debajo de la DMZ, incluso con escaramuzas que se han cobrado algunas vidas. Actualmente se pueden visitar algunos de los túneles que habrían permitido ataques de infantería liviana. Este también es el motivo por el cual el Rio Han (del que hablé en la primera entrega) se encuentra delimitado con tejido y vallas para detectar cualquier tipo de incursión costera o terrestre, ya que con -20° centígrados, el río se congela y es posible vadearlo a pie. En la “zona turística” de visita pública y en el infaltable shopping se encuentra personal militar de los dos países y todavía existe -a modo de recuerdo indeleble- una línea demarcatoria que, curiosamente pasa por el medio de la sala y la mesa donde se firmó el acuerdo en el punto denominado Joint Security Area (JSA). Para una mejor idea se puede leer y ver el libro y la película homónimos.


De esta historia (muy resumida) viene mi fascinación por la DMZ. ¿Quién diría que cuando configuramos servicios, redes y servidores con DMZ, nos caería toda esa historia encima?

Volviendo al mundo de la seguridad, tradicionalmente los tipos de controles se agrupan en físicos, técnicos/lógicos y administrativos. En la DMZ se los puede ver a todos y los mismos son tangibles:

• Vigilancia física: personal militar, perros y cámaras en todo el perímetro.
• Proceso de autorización (AAA): Identificación, mediante la solicitud repetitiva del pasaporte en distintas zonas; Autenticación, contra una base de datos de acceso al país y solicitud de visita a la Zona; Autorización, permiso expreso para visitar la zona por un par de horas; Accountability, registro de las actividades.
• Identificación de personal, administración de roles y permisos, control de acceso de personal no autorizado.
• Procesos para autorización y otorgamiento de privilegios.
• Rotación de personal y tareas.
Firewall físico de 4 km de ancho: división de zona de confianza de la que no lo es:
Need to Know: privilegio para ver y conocer sólo lo que desean y necesitan mostrarte.
• Menor privilegio: todo lo que no está permitido está denegado. Por ejemplo, no se puede usar cámara fotográfica ni teléfonos móviles en la zona.

Seguramente hay cientos de operaciones de control que se me escapan en este momento, pero las mencionadas sirven de ejemplo para confirmar que todas las actividades que desarrollamos en el mundo de la seguridad de la información tienen su fundamento en el mundo físico y siempre es un buen espejo donde mirar.

Otra provincia de interés en Corea del Sur es Jeju. Ubicada al sur del país, en el estrecho de Corea, es la isla más grande de la península y, desde 2011, es considerada una de las Siete maravillas naturales del mundo por la belleza de sus volcanes y la preservación de la biosfera. Su tamaño, aislamiento natural y cantidad de habitantes hace que sea campo de estudio ideal para (el cultivo de mandarinas exquisitas y) diferentes experimentos tecnológicos que luego son extrapolados en el territorio continental. En Jeju, por ejemplo, nació la empresa del mensajero Kakao Talk -que ya mencioné en otra entrega- y se encuentra el Korean Space Wheater Center, responsable del monitoreo de la actividad solar en oriente, tan importante en la detección de radiación y partículas dañinas para el ser humano y las comunicaciones.

Como mencioné en la segunda parte, Jeju es el campo de experimentación de SmartGrid más importante del mundo. SmartGrid es un sistema “inteligente” (porque ahora todo es inteligente) que permite controlar la generación, distribución y consumo de electricidad. A través del intercambio de datos y de técnicas de Data-Minning permite “conocer” los hábitos del usuario para mejorar su experiencia de consumo, aumentar la eficiencia, disminuir la emisión de dióxido de carbono y evitar el calentamiento global.

La combinación de dispositivos de hardware y software hace necesario también la creación de tecnología de control como Latch, el cual permite la protección de concentradores que se encargan de gestionar los Contadores PLC desde el propio diseño de los dispositivos. Con esto en mente, en la Isla de Jeju se encuentran Korea Electric Power Corporation (KEPCO) y Korea Southern Power (KOSPO) que buscan -mediante distintos acuerdos nacionales e internacionales y la instalación de miles de paneles solares y molinos eólicos- llevar adelante una ciudad verde e inteligente que sirva de base para futuros emplazamientos tecnológicos eficientes en Corea, Japón y China.

Seguimos disfrutando de la isla y ya llegamos al final de nuestro recorrido. Pero antes, ningún amante de la tecnología (friki o techie) puede dejar de visitar un museo de computadoras. Para ello fui a Nexon Computer Museum, inaugurado en 2013 y que tiene más de 6.500 aparatos y miles de programas de “aquellos tiempos”. Este museo hace las delicias de quienes crecimos programando en una TI-99, Commodore 64, MSX (existe una discusión si es de origen japonés o coreano) o Apple I o Apple II (en el museo hay una original reconstruida y firmada por Woz); matamos marcianos en el Galaga; caímos cinco pisos en el Prince of Persia; rompimos e intentamos arreglar un Family Game o tildamos un Pinball.


Finalmente, nos mudamos a Busan, ubicada al Sudeste de la península, es la segunda ciudad del país, después de Seúl y dispone de uno de los puertos más importante del mundo por tonelaje de carga y transporte.

Mi llegada a Busan fue en tren a 300 Km/hora, el mismo que aparece en la película de zombies (recomendada para los amantes del género) “Train to Busan”, traducida por el marketing como “Estación zombie” o “Invasión zombie”. Para compensar el ataque de nostalgia tecnológico del museo, y dejando por una vez la seguridad de la información de lado, mi interés por esta ciudad era turístico, por sus playas y belleza natural.

Con esto me despido de Corea del Sur y también de esta crónica en la cual intenté remarcar las principales observaciones realizadas en un país, donde la tecnología es omnipresente y la seguridad es una necesidad de estado, ya sea por la paranoia heredada de la guerra fría o el estado de alerta permanente en el que viven los países de la zona.

En mis tres meses viviendo en Corea aprendí mucho, pero lo más importante es lo siguiente: pretender que conocemos la solución a problemas que no tenemos (por ejemplo, la ciberguerra) es un gran error. En Internet, debemos comenzar a mirar el mundo como un gran globo sin fronteras que, sin embargo, está dividido por barreras tan fijas y firmes como la DMZ.



Cristian Borghello
ElevenPaths Argentina

Latch Antiransomware: Protege tus archivos de secuestros

miércoles, 18 de enero de 2017

Desde la semana pasada está disponible la herramienta Latch ARW. Los ransomware se han convertido en una amenaza real y molesta que afecta a empresas grandes, PYMES y usuarios domésticos. Una vez que el malware infecta el sistema, cifra tus archivos de manera que, generalmente no puedas descifrarlos, por lo que los pierdes. El malware te solicita un rescate si quieres volver a recuperar tus archivos, en otras palabras, es un secuestro en toda regla.

Nuestra herramienta Latch Antiransomware es una herramienta que añade una capa de autorización en sistemas Windows sobre carpetas “protegidas”. Además de los diferentes permisos que sobre las carpetas ofrece el sistema operativo se añade una capa de autorización con Latch, por lo que, si algún binario malicioso quiere modificar el contenido de la carpeta, por ejemplo, cifrando el archivo, la herramienta comprobará el estado del cerrojo de Latch asociado a la carpeta.

Si una carpeta se encuentra protegida con Latch ARW, cualquier acceso de escritura o borrado será consultado con Latch. De este modo, si el cerrojo está cerrado, ya que nosotros no estamos operando sobre la carpeta, nadie podrá realizar dichas operaciones sobre la carpeta, incluyendo la prohibición para los RansomWare. En el siguiente vídeo os dejamos una demostración de cómo llevar a cabo la instalación de la herramienta en un sistema Windows 8.



Recientemente, ElevenPaths estuvo involucrado en la investigación del ransomware PopCorn, para lograr obtener las claves de descifrado cuando un equipo infecta a otro. Un paso adelante en la lucha contra este tipo de amenazas. A continuación, os dejamos un vídeo del funcionamiento de la herramienta para evitar que te veas afectado por un incidente de ransomware.




No dudes en probar la herramienta y protege tus archivos más preciados. No olvides hacer backup de forma continuada, pero, además, protege las carpetas esenciales de tu equipo para hacer que el ransomware no vuelva a ser una lacra o te quite tus preciados recuerdos o tus ficheros confidenciales.


New Report: Most common errors when implementing HPKP, HSTS and preload conditions

martes, 17 de enero de 2017

We have collected and visited two different sources of domains and webpages, Alexa top million domains, and Shodan. These results come from November 2016 searches. From those domains, we have restricted the search to be able to determine which ones use HSTS or HPKP over HTTP or HTTPS, and even which of them uses different configurations for the headers. We have tried to determine not only the quantity but the "quality" of the implementation. Just 0,02% of most popular domains are implementing HPKP in the best possible way, and just 0,74% are doing so with HSTS. Even Whatsapp.com or Facebook.com have some errors.

We show now some excerpts from the report you cand find here.

Number of pins

When implementing HPKP it is important to respect the number of pins required. Despite the recommended values are using between 3 and 4 pins, some domains use from just one pin (violating the RFC) up to 17, which seems to be an irregularity that reduces the efficiency. Regarding Alexa top million domains, 282 out of 450 domains use 2 or 3 pins, which is correct. 89 (19,8%) use zero or just one, which is useless from the browser standpoint since it will ignore it.

Number of pins offered by top 1 million Alexa domains using HPKP.

Which certificate to pin

When using HPKP, choosing the right certificate to pin may be an important decision. Administrators may use whatever pin in the chain (root, intermediate or leaf) but this decision may impact directly in their usability and security from the administrator standpoint and user security. There is a tradeoff between security and maintenance.
  • Pinning the root offers less security, but an easier way for the administrator to deal with HPKP. This means that, as long as the administrator does not change its CA provider, no additional changes should be done, so less maintenance is required. But, on the other hand, if an attacker gets a fake certificate from the same CA, the browser would not detect the difference, since the root remains the same.
  • Pinning the intermediate certificate is the best choice, maybe. The attacker should get a certificate from the same subCA to make the "perfect" attack. The administrator, on the other hand, may change its leaf certificate as long as it comes from the same subCA with no extra cost of changing pins.
  • Pinning the leaf is the most secure way, but the most "dangerous" as well. If the certificate expires or for whatever reason the certificate changes (more specifically, the public key), even if issued by the same CA or subCA, the administrator has to modify its pins or use the backup one. On the other hand, an attacker may not be able to create a valid certificate (unless the private key is stolen) to create a man in the middle "perfect" scenario.
So we have checked what certificate does administrators pin, and this is what we have found. Most of them (73,65%) use the intermediate certificate to pin.

Pinned certificates in the trust chain for the top million Alexa domains using HPKP.


Pins reuse

Reusing pins among different domains is not an invalid practice at all. Considering that most of the pins used in HPKP are "intermediate" pins mostly from subCAs, it is even absolutely normal to share some pins between domains. But this procedure brings a little risk. Thus, from an attacker standpoint, knowing which subCAs or even CAs are pinned may allow to plan a specific APT for that domain. For example, if a domain issues its intermediate certificates with a specific subCA and pins this intermediate certificate, an attacker that gets a rogue leaf certificate for that domain issued from the same subCA will still have a perfect MiTM situation, since the browser will not show any warning message. Therefore, from the attackers standpoint, if they are able to determine if a domain pins its intermediate certificate, and furthermore, which one is the pinned subCA, it allows him to know better who to target. Additionally, if the attacker wants to maximize its scope, he would try to get a rogue certificate signed by this "popular" subCA.

The following map represents which certificates (and its pins) are pinned with more domains. These are the top 25 most pinned certificates. Since the protocol allows to know just the pin and not the certificate itself, it is necessary to "unhash" the certificate. We have collected several millions of certificates and hashed them to compare it with the pins associated to the domains. The results show how an intermediate certificate from Comodo is the most pinned certificate (klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=). It pins 40 different domains from Alexa and Shodan.

Pins reuse map. Click to enlarge.

Preload

To avoid "Trust on first use" issue, "preload" mechanism was introduced. This preload works as a root CA embedded in the browser. It is basically a list of domains that are willing to be accessed with HSTS securely from the first time. This list is maintained by Google and some conditions have to be satisfied to belong to this list.
  • Have a valid certificate chain and redirect from HTTP to HTTPS in the same host (of course)
  • Serve all subdomains under HTTPS. WWW is mandatory if it exists in DNS server.
  • Serve HSTS header via HTTPS with this properties:
    • max-age is at least 18 weeks (10886400 seconds).
    • includeSubDomains directive must be included.
    • preload directive must be included.
    • If serving an additional redirect from the HTTPS site, it must still use the HSTS header (rather than the page it redirects to).
If all these conditions are satisfied, the domain owner may apply to the list in here: htstpreload.appspot.com and the domain will be eventually included in the list. This webpage allows as well to check if a domain satisfies or not all these conditions. There are a total of 18197 domains preloaded in Chromium list (shared with Firefox). As of December 2016, only 2056 domains from the top 1 million from Alexa are in that list.

Preloading status in Alexa's top million domains

In the background, htstpreload.appspot.com uses a public API providing the reasons why a specific domain may be preloaded or not. We have checked all the top million Alexa domains against this API, to know if preloaded domains do really validate all this conditions to be preloaded. When a domain is checked against this API or preload list, the domain is visited in real time and errors checked. It is interesting to prove that, from those 2056 preloaded domains in top Alexa list, 662 contain some errors, thus, strictly speaking, they should not be preloaded. We have even detected that, 67 out of those 2056 preloaded domains in the list, do not contain the preload directive in the header, which as well violates the condition. Whatsapp.com and Facebook.com are domains that do not keep the mandatory conditions to be preloaded, but they actually are.




Conclusions

Although HSTS and HPKP protocols are intended to provide an additional layer of security to HTTPS communications, their implementation is not widespread. At server level, many of the most relevant Internet domains do not even implement them. Moreover, among the minority of domains that do use them, there exist a significant number of implementation errors, even a disregard of the recommendations of their respective RFCs. This situation shows both low level adoption and, somehow, some misunderstanding about how to take full advantage of these protocols. Some of the most interesting figures are:

  • From Alexa, we have collected 632648 HTTPS domains, and 901958 HTTP domains. We retrieved 30886979 HTTPS (port 443) domains and 45330802 HTTP (port 80) domains (a total of 76217781) from Shodan.
  • Only 1,9% of domains in Shodan use HSTS correctly over HTTPS, while just a 5,35% from the Alexa top million do so.
  • 4717 (roughly a 0.74%) of the top million domains in Alexa using HTTPS (632648) are implementing HSTS in the best possible way.
  • 175 of the top million domains in Alexa (a roughly 0,02%) using HTTPS (632648) are implementing HPKP the best possible way.
  • 20% of top Alexa domains using HPKP over HTTPS use zero or just one pin, which is useless from the browser standpoint since it will ignore it. Most of them (a 73,65%) use the intermediate certificate to pin.
  • 17% of domains in Alexa implementing HPKP are using a wrong or ignored max-age value.
  • The most used pin (a certificate from Comodo) pins 40 different domains from Alexa and Shodan.
  • There are a total of 18197 domains preloaded in Chromium list (shared with Firefox). As of December 2016, only 2056 domains from the top 1 million from Alexa are in that list.
  • From those 2056 preloaded domains in top Alexa list, 662 contain some errors if checked against the official preloading API, so, strictly speaking, they should not be preloaded. Whatsapp and Facebook are among those domains that do not keep the mandatory conditions to be preloaded, but they actually are.
Here is the whole report.




See You at the RSA Conference 2017

lunes, 16 de enero de 2017


The U.S. city of San Francisco is to host once again, as it does every year, one of the most important events worldwide in the field of security, RSA Conference. From 13 to 17 February, the most relevant players within the industry worldwide will gather, and ElevenPaths, Telefónica's cyber security unit, will be there among them of course.

We offer you a pass to the exhibition area absolutely free of charge. To get your ticket you only need to register here using the code: XE7TELFNCA. Deadline for registration February 10th.



We look forward to seeing you at stand #410 in the South Hall of the Moscone Center, where you will discover: 
  • Enjoy a one-on-one ElevenPaths' senior executives and cyber experts.*
  • Join our Cyber Security lovers’ day party on Tuesday 14 February at 3:00 p.m.


Remember! We look forward to seeing you from 13 to 17 February at the RSA Conference in San Francisco, at the Moscone Center, South Hall, stand #410.

*In order to book your one-on-one with our experts you should complete the mail with your name, surname, title, availability schedule, company, meeting purpose. Deadline for booking February 9th.

Nos vemos en RSA Conference 2017


La ciudad estadounidense de San Francisco vuelve a acoger, como cada año, uno de los eventos más relevantes a nivel mundial en el ámbito de la seguridad, RSA Conference. Del 13 al 17 de febrero los actores más relevantes de la industria a nivel mundial se reúnen durante estas jornadas y ElevenPaths, la unidad de Ciberseguridad de Telefónica, no podíamos faltar a esta cita.

Para que no te cueste nada, te ofrecemos totalmente gratis acceder a la zona de expositores. Para conseguir tu entrada sólo tienes que registrarte con el siguiente código: XE7TELFNCA. Solo disponible hasta el 10 de febrero.


Te esperamos en el stand #410 del South Hall en Moscone Center, donde podrás:
  • Disfrutar de una reunión privada con nuestros ejecutivos senior y ciberexpertos.*
  • Unirte a nuestra fiesta "El día de los enamorados de la ciberseguridad" el 14 de febrero a las 3:00 p.m.


¡Recuerda! Te esperamos del 13 al 17 de febrero en la RSA Conference en San Francisco, en el Moscone Center, South Hall, stand #410.


*Para reservar tu reunión privada con nuestros expertos deberás incluir en el correo nombre, apellidos, cargo, empresa, horario disponible y motivo de la reunión. Solo disponible si nos contactas antes del jueves 9 de febrero de 2017.

Browser Extension Usage by the Islamic State Propaganda

viernes, 13 de enero de 2017

One of the tools that the Islamic State has been using to spread its propaganda is the use of social networks. In the past they have shown how capable they are of expanding their capabilities to cover smartphones and mobile devices, but recently they have also opted for the development of browser add-ons in order to further facilitate access to their content.

Although Firefox extensions are mainly distributed by means of the official market run by Mozilla, the Amaq News Agency, identified as part of the Islamic State’s propaganda apparatus, is also distributing .xpi files in related websites. These files are compressed in .zip and renamed to a .xpi that contains the Javascript, CSS and HTML code that defines the behaviour of the extension.


About this extension, we have identified at least two different versions, 1.0.1 and 1.0.2, whose folder structure contains the same series of source and data files.
.
├── bootstrap.js
├── data
   ├── safe-16.png
   ├── safe-32.png
   ├── safe-48.png
   ├── safe-64.png
   ├── safe.png
   ├── unsafe-16.png
   ├── unsafe-32.png
   ├── unsafe-48.png
   ├── unsafe-64.png
   └── unsafe.png
├── icon.png
├── install.rdf
├── lib
   └── main.js
├── META-INF
   ├── manifest.mf
   ├── mozilla.rsa
   └── mozilla.sf
└── package.json

The most interesting files are three: package.json, install.rdf and the Javascript source file found at lib/main.js:
  • package.json contains metadata and information about the extension like the name, the author, the licenses or the permissions required.
{
    "name": "amaq",
    "title": "Amaq AR",
    "id": "jid1-5Fs7iTLaaUaZBgwdar@amaq",
    "description": "Amaq AR.",
    "author": "Amaq AR",
    "license": "MPL 2.0",
    "version": "1.0.2",
    "icon": "icon.png",
    "permissions": {
        "private-browsing": true
    },
    "engines": {
        "firefox": ">=38.0a1",
        "fennec": ">=38.0a1"
    },
    "main": "lib/main.js",
    "devDependencies": {
        "gulp": "^3.8.11",
        "gulp-image-resize": "^0.6.0",
        "gulp-rename": "^1.2.2"
    }
}
  • install.rdf defines in the field em:targetApplication that the extension is thought to be installed in certain versions. In this case, it explicitly shows that it is valid for different versions of Firefox Browsers, including Firefox for Android (this is defined by the tag <em:id>{aa3c5121-dab2-40e2-81ca-7ea25febc110}</em:id> tagasda).

<em:targetApplication>
    <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>38.0a1</em:minVersion>
        <em:maxVersion>43.0</em:maxVersion>
    </Description>
</em:targetApplication>
<em:targetApplication>
    <Description>
        <em:id>{aa3c5121-dab2-40e2-81ca-7ea25febc110}</em:id>
        <em:minVersion>38.0a1</em:minVersion>
        <em:maxVersion>43.0</em:maxVersion>
    </Description>
</em:targetApplication>

  • lib/main.js defines the code of the extension itself. In this case, it opens a new tab pointing to a given URL as shown in lines 107 and 108. The only difference between versions is the IP address shown in line 108.

var tabs=require("sdk/tabs");
tabs.open("http://190.14.37.220/v/");


Using the extension as a bookmark

In the case of the first release of the add-on 1.0.1, the URL opened was hosted at 88.80.20.1 IP address (a non-accessible address linked to an internet services provider settled in Sweden) while in the most recent version this IP address is 190.14.37.220. This address, still accessible at the moment of writing this article, is linked to an anonymous hosting provider settled in Panama that runs a nginx 1.6.2. However, this resource seems not to be hosting the contents itself because if we access to this URL it responds a 302 Moved Temporarily code and redirects us to jkikki.at, the agency website.  There, this Firefox extension can also be downloaded as amaq_news_agency_ar-1.0.2.xpi together with a hash of the file that would ultimately allow users to verify the legitimacy of the extension.

$ curl http://190.14.37.220/v/ -I
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.2
Date: Tue, 10 Jan 2017 11:02:55 GMT
Content-Type: text/html
Content-Length: 160
Connection: keep-alive
Location: https://jkikki.at/

The referred website is hosting news in Arabic about Amaq and the Islamic State and is protected by Cloudflare making it impossible to know the real location of the systems used to serve the contents.  By using this approach, banning the access to jkikki.at would not be enough to stop their propagation mechanisms considering that the application developer would only need to modify the Location field to redirect to the new domain in which the content would be hosted.



Identifying other affiliated websites

The structure of the URL found in the extension suggested the possibility of the existence of other domains. The tests conducted have returned new 302 responses that pointed to at least 6 other domains also protected by Cloudflare and whose content is also tied to the Islamic State. The details of the certificates used indicate recent validity periods as can be seen in the following table.

URL
Redirected domain
Language
Certificate valid since
http://190.14.37.220/b/
bibifm.at
Arabic
2017/01/10
http://190.14.37.220/f/
vosn.pw
N/F
2016/01/06
http://190.14.37.220/g/
baqiya.ga
German
2017/01/01
http://190.14.37.220/h/
halummu.at
N/F
N/F
http://190.14.37.220/t/
nikmat.gq
Bengali
2017/01/10
http://190.14.37.220/u/
vijestiummeta.ga
Bosnian
2017/01/05
http://190.14.37.220/v/
jkikki.at
Arabic
2016/12/31

Apart from this extension, there is no evidence of the existence of others with a similar behavior that point to the rest of domains. However, the recent creation of the certificates suggests that newer similar add-ons could be created easily by modifying only the URL of the original file to point to one of the URL shown before.


Registrant information and other metadata

Regarding the registry of identified domains, those that do not present special privacy protection measures have been registered email accounts using the tutanota.com encrypted email provider taking into account that the @keemail.me, @tuta.io, @tutamail.com and @tutanota.com (used to register a domain linked to the organization which is no longer used like jkikki.de) are different domains that make use of this service.

Domain
Registrant
bibifm.at
francnomoli@keemail.me
vosn.pw
e12b69957ce848b0b00e47a96a5682ef.protect@whoisguard.com
baqiya.ga
N/F
halummu.at
elana.samra@tuta.io
nikmat.gq
N/F
vijestiummeta.ga
N/F
jkikki.at
stephenjells@tutamail.com
jkikki.de
tomorrowdoma@tutanota.com

On the other hand, the rest of files identified in the extensions do not show too many details apart from some EXIF data found in the agency logos and icons. These files seem to have been edited with various Adobe products for Windows according to its metadata.


Assesment

The Islamic State has shown in the past that it has used the means at its disposal to massively spread its content in both, social networks and mobile applications. In this case, the use of a browser plug-in is another example of how the individuals linked to this organization are capable of adapting themselves to ensure the dissemination of content using not only a technological assets located in different countries, but tools and systems such as Cloudflare and various servers and methods to ensure the effectiveness of the difussion of their message. 

Félix Brezo
Intelligence Analyst at ElevenPaths

Yaiza Rubio
Intelligence Analyst at ElevenPaths