Quantcast
Channel: ElevenPaths Blog
Viewing all 1287 articles
Browse latest View live

Entorno nube seguro con un Telco Cloud Provider

$
0
0

En la actualidad, nadie puede negar los importantes beneficios de la computación en la nube, tanto en su modalidad de infraestructura como servicio (IaaS) como en software como servicio (SaaS). La computación en la nube implica ahorro de costes, flexibilidad a la hora de satisfacer las necesidades de las organizaciones e innovación. En suma, es un factor fundamental en la transformación digital corporativa. Sin embargo, los entornos en la nube conllevan un cierto nivel de complejidad a la hora de gestionar la seguridad TI, debido a que las organizaciones delegan en terceros la responsabilidad del almacenamiento y control de datos sensibles. A lo largo de este artículo, se identificará los retos de la seguridad en la nube y en consecuencia se propondrá un modelo de seguridad, de acuerdo a la perspectiva de un Telco Cloud Provider, para facilitar y asegurar el viaje hacia el entorno en la nube.

Los profesionales de TI y de seguridad son plenamente conscientes de los riesgos para la seguridad de la información y de cómo estos afectan a los entornos en la nube. Sin embargo el continuo bombardeo de noticias sobre ciberataques, a parte de fomentar la concienciación de seguridad en el público en general –lo que es claramente necesario-, está contribuyendo a difundir una serie de ideas equivocadas sobre el nivel de seguridad de estos entornos.

¿Qué crees que es más conveniente?, ¿guardar el dinero en el colchón o en un banco? Con el dinero en el colchón, este estará siempre disponible (simplicidad) y puede ser menos probable que seas seleccionado por los delincuentes como objetivo, pero si por alguna razón alguien asalta tu casa, sin duda necesitaras el mejor sistema de protección para impedirlo o detectarlo. Debemos preguntarnos entonces si somos capaces de implementar medidas de seguridad similares a las de un banco.

En el informe de Visión en Nube 2016 de IDC, se constató que las preocupaciones de seguridad siguen siendo el inhibidor clave para continuar con el despliegue de entornos en la nube. ¿Esta impresión está fundamentada en circunstancias reales? Creemos que no. La mayoría de los ataques cibernéticos no están relacionados con la propia infraestructura de la nube ni tampoco pueden atribuirse al proveedor de estos servicios. Por su parte, Gartner sustenta esta presunción en un reciente análisis el cual presume que, hasta 2020, el 95 por ciento de los fallos de seguridad en la nube serán responsabilidad del cliente.

Aunque el riesgo de seguridad es similar para un entorno de nube o en local, es necesario ser conscientes de que existen tres inconvenientes que deben ser atajados: la complejidad, comunicaciones vulnerables y el aumento en la exposición de los activos.

Complejidad de un entorno sin fronteras
El perímetro de las organizaciones actuales ha sido demolido por tecnologías como la movilidad, las redes definidas por software (SDN) y los servicios en la nube, así como por requisitos operativos como son la necesidad de segurizar el proceso de producción o la cadenas de suministro. Gartner vaticina que para el año 2018, el 25% del tráfico de datos corporativos fluirá directamente de los dispositivos móviles a la nube, evitando controles de seguridad empresariales tradicionales. Esto es un quebradero de cabeza para los departamentos de TI, quienes han de ocuparse de docenas de servicios de terceros alojados en diferentes nubes, proveedores de aplicaciones SaaS y servicios en la nube no autorizados tanto desde el interior del perímetro, como desde el exterior, lo que parece prácticamente imposible de manejar. Por esta razón, las organizaciones demandan a los proveedores de servicios en la nube la implementación de controles de seguridad adecuados, por lo menos equivalentes a los que se podría implantar en un centro de datos local, y además establecer mecanismos de control y notificación flexibles y efectivos.

Calidad de Servicio en Comunicaciones
Aunque las organizaciones puedan acceder a sus Virtual Private Clouds (VPC) a través de Internet, esta opción presenta inconvenientes diversos y costosos, como problemas de seguridad de las comunicaciones, latencia, demoras, pérdida de datos y jitter, entre otros. Esto, pone en riesgo la calidad de servicio (QoS) esperada de una red de datos en un entorno profesional cuando se trata de acceder a aplicaciones corporativas.

Exposición de aplicaciones
En el momento de abandonar el perímetro corporativo y hacer uso de SaaS o aplicaciones de cliente en IaaS, se presenta una mayor exposición y por tanto una mayor facilidad para explotar las vulnerabilidades. Este riesgo es una consecuencia indirecta de la migración de las aplicaciones corporativas a la nube. No es intrínseco a la propia nube, sino que reside en las vulnerabilidades no solucionadas en estas aplicaciones que por haber estado en un entorno más o menos cerrado han pasado desapercibidas. Puesto que las organizaciones han asumido que vivir en un agujero en el suelo ya no es una opción, entonces es necesario implementar una serie de buenas prácticas, tales como monitoreo de seguridad, evaluación de vulnerabilidades o gestión de identidad y acceso.

Seguridad de la nube
Los proveedores de servicios en la nube ponen el foco en asegurar la infraestructura, implementando mecanismos similares a los que usualmente se utilizan en los centros de datos, convirtiendo en transparentes estas medidas para los clientes. Estas medidas incluyen:
  • Resiliencia de la información: el proveedor de servicios de nube debe tener almacenamiento distribuido en varias regiones para garantizar la disponibilidad global. Como parte de su oferta global de servicios en la nube, Telefónica ofrece nodos en diferentes países para resolver problemas regulatorios locales, sin socavar una perspectiva unificada y global que pueda ser requerida por clientes multinacionales o que necesiten portabilidad de información entre regiones.
  • Segmentación: en un entorno compartido, debe garantizarse el aislamiento total entre los usuarios y que el uso (o abuso) de uno de ellos no afecta el rendimiento del resto.
  • Certificaciones: las certificaciones de terceros brindan garantías sobre la implementación y operación de las medidas de seguridad. Organizaciones como Cloud Security Alliance (CSA) otorgan certificaciones como CSA Star, basadas en el grupo de estándares ISO 27001 y adaptadas específicamente para servicios en la nube.

Seguridad hacia la nube
La mejor opción para abordar el problema de comunicación entre la red privada y la VPC es permitir la extensión de redes privadas virtuales (VPN) sobre tecnología IP / MPLS y con cobertura global. De esta manera, todos los recursos corporativos, instancias, bases de datos o puntos finales, independientemente de dónde se encuentren, son visibles en la misma LAN. Este modelo permite incluir fácilmente una capa de seguridad adicional mediante firewalls de próxima generación desplegados en la misma red de acceso para filtrar y bloquear cualquier malware y tráfico no deseado, lo que se conoce como servicios de Redes Limpias. Por último, las organizaciones pueden delegar el despliegue de la defensa perimetral en el proveedor de acceso a Internet, obteniendo una arquitectura de fácil escalabilidad, una mayor resiliencia y una reducción de costos (moviendo CAPEX a OPEX), y si el provedor de acceso a internet también puede proporcionar el entorno en la nube las sinergias serán significativas, a la vez que se garantiza una seguridad extremo a extremo.

Sumado a lo anterior, una propuesta integrada de servicios de nube y telecomunicaciones permite contratar servicios diferenciales de primera clase como AntiDDoS (Global Shield) que detiene los ataques desde la red, incluso antes de que afecten al centro de datos.

Seguridad en la nube
  • Visibilidad y control: también es necesario resaltar la importancia de contar con herramientas que permitan una visibilidad del estado general de seguridad, así como herramientas de monitorización, detección y respuesta. Una plataforma de análisis de vulnerabilidades como es Vamps puede integrarse en los procesos de prueba y contribuir a un proceso de desarrollo más seguro
  • Integración con plataformas de seguridad gestionadas: uno de los factores diferenciales de un proveedor de servicios en la nube es poder ofrecer una perfecta integración con servicios de Seguridad Gestionada (MSS/Managed Security Service). Si el mismo proveedor puede ofrecer ambos, la complejidad, el principal quebradero de cabeza de la seguridad gestionada, se reduce de manera significativa.
  • Gestión del riesgo y el cumplimiento normativo: es necesario contar con herramientas específicas para la gestión de riesgos y el cumplimiento normativo que se adapten a los servicios en la nube. Telefónica dispone en su cartera una solución específica, Sandas GRC, que interacciona con los recursos corporativos desplegados en la nube de Telefónica.
  • Gestión de Identidad y procesos de Autenticación: la plataforma de servicios en la nube debe ofrecer la capacidad de una gestión integral y genérica de la identidad, que se interrelacione con la del resto de servicios utilizados por la organización, como por ejemplo los de comunicaciones o aplicaciones. Para ello, Telefónica ofrece servicios tan conocidos como Latch y Mobile Connect en su oferta de servicios en la nube.

La solución de un Telco Cloud Provider
Como vemos, si se opta por un Telco Cloud Provider, las organizaciones pueden disponer de una oferta de productos integrados –alojamiento, comunicaciones, servicios especializados de seguridad, operación y soporte–, los cuales, al haber sido diseñados de manera holística, conllevan un dimensionamiento adecuado a las necesidades de seguridad, simplicidad a la hora de operar el sistema, garantía de calidad de servicio (QoS) en las comunicaciones y un ahorro de costes al contratarlo conjuntamente.

En resumen, Telefónica, gracias a su capacidad de proveedor integral, es capaz de ofrecer una solución única de seguridad en la nube en la que se combinan los servicios de alojamiento con la reputada experiencia de Telefónica para ofrecer calidad de servicio en las comunicaciones y también con la más avanzada protección de los productos de ElevenPaths operados desde los Centros de Operaciones de Seguridad (SOCs) desplegados por todo el mundo.

Mercedes Soto Rodríguez 
Jefe de Producto de seguridad en la nube 

Francisco Oteiza Lacalle 
Jefe de producto de Seguridad Gestionada 

Yaiza Rubio, la primera mujer hacker de España en participar en DefCON & BlackHat

$
0
0

Esta entrada tiene como protagonista a una de nuestras hackers favoritas Yaiza Rubio, del equipo de analistas de inteligencia de ElevenPaths. Licenciada en Ciencias de la Información y con tres masters (Análisis de Inteligencia, Logística y Economía de la Defensa, y Derecho Tecnológico y de las TIC), se ha convertido en una #mujerhacker referente en el mundo de la ciberseguridad. Comenzó a adentrarse en este sector junto a su compañero Félix Brezo, también analista de inteligencia de ElevenPaths, que conoció en el Máster de Análisis de Inteligencia. Ella trabajaba en ISDEFE, en la unidad de desarrollo de negocio de la industria española de defensa y seguridad, Félix en el laboratorio de seguridad de la Universidad de Deusto. De ahí llegaron a trabajar en el montaje de lo que actualmente es el servicio de CyberThreats de ElevenPaths. Después de esta aventura ahora se adentran en otra juntos, participando en las dos conferencias más importantes de ciberseguridad.

Yaiza es la primera mujer hacker de España que va a participar en las dos conferencias más importantes de ciberseguridad: DefCON & BlackHat en Las Vegas. Desde el pasado sábado 22 de julio y hasta el día 27, nuestros analistas de inteligencia presentarán en la BlackHat OSRFramework, un conjunto de herramientas de software libre con el que llevan trabajando cuatro años dando soporte a los procedimientos de investigación sobre la huella digital de ciberidentidades con presencia en la red, permitiendo identificar al responsable de cualquier actividad delictiva, desde acosadores hasta terroristas. Por otro lado, en la DefCON participarán a través de una intervención sobre ingeniería social, mostrando cuál es el proceso de preparación ante un ataque phishing, apoyándose en tecnologías como Tor (un software que permite acceder a la deep web).

Chema Alonso, Chairman de ElevenPaths, publicó en su blog una entrevista que realizó a la hacker en la que reconocía el orgullo que supone contar con ella como parte del equipo de ElevenPaths. Durante la entrevista, Chema se interesó por saber sus motivaciones sobre la intervención en la DefCON & BlackHat a lo que respondió que a pesar de que le asuste su primera experiencia, prefiere enfrentarse a ello antes que dejarlo de lado.

Mujeres hacker
Yaiza se ha convertido en un referente para las futuras generaciones que aspiran a convertir la tecnología como su forma de vida. En el vídeo donde presentamos a nuestras #mujereshacker Yaiza motiva a todas las mujeres a seguir su camino en el mundo de la tecnología y la seguridad, ya que considera que siempre hay que dar oportunidad a aprender.


Enhorabuena hacker, para ElevenPaths es un orgullo contar contigo en nuestro equipo. Let´s hack!

Síguenos y entérate de todo en nuestras redes sociales: Twitter, Facebook y LinkedIn

ElevenPaths Talks Special Edition: mASAPP, descubrimiento y análisis continuo sobre apps móviles

$
0
0

Hoy a las 15:30h (CET) no te pierdas el especial talk sobre nuestra nueva plataforma mASAPP, desarrollada para el descubrimiento autónomo y análisis persistentes de la seguridad sobre aplicaciones móviles. En este talk presentado por nuestro CSA Claudio Caracciolo, nuestros expertos Víctor Mundilla y Álvaro Rodríguez cuentan cómo en la actualidad nadie pone en duda la importancia de las aplicaciones móviles dentro de la estrategia de canal de una organización. Los smartphones se han convertido en un apéndice más de nuestro cuerpo, nos despertamos y nos acostamos con ellos, y las organizaciones lo tienen claro: su marca, en forma de app, ha de estar posicionada dentro de esta nueva extensión biotecnológica. Los beneficios son incontables e incluso obvios, ¿pero alguien ha pensado en los posibles downsides?

Esto y mucho más en el webinar de hoy cuya duración será de 40 minutos y se impartirá en castellano. Si quieres saber más acerca del tema, no dudes en pasarte por nuestra comunidad, donde nuestros compañeros y expertos hablan sobre éste y otros temas de interés en el mundo de la ciberseguridad.

Para quien se lo haya perdido, os dejamos todas los seminarios completos de nuestras tres temporadas:


Te esperamos hoy a las 15:30 horas (CET) en nuestro canal de YouTube. Si quieres saber más sobre nosotros accede a nuestra página web y síguenos en las principales redes sociales: Facebook, Twitter y LinkedIn. No te pierdas este Special Talk y aprende con nuestros expertos.

Los 433 MHz y el Software Libre. Parte 3

$
0
0
Antes de adentrarse en los proyectos de software, es conveniente considerar el hardware que será necesario, mínimo en muchos casos, pero imprescindible.

Hardware RF 433Mhz AM (ASK/OOK)
  • Receptor SDR-RTL. Aunque no es propiamente dicho un hardware específico para trabajar en la banda ISM de 433 MHz, su extrema versatilidad hace que sea posible de forma muy sencilla. Puede utilizarse cualquier receptor USB de TDT que cuente con un chipset compatible, existiendo controladores y software para sistemas Windows, Mac OS X, BSD, Linux (Raspberry incluido), e incluso para Android.


  • Receptor-Trasmisor por tarjeta de sonido. Es la opción más económica, ya que tan solo es necesario el receptor y/o el transmisor, conectándolos directamente a la tarjeta de sonido de cualquier equipo, aunque se recomienda una tarjeta de sonido externa por USB. Puede utilizarse tanto en Windows y Mac OS X, como en Linux (Raspberry incluido).


  • Receptor-Trasmisor por GPIO en Raspberry PI. Es extensible a cualquier plataforma Linux que pueda manejar, al menos, una línea de entrada/salida digital (GPIO), como podría ser un router con OpenWRT o similar.

  • Receptor-Trasmisor en Arduino. Esta es la opción preferida por la comunidad de makers que montan sus proyectos para funcionar de forma autónoma sin la necesidad de un PC, o bien como interface a través del puerto USB. Puede utilizarse en cualquiera de las múltiples plataformas compatibles con Arduino, como los ESP8266 con Wifi, los potentes Teensy, o los mínimos Trinket.
Antenas
Es habitual que los módulos de bajo coste se presenten sin antena. Esta configuración es funcional, pero el rango de alcance es de apenas unos metros, por lo que solo se puede utilizar para realizar pruebas dentro del entorno cercano. Si necesitamos un alcance mayor, tanto para el emisor como para el receptor, se hace imprescindible incorporar una antena sintonizada lo más aproximadamente posible a la frecuencia central de la banda de trabajo, en este caso, 433.92 MHz.

Las características de la antena influyen notablemente en la calidad de la emisión y recepción, por lo que es un elemento crucial cuando se requieren unas mínimas prestaciones
.


No obstante, el diseño de la antena puede ser realmente simple. Los tipos más usuales son en espiral, en bucle, o en hilo; todos ellos de fácil calculo e implementación, gracias a la abundante documentación y programas de ayuda disponibles en internet.

La antena más sencilla posible es tan solo un hilo (whip, látigo en inglés), de un cuarto de la longitud de onda, poco más de 17 centímetros, con la que se obtienen resultados satisfactorios. También son de uso habitual las antenas en espiral por su reducido tamaño, así como sus diferentes combinaciones con otros elementos.

Proyectos de Software Libre
El “Software Libre” (Free Software), y el software de “Código Abierto” (Open Source), no son lo mismo aunque suelen utilizarse ambos términos indistintamente; y por supuesto, ninguno de los dos tiene relación alguna con el concepto de “gratuito” al que muchas veces se simplifican.

Estas dos iniciativas son promovidas por organizaciones diferentes, por un lado la FSF, Fundación para el Software Libre, liderada por Richard Stallman, elabora, mantiene y defiende la Licencia Pública General GNU (GNU/GPL) desde 1989. Sus diferentes versiones y variantes se fundamentan en cuatro libertades esenciales:

  • La libertad para usar el software como se desee, con cualquier propósito (libertad 0).
  • La libertad para estudiar su funcionamiento y adaptarlo a otras necesidades (libertad 1).
  • La libertad para redistribuir copias a otros usuarios (libertad 2).
  • La libertad para modificar el software y distribuir copias de las modificaciones (libertad 3).

El acceso al código fuentees una condición necesaria para satisfacer las libertades primera y tercera, implicando que cualquier software derivado que utilice Software Libre, debe ser a su vez Software Libre, y por lo tanto respetar sus libertadas, quedando obligando a la publicación del código fuente, tanto de las modificaciones del Software Libre utilizado, si las hubiera, como del resto del software en su conjunto.

Por otro lado está la OSI, Iniciativa para el Código Abierto, creada casi 10 años más tarde por Bruce Perens y Eric S. Raymond, con el objetivo de acentuar los beneficios prácticos del acceso al código fuente, frente a los aspectos éticos o de libertad de índole filosófico que son tan relevantes en el Software Libre.

La FSF y la OSI se reconocen mutuamente como aliadas, ya que persiguen objetivos similares, aunque no coincidan demasiado en sus principios básicos. Articulan diferentes “licencias” como instrumentos jurídicos para definir y salvaguardar los términos en los que un software es publicado.

Se calcula que más del 60% de todo el software de dominio público se licencia bajo alguna de las versiones de Software Libre GNU/GPL, mientras que el resto queda muy repartido entre diferentes variantes y otras licencias Open Source más permisivas como BSD, Apache, X11, MIT, o Mozilla.

La diferencia más significativa entre las licencias de Software Libre y las licencias Open Source, es que estas últimas no obligan a redistribuir el código fuente del software que las utiliza.

Receptor SDR-RTL
Es posible utilizar cualquier receptor de tipo SDR que tenga capacidad para sintonizar la banda de 433 MHz para poder comenzar a experimentar utilizando herramientas de Software Libre muy maduras como GNU Radio, o las recogidas bajo osmocom.org, de la cual forman parte los trabajos para manejar los dispositivos USB receptores de TDT con chipset Realtek, SDR-RTL (enlace a github aquí) muy accesibles por su bajo coste.


En la wiki de osmocom se enlazan más de 30 proyectos de Software Libre relacionados, destacando especialmente el proyecto RTL_433 (enlace a github aquí), específicamente diseñado para desentrañar las comunicaciones AM (ASK/OOK) en de la banda ISM de 433 MHz.

Gracias a las numerosas contribuciones que realizan los investigadores al proyecto, dispone de capacidad para interpretar casi 80 protocolos de comunicación diferentes, lo que lo convierte en una herramienta extremadamente útil a la hora de analizar cualquier actividad en dicha banda.

Ejemplo de captura con RTL_433

Transmisor-Receptor por tarjeta de sonido
La conexión de módulos de emisión y/o recepción de radiofrecuencia ASK/OOK a la salida y/o entrada de audio de un equipo, transforma los impulsos de AM en señales manejables como si de audio se tratara, por lo que se puede emplear cualquier software existente para este ámbito; como Audacity por ejemplo, tanto para recibir como para emitir en la frecuencia de 433 MHz.

Como proyecto específico, es meritorio el trabajo de Danny Havenith, CHEAPL (enlace github aquí), ya que su simplicidad, solo soporta el protocolo X10, hace que sea tremendamente didáctico.

Digna de mención es también la labor del proyecto OpenHomeNet, los cuales han publicado un analizador de protocolos escrito en Java (enlace a github aquí) que soporta 12 de los protocolos más extendidos.

Analizador de protocolos del proyecto OpenHomeNet


Transmisor-Receptor por GP10
Cuando la conexión de los módulos de emisión y recepción AM (ASK/OOK) se realiza directamente a los terminales GPIO que exponen algunas plataformas como Raspberry PI o Beaglebone, las posibilidades de integración se incrementan notablemente, ya que es posible manejar las señales ASK/OOK como si de señales digitales binarias se tratara.

Destacan los proyectos de Jean-Christophe Rona (enlace a github aquí), abarcando desde una interface de recepción y emisión que soporta los 8 protocolos más habituales de interruptores domésticos, hasta una GUI Web para la interface, pasando por un módulo de Kernel Linux para su integración en routers con OpenWRT, de forma similar o otro proyecto parecido donde se ejecuta en espacio de usuario (enlace a github aquí).


Router OpenWRT con transmisor RF 433Mhz AM (ASK/OOK) por GPIO y GUI Web de control

En lenguaje Python, con entorno web, integrando con base de datos SQL y soportando el protocolo Nexa, encontramos el proyecto Cr-Smart-Home (enlace a github aquí); un buen ejemplo de las posibilidades que ofrece la combinación de diferentes componentes software.

Con un alcance mucho más amplio, ya que comprende un sistema domótico completo, destaca “pilight”, un magnifico proyecto excelentemente documentado, en el que han diseñado un robusta interface con los módulos de radiofrecuencia conectados vía GPIO mediante wrappers TCP/IP, e incluso han desarrollado un pre-filtro digital externo para mejorar las capacidades de recepción. Soportan decenas de protocolos tanto en emisión como en recepción, pudiéndose instalar y utilizar cada módulo de forma independiente (enlace a github aquí).

Menú de instalación de “pilight”

Transmisor-Receptor con Arduino
Arduino es sin duda la plataforma con mayor cantidad de proyectos de Software Libre y Código Abierto relacionados con los módulos de radiofrecuencia AM (ASK/OOK), debido a la facilidad con la que pueden manejarse, tanto en recepción como en emisión.

El proyecto emblema es RC-Switch (enlace a github aquí), tremendamente didáctico, soporta varios protocolos fácilmente ajustables, incluyendo un sketch de recepción a modo de scanner o sniffer, como el de RCControl, muy útil en tareas de investigación y depuración. Ha sido portado a otras plataformas como Raspberry PI, en diferentes implementaciones.

Aunque el entorno de programación de Arduino soporta ya plataformas muy potentes, tradicionalmente sus desarrollos han estado marcados por la escasez de recursos del hardware, por lo que es difícil encontrar un gran proyecto que soporte múltiples protocolos, en favor de múltiples proyectos que soportan un número reducido de protocolos; como por ejemplo: RemoteSwitch, NewRemoteSwitch, NexaCtrl, Oregon, InterTechno o FlamingoSwitch, combinándose estas implementaciones en otros proyectos que agrupan varias librerías como HRCSwitch y RFToy, o incluso en proyectos de traducción entre protocolos diferentes.


También son muy frecuentes las implementaciones de interconexión inalámbrica entre Arduinos, Raspberrys, o combinaciones de ambos, utilizando módulos de radiofrecuencia ASK/OOK, junto con estos protocolos, VirtualWire, o incluso directamente a través de la UART serie a baja velocidad, unos 2400 bps, como a continuación podemos observar en una simulación con Proteus.

Emulación de Arduino y módulos de RF 433MHz


Jorge Rivera 
CSA Global de ElevenPaths 

JlJmIhClBsr: La curiosa historia de cómo la NSA se delataba a sí misma con EternalBlue

$
0
0
No hay error ni errata en el titular. Y tampoco vamos a hablar de las mismas teorías ya tan machacadas una y otra vez. La cadena de texto en el titular delata en cierta forma cómo creó la NSA el EternalBlue y cómo por extensión WannaCry introducía (probablemente sin querer) una especie de marca que hacía que ambos ataques pudieran haber sido detectados antes de producirse. Y a partir de ahí, una curiosa (por momentos paranoica) historia de una cadena de texto que pasó, de forma interesante como veremos, a convertirse una firma de red de tráfico malicioso.

Ya sabemos todos la historia de EternalBlue. Un exploit entre tantos (parcheado con MS17-10) muy potente de la NSA robado por ShadowBrokers y que sirvió como difusor de WannaCry. Pero no repitamos lo de siempre. EternalBlue es en realidad un fallo en la función SrvOs2FeaToNt del protocolo SMBv1 de Windows. El "kit" del exploit usado por la NSA se descubrió en forma de framework de trabajo en Python, que lanzaba ejecutables ya compilados. Había que utilizar (y retocar) el framework para usar el ataque. Nuestra compañera Sheila Berta ya lo hizo aquí. Uno de estos ejecutables era EternalBlue2.2.0.exe (4e80fa7d98c8e87facecdef0fc7de0d957d809e1). Un fallo que a través de una petición por SMBv1 a un Windows, permitía la ejecución de código. Días después de hacerse público el ejecutable, fue rápidamente analizado

El nivel de detalle en el análisis fue el suficiente como para que poco después se hiciera muy popular la técnica gracias a su difusión como módulo en Metasploit-


Cuando apareció el exploit detallado en forma de módulo en Mestasploit, nos llamaron la atención un par de detalles.
  • El exploit no necesita SMBv2 para funcionar. Aunque envía paquetes disfrazados de este protocolo, no es realmente necesario para nada. Se cree que esta opción era simplemente una cortina de humo de la NSA en el exploit, para confundir (cosa que consiguió puesto que muchos al principio mezclaban SMBv2 como actor en el discurso del ataque, o se le atribuía directamente toda la responsabilidad). Lo pudimos comprobar en el laboratorio por el uso de estas cabeceras que marca el protocolo.
 "\xfeSMB" # SMB2
"\xffSMB" # SMB1

Modificando las cabeceras, el efecto era el mismo. Nuestras pruebas en el laboratorio confirmaron que deshabilitando SMBv2 en el destino, el exploit seguía funcionando. El fallo era exclusivo de SMBv1. Parecía que la NSA se había molestado en introducir SMBv2 para "despistar" y los sucesivos portes a Metasploit y otros lenguajes respetaron este protocolo aunque no fuese realmente necesario.

Muchos todavía afirman que EternalBlue explota un fallo en SMBv2 (así se creía al principio)

  • Por otro lado, algo mucho más interesante. Observando detenidamente el exploit de Metasploit. Vimos este comentario del creador del módulo Metasploit (actualmente han eliminado esta línea en la nueva versión, pero podéis encontrarla en los diferentes repositorios):

Una cadena que era sustituida por x41, al resultar "una firma IDS existente"

Se observa en los comentarios que esa zona del paquete SMB ("echo data") que está creando al vuelo para lanzar a la víctima, se asume como "una firma IDS ya existente" y se tomaba la libertad de anularla. A partir de aquí, un montón de preguntas. ¿Una firma de IDS? ¿Por qué habría de contener ExternalBlue una firma de IDS en su código? ¿Quién había introducido eso? ¿Por qué lo eliminaba el creador del exploit en Metasploit? ¿Esta firma se encontraba también en WannaCry? Nos llamó poderosamente la atención, y empezamos a investigar. Preguntamos a uno de los creadores del módulo (Sean Dillon), que rápida y amablemente nos respondió que parecía una amalgama de caracteres que la propia NSA eligió para rellenar ese campo del exploit (I think it was just a random SMB "ping" packet the NSA chose. I haven't seen the same packet before this). Con respecto a la pregunta de por qué la eliminó sustituyéndola por el carácter x41, la política de Metasploit es limpiar los exploits tanto como sea posible siempre que queden funcionales, para que las soluciones que deben detectar los ataques, no se distraigan con firmas sencillas, sino que vayan al grano. Loable por su parte.

Pero… ¿de verdad esa cadena era aleatoria y la eligió la NSA?

Tenemos por tanto una cadena que aunque aparecía en un campo del exploit original, no le aporta nada, y que por tanto parecía inventada por la NSA… No cuadra con la filosofía de ocultarse o despistar (usando protocolos innecesarios como SMBv2) y pasar desapercibido. Vayamos más allá. Lo primero era comprobar si realmente esa cadena se encontraba en el EternalBlue original y en otros paquetes:

La cadena se encuentra en los binarios de EternalBlue y EternalCore que hizo públicos ShadowBrokers

La cadena estaba en el binario, y en el tráfico de los exploits, claro. Se encontraba asociada al campo "Echo Data" de SMB... Parecía un valor concreto de ese campo que debía significar algo, pero era extraño porque no aportaba nada al exploit... ni al protocolo en sí.¿Qué sentido tiene introducir una firma IDS que ya existía, o sea, conseguir que el tráfico fuera fácilmente identificable? El siguiente paso fue comprobar si esa cadena se encontraba también en el tráfico de WannaCry original. Y sí, efectivamente allí estaba, en la captura de una infección lateral.

La cadena en una captura de tráfico de infección lateral de WannaCry,
lo que indica una clara inspiración en el EternalBlue original


Efectivamente, el creador de WannaCry se inspiró en el exploit original, no en el del módulo de Metasploit, porque este último apareció el 14 de mayo… O sea, el creador de WannaCry tampoco reparó en esta cadena que hubiera permitido identificar el ataque.

Teníamos que averiguar qué era esa cadena y qué significaba. \x4a\x6c\x4a\x6d\x49\x68\x43\x6c\x42\x73\x72\x00 es en realidad, “JlJmIhClBsr”. Hicimos varias búsquedas teniendo en cuenta todas sus posibles variables.

Búsquedas de la cadena en sus diferentes formatos

Muy pocos resultados en general. Buscado como cadena hexadecimal (5 resultados), todos relacionados precisamente con EternalBlue o WannaCry. ¿Había la NSA creado un exploit con firma IDS incorporada? No tenía sentido. Buscado la cadena en otro formato, vemos un resultado de 2014 y 2010, aunque solo dos. Si lo buscamos como cadena, encontramos algunos resultados más (415) incluso tan remotos como en tráfico de la BlackHat 2003. Esto se ponía interesante

Indagando en los resultados

Indagando en las coincidencias encontradas en Google, vemos usuarios que compartían pcaps de incidentes en 2010, 1014…, pero nada extraño, nada aparentemente relacionado con el malware. En este momento podría parecer que o bien la NSA había hecho circular el exploit antes de 2017, o bien (más probable) que esa cadena no pertenecía exclusivamente a EternalBlue.. O sea, la cadena existía desde antes de EternalBlue y era emitida en algún punto del protocolo SMB pero parecía que solo bajo circunstancias muy concretas. O, al menos, no resultaba muy común ver esta cadena así como así.

En este formato aparecen más resultados, no muchos, y casi todos asociados a WannaCry
 
Buscando con esta fórmula, obtenemos el mayor número de resultados (aunque no muchos, 1160). La inmensa mayoría, resultan ser reglas Snort para detectar WannaCry. Así que a muchos IDS no les pasó desapercibida esa cadena como detector de WannaCry. Incluso a alguno no les pasó inadvertida como detector de EternalBlue, aunque fue a los que menos. Fijaos en esa última entrada del 5 de mayo (antes de WannaCry, que fue el 12) donde ya se ofrece una regla de Snort basada en esa cadena. Pero si hay evidencias de que esa cadena existía años atrás (2003, 2014, 2010... desarrolladores o usuarios con problemas en SAMBA),¿por qué todo el mundo la asocia a WannaCry y algunos incluso a EternalBlue como si le perteneciera en exclusiva?

La respuesta…pertenece en cierta forma a un campo poco usado del protocolo SMB

Vamos al grano entonces. JlJmIhClBsr efectivamente es una cadena aparentemente aleatoria (o no, quién sabe si significa algo), pero no ideada por ningún atacante, ni mucho menos por la NSA. Es una cadena creada por Microsoft, y que pertenece en principio a versiones antiguas de Driver Kit oficial de Windows. En estos kits se suele adjuntar fuentes en C de ejemplos de implementaciones. En concreto, esta cadena se encuentra en el ejemplo base de un mini redirector SMB (MRXSMB) de la parte de drivers de sistema de ficheros. En este kit, encontramos un fichero concreto llamado SRVCALL.C, al menos desde 1999.

En este fichero aparece la cadena por primera vez, como parte de código oficial de Microsoft


Este redirector SMB es una especie de cliente SMB de Windows, un ejemplo para que un desarrollador se base en él a la hora de crear sus drivers o clientes derivados. De hecho, y esto es curioso igualmente, el archivo mrxsmb.sys (un driver oficial de Windows) contiene la cadena.

La cadena se encuentra en los drivers MRXSMB de Windows XP y 8, por ejemplo

Lo tenemos igual en un XP que en un Windows 8. No en Windows 10. MRXSMB.SYS dejó de contenerlo tal y como lo hacía en 2010. De hecho está "deprecated" en cierta manera. Se eliminó del WDK en su versión 7600 (posterior al WDK de 2008). La razón para eliminarlo es que usaba el Transport Driver Interface para comunicarse, cosa que está de nuevo en vías de extinción desde Vista en favor del Winsock Kernel.

Pero que se encuentre en el código fuente de un driver oficial de Windows no significa que se utilice durante el proceso de negociación del protocolo y se transmita por la red. Probablemente podrías analizar tráfico SMB de Widnows durante mucho tiempo y no toparte con ese conjunto de caracteres. Tanto es así, que parece que nadie se ha quejado hasta el momento de que, ahora que se le conoce como una cadena de red que identifica a WannaCry, se hayan dado falsos positivos. Aunque claro que los habrá. De hecho los ejemplos encontrados en la red anteriores a 2017, de capturas legítimas de datos previas a EternalBlue, serían hoy por hoy en su mayoría detectadas erróneamente como un ataque EternalBlue o WannaCry a causa de esa cadena.

¿Conclusiones?

De esta curiosidad se pueden desprender algunas conclusiones. Es posible que quien creó el EternalBlue original se basó en el ejemplo del WDK en su versión 7600 de aproximadamente 2008. Buscó un ejemplo de implementación de cliente SMB oficial y trabajó sobre él. Esto a su vez hace pensar que quizás no utilizó técnicas de fuzzing, que puede ser lo más habitual, sino que creó su propia arma desde un kit de desarrollo, lo que podríamos calificar de comportamiento quizás no muy habitual entre los exploiters.

También podemos concluir que al encontrarse una constante en un ejemplo de implementación (y en el código fuente del propio driver oficial de Windows), lo más sensato desde el punto de vista de un atacante sería averiguar para qué sirve y eliminarla, como hicieron los programadores del módulo de Metasploit. Desde ese punto de vista, fue un error de la NSA, porque la cadena no tiene utilidad, es poco conocida, singular y por tanto muy delatora para los IDS. Otro misterio es para qué la usa Windows exactamente (si es que la usa).

Puede que la NSA la dejara allí como despiste cuando se basó en el código fuente del driver, pero en el caso del creador de Wannacry se trata de un error heredado que lo ha hecho fácilmente identificable. De hecho, ya existían reglas Snort (del 5 de mayo) públicas para detener EternalBlue, que hubieran detenido WannaCry si estas reglas se hubiesen adoptado. Otro incomprensible comportamiento que añadir a la poca profesionalidad demostrada de WannaCry en general.

Otra curiosidad es que parece que una cadena original de Windows, se ha convertido en una firma IDS oficial/oficiosa de WannaCry y EternalBlue, sin tener en cuenta los posibles desarrollos legítimos que pueden verse afectados por estar basados en ese drivers y que contienen la cadena. Debe haber muy pocos para que no se haya llamado la atención sobre potenciales falsos positivos. Y esto incluye el propio driver MRXSMB de Windows, que lo incorpora pero parece no emitirlo por la red. Quizás esto habría que analizarlo mucho mejor para entender exactamente el funcionamiento del ejemplo y los drivers.

Bola Extra: Entramos en modo paranoico

De esta curiosidad se puede ir más allá y entrar en modo paranoico. Titulares del tipo "La NSA tuvo acceso a parte del código fuente de Windows para crear EternalBlue"podrían llegar a ser portada si se dejan atrás ciertos matices, detalles y escrúpulos. Y ya que estamos en modo paranoico, el siguiente ejemplo nos llamó igualmente la atención. Conficker es un gusano del que se sabe muy poco y que explota una vulnerabilidad muy similar a EternalBlue, pero parcheada en MS08-67. Investigando, nos detuvimos en una captura de un pcap en 2014 que se llamaba "badguy_traffic".

Conseguimos el pcap de 2014 y efectivamente contiene malware y la cadena en cuestión. Pero no eran pruebas de la existencia EternalBlue en 2014. Bien es cierto que resulta en un intento de explotación de una vulnerabilidad en SMB en la víctima 94.242.232.132 a través de su puerto 445… y tras volcar el binario de esa captura, parece que el ejecutable que descarga este tráfico es una variante de Conficker explotada a través de SMB. En este caso concreto el atacante proviene de 190.56.249.98, de Guatemala. Pero lo curioso es que el exploit SMB aprovechado por Conficker, (habitualmente y en los miles de muestras analizadas desde 2008), no usa esta cadena "JlJmIhClBsr" en su código como campo de "echo data". Al contrario que para WannaCry, esta cadena no está asociada como IDS de Conficker de forma generalizada.. Se trata pues de una implementación muy concreta del método de difusión de un Conficker.

Tráfico de 2014 con la cadena y la descarga del binario Conficker

Otra curiosidad. Existe un fichero "dump" de memoria que fue enviado sin posibilidad de compartición (por tanto eludió VirusTotal, por ejemplo) a un par de páginas de análisis de malware. Esto ya denota cierto nivel de secretismo no muy habitual. Aunque no tiene sentido por otro lado analizar como ejecutable un volcado de memoria… En un dump de este tipo se puede encontrar cualquier cosa mezclada de un proceso de memoria. Aunque no podamos descargar el fichero, las páginas de análisis realizan un "strings" y extraen las cadenas legibles. En este caso en concreto, que data de octubre de 2016, encontramos tres elementos muy significativos. Por supuesto JlJmIhClBsr, pero además también texto público sobre cómo aprovechar un fallo del kernel de Windows. Y además, por varios indicios como por ejemplo el tipo de letra usado, podemos concluir que el usuario era Coreano.

Un "dump" de memoria con la cadena, y visitando páginas de vulnerabilidades probablemente desde Corea

Y para rematar, el modo paranoico más extraño. Esta cadena JlJmIhClBsr, está presente en una página de un organismo gubernamental de Atlanta, donde debería en realidad encontrarse un correo electrónico. ¿Cómo acabó allí?



Sergio de los Santos
Innovación y desarrollo
ssantos@11paths.com

Disponible la nueva versión de Latch

$
0
0
No podía ser de otra manera, ya estamos aquí con una nueva versión de Latch que tenéis disponible en los distintos appstores al alcance de todos.

Queremos ayudaros a disponer de herramientas y servicios que mejoren vuestra seguridad y el control sobre vuestra identidad digital, que pertenece a cada uno de vosotros. Es bueno que tomemos ciertas medidas que nos den ese “plus” de protección.

En este caso concreto, hemos querido dar una respuesta a las noticias que se suceden de la sustracción de credenciales y ataques de seguridad, siendo Latch ese “compañero” fiel que intenta acompañarte en todo momento, por un lado, con los pestillos y por el otro lado con los cloud TOTPs.

Ilustración 1: Pantalla inicial de Latch.



Y son estos últimos los protagonistas de nuestra “canción del verano”, en esta nueva versión hemos conseguido facilitar el enrollment de los TOTPs, con unos manuales que pueden visualizarse en tu smartphone, para guiarte y ponértelo fácil.

Ilustración 2: Pantalla para manuales de TOTPs.

De esta manera tendrás TOTPs y “pestillos” en una sola app, disponibles a un solo click.

Ilustración 3: Pantalla pestillos y TOTPs y acceso a carrusel nuevos TOTPs con manuales.

Si quisiéramos dejar de mostrar el carrusel de los manuales, lo podríamos configurar a través del panel de configuración de Latch.

Ilustración 4: Pantalla Configuración donde se muestra la opción de muestra sugerencias TOTP.

También os anunciamos otra serie de funcionalidades que hemos ido incorporando como os indicamos a continuación:
  • Alternativas a la necesidad de hacer ‘polling’ constante o en periodos cortos de tiempo a la API de Latch, mejorando el uso de recursos y evitando las notificaciones consecutivas, a través de la funcionalidad de WebHooks.

Podéis probar estas funcionalidades y decirnos que os parece en latch-support@support.elevenpaths.com.

Y para finalizar esta entrada en el blog, os indicamos lugares donde podéis participar y profundizar en Latch y/o ciberseguridad:


Ilustración 5: Página de la comunidad de ElevenPaths.

Ilustración 6: Página del área de desarrolladores de Latch.

ElevenPaths Talks Special Edition: DroneTinder, vigilancia continua en Tinder con Drones Virtuales

$
0
0



Hoy a las 15:30h (CET) no te pierdas esta nueva edición especial donde trataremos problemas de privacidad que pueden generarse detrás de aplicaciones tan populares como Tinder. Desde el punto de vista de los analistas de inteligencia, Tinder ofrece información fiable para localizar a personas. Para darse de alta en la aplicación es necesario un perfil de Facebook que sirve para validar al usuario, además de un número de teléfono válido.

De la mano de nuestros expertos Pablo San Emeterio y Julio García realizaremos además, una demo del proyecto Drone Tinder, en la que veremos cómo es posible seguir a una persona 24/7 sólo con el simple hecho de usar esta red social.

El webinar tendrá una duración de 40 minutos y se impartirá en castellano en nuestro canal de YouTubeSi quieres saber más acerca del tema, no dudes en pasarte por nuestra comunidad, donde nuestros compañeros y expertos hablan sobre éste y otros temas de interés en el mundo de la ciberseguridad.

Si quieres ver el resto de las temporadas, aquí os dejamos todas los seminarios completos:


Agenda de eventos en agosto para estar al día en seguridad informática

$
0
0

El mes de agosto llega cargado de eventos sobre ciberseguridad y hacking que no te puedes perder. Algunos de ellos se celebrarán en Latinoamérica y otros online. ¡Toma nota y participa!

Andicom
Diego Espitia, experto y CSA de ElevenPaths en Colombia, participa en este Congreso Internacional de las TIC que tendrá lugar del 23 al 25 de Agosto en Cartagena, con la charla Todos somos víctimas de la ciberdelincuencia. En su web oficial puedes encontrar todos los detalles sobre el evento.


ToorCON 2017
Aunque el evento se celebrará durante la primera semana de septiembre, tienes hasta el 25 de agosto para registrarte. Nuestro Chairman, Chema Alonso, estará en San Diego, la esquina de la Costa Oeste de Estados Unidos, en la que ya había participado en 2008. En esta ocasión, hablará sobre DirtyTooth. Además, en este evento participará Santiago Hernández, compañero de ElevenPaths, quién explicará el trabajo que hizo para el Master de Seguridad de la UEM con Alejandro Ramos titulado WinReg MiTM: Simple Injection and Remote Fileless Payload Execution o como hackear sistemas Microsoft Windows con inyecciones en el registry por red. Para más información, visita el post de Chema Alonso, De Sur a Norte: un viaje de tres semanas por América.



ElevenPaths Talks
Como venimos haciendo durante todo el año, los jueves a las 15.30h (CET) tienes una cita con nuestros expertos en nuestra serie de webinars onlines gratuitos. Durante este mes de agosto tendremos tres sesiones impartidas por nuestros expertos CSAs. Estos son los próximos webcast a los que te puedes apuntar de manera gratuita:

  • 03 de Agosto: Special Edition: Drone Tinder: En esta sesión nuestros expertos Pablo San Emeterio y Julio García te cuentan todo lo que tienes que saber sobre Drone Tinder. ¿Sabías que los bots en la app de Tinder podrían monitorizar tu localización? ¡No te pierdas este webinar!
  • 10 de Agosto: Seguridad Defensiva vs. Seguridad Ofensiva: En este webinar Claudio Caracciolo y Jorge Rivera junto a un invitado especial, analizarán las ventajas y desventajas de las técnicas de cada uno de los modelos con un mismo objetivo, proteger los activos de la información de las compañías.
  • 24 de Agosto: Inteligencia Artificial y Machine Learning En este talk, Diego Espitia y Rames Sarwat junto a un invitado especial hablarán sobre innovación desde ambas ópticas aplicadas a la seguridad.

Si te has perdido los anteriores capítulos, puedes verlos en nuestro canal de YouTube de la serie ElevenPaths Talks - Season 3. 

Esperamos que alguna de estas citas sean de vuestro interés, y nos veamos presencialmente o por Internet.¡Feliz verano, hackers!

Los 433 MHz y el software libre. Parte 4

$
0
0

Lo que nunca se debe hacer

Tras un breve vistazo se puede apreciar la gran cantidad y variedad de proyectos de Software Libre o de Código Abierto publicados bajo diferentes licencias, mediante las cuales los desarrolladores conservan sus derechos de autor, proporcionándoles una garantía legal de protección ante apropiaciones ilegitimas o que restrinjan las libertades a otros usuarios.

Son innumerables los casos de éxito de software licenciado bajo GNU/GPL, como sonados los procesos en los que se detectó una violación o incumplimiento de la licencia y el fabricante se vio obligado a publicar el código fuente, retirar en producto, o dejar de distribuirlo. Apple, Microsoft, Cisco, Asus, VMware y otras muchas compañías de primer orden han tenido que ceder ante las reclamaciones y demandas de la FSF (Free Software Fundation), que según sus propias cifras, tramitan más de 50 grandes casos cada año.

Por tanto, lo que nunca se debe hacer es utilizar Software Libre en un proyecto que no vaya a ser a su vez Software Libre. Y mucho menos apropiarse del código fuente y atribuirse su autoría.

Desgraciadamente, también hay ejemplos de estos casos. Es precisamente lo ocurrido con el proyecto Nodo, un excelente desarrollo domótico, que implementa una interface Serial/USB vía Arduino a múltiples protocolos de radiofrecuencia en codificación ASK/OOK, tanto para emisión como para recepción. Muy versátil gracias a su particular confección mediante plugins; la ultima versión liberada v3.7 disponía de 34 plugins, y comenzaba a esbozar soporte para protocolos de radiofrecuencia a 2.4 GHz, almacenamiento en tarjetas SDcard y conectividad de red vía Ethernet.

Publicado en 2013 por Paul Tonkes bajo licencia GNU GPL v3, el proyecto Nodo ha sido usurpado por un grupo que se hace llamar Stuntteam, los cuales distribuyen desde la web un software que denominan RFLink Gateway, esencialmente igual al proyecto Nodo, pero solo como un binario precompilado para Arduino Mega, infringiendo  cuarta sección de la licencia GNU GPL v2 y la decimoséptima sección de la GPL v3, las cuales exigen que los programas distribuidos como binarios precompilados estén acompañados de una copia de su código fuente.

RFLink debió ser más abierto en sus orígenes, ya que existen repositorios de código, tanto en SourceForge , como en GitHub, pero actualmente ambos repositorios se encuentran vacíos. Si bien es cierto que está disponible para su descarga una versión antigua (R33-2015) del código fuente desde una compartición en Google Drive, esta ya incluye un estrambótico licenciamiento, donde a pesar de reconocer la autoría de Paul Tonkes, obvian cualquier referencia al Software Libre y su licencia GNU GPL v3 original, y por el contrario, añaden indignantes clausulas totalmente contrarias al espíritu del Software Libre; citando textualmente:

“No se permite descompilar, desensamblar o realizar ingeniería inversa de ninguna parte del programa precompilado”.

Predicando con el ejemplo

Para predicar con el ejemplo, no hay mejor forma que desarrollar un proyecto a modo de prueba de concepto (PoC), que haga uso de Software Libre, y que por tanto, deberá quedar publicado igualmente como Software Libre.

La PoC propuesta será un dispositivo IoT que actúe como interface de transmisión de varios protocolos de radiofrecuencia ASK/OOK en la banda ISM de 433MHz, a una conexión de red TCP/IP, para poder utilizarse tanto localmente como desde Internet.

Para simplificarla al máximo y hacerla lo más accesible posible, se ha elegido como plataforma de desarrollo un Arduino UNO R3, junto con la Shield Ethernet W5100. Ambos elementos estándar, muy económicos y fáciles de conseguir; incluso disponiendo de una caja específica para el conjunto con espacio suficiente para alojar componentes adicionales.


Arduino UNO R3, Shield Ethernet W5100 y carcasa para el conjunto

Como transmisor de RF 433MHz AM (ASK/OOK) es posible utilizar cualquiera de los comentados anteriormente, ya que el rendimiento en transmisión es adecuado en todos ellos. No obstante, y pese a tratarse de una prueba de concepto, se ha empleado una antena comercial estándar, junto con un transmisor Aurel/Cebek C-0507 que puede alcanzar los 400mW funcionando a 12v, aunque alimentado a 5v no supera 100mW; respetando así la  regulación de la banda ISM. Su conexión es muy sencilla, ya que tan solo emplea un PIN de comunicación con Arduino, y únicamente se ha añadido un condensador para absorber posibles picos de consumo durante los instantes de transmisión.   
 
 
PoC interface RF 433MHz ASK/OOK a TCP/IP vía Ethernet 


Los protocolos a manejar serán los tres más comunes utilizados en interruptores inalámbricos tipo plug (enchufe), pero que también se encuentran en otros formatos para incorporar a la instalación eléctrica y actuar sobre cualquier elemento conectado; estos son:
  • Flamingo 500: con codificación pseudo-rolling-code, es utilizado por los interruptores inalámbricos HomeEasy-Smartwares y sus variantes de Elro, AB440S, etc.
  • FHT-7901: utilizado por los veteranos interruptores inalámbricos configurables por micro switchs. De origen chino, introducidos por Kjell & Company, son comercializados bajo múltiples marcas como Bricolux, Avidsen, Impuls, etc. a precios muy económicos. 


Como interface al protocolo TCP/IP se ha optado por una API REST sobre un servidor Web (HTTP), la cual garantiza la interoperabilidad con cualquier sistema domótico, frontal web, o aplicación móvil, de forma extremadamente sencilla, ya que tan solo hay que realizar una petición Web (HTTP GET) para emitir un comando de radiofrecuencia codificado en el protocolo deseado.

Además de las librerías estándar de Arduino, licenciadas bajo GNU LGPL, se emplearan librerías licencias con GNU GPL v3, MIT y BSD, por lo que todo el proyecto en su conjunto se publicará bajo la licencia GNU GPL v3.

El código generado es valido para cualquier plataforma Arduino con arquitectura AVR: Uno, Mini, Nano, Leonardo, Mega, etc., aunque con algunos ajustes se podría adaptar a otras plataformas como Due, M0, MKR1000, ESP8266, etc.

Su funcionamiento es muy sencillo; todas las tareas relacionadas con la conexión a la red están incluidas en la librería estándar de Arduino para la Shield Ethernet con el chipset de WIZnet W5100 Ethernet.h. Pese a soportar DHCP, en la PoC se utiliza direccionamiento IP estático, indicándole todos los parámetros necesarios, IP, MASK, GW, e incluso DNS, junto con la MAC Ethernet, que es obligatoria en cualquier caso. Esta librería implementa también el servidor web (HTTP) necesario para atender las peticiones web.
La API REST se implementa en la librería aREST, creada por Marco Schwartz para mapear de forma sencilla las entradas y salidas de Arduino, pero en este caso no se utiliza dicha característica, y si sus facilidades para crear llamadas a funciones previamente definidas, a las que incluso les puede hacer llegar algunos parámetros de la petición HTTP GET.

Se ha definido una función específica de transmisión para cada uno de los tres protocolos a manejar, los cuales están implementados en sendas librerías: FlamingoSwitchde Karl-Heinz Wind para Flamingo 500, NewRemoteSwitchpara NewKAKU, y RemoteSwitch para FHT-7901, estas dos últimas desarrolladas por Randy Simons.

Las llamadas a las funciones son muy parecidas, ya que los tres protocolos funcionan de forma muy similar; vía web requieren pasar los siguientes parámetros mediante la clausula  params separados por el carácter punto “.” y en este orden:
  • Comando de acción; es decir, el comando de actuación a emitir que será reconocido por el dispositivo emparejado. En Flamingo y NewKAKU puede ser “on” para encender, off para apagar y dim para indicar el valor de un rango definido en dispositivos regulables (dimmers) que permiten regular la intensidad de una luz, por ejemplo, y no solo apagarla o encenderla. FHT solo soporta “on” y “off”.
  • Identificador de controlador; es decir, el identificador de un mando original. En Flamingo y NewKAKU es numérico, y en FHT se define según la posición de los cinco micro switch del mando. Si no se dispone de un mando original, o no podemos leer su identificador, podemos elegir cualquiera al azar y emparejar los dispositivos con él.
  • Identificador de dispositivo; es decir, el identificador del botón de un mando original emparejado con un dispositivo. En Flamingo y NewKAKU podemos elegir cualquiera al azar, ya que los dispositivos tienen la capacidad de reconocer el identificador al emparejarse. Por el contrario, en FHT debe corresponderse con la letra seleccionada en el micro switch del dispositivo.

Adicionalmente a los elementos propios para el funcionamiento de la PoC, tan solo se ha añadido un watchdog timercomo medida de protección ante un hipotético bloqueo del sistema (tras semanas de pruebas y uso intensivo no se ha dado el caso), y la impresión de mensajes de depuración por la salida Serie/USB de Arduino, tal y como se muestra a continuación:
Estos mensajes de depuración incluyen un identificador numérico negativo cuando se produce una condición de error, cuyo significado variará según sea el caso, por lo que hay que recurrir a los comentarios del código fuente para interpretarlo.
Dada la implementación de la API REST en la librería “aREST.h”, esta devolverá siempre un código de estado HTTP 200 OK, junto con una respuesta en formato JSON, ante cualquier petición web (HTTP GET) que se realice.

El array JSON de respuesta deberá contener siempre el elemento return_value con valor  cero “0” en caso de ejecución satisfactoria, o el valor negativo correspondiente al código de error producido en su defecto. La ausencia el elemento return_value puede considerarse también una condición de error, ya que indica que no se ha ejecutado ninguna de las tres funciones definidas para la transmisión de comandos de RF. A continuación se muestran los tres tipos de respuestas JSON citados:
Todo el código fuente de la PoC está publicado bajo licencia GNU GPL v3 en el siguiente repositorio de GitHub:

Se incluyen las partes utilizadas de todas las librerías necesarias, por lo que basta con clonar o descargarse el repositorio, y compilar el Sketch desde el IDE de Arduino, para comenzar a utilizarlo de forma tan sencilla como se muestra a continuación:

Este es el aspecto final del dispositivo IoT creado para la PoC propuesta:
Conclusiones

La gran mayoría de los sistemas IoT y Domóticos que hacen uso de la banda ISM de 433MHzen AM, lo hacen, por norma general, en ausencia de medidas de seguridad. No ofreciendo ninguna garantía de privacidad, autenticidad, o integridad; siendo posible interceptar y suplantar prácticamente cualquier comunicación.

No es necesario disponer de un costoso hardware específico; con tan solo unos económicos módulos genéricos y un Arduino o Raspberry PI, es suficiente para comenzar a experimentar en la banda.

Hay disponible una ingente cantidad de software que permite capturar las señales de radiofrecuencia, analizar los protocolos de comunicación, construir nuevos mensajes y emitirlos sin mayor dificultad.

Queda demostrado que la seguridad por oscuridad que persiguen algunos fabricantes no constituye una buena practica, siendo sobrepasada por la altruista práctica de compartir descubrimientos y código que realiza una amplia comunidad de desarrolladores.
    Jorge Rivera 
    CSA Global de ElevenPaths 

    Un año de NoMoreRansom.org, donde ElevenPaths es entidad asociada

    $
    0
    0
    Hace un año, el 25 de julio de 2016, la iniciativa No More Ransom comenzó gracias al esfuerzo de la Policía Nacional Holandesa, Europol, McAfee y Kaspersky Lab. Hoy ya son más de 100 los socios que se han unido a ella con el ánimo de prevenir y mitigar los principales ataques de ransomware que continúan dominando las noticias y golpeando a empresas, gobiernos e individuos de todo el mundo. Durante este año, la plataforma ha conseguido descifrar 28.000 dispositivos este año, y ElevenPaths forma parte del consorcio como entidad asociada gracias al desarrollo una de estas herramienta de descifrado. 





    La plataforma www.nomoreransom.org tiene el claro objetivo de, por un lado, asistir y permitir a las víctimas del ransomware la recuperación de su información cifrada sin tener que pagar a los criminales. Por otro, perseguir desde el plano legal a los responsables de estas estafas compartiendo información entre las fuerzas de seguridad. ElevenPaths aporta su experiencia en este campo desarrollando y ofreciendo gratuitamente una herramienta a esta iniciativa, lo que gracias a la labor del área de innovación y laboratorio, le ha permitido formar parte del consorcio, como una de las nueve entidades asociadas, junto con, entre otras, Avast, Bitdefender, CERT de Polonia, Check Point, Emsisoft y Kasperksy.

    La amenaza del ransomware está aumentando

    El Ransomware se ha disparado desde 2012, con los atacantes atraídos por la promesa de beneficios económicos y una fácil implementación. La amenaza continúa evolucionando, volviéndose más furtiva y destructiva, y está dirigiéndose cada vez más a las empresas porque los "retornos de inversión" potenciales son mucho más altos.

    El ataque indiscriminado de WannaCry a mediados de mayo causó más de 300.000 víctimas comerciales en 150 países en sus primeros días, paralizando infraestructuras críticas y negocios. Algunas organizaciones todavía están luchando para recuperarse de los ataques de ExPetya del 27 de junio.

    El número total de usuarios que se enfrentaron a un Ransomware entre abril de 2016 y marzo de 2017 aumentó un 11,4% en comparación con los 12 meses anteriores, de 2.315.931 a 2.581.026 usuarios de todo el mundo. Las estadísticas indican que estamos en presencia de la epidemia mundial de Ransomware.

    El primer año de No More Ransom en números

    El sitio cuenta actualmente con 54 herramientas de descifrado, proporcionadas por nueve asociados, que cubren 104 tipos (familias) de Ransomware. Hasta el momento, estas herramientas han conseguido descifrar más de 28.000 dispositivos, privando a los cibercriminales de unos 8 millones de euros en rescates.

    El portal ha contado con más de 1,3 millones de visitantes únicos. El 14 de mayo, durante la crisis de WannaCry, 150.000 personas visitaron el sitio web.

    La plataforma No More Ransom ya está disponible en 26 idiomas, con las adiciones más recientes: búlgaro, chino, checo, griego, húngaro, indonesio, malayo, noruego, rumano, sueco, tamil y tailandés.

    Más de 100 partners: Sin fronteras entre privados, públicos o competidores

    No More Ransom cuenta ahora con 109 partners. Las últimas incorporaciones incluyen, desde el sector privado: Abelssoft, Ascora GmbH, Barclays, Bitsight, Universidad de Bournemouth, CERT.BE, Claranet, CERT PSE, Agencia de Seguridad Cibernética de Singapur (CSA), ESTSecurity, Fortinet, Global Forum (GFCE), InterWorks, IPA (Agencia de Promoción de la Tecnología de la Información, Japón), KISA (Korea Internet & Security Agency), Munich RE, TWCERT / CC, LLC, Universidad de Porto y vpnMentor.

    Se han unido también cuatro agencias policiales, provenientes de República Checa, Grecia, Hong Kong e Irán. El éxito de la iniciativa No More Ransom es un éxito compartido, que no puede lograrse solo por las agencias policiales ni por la industria privada.

    PopCorn Decryptor y Latch ARW

    RecoverPopCorn es una utilidad desarrollada desde el área de innovación de ElevenPaths para solucionar la infección producida por el ransomware PopCorn. Con esta aportación se convierte así en uno de los miembros asociados a la alianza, que desde diciembre de 2016, ha ayudado a las más de 10.000 víctimas en todo el planeta.

    Para más información sobre ransomware y consejos de prevención podéis acudir a ElevenPaths, www.nomoreransom.org y utilizar herramientas propias de prevención como Latch ARW.

    Nueva versión de SDK Go para Latch

    $
    0
    0
    Importante: esta versión de SDK Go no es oficial de Eleven Paths.


    SDK Go para Latch
    Latch tiene varios SDK implementados en varios lenguajes conocidos como Python o .NET. pero hasta ahora no había ninguno para el lenguaje Go, el cual cada vez está ganando más popularidad. Rafael Troncoso (@tuxotron de @cyberhadesblog) ha creado una primera versión de un SDK en este lenguaje creado por Google. Hemos estado realizando varias pruebas de los módulos básicos para comprobar que todo funciona perfectamente y así preparar una serie de artículos explicando su funcionamiento. Este será el primero de varios relacionados a la utilización de este SDK realizando diferentes operaciones sobre Latch.




    El primer paso es obtener una cuenta de Latch ;) , directamente como desarrollador si no tienes ninguna, o puedes activar tu cuenta actual de usuario Latch como desarrollador (imagen superior). También será necesario instalar Go en la plataforma en el cual estemos trabajando Windows, Linux o Mac. Finalmente instalaremos la aplicación Latch para el teléfono móvil (puedes buscarla en la tienda de tu smartphone o desde la web)

    Para instalar el SDK de Latch para Go tienes que ejecutar el siguiente comando desde la shell de tu plataforma:

    # go get github.com/tuxotron//latch-sdk-go

    Una vez ejecutado este comando, el SDK debería de estar instalado en la siguiente ruta:

    $GOPATH/src/github.com/tuxotron/latch-sdk-go/

    Prácticamente eso es todo lo que tienes que hacer para poder usar el SDK. Por lo que ya podemos comenzar a probar nuestra aplicación. 

    Hay 2 valores que necesitaremos obtener desde la consola web de administración de Latch: Application ID y Secret. Estos valores pertenecen a la aplicación que hayamos creado. Desde el menú Manage Applications, seleccionamos el icono Edit de la aplicación que queremos proteger.


    En este caso de ejemplo, los valores son: YkmAJAX2W4v4JU9jP3Ce y 7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c, para Application ID y Secret respectivamente.

    Vamos a realizar a continuación algunas pruebas básicas para testear la ejecución de código en Go realizando algunas llamadas a Latch básicas.

    Crearemos un fichero de texto llamado main.go, por ejemplo, utilizando nuestro editor de texto favorito y escribimos el siguiente código:

    package main
    import (
    "github.com/tuxotron/latch-sdk-go"
    )
    func main() {
    const (
    AppId  = "YkmAJAX2W4v4JU9jP3Ce"
    Secret = "7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c"
    )
    credentials := latch.Credentials{AppId, Secret}
    application := latch.NewLatchApplication(credentials)
    }

    Este programa simplemente abrirá una instancia de nuestro servicio de Latch. Para poder asociar nuestra aplicación a Latch, desde la aplicación móvil tenemos añadir un nuevo servicio, si ya tenemos algún otro servicio pareado, o parear con Latch (Pair with Latch), si no tenemos ninguno pareado (recuerda que en Latch puedes crear varias aplicaciones al mismo tiempo).


    Una hemos elegido la opción de parear, la aplicación móvil nos muestra un token de 6 dígitos.


    De vuelta a nuestro código, vamos a añadir la llamada para realizar el pareo. El texto marcado en azul es el código que hemos añadido:

    package main
    import (
    "fmt"
    "github.com/tuxotron/latch-sdk-go"
    )
    func main() {
    const (
    AppId  = "YkmAJAX2W4v4JU9jP3Ce"
    Secret = "7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c"
    )
    credentials := latch.Credentials{AppId, Secret}
    application := latch.NewLatchApplication(credentials)
    res := application.PairWithToken("iMKUkV")

    if res.Error.Code != 0 {
    fmt.Println("Error Code:", res.Error.Code, ", Error Message:", res.Error.Message)
    } else {
    fmt.Println("OK")
    fmt.Println(string(res.Data))
    }
    }

    Este nuevo código realiza una  llamada a la función pair con el token recibido en la aplicación móvil:

    res := application.PairWithToken("iMKUkV")

    El resto del código simplemente imprime por pantalla el resultado de la llamada (no olvides el “fmt” en la sección de import). Si todo ha ido bien, cuando ejecutes tu código (go run main.go) recibirás el accountId. En nuestro caso este fue el resultado:

    OK
    {"accountId":"zZhqg7H9pabaZDDJg4y2HcFWCjZtDm6yXBg7QDdrKNjBJfreirxzjY74R2dtxbta"}

    Ese accountId es lo que usaremos ahora para comprobar el estado de nuestra aplicación en Latch. Cómo ya hemos pareado nuestra aplicación, la llamada a la función de pareo (PairWithToken(...)) ya no la necesitaremos más , así que la vamos a comentar y vamos a añadir la llamada para comprobar el estado de nuestro Latch (status(...)). De nuevo el texto en azul refleja las modificaciones que hemos realizado:

    package main
    import (
    "fmt"
    "github.com/tuxotron/latch-sdk-go"
    )
    func main() {
    const (
    AppId  = "YkmAJAX2W4v4JU9jP3Ce"
    Secret = "7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c"
    )
    credentials := latch.Credentials{AppId, Secret}
    application := latch.NewLatchApplication(credentials)
    // res := application.PairWithToken("iMKUkV")
    res := application.Status("zZhqg7H9pabaZDDJg4y2HcFWCjZtDm6yXBg7QDdrKNjBJfreirxzjY74R2dtxbta", false, false)

    if res.Error.Code != 0 {
    fmt.Println("Error Code:", res.Error.Code, ", Error Message:", res.Error.Message)
    } else {
    fmt.Println("OK")
    fmt.Println(string(res.Data))
    }
    }

    Hemos comentado la llamada a pair y hemos añadido la llamada a status. Esta función recibe tres parámetros. El primero de ellos es el accountId, el cual recibimos cuando hicimos el pareado y los otros dos son valores booleanos, que dictan como la aplicación móvil va a reaccionar (ver documentación Latch).

    Si ejecutamos nuestro código ahora y no tenemos nuestra aplicación bloqueada con Latch, deberíamos ver por pantalla algo como:

    OK
    {"operations":{"WcqfYQErkANrk7wfijgv":{"status":"on"}}}

    Como puedes recibimos dos valores, el ID de la operación y el estado. Latch te permite definir distintas operaciones dentro de una aplicación, por ejemplo, podríamos tener una operación que te permitiera hacer login y otra que te permita actualizar o crear registros, etc. En nuestro caso no tenemos definida ninguna operación por lo que Latch nos muestra la operación genérica para nuestra aplicación. El segundo valor que vemos es el estado de dicha operación. En este caso la operación está activa, no bloqueada.


    Si ahora nos vamos a la aplicación móvil, bloqueamos nuestra aplicación y volvemos a ejecutar nuestro código, obtendremos algo como:

    OK
    {"operations":{"WcqfYQErkANrk7wfijgv":{"status":"off"}}}

    Como podemos ver ahora el estado de nuestra operación está apagado o lo que es lo mismo la operación está bloqueada por Latch. Y además, como el tercer nuestros parámetros silent, lo hemos pasado con el valor falso, en la aplicación del móvil recibiremos una alerta:


    Resumiendo, para proteger un servicio con Latch tendremos que realizar los siguientes pasos:

    1.Obtener nuestro Applicaction ID y Secret
    2.Petición de pareo, llamar a la función PairWithToken con el token obtenido en la aplicación móvil.
    3.Guardar el accountId recibido en el pareo
    4.Para proteger cierta operación, llamamos a la función Status con el accountId, y comprobamos si el estado (status) está a ON, entonces permitimos el uso de dicha operación, si el estado está a OFF, evitamos la ejecución de la operación y notificamos al usuario con el algún tipo de error.


    Para terminar, si queremos desparear nuestra aplicación todo lo que necesitamos es llamar a la función Unpair, y le pasamos como parámetro el accountId:

    package main
    import (
    "fmt"
    "github.com/tuxotron/latch-sdk-go"
    )
    func main() {
    const (
    AppId  = "YkmAJAX2W4v4JU9jP3Ce"
    Secret = "7p9hrnmiWLf8EpbNcPFNfkaCrzPjW3kzTt2rrW9c"
    )
    credentials := latch.Credentials{AppId, Secret}
    application := latch.NewLatchApplication(credentials)
    res := application.Unpair("zZhqg7H9pabaZDDJg4y2HcFWCjZtDm6yXBg7QDdrKNjBJfreirxzjY74R2dtxbta")
    if res.Error.Code != 0 {
    fmt.Println("Error Code:", res.Error.Code, ", Error Message:", res.Error.Message)
    } else {
    fmt.Println("OK")
    fmt.Println(string(res.Data))
    }
    }

    Y si todo ha ido bien, veremos impreso por pantalla un OK y también recibiremos una alerta en el móvil.




    Estos son sólo los pasos básicos para comenzar a utilizar este SDK de Go. Vamos a seguir realizando pruebas que iremos publicando en este blog de ElevenPaths

    Fran Ramírez
    Investigador de ElevenPaths y escritor del libro “Microhistorias: anécdotas y curiosidades de la Informática” 


    Rafael Troncoso



    ElevenPaths Talks: Seguridad Defensiva vs Seguridad Ofensiva

    $
    0
    0

    Hoy a las 15:30h (CET) tienes una cita en nuestro canal de Youtube con nuestros expertos Claudio Caracciolo y Jorge Rivera, junto a un invitado especial. En esta ocasión, nos informarán sobre las ventajas y desventajas de las técnicas de seguridad defensiva frente a las de seguridad ofensiva. 

    ¿La seguridad de una empresa debe basarse en técnicas defensivas puras o debe evolucionar a técnicas ofensivas? En este webinar se quiere trabajar esta idea para que nuestros participantes puedan analizar junto a nuestros CSAs las ventajas y desventajas de cada uno de los modelos, y también plantear escenarios de convivencia dentro de una misma empresa, con un mismo objetivo: proteger los activos de información de la compañía.

    La duración de la sesión será de 50 minutos y estará dividida en tres bloques: el primero contará noticias interesantes sobre la temática a tratar, el segundo será el centro del ElevenPaths Talk, con el debate entre los dos CSAs, y por último 10 minutos sobre consejos y herramientas.

    Para aprender más sobre el tema, accede a la Comunidad de ElevenPaths para debatir con nuestros expertos y otros profesionales de la ciberseguridad, compartir opiniones y aprender sobre el mundo digital.

    Y si te has perdido los anteriores talks, te dejamos todos los seminarios completos de nuestras tres temporadas:


    Te esperamos hoy a las 15:30h (CET) en nuestro canal de Youtube. ¡No te lo puedes perder!

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

    Nueva herramienta: DirtyTooth para Raspberry Pi

    $
    0
    0
    Ya se ha liberado el código de Dirtytooth para Raspberry Pi. Durante la pasada RootedCON presentamos DirtyTooth, un nuevo tipo de ataque basado en un altavoz BlueTooth que aparte de reproducir música puede capturar la agenda de contactos de los dispositivos iOS. Una mala gestión de perfiles puede ser la causa de una fuga de información del dispositivo y aprovechando este fallo, se puede obtener una gran cantidad de información sobre el usuario y su entorno. Esto es lo que hace fundamentalmente DirtyTooth, aprovecharse de un problema de BlueTooth en la gestión de los perfiles y permitir, a través de lo que para el usuario es un simple altavoz por BlueTooth, demostrar que es posible extraer información sensible del dispositivo. 


    Para construir el altavoz "falso", es necesario integrar cierto software en el altavoz en sí. Esto no es trivial, por tanto hemos decidido, a modo de experimento instructivo, realizar una implementación del DirtyTooth Hack en Raspberry Pi, de forma que pueda ser usado en cualquier lugar. Y para que cualquiera pueda ver cómo funciona, ya está liberado el código de DirtyTooth para Raspberry Pi que convierte este dispositivo en un altavoz con el que realizar la demostración de este ataque.

    Aquí está el vídeo de cómo instalarlo: 



    Y aquí la charla que explica el ataque en detalle:



    La herramienta, desarrollada en el laboratorio de ElevenPaths, puede ser descargada desde aquí:
    https://github.com/ElevenPaths/DirtyTooth-RaspberryPi 
      
    Innovación y laboratorio
    www.elevenpaths.com
     
     

    Cuidado con a quién entregas tus datos biométricos. Parte 1.

    $
    0
    0
    Aunque los sistemas de reconocimiento biométrico existen hace décadas, en los últimos años hemos visto cómo se han popularizado su uso con su integración en smartphones y tabletas. 

    Especialmente hemos visto la adopción masiva de la huella dactilar como método seguro de desbloqueo en terminales de gama media y alta, aunque también existen otros métodos de reconocimiento biométrico de personas integrados en diversas apps como el reconocimiento facial en 2D o 3D, de iris, de voz o del patrón caligráfico. El reciente Samsung Galaxy S8 incorpora un avanzado sistema de reconocimiento de iris y previsiblemente el próximo iPhone incorporará un sistema de reconocimiento facial 3D dejando atrás el sensor de huella.

    Ilustración 1: Reconocimiento de Iris (licencia CC)

    La palabra biometría proviene de la combinación del termino griego bios que significa vida y del termino metron que significa medida. Entendemos por tanto la biometría como la ciencia que estudia el reconocimiento inequívoco de personas basado en uno o más rasgos físicos intrínsecos o bien de su conducta (conductuales).

    Los rasgos como la huella dactilar, su cara, su iris, etc. son rasgos intrínsecos. Estos rasgos son parte de la persona que no pueden cambiarse, salvo que esta se sometiese a una cirugía.

    Los rasgos conductuales son rasgos que reflejan la conducta del individuo y que si este quisiera podría cambiarlos, aunque en muchos casos le supondría un importante esfuerzo. Ejemplos de estos rasgos son la forma de andar, de hablar, de escribir, etc…

    Los sistemas de reconocimiento biométrico consisten casi siempre en un proceso muy similar. Se trata de capturar una imagen o muestra del rasgo biométrico a comparar, procesarlo para extraer un cierto número de características (p.e. puntos característicos de la huella dactilar conocidos como minucias como en la ilustración), codificar estas características extraídas en un vector y ejecutar un algoritmo de comparación de este vector con uno almacenado que damos por cierto y que pertenece al individuo al que queremos reconocer. A estos dos procesos se les conoce como procesos de extracción y de comparación de las características biométricas.

    Ilustración 2: Tipos de minucias de una huella dactilar (licencia CC)

    Existen factores que hacen que dos muestras de una misma persona tomadas en diferente momento no sean exactamente iguales. Esta diferencia se puede deber a factores externos como por ejemplo en el caso de la captura de la huella dactilar. Estos factores pueden ser el uso de diferentes dispositivos de captura con características diferentes de resolución y tecnologías de captura, la suciedad del lector, la posición del dedo durante la captura o su movimiento, la sudoración del individuo, las a enfermedades o heridas que producen alteraciones de la piel del dedo, las condiciones medioambientales como humedad, calor, etc…

    Por tanto, tenemos que esta comparación de vectores es compleja y su resultado no es certero sino probabilístico. El resultado de dicha comparación devuelve habitualmente una puntación o score que indica normalmente la probabilidad de que ambas huellas sean de la misma persona. En general se establece un umbral a partir del cual se asume como cierto el cotejo de ambas huellas admitiendo que puede existir un mínimo error.

    Si el umbral se establece muy alto se producen casos conocidos como falsos negativos (FRR - False Rejection Rate en inglés), es decir, que un usuario legítimo es rechazado puesto que el score que devuelve el algoritmo de comparación está por debajo del umbral fijado. Este comportamiento es molesto para el usuario, pero desde el punto de vista de la seguridad supone riesgo de acceso no autorizado. Digamos que hacemos que el algoritmo de comparación sea excesivamente estricto.

    Sin embargo, si establecemos el umbral muy bajo permitiremos que se produzcan los temidos falsos positivos (FAR – False Acceptance Rate), es decir, que el algoritmo dará por buena la comparación de una huella de otra persona y permitirá el acceso a un usuario no legítimo.

    El ajuste del algoritmo de comparación de biométrica se realiza estableciendo el umbral en su punto óptimo donde se minimice el número de errores producidos, tanto los falsos positivos (FAR – False Aceptance Rate) y los falsos negativos (FRR – False Rejection Rate), minimizando un índice combinado que se conoce EER (Equal Error Rate).

    Ilustración 3: Calculo de la tasa de error equivalente (EER) en un sistema biométrico (licencia CC)

    Desde el punto de vista de la seguridad y de la privacidad, uno de los riesgos más importantes es el tratamiento que se realiza de los datos biométricos. Los algoritmos de extracción procesan la imagen o muestra capturada para extraer un vector de características y de forma inmediatamente posterior suelen descartar la imagen o muestra procesada para evitar que sea comprometida almacenando sólo el vector de características.

    En general, a partir del vector de características extraídas no es posible recrear la imagen o muestra, ya que el vector tiene mucha menos información que la imagen o muestra, aunque la verdad es que ya existen aplicaciones que son capaces de crear muestras simuladas a partir de un vector de características.

    Por ejemplo, a partir de un vector de minucias o puntos característicos de una huella, algunas aplicaciones son capaces de componer una imagen de una huella completa aleatoria que al ser procesada genera el mismo vector de características que el indicado. Luego ya sólo quedaría imprimir dicha huella (os aseguro que es más fácil de lo que pensáis) y tratar de engañar al lector y algoritmo de comparación para suplantar al usuario legítimo.

    Para evitar las suplantaciones, casi todos los algoritmos incorporan técnicas conocidas como antispoofing. En el caso de la huella dactilar, los sensores incorporan tecnología para el liveness detection (detección de vida) mediante diversas técnicas entre las que destacan la medición de la conductividad de la piel humana durante la captura. En caso de usar plásticos o pieles sintéticas impresas con una huella dactilar, al no ser conductoras de electricidad, serían detectadas y rechazadas.

    En otros rasgos, para evitar falsificaciones a través de una grabación de la voz, una foto o video de la cara o el iris,… se le pide al usuario que realice una variación (p.e. que lea un texto aleatorio en caso de la voz, que guiñe un ojo, sonría o gire la cabeza en caso del reconocimiento facial, que pestañee en caso del iris o medidas anti-suplantación similares).

    Por ello es muy importante que ni la imagen o muestra capturada ni el vector de características extraídas por el algoritmo de comparación se puedan ver comprometido. En caso de que esto sucediera, las consecuencias pueden llegar a ser catastróficas para el individuo.

    Rames Sarwat 
    VP de Alianzas Estratégicas y Partnerships 

    INCIBE abre la convocatoria de su programa de aceleración internacional en ciberseguridad para startups con la colaboración de ElevenPaths

    $
    0
    0
    El Instituto Nacional de Ciberseguridad de España (INCIBE), entidad dependiente del Ministerio de Energía, Turismo y Agenda Digital, en su apuesta por el crecimiento de la ciberseguridad ha abierto la convocatoria de su Programa Internacional de Aceleración Cybersecurity Ventures. Un programa que ofrecerá un apoyo intensivo a los equipos de una selección de 10 startups en forma de capacitación, mentorización y vinculación con inversores, con el objetivo de madurar los negocios para atraer inversiones y ayudarlos a captar los primeros clientes.


    La iniciativa cuenta con la colaboración de la Junta de Castilla y León, a través del Instituto para la Competitividad Empresarial de Castilla y León (anteriormente ADE) y el Instituto Leonés de Desarrollo, Formación y Empleo (ILDEFE). Una colaboración que se ha materializado en un convenio suscrito por Pilar del Olmo, consejera de Economía y Hacienda de la Junta de Castilla y León, Alberto Hernández, director general de INCIBE y Antonio Silván, alcalde de León, en representación de ILDEFE.

    El acuerdo entre los tres organismos tiene como objeto la promoción del emprendimiento en ciberseguridad mediante el apoyo a la atracción de talento (incubadora de ideas) y la aceleración de proyectos emprendedores en materia de ciberseguridad que se ubicarán en León.

    Desde ElevenPaths apoyamos las iniciativas de emprendimiento en el área de ciberseguridad con colaboraciones con aceleradoras como Wayra e INCIBE Ventures. Nuestro CEO, Pedro Pablo Pérez, participará en el comité científico que contribuirá a la evaluación de los proyectos presentados.

    La Junta de Castilla y León, a través del Instituto para la Competividad Empresarial, proporcionará espacios gratuitos en el Parque Tecnológico de León para las fases de incubación y aceleración de proyectos. Además, en el marco del plan de acogida a startups, facilitará a los emprendedores un paquete de servicios especializados y ayudas y financiación a través de la Lanzadera Financiera.

    El Ayuntamiento de León, a través de Ildefe, promueve desde hace más de una década la actividad empresarial y comercial, favoreciendo la creación de empleo y emprendimiento. Colaborará en los servicios formativos y de consultoría a impartir en la incubadora de ideas y la aceleradora de proyectos y en los premios del concurso de aceleradora, así como en la difusión del proyecto en el tejido empresarial y emprendedor.

    Más información en incibe.es

    Cuidado con a quién entregas tus datos biométricos. Parte 2.

    $
    0
    0
    Si sucede que nuestro usuario y contraseña se ven expuestos, nos vemos obligados a cambiar nuestra contraseña para volver a una situación de control de nuestra identidad. Sin embargo, en caso de que uno de nuestros rasgos se vea comprometido y lo estemos usando para proteger el acceso a nuestra información, no tenemos la posibilidad de cambiar nuestro rasgo (al menos de forma fácil) para volver a retomar el control. En el caso de los rasgos conductuales, como es el caso de la voz o la firma, podríamos llegar a modificarlos pero imagino que coincidimos con que no sería muy deseable.

    El impacto de ver comprometidos nuestros datos biométricos es tan alto que la Comisión Europea financió desde el año 2008 al 2011 el proyecto TURBINE (TrUsted Revocable Biometric IdeNtitiEs) que tenía como objetivo crear identidades biométricas revocables.

    La mayoría de los terminales móviles que gestionan datos biométricos, como smartphones y tabletas, disponen de un chip de seguridad o una zona especial en su procesador en el que se almacena la información biométrica de los usuarios del dispositivo, así como el algoritmo de comparación formando lo que se conoce como un entorno confiable de ejecución (TEE – Trusted Execution Environment). Cuando una app quiere verificar una identidad, no tiene acceso ni a los datos biométricos capturados por el sensor, ni a los almacenados, ni al algoritmo de comparación. Tan solo recibe el resultado de la comparación realizada evitando que una app maliciosa pudiera hacerse con nuestros datos.

    Vamos con un n ejemplo de este TEE. El DNI electrónico español (no lo puedo evitar, acabo siempre hablando de él) dispone en su chip de dos de nuestras huellas dactilares almacenadas y del algoritmo de comparación en su interior que permite que en caso de olvidarnos del PIN de la tarjeta podamos acudir a una comisaría y en unos kioscos bastionados podamos capturar nuestra huella y establecer un nuevo PIN, todo ello de forma desatendida. El chip del DNI y su sistema operativo, que cuenta con la certificación de seguridad Common Criteria EAL4 actúa como TEE para nuestros datos biométricos.


    El reconocimiento biométrico hace más usable y conveniente para el usuario los procesos de autenticación. En la actualidad existen múltiples librerías y servicios online que nos permiten incorporar a nuestras apps y aplicaciones de escritorio mecanismos de reconocimiento biométrico de forma muy sencilla, pero es importante que nos planteemos que la responsabilidad de la custodia de dichos datos biométricos generados es exclusivamente nuestra y que debemos asegurarnos en la medida de lo posible que dichos datos no quedan expuestos o puedan ser manipulados.

    Si por un error u omisión, nuestra aplicación o apps permite que los datos biométricos de nuestros clientes, empleados o proveedores se vean expuestos, como dice nuestro Chairman Chema Alonso, solo habrá una cosa que podremos hacer y es decir “Lo siento”. Ya no tendremos una nueva oportunidad para corregir el problema generado.

    Si os estáis planteando incorporar a vuestra app un reconocimiento biométrico, es conveniente verificar las medidas de seguridad que incorporan las librerías o servicios web que pensáis utilizar, saber si estos cuentan con alguna certificación de seguridad y si se apoyan en mecanismos seguros de custodia de información como los TEE de los terminales.

    Adicionalmente, no está de más que verifiquéis vuestra app con algún sistema de análisis de vulnerabilidades de aplicaciones móviles como mASAPP de ElevenPaths. Esta herramienta es capaz de analizar en tiempo real e identificar de manera continua los riesgos de seguridad.



    Si por el contrario la aplicación en la que os estáis planteando incorporar un reconocimiento biométrico está basada en tecnología web, en este caso por la arquitectura de las aplicaciones web, mucho cuidado con los componentes y librerías que seleccionáis. Aquellos componentes basados en lenguajes, como JavaScript, al ejecutarse en el navegador y tener su código fuente accesible son muy vulnerables a ataques que permiten capturar, manipular o incluso inyectar datos biométricos a la aplicación. Ataques como XSS (del inglés Cross-Site Scripting) permitirían ejecutar en páginas web visitadas por el usuario códigos JavaScript que podrían manipular o exponer los datos biométricos.

    Es conveniente evitar este tipo de librerías dado que, aunque pueden ser muy convenientes, su uso pone en riesgo la identidad y datos personales de los usuarios de nuestra aplicación.

    Es una buena idea invertir tiempo y esfuerzo en hacerle la vida más fácil al usuario incorporando un reconocimiento biométrico en lugar de hacerle recordar complicadas passwords, pero el uso de éste nos puede generar una falsa sensación de seguridad. La biometría por sí sola no es más robusta que una contraseña y es una buena idea combinarla con otros factores de autenticación generando sistemas multifactor para hacerlos más seguros y usables.

    Los algoritmos de reconocimiento requieren de entornos seguros para la captura, extracción, almacenamiento y comparación de los datos generados. Sin ellos estaremos generando un entorno más vulnerable y de riesgo para las personas que utilicen nuestros sistemas.

    Nuestra recomendación es utilizar sistemas que hayan sido verificados y que cuenten con medidas de seguridad suficientes para no tener que lamentar fugas de información. Tengamos en cuenta que si exponemos las identidades biométricas de clientes, proveedores o empleados al intentar mejorar la usabilidad corremos un riesgo elevado que puede tener consecuencias de fugas de seguridad y de multas con una legislación cada vez más concienciada y vigilante con estos temas.

    Más información:
    Cuidado con a quién entregas tus datos biométricos. Parte 1.

    Rames Sarwat 
    VP de Alianzas Estratégicas y Partnerships 

    ElevenPaths en la RootedCON Valencia

    $
    0
    0
    El congreso RootedValencia 2017 celebra su cuarta edición durante los días 15 y 16 de septiembre de 2017 en la Fundación Universidad-Empresa de la Universitat de València (ADEIT). RootedCON Valencia es un Congreso de seguridad cuyo evento matriz, RootedCON es a su vez el congreso especializado más importante que se realiza en el país y uno de los más grandes de Europa. Cuenta con perfiles de asistentes que varían desde estudiantes, a Fuerzas y Cuerpos de Seguridad del Estado, pasando por profesionales dentro del mercado de la Tecnología y la Seguridad en TI o, simplemente, entusiastas de la tecnología. ElevenPaths participará con dos ponencias este año.



    Por un lado José Torres y Sergio de los Santos, que hablarán sobre cómo explotar los puntos ciegos de Certificate Transparency. En esta charla, detallaremos por un lado, quién y cómo está usando Certificate Transparency realmente. Por otro lado, se realizará una profunda incursión en los puntos ciegos de la especificación de CT, con el objetivo de explotarlos desde el punto de vista del atacante que pretende crear un "rogue certificate" y realizar un bypass de Certificate Transparency y las limitaciones que supone este mecanismo. De este modo, se podrían seguir ejecutando ataques tradicionales como por ejemplo MiTM, que pretenden precisamente ser mitigados con CT.

    Por otro, Pablo González y Francisco Ramírez presentarán "Anatomy of a modern malware: How easy the bad guys can f*** the world". En la charla se detallará cómo de fácil es modular, por un bad boy, un malware a través de vulnerabilidades y técnicas publicadas en el último año: la técnica Fileless & Fileless2 para hacer bypass UAC o crear persistencia en Windows sin crear un archivo en disco ya ha sido utilizada en campañas de malware; La vulnerabilidad Eternalblue ha sido aprovechada para propagar malware a través del protocolo SMB; La lacra del ransomware sigue siendo utilizada para obtener un beneficio directo y, hoy en día, cualquier usuario puede modularizar las partes y hacer un malware más potente... ¿Estamos preparados para luchar contra todo esto?

    Otros ponentes este año serán José Selvi, Jaume Martín, Elías Grande, Paula de la Hoz, Alfonso Muñoz y Miguel Hernández. Nuestros compañeros Pablo San Emeterio y Pablo González participarán además en los talleres de formación.

    Code Talks for Devs: Nueva serie de webinars sobre programación para desarrolladores

    $
    0
    0


    ¿Preparados para la nueva serie de ElevenPaths Code Talks for Devs? El 13 de septiembre lanzamos esta serie de webinars sobre temáticas de programación para desarolladores. Las sesiones serán quincenales, los miércoles, y comenzarán a las 15.30h (CET). Los talks serán en castellano y se presentarán en el canal de YouTube de ElevenPaths, en el que podrás comentar y preguntar en directo a nuestros expertos y CSAs. Posteriormente se mantendrán publicados para que puedas verlos tantas veces como quieras.





    Si tienes espíritu hacker, únete a los expertos en ElevenPaths Code Talks for Devs y participa en nuestros seminarios online gratuitos. No te pierdas la oportunidad de profundizar sobre lenguajes de programación, código, integraciones técnicas, APIS y mucho más. A continuación, os dejamos el listado por fechas de los webinars y el tema que será expuesto:

    • 13 de septiembre  de 2017. Di adiós al ‘polling’ en Latch con los nuevos Webhooks por Javier Espinosa.
    • 27 de septiembre de 2017. SDK de Go para Latch por Fran Ramírez y Rafael Troncoso.
    • 11 de octubre de 2017. Implementación de Data Exfiltration con Latch’sApp por Álvaro Nuñez-Romero y Pablo González.
    • 25 de octubre de 2017. DirtyTooth: Instalación en tu Raspberry con un paquete DEB por Álvaro Nuñez-Romero y Pablo González.
    • 8 de noviembre de 2017. Latch Cloud TOTP en NodeJS y .NET por Carlos del Prado y Ioseba Palop.
    • 22 de noviembre de 2017. MicroLatch: Construyendo Latch en la palma de tu mano por Álvaro Nuñez-Romero.
    • 13 de diciembre de 2017. Detección de anomalías en el tráfico de red utilizando Machine Learning por Carmen Torrano.
    • 27 de diciembre de 2017. Proteger tu OpenWRT integrando Latch a distintos niveles por Javier Alcaraz.
    • 10 de enero de 2018. Limited Secrets. Distribuye tu secreto Latch sin riesgo por Javier Espinosa.

    ¿Quieres enterarte de todo antes que nadie? No te lo pierdas, ¡suscríbete a nuestro blog y pregunta en nuestra comunidad! Os esperamos para que nuestros expertos os enseñen las temáticas más geeks en el mundo de la programación. Recuerda que tienes una cita el próximo 13 de septiembre a las 15.30h (CET).

    Más información próximamente en:

    Una sanidad conectada y sin papeles

    $
    0
    0
    Durante los juicios de Nüremberg, celebrados entre 1945 y 1946, se juzgaron a un grupo de 24 doctores por realizar experimentos en prisioneros de guerra en los campos de concentración nazi durante la Segunda Guerra Mundial. 

    A raíz de este juicio y sus deliberaciones posteriores, se creó el Código de Nüremberg,  publicado el 20 de Agosto de 1947, que establece los principios que han de regir en la experimentación con seres humanos. El código está formado por diez puntos entre los que se incluye el Consentimiento Informado (CI) y cuya finalidad era garantizar el derecho legal de toda persona a decidir libremente sobre su participación en un experimento médico. 

    En la actualidad, el Consentimiento Informado es un proceso de relación entre el profesional sanitario y paciente. El paciente recibe del profesional sanitario una información comprensible y suficiente que le permite participar en las decisiones respecto a su diagnóstico y tratamiento, garantizando su libertad en la toma de decisiones que afectan a su salud.  


    En aquellos procedimientos que implican riesgos significativos para la salud del paciente, el proceso debe ser presentado por escrito dando lugar al Formulario de Consentimiento Informado (FCI).  El FCI es específico para el paciente y su tratamiento, y debe estar firmado y fechado tanto por el profesional sanitario como por el paciente o su representante legal y una copia del formulario de consentimiento firmado estará siempre disponible para el paciente y para su médico.

    Ilustración 1: El formulario de Consentimiento Informado (FCI) para intervenciones de riesgo para la salud del paciente

    Todos los hospitales y clínicas, tanto públicas como privadas, gestionan hoy en día millones de estos documentos para cumplir con la legislación y normativa vigente. Los FCI firmados pasan a formar parte de la historia clínica del paciente, y por tanto, deben ser custodiados a largo plazo junto como parte de su historia clínica. 

    En muchos centros sanitarios, el FCI es hoy un documento en papel, que debe ser impreso y posteriormente firmado. Por lo general, después de su firma el documento se envía para su digitalización con el fin de ser anexado a la historia clínica electrónica del paciente y el original en papel a un archivo físico para su custodia.

    La gestión de los FCI requiere dedicación de recursos administrativos e implica ciertos riesgos para el centro relacionados con su extravío o deterioro, error en su indexado y dificultad de control para asegurar que se cumple con esta obligación. Al mismo tiempo obliga a mantener costosos archivos físicos de documentos.

    La transformación del FCI en un documento electrónico supone muchas ventajas desde el punto de vista de costes, seguridad y eficiencia en su gestión pero se encuentra con el desafío de su firma. Aunque desde hace tiempo es posible la firma digital de documentos electrónicos, para ser una firma legal en España, requiere que los firmantes dispongan de un certificado digital emitido por una autoridad de certificación reconocida e incluida en el registro que mantiene el Ministerio de Energía, Turismo y Agenda Digital.

    Se trata por tanto de encontrar un método que cuenten con validez suficiente desde el punto de vista legal para la firma de los FCI en formato electrónico y al mismo tiempo sea universal y fácil de utilizar. 

    Quizá, el hecho de ser el país europeo que más documentos de identificación electrónica ha emitido (hasta la fecha más de 31 millones de DNI electrónicos) y que dicho documento contenga un certificado digital reconocido nos puede hacer pensar en que sería el método apropiado para la firma de los FCI.
    Sin embargo, hay que tener en cuenta que el uso de la faceta electrónica del DNIe es muy bajo, no toda la población dispone de él y en el ámbito sanitario se atienden a muchas personas que o bien no disponen de él (p.e. extranjeros) o bien no saben o quieren usarlo (p.e. personas mayores).

    También es razonable pensar en proporcionar una tarjeta profesional con chip a todos los profesionales sanitarios que contenga un certificado digital que les acredite como profesionales sanitarios y les permita firmar electrónicamente mediante su posesión y el conocimiento de un número personal (PIN). Sin embargo, este esquema no parece viable para ser extendido por su complejidad y altos costes.

    Ilustración 2: La firma de los profesionales sanitarios de los FCI (licencia CC)

    La firma digitalizada con parámetros biométricos (firma biométrica) se basa en la firma manuscrita de una persona realizada sobre un dispositivo con pantalla táctil que durante la firma registra parámetros como la velocidad y presión. A partir de estos datos capturados, un algoritmo matemático genera un patrón caligráfico único para cada persona que permite verificar en cualquier momento que esa persona y sólo ella ha firmado ese documento. 

    Estos algoritmos biométricos de firma digitalizada se basan en la traslación al mundo digital de las técnicas empleadas desde hace años por los peritos calígrafos con el fin de determinar la autoría de una firma en papel y su validez desde el punto de vista legal como método de firma. Con esta firma se permite demostrar que el autor de la firma es quien dice haberla hecho (autenticidad) y sirve como método o forma de mostrar la aprobación sobre lo firmado (consentimiento).

    Mediante la combinación de algoritmos biométricos y la firma digital es posible conseguir un método de firma universal de FCI en formato electrónico que pueda ser firmado de forma similar a como se firma hoy un formulario en papel y con validez legal en caso de disputa judicial. Esta validez legal ha sido constada a través de estudios realizados por prestigiosos despachos de abogados y por peritos calígrafos independientes.

    La gestión de los FCI en formato electrónico permite un ahorro significativo de costes con un retorno rápido de la inversión, en la mayoría de los casos, en un periodo inferior a un primer año además de mejorar el cumplimiento legislativo y normativo y proporcionar mayor eficiencia al proceso.
    La tecnología de firma digitalizada biométrica de ElevenPaths, denominada SealSign BioSignature, ha permitido a diferentes entidades sanitarias implantar con éxito la firma de los FCI con una excelente aceptación por parte de los pacientes y los profesionales sanitarios, contribuyendo a reducir los costes asociados a la gestión de dichos documentos en papel y asegurar el cumplimiento legal.

    Rames Sarwat
    Head of Strategic Alliances & Partnerships



    ElevenPaths Talks: Inteligencia Artificial & Machine Learning

    $
    0
    0





    Hoy a las 15:30h (CET) no te puedes perder una nueva edición en nuestro canal de Youtube en la que nuestros expertos Diego Espitia y Rames Sarwat analizarán cuestiones específicas sobre Inteligencia Artificial y Machine Learning, siempre desde la óptica de la seguridad de la información.

    Estas tecnologías llevan varios años en desarrollo y perfeccionamiento de procesos de aprendizaje automático y la aplicación de ambas en hábitos de seguridad son por lo general muy bien recibidas y analizadas, pero ¿el futuro de la Inteligencia Artificial y Machine Learning nos acerca más al concepto de la Skynet?, ¿estamos muy lejos de lo que se predice en los relatos de ciencia ficción?

    Todas las respuestas en este nuevo webinar cuya duración será de 40 minutos y se impartirá en castellano. Para aprender más sobre el tema, accede a la Comunidad de ElevenPaths y debate con nuestros expertos y otros profesionales de la ciberseguridad, comparte opiniones y aprende sobre el mundo digital.

    Y si te has perdido los anteriores talks, te dejamos todos los seminarios completos de nuestras tres temporadas:

    » ElevenPaths Talks - Temporada 1
    » ElevenPaths Talks - Temporada 2 
    » ElevenPaths Talks - Temporada 3

    Te esperamos hoy a las 15:30h (CET) en nuestro canal de Youtube. ¡No te lo pierdas!

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

    Viewing all 1287 articles
    Browse latest View live