¡Hola hackers! Un mes más, presentamos los eventos en los que participamos y que no debes de perderte para estar al día en seguridad informática.

Security Day 2018 - Cybersecurity On Board

Ya tenemos fecha para nuestro evento anual de ciberseguridad consolidado como un evento de referencia en el sector de la seguridad de la información y TIC a nivel nacional, Security Day 2018. El próximo 30 de mayo celebraremos esta jornada anual en la que presentamos, de la mano de nuestros partners y expertos, las últimas novedades de nuestras tecnologías.

Este año nuestro lema es 'Cybersecurity On Board', un valor intrínseco a todos los productos de la compañía que se materializa en un viaje de acompañamiento end to end. Un sello de calidad que garantiza un camino seguro para que las empresas que confían en nuestros servicios crezcan. Un viaje, en el que ElevenPaths acompaña a todos sus clientes, hasta lograr que alcancen la madurez en seguridad de cada uno de ellos necesita.

Accede a la web del evento y entérate de todas las novedades tecnológicas que vamos a presentar el próximo 30 de mayo en el Auditorio Central de Telefónica, Madrid. Además, también puedes encontrar información sobre la agenda, los ponentes e información sobre ediciones anteriores. Reserva tu asiento cuanto antes porque el aforo es limitado. ¡Regístrate aquí!

Security Day 2018 - Cybersecurity On Board imagen

Además, no te olvides de seguir el hashtag #SD2018 con el que comunicaremos las últimas actualizaciones del evento. Síguenos en nuestra red social Twitter: @ElevenPaths

Hack Miami Conference
El próximo 19 de mayo el CSA Manager, Claudio Caracciolo, junto a Rafael Ortiz, viaja a Florida para asistir a la conferencia HackMiami 2018. Presentarán la charla de "Breaking out HSTS (and HPKP) on Firefox and Chrome" a las 10:00h (CST). Accede a la web y regístrate al evento.

Info Security 2018

Fabián Chiera, CSA panameño, estará el miércoles 23 de mayo en Info Security 2018, uno de los eventos líderes en ciberseguridad e IT de México. Además, consta con un programa educativo de alto nivel con expertos naciones e internacionales. Fabián hablará sobre Blockchain y los Smart Contracts, seguridad más allá de la criptografía.

Big Data for Social Good 2018 - LUCA

LUCA, la unidad de Telefónica especializada en Big Data, celebra la mañana del próximo 24 de mayo, el evento anual Big Data for Social Good 2018, con el lema "Ready for a Wild World".

Vivimos en un mundo cada vez más digitalizado en el que la actividad humana genera una inmensa cantidad de datos. Toda esta información, junto a un análisis avanzado de la misma, está ayudando a cambiar y mejorar nuestra sociedad: desde señalar zonas de riesgo de inundación hasta analizar el nivel de analfabetismo en zonas de difícil acceso o predecir la difusión de enfermedades como el Zika. Accede a la web del evento para más información.

Big Data for Social Good 2018 - LUCA imagen

ElevenPaths Talks

Si eres de los que les apasiona el mundo de la tecnología y seguridad, no te pierdas este webinar de nuestra serie #11PathsTalks en el que nuestros CSAs e invitados estrellas hablan sobre Smart Contract. También, mencionarán las principales recomendaciones de seguridad a la hora de elaborarlos, y las diferentes técnicas de auditoría de código y verificación de contratos. No te pierdas este webinar con casos de usos prácticos y reales donde ya se está utilizando esta tecnología de forma exitosa. ¡Aprende con nuestros CSAs!

Code Talks for Devs
El próximo 23 de mayo, los expertos Guillermo Román Ferrero y Javier Gutiérrez Navío hablan sobre 'Air Profiling' y cómo hacer perfiles de usuarios procesando su tráfico de red. No te pierdas este webinar en el que explicamos este proyecto y su objetivo principal: explotar las inseguridades en las redes Wireless y el uso de protocolos no seguros. ¿Quieres saber más? Apúntate la fecha, te esperamos.

Code Talks for Devs: Hidden Networks imagen

Esto es todo hacker, os esperamos el mes que viene con muchos más eventos y conferencias de hacking y ciberseguridad. Let's hack!

Los SIEM suelen utilizarse en ambientes de alta seguridad o regulados, donde se requiere un monitoreo y análisis de logs periódico en busca de incidentes de seguridad. Ayudan a que una red esté más segura, sí… pero… nos preguntamos un poco más allá: ¿realmente los logs de los equipos de nuestra infraestructura están adecuadamente protegidos? Vamos a abordar en esta entrada unas pautas mínimas que se deben tener en cuenta para securizar un SIEM, poniendo como ejemplo y caso de uso una investigación particular sobre Splunk, uno de los SIEM más conocidos.

Hace un tiempo atrás, en uno de nuestros webinars de #11PathsTalks, @holesec y @DaPriMar nos hablaban sobre qué es un SIEM y sobre correlación avanzada. Analizaremos las distintas cuestiones que pueden influir de forma positiva o negativa en la seguridad de un SIEM, pero en este caso nos basaremos en Splunk. Como cualquier SIEM, permite buscar, monitorear y analizar información generada por diferentes equipos de la infraestructura, en su caso por medio de una interfaz web. Este software captura, indexa y correlaciona información en tiempo real en un repositorio que permite generar gráficos, reportes, alertas y diferentes visualizaciones. Según su web, tiene más de 3700 clientes, incluyendo más de la mitad de las Fortune 100. Las versiones de Splunk más utilizadas son tres: Splunk Free, Splunk Enterprise y Splunk Cloud. También hay una versión light que se utiliza principalmente para AWS pero que no analizaremos en esta oportunidad.

Si bien es posible analizar un SIEM desde muchos posibles vectores de ataque, para esta primera aproximación en particular nos gustaría centrarnos en 4 puntos en concreto:

Métodos de autenticación
Usuarios de instalación
Administración e instalación de aplicaciones
Exposición a Internet

En base a esto y trabajando en el análisis sobre las diferentes versiones, nos hemos encontrado con algunas curiosidades que mencionamos a continuación, y que podrían servir como "molde" para el análisis de cualquier sistema de este tipo.

Métodos de autenticación

Splunk Free no posee ningún tipo de autenticación, cualquier usuario que conozca la dirección IP y el puerto correspondiente puede iniciar sesión en Splunk con privilegios administrativos. En la misma web del fabricante indica claramente que esta versión no es adecuada para ambientes corporativos.

Splunk Enterprise posee varias opciones de métodos de autenticación a elegir (Splunk, LDAP, Scripted, SAML, ProxySS) que se configuran en el archivo

$SPLUNK_HOME/etc/system/local/authentication.conf.

La autenticación propia de Splunk (método de autenticación seleccionado por defecto) tampoco es adecuada para ambientes corporativos ya que el único parámetro de contraseña que permite configurar es la longitud de contraseña, y por defecto se encuentra configurada con valor 0. Splunk no permite configurar bloqueo por intentos fallidos de acceso, lo cual lo hace susceptible a ataques de fuerza bruta, ni tampoco reglas que garanticen la complejidad de contraseñas. El usuario por defecto de la versión Enterprise es admin y su correspondiente contraseña "changeme".

Splunk Cloud viene en dos versiones diferentes, Managed Splunk Cloud y Self-Service Splunk Cloud. Para diferenciar uno de otro se puede analizar la URL. Las URLs de los Self-Service son del estilo: https://prd-*.cloud.splunk.com y las URLs de los Managed son del estilo: https://*.splunkcloud.com. En los Splunk Self-Service los usuarios se autentican con su cuenta de splunk.com que tiene restricciones de longitud y complejidad de contraseña. En los Splunk Managed los usuarios pueden autenticarse por medio de SAML, aunque suele utilizarse la autenticación propia de Splunk ya que viene por defecto. Si bien trae configurada una longitud máxima de 8 caracteres, es el único parámetro que permite configurar.

Es importante tener en cuenta que al configurar Splunk para utilizar otro método de autenticación que no sea la autenticación propia (como por ejemplo LDAP), todas las cuentas de usuario locales con autenticación propia de Splunk siguen activas (incluyendo la cuenta admin). Para eliminar todas las cuentas locales se debe dejar en blanco el archivo $SPLUNK_HOME/etc/passwd. Este archivo no debe ser eliminado, ya que , en caso contrario, se vuelve al usuario por defecto admin con contraseña "changeme".

Usuario de instalación

Tanto Splunk Free como Enterprise pueden ser instalados con privilegios de root en plataformas Linux/Unix, con privilegios administrativos en plataformas Windows o con usuarios con menores privilegios en ambas plataformas, configurando adecuadamente los permisos necesarios en el sistema de ficheros. Esta última opción es la más recomendada en ambientes corporativos ya que reduce la superficie de ataques en caso de que Splunk sea comprometido. La documentación de instalación de Splunk indica cómo realizar la instalación con usuarios con privilegios restringidos en las diferentes plataformas. También los universal forwarders o clientes de Splunk que se instalan en los equipos de los cuales se van a recolectar logs, deben ser instalados con usuarios de privilegios limitados, puesto que podrían ser usados para ejecutar comandos o scripts enviados desde el servidor Splunk utilizándolo como deployment server.

Administración e Instalación de Aplicaciones

Splunk Free y Enterprise pueden administrarse de diversos modos: desde la consola web, el Splunk CLI, modificando los archivos de configuración correspondientes en el sistema operativo o utilizando la REST API. Tanto Splunk Free como Enterprise permiten la instalación de aplicaciones "custom" o creadas por el usuario (por ejemplo en Python) además de las presentes en Splunkbase, que es el repositorio oficial de aplicaciones y add-ons de Splunk. La instalación de aplicaciones creadas por el usuario presenta riesgos, ya que una vez comprometido el servidor Splunk se podría instalar cualquier tipo de aplicación maliciosa que, por ejemplo, permita administrar el servidor por medio de un web shell o un reverse shell(siempre teniendo en cuenta los permisos de la cuenta de usuario utilizada para la instalación de Splunk), o se envíe a los universal forwarders para comprometer a los equipos clientes de Splunk.

En Splunk Cloud no se tiene acceso para administrar Splunk desde el CLI ni al sistema de ficheros para modificar los archivos de configuración. Se pude utilizar Splunk Web y la REST API para realizar algunas tareas administrativas. Tampoco se puede instalar cualquier aplicación, sino únicamente las aprobadas por Splunk para ser usadas en un ambiente cloud. Las aplicaciones antes de ser aprobadas pasan por una validación por medio de la herramienta AppInspect que determina si cumplen con los requisitos de seguridad definidos, como por ejemplo: no requerir elevación de privilegios con sudo, su, groupadd o useradd, no usar reverse shells, no manipular archivos fuera del directorio de la aplicación, no manipular procesos fuera del control de la aplicación ni el sistema operativo, ni reiniciar el servidor.

Exposición a Internet

Búsqueda en Shodan de servidores Splunk

En el caso de Splunk Free y Enterprise, no es recomendable exponer la interfaz web (puerto por defecto 8080) ni la interfaz de management (puerto 8089) a Internet. Sin embargo, lamentablemente, es una práctica bastante común como se puede apreciar en el buscador Shodan buscando por http.component:"splunk" donde aparecen casi 8000 equipos. También es posible identificar de qué tipo de Splunk se trata analizando el código fuente de la página de login del mismo Splunk:

[dirección ip="" n=""]:[puerto]/en-US/account/login?return_to=%2Fen-US%2F[/puerto][/dirección]

"isFree":true nos indica que se trata de un Splunk Versión Free (sin autenticación)
"instance_type":"cloud" nos indica de que se trata de Splunk versión Cloud
"instance_type":"download" y "product_type":"enterprise" nos indican que se trata de un Splunk Versión Enterprise.
"hasLoggedIn":false nos indica que ningún usuario inició sesión en el equipo, lo cual es un claro indicador de que ese Splunk aún mantiene la contraseña por defecto ya que nadie pudo iniciar sesión para cambiarla.

Como dato curioso, para el caso particular del análisis de Splunk, nos hemos encontrado con que al momento de instalación, se crea un archivo con la clave a utilizar para cifrar información de autenticación en archivos de configuración y para cifrar las claves utilizadas por las diferentes aplicaciones. Esta clave se encuentra en el archivo

$SPLUNK_HOME/etc/auth/splunk.secret

y es única por cada instalación de Splunk. Las aplicaciones que se bajan de Splunkbase (como por ejemplo el addon que permite la integración con Active Directory, o los que permiten integrar Splunk con dispositivos de comunicaciones) necesitan almacenar credenciales en los archivos de configuración de la propia aplicación. Splunk cifra esas contraseñas por medio de splunk.secret. El riesgo en este caso, es que una vez comprometido el servidor Splunk, se puede utilizar la misma API de Splunk para descifrar la contraseña de estas aplicaciones con un simple script de Python y así poder comprometer otros componentes de la infraestructura.

Conclusiones

Como en muchos otros ámbitos, se pueden proteger los equipos de la infraestructura, y el servidor donde se encuentra instalado el SIEM eligiendo adecuadamente la versión a utilizar y configurándolo de manera segura (siguiendo las mejores prácticas del fabricante). Lógicamente, ante una infraestructura tan delicada,cualquier error podría exponer información muy valiosa para los atacantes, e incluso algunas veces podría dar a conocer claves de las aplicaciones internas de la organización. En este ejemplo nos hemos centrado en Splunk como "caso práctico" pero, en general para realizar el hardening de un SIEM, deberían considerarse los siguientes aspectos:

Utilizar un usuario no privilegiado (ni root ni administrador) para la instalación
Modificar las contraseñas por defecto apenas instalado
Seleccionar un método de autenticación robusto y asegurarse que no existan formas fáciles de eludirlo (como vimos en el caso de Splunk que requería borrar el archivo $SPLUNK_HOME/etc/passwd)
Utilizar certificados en la interfaz web, preferentemente no autogenerados
Deshabilitar el componente web en caso de no utilizarlo
No exponer los puertos del SIEM a redes no confiables
Actualizar el SIEM regularmente, e incorporarlo en el alcance de las auditorias o test de intrusión que se realicen periódicamente
Activar la auditoria propia del SIEM y monitorear los eventos resultantes

Para cerrar este post, y dado que hemos hablado de Splunk durante nuestro análisis, recopilamos a continuación los enlaces propios del fabricante con las mejores prácticas para proteger estos equipos:

Yamila Levalle

Equipo de Innovación y Laboratorio de ElevenPaths

Yamila.levalle@11paths.com

@ylevalle

Un grupo bipartidista de legisladores de la Cámara de Representantes ha introducido una legislación que impediría al gobierno federal de Estados Unidos exigir a las empresas que diseñen tecnología con backdoors y así garantizar el acceso de las fuerzas de seguridad a cierta información. Este proyecto de ley representa el último esfuerzo de los legisladores en el Congreso para eliminar la batalla entre los funcionarios federales encargados de hacer cumplir la ley y las empresas de tecnología sobre el cifrado, que alcanzó un punto de ebullición en 2015 cuando el FBI se peleó con Apple por un iPhone bloqueado vinculado al caso del atentado terrorista de San Bernardino.

Sin embargo, no ha sido la única compañía que ha tenido problemas con la justicia durante años anteriores. El vicepresidente de Facebook en Latinoamérica también fue detenido por la Policía Federal de Brasil al negarse a compartir información con las autoridades por una investigación sobre el tráfico de drogas. En este sentido, en 2016 algunos de los fabricantes comenzaron a tomar medidas para adecuarse a las necesidades de los nuevos tiempos en materia de privacidad. La implementación del cifrado punto a punto, como fue el caso de Whatsapp, o el reporte periódico que hace Google sobre el número de peticiones de información sobre sus usuarios por parte de las Fuerzas y Cuerpos de Seguridad, han sido algunas de ellas.

Sin embargo, esta situación con las tecnológicas también ha provocado que en algunos países como Rusia se presione desde el gobierno a la implantación de backdoors desde la legislación o que en otros como China se obligue a las tecnológicas a colaborar en aquellos temas considerados como seguridad nacional. Aunque a veces veamos muy lejanas estas medidas, se tiene cierto temor que el terrorismo, por ejemplo, que tanto está impactando en Occidente pudiera provocar cierto cese de nuestras libertades a cambio de una mayor sensación de seguridad.

Más información en The Hill

Noticias destacadas

Google y Microsoft piden al gobernador de Georgia que vete el proyecto de ley sobre hack back

Google y Microsoft piden al gobernador de Georgia, Nathan Deal, que vete un proyecto de ley bastante controvertido que permitiría criminalizar el "acceso no autorizado a equipos" en el que una compañía podría llevar a cabo operaciones ofensivas. La Asamblea General de Georgia aprobó el proyecto de ley a fines de marzo y lo envió a Deal, quien tiene 40 días para firmarlo. La ley ha sido acogida de forma negativa por la comunidad ya que pondría tener un impacto escalofriante en la investigación legítima de un incidente. De esta manera, representantes de Microsoft y Google escribieron una carta fechada a 16 de abril en el que se centran en una de las disposiciones del proyecto donde aseguran que esta ley otorga a las compañías la suficiente autoridad como para realizar operaciones ofensivas con fines competitivos.

Más información en Legis

En busca de unas elecciones en Estados Unidos sin injerencias extranjeras

Con las elecciones primarias en Estados Unidos a punto de entrar en pleno apogeo, el Departamento de Seguridad Nacional se está poniendo al día para ayudar a garantizar que los sistemas electorales estatales estén seguros contra la manipulación de terceros. Dicho departamento ha comentado que ha completado las evaluaciones en sólo nueve de los 17 estados que los han solicitado formalmente hasta ahora. Sin embargo, se ha comprometido a hacerlo en noviembre para cada estado que lo solicite. Los funcionarios de Seguridad Nacional atribuyen el atraso a una mayor demanda de tales revisiones desde las elecciones presidenciales de 2016 y aseguran que están dedicando más dinero y recursos para reducir los tiempos de espera. Las revisiones suelen durar dos semanas cada una.

Más información en Fifthdomain

Noticias del resto de la semana

Errores graves en PGP y S/MIME pueden revelar correos electrónicos cifrados en texto plano

Un equipo de investigadores de seguridad europeos ha publicado una advertencia sobre un conjunto de vulnerabilidades críticas descubiertas en las herramientas de cifrado PGP y S/MIME que podrían revelar sus correos electrónicos cifrados en texto plano. Para aquellos que no lo sepan, PGP es un estándar de cifrado punto a punto de código abierto que se utiliza para cifrar correos electrónicos de forma que nadie pudiera interceptarlos. Por su parte, S/MIME es una tecnología basada en criptografía asimétrica que permite a los usuarios enviar correos electrónicos firmados digitalmente y cifrados. La Electronic Frontier Foundation (EFF) también ha confirmado la existencia de vulnerabilidades "no reveladas" y ha recomendado a los usuarios que desinstalen las aplicaciones PGP y S/MIME hasta que se reparen las fallos.

Más información en EFF y Efail

Se descubre un error grave en Signal para Windows y Linux

Investigadores han descubierto una grave vulnerabilidad en la popular aplicación de mensajería Signal para Windows y Linux que podría permitir a los atacantes ejecutar código malicioso de forma remota en el sistema del destinatario con sólo enviar un mensaje, sin requerir la interacción del usuario. Aunque los detalles técnicos de la vulnerabilidad no han sido revelados hasta ahora, el problema parece ser una vulnerabilidad de ejecución remota de código en Signal o al menos algo muy cercano al persistente cross-site scripting (XSS) que eventualmente podría permitir a los atacantes inyectar código malicioso en sistemas Windows y Linux objetivo.

Más información en The Hacker News

FacexWorm apunta a plataformas de trading de criptodivisas utilizando Facebook Messenger para su propagación

Una extensión maliciosa de Chrome llamada FacexWorm utiliza diversas técnicas para afectar a plataformas de criptodivisas a las que se accede a través de un navegador afectado y se propaga a través de Facebook Messenger. La nueva versión mantiene el ejercicio de listar y enviar enlaces mediante técnicas de ingeniería social a amigos de una cuenta de Facebook afectada. Sin embargo, ahora también puede robar cuentas y credenciales de sitios web de interés. También redirige a las posibles víctimas a estafas de criptodivisas, inyecta código de minería en webs, redirige a enlaces de programas relacionados con criptodivisas y secuestra transacciones en plataformas de trading y wallets en la nube mediante la sustitución de la dirección del destinatario por la del atacante.

Más información en TrendMicro

Otras noticias

Más de 400 webs atacadas a partir de una campaña de cryptojacking tras un fallo en Drupal

Más información en Badpackets

El ransomware SynAck implementa la técnica de evasión Doppelgänging

Más información en SC Magazine

El malware Nigelthorn infectó a más de 100.000 sistemas que se aprovechaban de extensiones Chrome

Más información en Radware

¡Regístrate a la newsletter!

En nuestra entrada anterior sobre este tema, terminamos el post preguntándonos: ¿Existirán colisiones en los algoritmos utilizados en Bitcoin?, pues vamos a analizarlo.

La criptografía de Bitcoin

Los principales organismos reguladores NIST, FIPS, la misma NSA, el MITRE y los gigantes del sector privado, con Google a la cabeza; se preocupan muy mucho por la seguridad de los criptosistemas de uso general, pero… ¿Quién vela por la seguridad de las criptodivisas como el Bitcoin? ¿Existen colisiones en los algoritmos utilizados en Bitcoin?

El protocolo Bitcoin hace uso de tres algoritmos criptográficos:

ECDSA: en la firma y verificación de transacciones, a partir de claves privadas y públicas (criptografía asimétrica).
SHA-256 y RIPEMD160: como algoritmos de Hash (resumen criptográfico) en varios usos.

Algoritmo ECDSA

ECDSA es una modificación del algoritmo de Firma Digital DSA para ser utilizado con operaciones sobre “Curvas Elípticas” ECC, en lugar de basarse en sistemas de exponenciación o factorización, como los utilizados por DSA o RSA. Estos requieren un tamaño de clave muy superior para obtener un mismo nivel de seguridad, siendo hasta 400 veces más lentos.

Una curva elíptica es una curva plana definida por una ecuación cúbica de tercer grado de la forma:

y^2=x^3+ax+b

Para sus usos en criptografía se definen sobre un cuerpo finito de números enteros.

Existen diferentes organismos que definen los parámetros de las curvas elípticas empleadas en criptografía. Los principales son: ANSI, IEEE, NIST o Brainpool, siendo el más extendido y reconocido SECG (Standards for Efficient Cryptography Group) por su carácter independiente.

Cada criptosistema de curva elíptica consta de unos determinados “parámetros de dominio” que especifican los valores necesarios para establecer el campo finito, los coeficientes y demás elementos que definen la curva. Se expresan en una séxtupla T = (p, a, b, G, n, h), siendo:

El número de elementos del cuerpo finito (p)
Los coeficientes (a y b)
Las coordenadas del punto base G (x,y)
El orden del punto de la curva (n)
El cofactor (h)

Una de las curvas elípticas más utilizadas en criptografía es la “NIST P-256”, igualmente definida por el SECG como “secp256r1”, y por el ANSI X9.62 como “prime256v1”. Esta es la única curva, junto a la P-384 y P-521, que cumple con los requisitos de seguridad de la Suite B de la NSA (estándar de factor para el entorno militar de la OTAN). Sus parámetros son:

p = 115792089210356248762697446949407573530086143415290314195533631308867097853951
a = -3
b = 41058363725152142129326129780047268409114441015993725554835256314039467401291
x = 48439561293906451759052585252797914202762949526041747995844080717082404635286
y = 36134250956749795798585127919587881956611106672985015071877198253568414405109
n = 115792089210356248762697446949407573529996955224135760342422259061068512044369
h = 1

Podemos ver un ejemplo de utilización de esta curva en la firma de los certificados digitales que emplean las principales webs de Internet. Véase el siguiente correspondiente a google.com:

Firma de certificados digitales Google imagen

No obstante, esta no es la curva que utiliza el protocolo Bitcoin, el cual usa la curva “secp256k1”. Únicamente definida por el SECG, ortográficamente sólo cambia una “r” por una “k”, pero sus parámetros de dominio varían sustancialmente.

La letra “r” hace referencia a “random” ya que sus parámetros de dominio han sido seleccionados de forma “teóricamente” aleatoria. También son conocidas como curvas sobre cuerpos primos o “Prime”.

Sin embargo, la letra “k” hace referencia a “Koblitz”, por tratarse de un tipo de curvas binarias anómalas denominadas así en honor al profesor de matemáticas Neal Koblitz (co-autor junto a Victor S. Miller de la criptografía de curvas elípticas a mediados de los 80’s), cuyos parámetros de dominio no son elegidos al azar, si no, “rígidamente” calculados. También son conocidas como curvas sobre cuerpos binarios, aunque existen curvas sobre cuerpos binarios que no son curvas de Koblitz (ej. NIST B).

Los parámetros de dominio de la curva “secp256k1” utilizada en el protocolo Bitcoin son los siguientes:

p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
a = 0
b = 7
x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
n = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h = 1

Quedando simplificada su ecuación de la siguiente manera:

y^2=x^3+7

Matemáticamente, las curvas de Koblitz son unos pocos bits más débiles que otras curvas. Para obtener el mismo grado de seguridad que una curva Prime con clave de 256 bits, una curva Koblitz requiere una longitud de clave de 283 bits.

La mayor estructura que presentan estas curvas permie realizar ataques más eficientes, además de que el cálculo de multiplicación escalar es mucho más rápido que en otro tipo de curvas.

No obstante, las curvas “secp256r1” y “secp256k1” tienen una seguridad equiparable. Si consideramos solo los ataques conocidos hoy, poseen una seguridad prácticamente idéntica.

Sin embargo, con la excusa de no disponer de suficientes garantías frente al criptoanálisis, ninguna curva de Koblitz, independientemente de su longitud de clave, ha sido recogida en las definiciones de organismos como la NSA, el ANSI, o Brainpool.

Por el contrario, una importante corriente de investigadores denuncia la imposibilidad de verificar la verdadera “aleatoriedad” de los parámetros de dominio definidos para las curvas Prime, como la “secp256r1”, alimentando las sospechas sobre la existencia de una “puerta trasera” introducida por la NSA, desde que en el año 2006 el NIST adoptara varios algoritmos propuestos por la agencia.

Tan solo un año más tarde, en 2007, dos investigadores de Microsoft, Dan Shumow y Niels Ferguson, concluyeron que uno de estos algoritmos de la NSA, el “Dual_EC_DRBG” (Dual Elliptic Curve Deterministic Random Bit Generator) era potencialmente inseguro.

Pero no fue hasta junio de 2013, cuando Edward Snowden, antiguo empleado de la CIA y la NSA, hizo públicos un elevado número de documentos secretos, donde pudo verificarse que se trataba de una puerta trasera de la NSA, e incluso que fue desarrollada por la compañía RSA, al precio de 10 millones de dólares. El algoritmo Dual_EC_DRBG fue inmediatamente retirado y el NIST emprendió una campaña para lavar su imagen, en la que todavía continua inmerso.

De forma similar a cualquier otro criptosistema, los algoritmos de curva elíptica están en constante evaluación mediante diferentes técnicas de criptoanálisis; desde simples ataques de fuerza bruta, hasta los más complejos ataques de Pohlig-Hellman, de Shor, de BGGS (Baby Step, Giant Step), de MOV (Menezes-Okamoto-Vanstone), de Pollard, de Frey-Rück o Index-Xedni-Calculus, pasando por cualquier aplicación de teorías de grupos o giros cuadráticos.

Hasta la fecha, no se han encontrado debilidades, ni vulnerabilidades en el diseño de estos criptosistemas, aunque existen varios casos en los que una implementación deficiente del algoritmo, provocó un importante incidente de seguridad.

Uno de los casos más sonados fue el de Sony con su PlayStation 3. La tercera versión de la popular consola de videojuegos lanzada en 2006, empleaba ECDSA como algoritmo de firma digital para validar el software que podía ser ejecutado, impidiendo así la posibilidad de ejecución de programas y juegos no autorizados.

El proceso de firma digital requiere, además de la clave privada, un número aleatorio que no debe reutilizarse. Sorprendentemente Sony utilizó el mismo valor en todas las firmas de código que emitía. Esta debilidad fue anunciada por el grupo de investigadores“fail0verflow” en 2010, y poco después George Hotz “Geohot” consiguió explotarla para obtener la clave privada de Sony, y la publicó en su web personal; aunque hoy está ya deshabilitada, es bien conocida: “BA9055916861B977EDCBED92005092F66C7A3D8D”.

La generación de números aleatorios es un proceso crítico para cualquier criptosistema. Las autoridades de certificación y otros organismos que requieren de garantía absoluta de aleatoriedad, recurren a hardware específicamente diseñado para este propósito. Pero para un uso ordinario, se delega en el Sistema Operativo la generación de números aleatorios.

Son conocidos varios incidentes de seguridad provocados por una utilización defectuosa de la generación de números aleatorios en procesos criptográficos, aunque no transcendían más allá de una pequeña reseña, normalmente cuando ya estaban corregidos.

La aparente inocencia con la que eran percibidos los defectos de aleatoriedad, se tornó dramática en el verano de 2013, cuando salió a la luz una vulnerabilidad en la clase Java SecureRandom del SDK de Android que afectaba todas las versiones anteriores a la v4.2, lo que en aquella época suponía la práctica totalidad de tablets y smartphones Android (CVE-2013-7372).

El impacto de esta vulnerabilidad fue terrible para los usuarios de wallets de Bitcoin para Android, estando afectados la mayoría de los existentes entonces: Bitcoin Wallet, BitcoinSpinner, Mycelium y Blockchain.info. Todos los fondos depositados en estas carteras fueron sustraídos.

Se alertó desde la web Bitcoin.org, y aunque los desarrolladores publicaron rápidamente actualizaciones que parcheaban el problema, el daño ya estaba hecho. No fue posible cuantificar las cantidades sustraídas al tratarse de un robo que afectaba de forma individual a cada usuario, pero se sabe que fueron miles los que perdieron todos sus bitcoins. Google reconoció el error, corrigiéndolo con celeridad. Pero ya era tarde, no existía posibilidad alguna de recuperar las cantidades usurpadas, ya que las transacciones quedan inmutablemente recogidas en la blockchain.

Se desconocen los verdaderos motivos por los que el creador de Bitcoin eligió para el algoritmo ECDSA una curva de Koblitz en lugar de una curva Prime. Puede que simplemente se fiara más del profesor Neal que de la NSA.

Vitalik Buterin, ferviente seguidor de Bitcoin y la postre creador de Ethereum, comentaba en la Bitcoin Magazine, como Satoshi Nakamoto había encontrado formas inesperadas de esquivar “balas criptográficas”, tanto por elegir una curva de Koblitz, como por definir que las direcciones de pago de Bitcoin como un hash de la clave pública en lugar de la propia clave pública.

Pero, ¿son estas precauciones suficientes?, ¿los algoritmos de hash utilizados SHA-256 y RIPEMD160 son suficientemente seguros?, ¿hay colisiones en las direcciones de Bitcoin? Te lo contaremos todo en la tercera parte, no te pierdas la próxima entrega! Y recuerda que si tienes dudas o quieres discutir más sobre el tema, puedes visitarnos en la Comunidad de ElevenPaths.

» Colisiones, haberlas hay(las). Parte 1

Jorge Rivera

CSA, Chief Security Ambassador

jorge.rivera@11paths.com

Cualquier persona que trabaja en seguridad desde hace años es capaz de comprender que no existe el Plan Estratégico de Defensa perfecto. Sin duda alguna, también estará de acuerdo con mi afirmación de que, aún si tuviera un plan definido formalmente, el mismo no sería estático y cada evento diario podría modificar sus definiciones.

La tecnología avanza, los ataques evoluciones, se desarrollan nuevos protocolos, nuevos estándares, nuevas metodologías, y el mercado entero reacciona hacia ellas hasta que algo la golpea… Tal como fue la implementación de HSTS de Facebook, que luego de la charla brindada por nuestro equipo en Black Hat Europe se decidió modificarla y finalmente hablamos sobre esto.

No importa cuanto tiempo nos lleve desarrollar un Plan Estratégico de Seguridad, siempre habrá fallas en él, e incluso se generarán nuevas fallas durante el proceso de implementación. Es duro, tal vez, pero es la profesión que nos gusta. Los planes se amoldan al día a día de cada empresa, de cada organización, de cada país… Si partimos desde esta premisa, podemos suponer que aunque los Estados Latinoamericanos han estado trabajando fuertemente estos últimos años en tratar de acercarnos más al estado de madurez que posee España, generando los famosos Planes Estratégicos para la ciberdefensa, seguramente caeríamos en la trampa mental de que todos los problemas de seguridad desaparecen de la noche a la mañana, y no se tienen más problemas. Sin embargo, las realidades, tanto económicas como políticas para cada país, son muy diferentes. Este es el motico por el que finalmente decidimos desarrollar una serie de informes a partir de la información pública que se encuentra en cada país latinoamericano, con el fin de poner en juego una especie de comparación para que cada uno pueda ver cómo está en la región. Queremos que estos informes despierten las ansias por tratar de corregir esas fallas antes que los demás, y sobre todo, por lograr que los pedidos que seguramente hacen al interno y nadie los atiende, sean escuchados.

Queremos presentar una serie de informes que vamos a publicar en la web de ElevenPaths, dentro de los Cyberintelligence Report en el que analizaremos información relativa a los gobiernos lationamericanos. El primero de los informes que hemos desarrollado se basa en la búsqueda de información pública de los países latinoamericanos que hemos definido dentro del alcance, a partir de sus sitios oficiales. Después de esto hemos querido realizar un análisis de metadatos de cada documento encontrado, pero no sin antes realizar algunas pruebas de OSINT muy interesantes. En ningún caso se utilizaron herramientas intrusivas ni se intentó afectar o desmejorar ningún servicio. De paso, agradezco a Diego Espitia por todo el aporte realizado a este documento. Esperemos que les sea de utilidad para cada país, pero también a los privados para entender y comprender que su ayuda es importante siempre.

» Accede al informe completo: ¿Qué revelan los metadatos de los estados de Latinoamérica?

En otros informes iremos analizado otro tipo de información relativa a los gobiernos de la región, que nos ayudará a entender que a veces, sin querer, los polícos nos pueden poner en un arreglo que desde el minuto cero es ilegal… Esperamos que disfruten el primero, al cual hemos llamado “¿Qué revelan los metadatos de los países latinoamericanos?”. Cualquier comentario o sugerencia, saben que pueden hacerlo escribiendo en la community de ElevenPaths.

Claudio Caracciolo

Team Leader of the CSA and the Bs. As. Research Office at ElevenPaths

Innovación y Laboratorio

claudio.caracciolo@11paths.com

@holesec

Hace quince días publicábamos la primera versión de Neto, nuestro analizador de extensiones en Github. Publicada bajo licencia libre, en este tiempo hemos trabajado en una serie de funcionalidades que permitan a los analistas una mejor interacción con cada una de las utilidades de la herramienta además de mejorar su configuración. En este postveremos algunas de las novedades que hemos incluido en esta versión entre las que destaca su interfaz interactiva.

Las principales novedades de la versión 0.6

En esta segunda release pública incluimos algunas funcionalidades que consideramos relevantes:

La consola de Neto es la principal utilidad incluida en esta versión. Se trata de una pequeña interfaz de comandos que invocamos con neto console y desde la que podremos ejecutar diferentes comandos de análisis de forma interactiva como veremos más adelante en este post.
La carpeta de configuración. En esta prerelease también hemos incluido una serie de archivos de configuración que generaremos en la instalación. En sistemas GNU/Linux la carpeta de configuración se creará en /home//.config/ElevenPaths/Neto y será, además del lugar en el que almacenamos los archivos de configuración principales y unos backups, una carpeta de referencia donde almacenar resultados de los análisis. En sistemas Windows esta carpeta se creará en C:/Users//ElevenPaths/Neto.
Visualización de características de los análisis realizados en la CLI. De esta manera, el analista podrá comprobar desde la propia línea de comandos las principales características extraídas del en el análisis, como el hash de la extensión, los permisos que utiliza, los scripts que carga en cada pestaña o en background o la valoración que hace Virustotal del archivo entre otras sin necesidad de explorar manualmente el JSON. El JSON se seguirá generando con los datos completos.

La forma más sencilla de instalar la herramienta es con el comando de pip:

pip3 install neto

Los que ya tengamos descargada la versión anterior, tendremos que actualizarla añadiendo --upgrade al comando anterior:

pip3 install neto --upgrade

En sistemas GNU/Linux dicho comando puede ejecutarse o bien con un perfil de administrador, o bien con sudo o, si no somos administradores y no tenemos privilegios, añadiéndole --user para instalarlo solo para el usuario actual.

La consola interactiva

Como comentábamos anteriormente, la principal novedad de esta versión ha sido la adición de la consola interactiva de Neto. Con la interfaz de comandos que hemos incluido hemos querido acercar algunas de las funcionalidades de Neto de forma más cómoda para que sea más fácil la exploración de extensiones. Para lanzarla desde línea de comandos utilizaremos neto console, lo que nos abrirá una interfaz interactiva.

A partir de ahí, en todo momento podremos apoyarnos en el comando help para ver qué opciones tenemos.

Hasta el momento incluimos 13 comandos diferentes con distintas utilidades que ordenamos a continuación en orden alfabético. Donde ha sido posible, hemos implementado la opción de autocompletar. En cualquier caso, si tenemos dudas sobre el funcionamiento de cualquiera de ellas, podremos usar help comando para ver la ayuda sobre el mismo y ejemplos de cómo utilizarlos:

analyse. El comando principal de análisis. Irá seguido de las palabras clave «local» o «remote» en función de si la extensión que vayamos a analizar la tenemos almacenada en local o lo que facilitamos es una dirección URL remota. Si seleccionamos la opción local, podemos autocompletar los nombres de las extensiones contenidas en el working_directory que hayamos definido.

delete. Un comando para eliminar los análisis realizados. Se encarga de eliminar los archivos de análisis que no nos sean útiles. Podremos hacer referencia al análisis a realizar por medio de las palabras reservadas ALL o SELECTED así como por el nombre de la extensión. Hay que usarlo con cautela para evitar desastres.
deselect. Es el comando inverso a deselect. Desmarcará una extensión marcada como seleccionada si se especifica el nombre de la misma de forma literal. Se puede usar también la palabra reservada «ALL»
details. Muestra la información más relevante de la extensión que podremos seleccionar usando las funciones de autocompletar. Se trata de la misma información que veríamos tras realizar el análisis usando el CLI. Si queremos los detalles completos del JSON podremos usar full_details.
exit. Cierra la consola.
full_details. Muestra el JSON correspondiente a la extensión seleccionada.
grep. Un comando de búsqueda literal en los análisis ya almacenados. Nos devolverá los nombres de las extensiones que contengan la cadena de texto literal que hayamos incluido a continuación del nombre. Por defecto, la búsqueda se realizará solamente sobre las extensiones que hayan sido seleccionadas. En caso de que no haya ninguna, se realizará sobre todas.
help. El comando de ayuda.
list. Con él listaremos los análisis realizados. Podremos utilizar además de las palabras reservadas «ALL» y «SELECTED», el wildcard«*» para indicar extensiones que empiecen por una determinada cadena de texto (e. g.: list ad*).

select. Es un comando para seleccionar alguna de las extensiones que hayamos visto anteriormente (por ejemplo, para borrarlas o para buscar sobre ellas).
set. Se trata de un comando que utilizaremos para modificar algún valor propio de las opciones de la interfaz, como el directorio de trabajo.
show. Este comando lo utilizaremos solamente para mostrar información de la herramienta, como los datos genéricos de la misma (usando show info) o las opciones de la interfaz (usando show info).
update. Actualiza el listado de extensiones conocidas. Esto es útil si mientras mantenemos la interfaz abierta tenemos otro proceso por detrás (por ejemplo, el CLI lanzado con neto analyse -e miextension.xpi) que sigue añadiendo extensiones.

A continuación incorporamos un pequeño vídeo demostrativo de cómo funciona la interfaz de consola que incluimos en Neto Console para que nos hagamos a la idea.

Continuará…

Aunque el estado de desarrollo de Neto es claramente un work in progress, desde el Laboratorio de innovación de ElevenPaths sí queremos continuar profundizando en las características de la herramienta. Las próximas semanas hablaremos de cómo desarrollar nuevos plugins de análisis para añadir nuevas características que encontremos en las extensiones y de algunos casos en los que la herramienta nos puede servir de ayuda para analizar de un vistazo las características de una extensión. Mientras tanto, para ir mejorando poco a poco siempre podéis dejarnos vuestras dudas con respecto a cómo funciona como issues en el propio proyecto de Github. Cualquier idea será bien recibida.

Félix Brezo

Innovation and Laboratory Team ElevenPaths

@febrezo

felix.brezo@11paths.com

Resolver la autoría de un ataque es una pregunta que todo analista quiere contestar. Sin embargo, nos encontramos ante una situación en la que los atacantes cada vez más utilizan técnicas de decepción. Este concepto, conocido por los servicios de inteligencia también como contrainformación, permite mantener la iniciativa y provocar que el contrario perciba como cierta una información que es incorrecta.

Durante la Segunda Guerra Mundial y la Guerra Fría se conocieron numerosos casos de falsos traidores del bloque soviético que intoxicaron los sistemas de obtención de información británico y norteamericano. Pero, ¿hasta qué punto ha evolucionado este concepto para luchar contra las ciberamenazas?

Figura 1. Fotografía de la Operación Titánico.

Ataques de falsa bandera

Para asentar las bases conceptuales en un mundo tan nuevo como es el de la ciberinteligencia, se han aprovechado términos procedentes de la inteligencia tradicional. De hecho, los ataques de falsa bandera no dejan de ser un subconjunto de acciones de decepción pero relacionado con el establecimiento de la atribución de un ataque. En este sentido, se plantean dos escenarios:

Cuando no se conoce quién es el responsable (no-flag), por lo que no hay atribución.

Y, por otro lado, cuando los analistas llegan a la atribución. Puede ser que se sepa con certeza quién se encuentra detrás o, por el contrario, que se tengan indicios de que la autoría haya podido ser falsificada (false flag).

Antes de llegar a algún tipo de conclusión sobre la atribución de un ataque, los analistas previamente han tenido que evaluar la información que han obtenido. Es más que recomendable ver la conferencia impartida por dos analistas de Kaspersky, Juan Andrés Guerrero-Saade y Brian Bartholomew, en la RSA de 2017 donde examinan cuán manipulable son los inputs de información sobre los que nos basamos a la hora de hacer un ejercicio de atribución. Ellos resaltaban los siguientes más comunes:

Los timestamps de compilación de las muestras de malware podría determinar las horas de trabajo de los desarrolladores por lo que esta información podría sugerir una determinada zona horaria.

Numerosas muestras de malware a menudo incluyen strings que pueden sugerir el uso de un idioma de determinado o son lo suficientemente significativas que pueden haberse visto en el pasado.

La infraestructura y las herramientas utilizadas por un determinado grupo a menudo suelen ser reutilizadas, por lo que los analistas podrían asumir la atribución a determinados grupos.

Los objetivos de los atacantes, en ocasiones, suele ser revelador. Dependerá de la variedad de víctimas que tengan como objetivo.

Sin embargo, si nos damos cuenta, todas ellas son susceptibles de ser manipulables. Un ejemplo lo pudimos analizar en el contexto de las pasadas Olimpiadas donde un grupo identificado como @FancyBears en Twitter publicaba, en una web de reciente creación, información sobre cuatro conocidas deportistas de élite que, presuntamente, habría sido sustraída en una acción perpetrada contra la WADA (World Anti Doping Agency). En un comunicado oficial la propia organización había confirmado el ataque y la exposición de información de hasta 29 atletas, atribuyendo el ataque a orígenes rusos.

En este sentido, diversos medios de comunicación y la propia Agencia Mundial Antidopaje manifestaron que los presuntos responsables procederían de Rusia. Se identificaron evidencias que respaldan esta hipótesis como la publicación de los contenidos en una zona horaria de al menos UTC+3 y la referencia a una fotografía solamente encontrada en un dominio de origen ruso. Sin embargo, en algunos momentos también la información recopilada era contradictoria con la atribución inicial como, por ejemplo, comentarios en coreano en el código fuente de la página web de este grupo o el whois del dominio donde dicho grupo colgaba los expedientes médicos de los deportistas. Dicho esto, tampoco se pudo descartar por completo que se tratara de un ataque de falsa bandera en el que la información fuera intencionadamente expuesta para hacer creer que el ataque procedía de Rusia.

¿En qué sentido la atribución puede ser un problema?
Por el momento, la labor que realizan los analistas a la hora de evaluar información es esencial. Sin embargo, la formación de estos equipos se torna complicada. Para empezar, a nosotros mismo nos cuesta ponernos de acuerdo sobre qué queremos decir en cada momento. Un ejemplo lo podemos ver en un estudio publicado por la CIA en 2007 sobre los sesgos a la hora de hacer referencia a la probabilidad. Asimismo, otro riesgo, aunque menor, trata sobre los protocolos más comunes de estandarización de información sobre actividad maliciosa donde se presentan ciertos problemas relacionados con los datos colaborativos a intercambiar.

Figura 2. Diferencias entre analistas a la hora de percibir conceptos relacionados con la probabilidad.

Por otro lado, una correcta atribución es necesaria para poder perseguir a aquellos que quebranten las leyes y tratados. Pero, ¿para quién es relevante esta información? Sin duda para aquellos cuya inteligencia será accionable, es decir, cuyo conocimiento servirá para llevar a cabo una acción concreta con efectos y resultados medibles. Por ahora, los gobiernos son los únicos que necesitan un nivel de fiabilidad alto en la atribución con el objetivo de realizar operaciones ofensivas o incluso imponer sanciones a terceros actores.

Sin embargo, llegar a una atribución individual por parte de una empresa no es tan relevante mientras que no evolucione la legislación a favor del hack back. Un ejemplo de esto lo encontramos en la atribución realizada por diferentes firmas del ataque perpetrado a la red de la organización de las olimpiadas de PyeongChang donde fue atribuido a la vez a a rusos, iraníes, chinos y a grupos como Lazarus, un grupo relacionado con Corea del Norte. Dada la reciente politización del ciberespacio, una atribución errónea podría tener graves consecuencias y los actores podrían empezar a tratar de manipular la opinión de la comunidad para influir en la agenda geopolítica.

Por el contrario, sí nos interesa como empresa conocer las técnicas, tácticas y motivaciones llevadas a cabo por los grupos afincados en determinados países con el fin de administrar los recursos defensivos a nuestra disposición de una forma más eficiente. Al fin y al cabo, las consecuencias derivadas de una atribución errónea por parte de una empresa entrañan unos riesgos reputacionales innecesarios que van más allá del cometido de un departamento de seguridad: la protección de los activos de la empresa.

Yaiza Rubio

Equipo de Innovación y Laboratorio de ElevenPaths

@yrubiosec
yaiza.rubio@11paths.com

PGP y S/MIME son dos de los métodos más conocidos para cifrar emails por todo Internet. PGP (Pretty Good Privacy) fue desarrollado por Phil Zimmermann el cual utiliza la criptografía de clave pública para cifrar la información y es todo un clásico ya que lleva funcionando desde 1991. S/MIME (Secure/Multipurpose Internet Mail Extensions) es también una tecnología que permite cifrar información basado en criptografía asimétrica. Ambos sistemas también permiten firmar los correos para confirmar la identidad de la persona que los ha enviado.

Hace unos días se comentó en ELDM la aparición de esta nueva vulnerabilidad llamada efail. En él se explicaba un bug con el cual es posible descifrar a texto plano los mensajes cifrados con ambas plataformas. Ahí es poco. Y lo más grave, también sirve para cifrar cualquier email enviado en estos últimos años. El mensaje publicado por estos investigadores es bastante claro: desinstala ahora en tu cliente de email cualquiera de estos métodos de cifrado.

Sebastian Schinzel, profesor de seguridad informática en la universidad de Munster de Ciencias Aplicadas, escribió en su Twitter: “…podría (el bug) revelar el texto plano de los emails cifrados, incluidos los emails cifrados que enviaste en el pasado”. Además, acaba diciendo “No hay hoy en día ningún parche para esta vulnerabilidad. Si utilizas PGP/GPG o S/MIME para envío de información sensible, deberías de deshabilitarlo en tu cliente de email”. El mensaje en sí es bastante preocupante, ya que destroza uno de los métodos de cifrado más robustos, comunes y utilizados en Internet.

Sebastian Schinzel twitter PGP/GPG imagen

Imagen 1. Tweet publicado por Sebastian Schinzel el 14 de mayo de 2018.

Pero no sólo ha sido Sebastian Schinzel quien lo ha anunciado, la Electronic Frontier Fundation o EFF ha dicho en un comunicado que confirma este fallo de seguridad. Por lo visto han estado en permanente contacto con el equipo de investigación que les ha confirmado este fallo. Este es el mensaje que ha lanzado la EEF:

“Nuestro aviso, que es el mismo que el de los investigadores, es deshabilitar inmediatamente y/o desinstalar herramientas que automáticamente descifren los emails cifrados con PGP. Hasta que los fallos descritos en el paper se comprendan y sean reparados, los usuarios deberían comenzar a buscar una alternativa para enviar mensajes punto-a-punto por canales seguros, como por ejemplo Signal, y temporalmente parar de enviar y especialmente leer mensajes cifrados con PGP.”

Hasta aquí parece el fin del mundo tal y como lo conocemos. FIN. Pero antes de sacar las antorchas para quemar los ordenadores, vamos a analizar un poco mejor el problema porque puede que no sea para tanto. En primer lugar, el problema existe, pero afecta sólo a emails en formato HTML, algo que Sergio de lo Santos ya comentaba en un tweet el mismo día de su publicación:

Sergio de los santos twitter PGP/GPG imagen

Imagen 2. Tweet publicado por Sergio de los Santos el 14 de mayo de 2018.

En efecto, según la información publicada en efail.de este ataque se aprovecha de vulnerabilidades en el contenido de emails con formato HTML. Estos mensajes permiten por ejemplo cargar imágenes o fuentes de letra, y estos mismos componentes pueden ser reutilizados como medio para conseguir el mensaje en texto plano a través de una URL. Como requisito principal, para conseguir el descifrado el atacante debe de tener acceso a los emails del objetivo ya sea consiguiendo acceso a su cuenta de correo, interceptando el tráfico de red o accediendo directamente a los servidores de email o sus copias de seguridad. Como se puede observar, es posible que sea más peligroso el hecho que el atacante tenga acceso a esos recursos (ha entrado hasta la cocina en tus sistemas) que el efail en sí mismo.

Como también comenta comenta Sergio, hace ya mucho tiempo que nadie utiliza HTML en los correos (¿o sí?). Es bastante conocido que los emails en HTML y en particular enlaces externos tipo

son un problema de seguridad. HTML permite de ejecutar elementos como scripts, controles ActiveX, etc. Menos mal que el líder de GnuPG, Wener Koch, ha sido quien ha puesto un poco de sensatez a este mensaje tan alarmista sobre este fallo de seguridad. Lo deja claro en este tweet, el problema está en los clientes de email y sus plugins, no en los protocolos. También deja claro cómo solucionar el problema: no utilizar HTML en los correos y usar cifrado autenticado.

Pero vamos a ver un poco más en detalle el origen de estos problemas relacionados con los clientes de email. El primero, la principal vulnerabilidad, es que un atacante podría preparar un correo con una capa HTML con un componente modificado, una capa con el texto cifrado y otra capa con otro componente HTML modificado el cual utiliza enlaces remotos que finalmente permiten enviar el texto cifrado en texto plano. El segundo problema está en las especificaciones técnicas y de implementación de OpenPGP y S/MIME.

Sobre el problema relacionado con los emails en HTML, existen a su vez dos tipos de ataque efail. El primero llamado direct exfiltration explota vulnerabilidades en Apple Mail, iOS Mail y Mozilla Thunderbird. El atacante crea un nuevo correo con varias partes, en concreto tres partes tipo body. La primera es un body HTML que contiene una etiqueta de imagen HTML. Es importante destacar que la etiqueta de imagen no está cerrada, es decir, comienza con comillas, pero no se cierra, como se puede observar en rojo en la siguiente captura:

texto cifrado y la etiqueta de imagen imagen

Imagen 3. Primera parte con el texto cifrado y la etiqueta de imagen.. Fuente.

La parte que viene a continuación, una nueva parte body contiene el texto cifrado PGP o S/MIME. Por última, la tercera parte body es la que cierra la etiqueta de imagen que antes quedó abierta.

Entonces el atacante envía un email a la víctima y el cliente de correo descifra el texto que estaba cifrado en la segunda parte body que antes se ha comentado. Finalmente, el cliente junta todas las partes y obteniendo como resultado el siguiente mensaje, el cual, al cerrar al final las comillas, se ha expandido a 4 líneas formando una URL de esta longitud:

Resultado final de juntar todas las capas imagen

Imagen 4. Resultado final de juntar todas las capas. Fuente.

Finalmente, el cliente de email codifica la URL y solicita una imagen de esa direccoçpmL. Como la ruta de esta URL tiene incluido el texto plano del email cifrado, el cliente de email de la víctima lo enviará al atacante.

Imagen 5. URL final obtenida. Fuente.

El siguiente ataque, basado en las especificaciones técnicas y de implementación de OpenPGP y S/MIME, es más elaborado y se llama ataque CBC/CFB Gadget Attack. Esta vez el atacante podría enviar bloques de datos malformados los cuales, cuando sean leídos por el objetivo, pueden engañar al cliente de email para que envíe al ordenador del atacante el texto plano de los mensajes. Un requisito, debido a las especificaciones de CBC, es que el atacante sepa por lo menos un bloque completo del texto sin cifrar (texto plano).

Esto que en principio parece un hándicap insalvable se convierte en algo plausible ya que la mayoría de los mensajes S/MIME cifrados suelen comenzar por “Content-type: multipart/signed” con lo cual ya tenemos nuestro primer bloque de texto sin cifrar. En la figura 6, como se puede apreciar en el apartado (a). El siguiente paso (b), es construir un bloque de texto plano válida utilizando ceros (el bloque conformado por X y C0 se llama CBC gadget). El paso final (c) se van añadiendo gadgets para insertar una etiqueta de imagen dentro del texto cifrado, creando finalmente un solo body que mostrará el texto plano cuando la atacante abra el email. El ataque usando CFB funciona exactamente igual ya que tiene las mismas propiedades criptográficas que CBC.

Este ataque es muy similar en ejecución para PGP o S/MIME, aunque para S/MIME funciona mejor que para PGP, el cual sólo tiene un rango de éxito de 1/3 (debido a la compresión que PGP realiza sobre el texto plano antes de cifrarlo). Para más información aquí tenéis el paper completo.

squema del ataque CBC/CFB Gadget Attack imagen

Imagen 6. Esquema del ataque CBC/CFB Gadget Attack.

El ataque PGP CFB gadget tiene el CVE-2017-17688 y el S/MIME CBC se le ha asignado el CVE-2017-17689.

Como hemos podido observar, al final esta vulnerabilidad no es tan grave como parecía al principio. Pero de todas formas hay que tenerla en cuenta y al menos tomar algunas medidas de seguridad. La primera, no utilizar mensajes con HTML y deshabilitar todos los plugins de email. También es conveniente rechazar los correos HTML (no abrirlos) y deshabilitar la opción de carga de recursos externos (las cuales suelen ser habitualmente imágenes).

MDC (Modification Detection Code) es una característica que si está incluida en tu programa/plugin de correo, que resuelve el problema (por ejemplo, OpenPGP lo lleva), el problema es que S/MIME no soporta esta característica. Por otro lado, también se recomienda abrir los emails cifrados con PGP en un editor de texto, en una máquina virtual segura, un contenedor docker o lo que se te ocurra en vez de dejar que estos mensajes sean procesados por algún tipo de programa/plugin.

Utilizar TLS no protege contra este ataque ya que TLS sólo cifra el tráfico entre los clientes de email y los servidores, o entre dos servidores de email, pero todos los correos se procesan y almacenan en texto plano en los servidores y en las respectivas cuentas de correos.

De todas formas, estaremos atentos a la evolución de este bug por si trae más sorpresas.

Fran Ramírez

Equipo de Crazy Ideas en CDO en Telefónica e investigador de Seguridad Informática en ElevenPaths

@cyberhadesblog

franciscojose.ramirezvicente@telefonica.com

En la entrada anterior sobre este tema comentamos la idoneidad del algoritmo ECDSA y más concretamente, de la curva “secp256k1”. No estando afectado por vulnerabilidades conocidas, se podría considerar seguro, aunque esto, depende en gran medida de cómo se utilice. Pues, ¡vamos a analizarlo!

Claves privadas de Bitcoin

Al igual que otros sistemas de Criptografía Asimétrica, ECDSA se fundamenta en el binomio de claves privadas y claves públicas. En Bitcoin, según están definidos los parámetros de dominio de la curva “secp256k1”, una clave privada puede ser cualquier número comprendido entre 1 y el número de puntos de la curva u orden “n” menos 1:

n = 115792089237316195423570985008687907852837564279074904382605163141518161494337 - 1

El valor de “n-1” es algo menos de 2^256, pero es un número tremendamente grande. Tanto, que cuesta trabajo imaginarse sus colosales dimensiones, e incluso escribirlo en formato decimal, ya que tiene 78 cifras, aproximadamente 10^77.

10^77 es un número tan descomunal, que es difícil incluso de comparar; los granos de arena de todas las playas del planeta rondan los 10^20, y todas las estrellas del Universo apenas llegan a 10^23. Solo el cálculo aproximado de todos los átomos del Universo 10^80, está en su orden de magnitud, siendo ambos sobrepasados ampliamente por el Número de Shannon 10^120, que representa el número teórico de partidas de ajedrez posibles.

Mientras que no se descubra alguna vulnerabilidad en el algoritmo, o la computación cuántica consiga llevar la capacidad de computo a limites desconocidos, se puede considerar que una clave privada de 256 bits es suficientemente segura para criptosistemas de curva elíptica, siempre y cuando dicha clave sea generada de forma verdaderamente aleatoria.

Si la generación de la clave privada se lleva a cabo de forma verdaderamente aleatoria, la probabilidad de colisión tiende tanto a cero que no puede, ni siquiera, llegar a tenerse en consideración.

Existen precedentes donde una implementación errónea de la generación de claves, o como parte de alguna prueba de concepto, se utiliza un número, no ya predecible, sino simplemente igual a “1” (primera clave privada) o igual a “n-1” (última clave privada) como clave privada.

Matemáticamente es posible resolver la ecuación de la curva con un número de clave privada mayor a “n-1”, por ejemplo “n”, pero al tratarse de un factor modular, el resultado será la misma clave pública generada a partir de la clave privada “1”. Esto no puede considerarse una colisión de claves privadas; la mayoría de las implementaciones devuelve un error al tratar de utilizar como clave privada un valor superior a “n-1”. Por ejemplo en el módulo pybitcoin de Python v2.7:

raise IndexError(_errors["EXPONENT_OUTSIDE_CURVE_ORDER"]) IndexError: Secret exponent is outside of the valid range. Must be >= 1 and < the curve order.

En cualquier caso, ya sea por error, como parte de una prueba de concepto, o por mera experimentación, las direcciones de Bitcoin correspondientes a las claves privadas “1” y “n-1”, han sido utilizadas en el pasado, y sorprendentemente, continúan siendo utilizadas en el presente, tal y como se puede comprobar explorando la cadena de bloques:

Clave privada “1”, dirección comprimida: 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
Clave privada “1”, dirección sin comprimir: 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
Clave privada “n-1”, dirección comprimida: 1GrLCmVQXoyJXaPJQdqssNqwxvha1eUo2E
Clave privada “n-1”, dirección sin comprimir: 1JPbzbsAx1HyaDQoLMapWGoqf9pD5uha5m

¿Quiere esto decir que se conocen las claves privadas de todas las direcciones de Bitcoin? No, más bien, lo que quiere decir es que, se pueden calcular las direcciones de Bitcoin de todas las claves privadas que existen; el problema es, como hemos visto, que son demasiadas.

Son tantas que, en base a la potencia de cálculo actual, se tardarían decenas de miles de millones años en computarse; sin mencionar que, un hipotético dispositivo para almacenarlas excedería el tamaño de nuestra galaxia.

No obstante, estos pequeños detalles no han supuesto un impedimento a la hora de tratar de representar todas las claves privadas y sus direcciones de Bitcoin correspondientes. Sí, “todas”, pero no de golpe, solo aquellas que se consulten. Este fue precisamente el objetivo del proyecto directory.io, el cual hoy ya no está operativo, pero han surgido otras muchas webs, donde con algo de publicidad, ofrecen un servicio similar e incluso mejorado, al consultar en la cadena de bloques los fondos que pudiera haber en las direcciones de Bitcoin obtenidas:

En la siguiente captura del 1 de diciembre de 2013 almacenada por archive.org, se observa como directory.io muestra únicamente las direcciones sin comprimir, que eran las más utilizadas en los primeros años de Bitcoin, destacando que comienza por la polémica dirección no valida “16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM”, ya que, pese a haber recibido varias transacciones, no es una dirección utilizable, al corresponderse con una clave inexistente, cuyo valor teórico sería cero. Su jocosa FAQ estaba repleta se sarcasmos.

El código fuente original de directory.io estuvo disponible por algún tiempo, y pese a que no aportaba ninguna novedad destacable, ciertos matices en su estructura eran semejantes a los encontrados en el código fuente original de Bitcoin que publicó Satoshi Nakamoto. Por ello, se vinculó al creador de Bitcon con su mantenedor, Arran Walker, que además publica en su espacio de GitHub una variante optimizada en lenguaje GO.

captura de pantalla almaceada por archive.org imagen

No es necesario mencionar que cualquier cantidad de bitcoins transferida a cualquiera de estas direcciones cuya clave privada es conocida, es inmediatamente sustraída por alguno de los cientos de “bots” que están monitorizando permanentemente el “mempool” de la red de Bitcoin, a la espera de una transacción incauta.

Esta operativa de robo de bitcoins de forma automática e instantánea por medio de bots, que incluso compiten entre ellos, fue diseccionada por Yaiza Rubio y Felix Frezo en la ponencia que ofrecieron en la RootedCON de 2015. El objetivo en esta ocasión eran las direcciones de Bitcoin generadas a partir de “carteras mentales”; una práctica totalmente desaconsejada, ya que los bots cuentan con millones de claves precalculadas, a partir de diccionarios de múltiples idiomas y de contraseñas habituales. Este uso ha sido relegado a favor del BIP0039, que genera una estructura de claves y direcciones de modo determinista a partir de una relación de 12 palabras a elegir entre 2048, con la que se obtiene una entropía de 128 bits; de momento suficiente para mantener a salvo cualquier wallet.

De igual forma que no se puede considerar una colisión de clave privada cuando esta ha sido generada sin la suficiente aleatoriedad, tampoco se puede considerar una colisión cuando la clave privada ha sido generada a partir de una contraseña o palabras de un diccionario conocido o susceptible de haber sido previamente calculado.

Se deduce entonces, que no existen colisiones conocidas, ni riesgo de haberlas a corto plazo, en las claves privadas de Bitcoin, siempre que estas se generen con suficiente aleatoriedad. Pero, ¿qué ocurre con las claves públicas y sobre todo con los algoritmos de hash SHA-256 y RIPEMD-160?, ¿serán suficientemente seguros para impedir colisiones en las direcciones de Bitcoin?

Te lo contaremos todo en la cuarta parte, ¡no te pierdas la próxima entrega hacker! Y recuerda que si tienes dudas o quieres discutir más sobre el tema, puedes visitarnos en la Comunidad de ElevenPaths.

Jorge Rivera

CSA, Chief Security Ambassador

jorge.rivera@11paths.com

RGPD, el comienzo de una nueva etapa imagen

Hoy comienza una nueva etapa para todos nosotros y las distintas organizaciones. Hoy se convierte de obligado cumplimiento la aplicación del Nuevo Reglamento General de Protección de Datos (RGPD). Paramos a echar la vista atrás para revisar el trabajo realizado, reflexionar sobre las lecciones aprendidas y planificar nuestros siguientes pasos. Sin duda, se trata de la normativa que ha tenido mayor impacto en las organizaciones durante los últimos años si bien es verdad que no partíamos de cero. Desde las Conferencias Internacionales de Autoridades de Protección de Datos y Privacidad, cuya primera edición se desarrolló en el 79, pasando por las directrices de la OCDE sobre protección de la privacidad y flujos transfronterizos de datos que datan de los 80, hasta llegar a las españolas LORTAD y LOPD que nos traen hasta el punto en el que estamos.

Bajo mi punto de vista, tenemos que analizar los requerimientos de RGPD no solo desde la obligatoriedad, si no desde la conveniencia. El abaratamiento en el coste de la recopilación, almacenamiento y tratamiento de datos y su valor como activo central en la nueva economía hace que la innovación impulsada por los datos sea un pilar clave de crecimiento. Lo cual no está exento de riesgos. Esta es la nueva economía de los datos pero lo es también de la confianza. De todos es de sobra conocido las recientes perdidas en bolsa por un mal uso de los datos en algunas organizaciones. Por lo que siempre es muy conveniente poner en una balanza oportunidad y riesgo y actuar en consecuencia.

Durante estos meses hemos constatado que:

No existe una única forma de cumplir con el RGPD. Hecho que hemos comprobado tanto por nuestra propia experiencia como por la de nuestros clientes. La tecnología nos puede ayudar pero es una normativa con un impacto tan grande en las organizaciones que dependerá mucho de nuestras circunstancias. Se trata de aplicar una combinación de procesos, personas y tecnología, sin olvidar aspectos tan importantes como la formación y la concienciación.
Hemos ido implementado los nuevos requerimientos aprovechando aquello que ya teníamos porque, como decíamos antes, no partimos desde cero.
Es necesario un enfoque integral y el trabajo conjunto de múltiples departamentos (Legal, Seguridad, Sistemas, Negocio, Marketing…) además del apoyo de la dirección. A partir de ahora tenemos que aprovechar para seguir trabajando de forma coordinada ya que esto repercutirá en una mejora en la privacidad y seguridad de los datos.
El enfoque basado en riesgos ha sido muy acertado de cara a poner atención allí donde ha sido necesario. Esto nos ha permitido una racionalización de los recursos para poner foco en aquellas áreas que mayor atención requerían.

Y a partir de ahora, ¿en qué nos centramos?

Sigamos interiorizando desde todos los ámbitos de la organización la privacidad desde el diseño y, por defecto, la cultura del enfoque basado en riesgos. Esto tiene que ser una parte esencial en el ciclo de vida de todos los productos y servicios.
Estemos preparados para demostrar todas las medidas que se han tomado y las acciones que se están llevando a cabo. Esto implica tener tanto nuestros procedimientos bien documentados como trazabilidad de las acciones.
Pongamos foco en mantener todo el trabajo realizado. De otro modo, pronto podría quedar desactualizado y no habrá servido el esfuerzo de adecuación. Sin el mantenimiento oportuno se podrían degradar tanto la seguridad como la privacidad de los datos. Para esto será muy útil apoyarnos en la tecnología que nos puede ayudar en aspectos como: mantener nuestro registro de actividades de tratamiento actualizado, obtener informes automatizados que nos faciliten el trabajo, hacer descubrimiento y clasificación de datos personales tanto estructurados como no estructurados e independientemente de su ubicación (nuestras instalaciones o en la nube), monitorización y generación de alarmas, entre otros...
No debemos descuidar algo tan importante como nuestra cadena de suministro. Si tenemos encargados de tratamiento, el RGPD nos indica que únicamente debemos recurrir a aquellos que ofrezcan suficientes garantías, en particular en lo que respecta a conocimientos especializados, fiabilidad y recursos, de cara a la aplicación de medidas técnicas y organizativas que cumplan los requisitos del Reglamento, incluida la seguridad del tratamiento.
Aunque el RGPD es de aplicación directa, en España se está tramitando el Proyecto de la nueva Ley Orgánica de Protección de Datos, que ajusta nuestro ordenamiento a este nuevo Reglamento. Deberemos estar atentos a su aprobación y a las modificaciones que se vayan produciendo sobre el proyecto presentado y lo que esto nos pueda implicar.

En definitiva, ahora es el momento de establecer un sistema de mejora continua que se incorpore en los procesos diarios de las organizaciones y que será garantía de un nivel elevado de protección efectiva de los datos de carácter personal

Alicia Hurtado López

Global Security Product Manager en ElevenPaths

alicia.hurtadolopez@telefonica.com

En posts anteriores hemos introducido Neto como analizador de extensiones de navegador. La primera versión que liberamos, 0.5.x incluía un CLI, una interfaz JSON-RPC y podía ser utilizada directamente desde vuestros scripts. En la serie 0.6.x hemos ganado en estabilidad y hemos añadido además algunas características interesantes como la consola interactiva para hacer del analizador una herramienta con la que se pueda interactuar. Sin embargo, aún no hemos hablado de cómo podemos ampliar las funcionalidades de Neto para adecuarlas a nuestras necesidades.

Un sistema de plugins para ganar flexibilidad

Pese a las necesidades de investigación que podamos tener nosotros desde ElevenPaths, puede ocurrir que otros analistas de seguridad quieran también llevar a cabo otras tareas en las que nosotros no hemos pensado. Con el objetivo de flexibilizar su uso lo más posible, hemos pensado en un sistema de plugins que os permita diseñar vuestros propios módulos. Recordad en este punto que siempre podremos instalar la versión más reciente desde PyPI con:

$ pip3 install neto --user --upgrade

Pero antes, os hacemos una breve descripción de cómo funciona Neto. Cada extensión se representa en Python en un objeto que carga los métodos de análisis oficiales que hemos incluido en neto/plugins/analysis. Neto automáticamente ejecutará la función definida como runAnalysis en la que recibiremos dos parámetros diferentes que podremos usar según nuestras necesidades:

extensionFile. La ruta local en la que se encuentra el fichero comprimido de la extensión.
unzippedFiles. Un diccionario en el que las claves es la ruta relativa del fichero descomprimido encontrado en la extensión y el valor la ruta absoluta en donde se ha descomprimido en el sistema. Por defecto, se trata de una ruta temporal.
```
    {
        "manifest.json": "/tmp/extension/manifest.json"
…
    }
```

De esta manera, en función de lo que queramos hacer podremos optar por una o por otra opción. Por ejemplo, si queremos trabajar únicamente con los archivos .png presentes en la extensión, es más fácil que lo hagamos usando unzippedFiles, pero si queremos analizar el fichero en sí mismo podemos usar extensionFile. Dependerá de nuestras necesidades. Lo que sí que tenemos que tener en cuenta es que debe devolver siempre un diccionario en el que la clave sea el nombre que damos a nuestro procedimiento y el valor los resultados del mismo. Así este nuevo atributo será añadido al resto de elementos ya obtenidos.

Para definir nuestros propios módulos de análisis en estas primeras versiones de Neto bastará con que generemos unos pequeños scripts en Python que almacenará en su carpeta local ~/.config/ElevenPaths/Neto/plugins/. Las características de estos módulos de usuario son idénticas a las de los módulos oficiales solo que se cargarán a petición del usuario.

Creando nuestro primer plugin para Neto

Para facilitarnos el proceso, hemos incluido una template de plugin con cada instalación en ~/.config/ElevenPaths/Neto/plugins/template.py.sample. Empezar a desarrollar es fácil a partir de esta plantilla y para verlo haremos un plugin sencillo que contará el número de ficheros que contiene la extensión.

def runAnalysis(**kwargs):
    """
    Method that runs an analysis

    This method is dinamically loaded by neto.lib.extensions.Extension objects
    to conduct an analysis. The analyst can choose to perform the analysis on
    kwargs["extensionFile"] or on kwargs["unzippedFiles"]. It SHOULD return a
    dictionary with the results of the analysis that will be updated to the
    features property of the Extension.

    Args:
    -----
        kwargs: It currently contain:
            - extensionFile: A string to the local path of the extension.
            - unzippedFiles: A dictionary where the key is the relative path to
                the file and the the value the absolute path to the extension.
                {
                    "manifest.json": "/tmp/extension/manifest.json"
…
                }
    Returns:
    --------
        A dictionary where the key is the name given to the analysis and the
            value is the result of the analysis. This result can be of any
            format.
    """
    results = {}

    # Iterate through all the files in the folder
    for f, realPath in kwargs["unzippedFiles"].items():
        if os.path.isfile(realPath):
            # TODO: Your code here for each file
            pass

    return {__name__: results}

Partiendo del código original, utilizaremos la información almacenada en kwargs["unzippedFiles"] y reutilizaremos el bucle que ya tenemos para contar aquellos elementos que sean ficheros incrementando la variable myCounter que inicializamos al principio del método.

    myCounter = 0

    # Iterate through all the files in the folder
    for f, realPath in kwargs["unzippedFiles"].items():
        if os.path.isfile(realPath):
            # TODO: Your code here for each file
            myCounter += 1

    return {"num_files": myCounter}

Ahora guardaremos el fichero en la carpeta en cuestión como ~/.config/ElevenPaths/Neto/plugins/hello_world.py por ejemplo. Solo falta arrancar Neto con una nueva extensión (por ejemplo, con el CLI) y comprobar la salida:

$ neto analyser -e ./my_demo.xpi
$ cat /home/USER/.config/ElevenPaths/Neto/data/analysis/854…78f.json | grep num_files
    "num_files": 151,

¡Ya tenemos nuestro primer plugin para Neto!

Ahora bien, ¿cómo comparto mis plugins con el resto?

Una vez que ya hayas definido tu plugin y lo hayas probado en una instancia local, te invitamos a que lo compartas con nosotros para mergearlo con el proyecto principal. Logueado con tu usuario, haz un fork del proyecto en tu plataforma y clona tu repositorio bifurcado en tu máquina. Lo hacemos así porque para prevenir circunstancias no deseadas, al pushear el contenido al repositorio principal Github te lo rechazará al no estar autorizado.

$ git clone https://github.com/USER/neto
$ cd neto

Una vez descargado, copia el fichero que ya has probado localmente al repositorio. Por ejemplo, en un sistema GNU/Linux podrás recoger el plugin de la carpeta ~/.config/ElevenPaths/Neto/plugins/hello_world.py y cópialo en la carpeta de neto/plugins/analysis.

$ cp ~/.config/ElevenPaths/Neto/plugins/hello_world.py neto/plugins/analysis

Una vez añadido el fichero, solo falta añadirlo, commitear los cambios y pushearlo a tu repositorio.

$ git add neto/plugins/analyser
$ git commit -m "Add hello_world plugin following the tutorial"
$ git push origin master

Una vez autenticado con tu usuario, solo falta hacer el pull request para que lo podamos revisar y mergear con el proyecto principal. Puede ser que en ese proceso de revisión te pidamos aclarar algunas cosas por lo que es conveniente mantener una cierta homogeneidad utilizaremos las directrices de estilo marcadas por el PEP-8 donde sea posible.

De todas formas, la única condición general es que la respuesta generada sea un diccionario en el que la key sea un elemento que identifique tu análisis de forma unívoca y no entre en conflicto con el resto de métodos ya implementados. Ten en cuenta también que en en el caso de que tu plugin dependa de algún otro paquete que no se encuentre por defecto en Python 3, será necesario actualizar el setup.py para que se satisfagan las correspondientes dependencias. Aún así, no estarás en el solo el proceso. ¿Te animas a probar?

Félix Brezo

Innovation and Laboratory Team ElevenPaths

@febrezo

felix.brezo@11paths.com

Porque necesitamos una red cada vez más flexible y basada en software, este año queremos compartir contigo nuestra visión sobre cómo será la red del futuro. Telefónica organiza el próximo 14 de junio el evento más importante del año de innovación en la red: Network Innovation Day- We are in.

¡REGÍSTRATE AQUÍ!

El lema para nuestro evento de innovación en la red es: We are in. Desde dentro. Desde el corazón. Desde el centro neurálgico de Telefónica llega la verdadera transformación de la red. Gracias a la Inteligencia Artificial (IA), el Big Data, el 5G y la Seguridad recorremos un camino innovador revolucionando todos los procesos e infraestructuras técnicas hacia el futuro digital de nuestros clientes.

¡Reserva ya tu sitio y regístrate ahora!

Conoce de la mano de nuestros expertos las líneas de innovación tecnológica de Telefónica para responder a los nuevos desafíos que plantea la industria. Intervienen: José María Álvarez-Pallete, Chairman y CEO de Telefónica; Chema Alonso, Chief Data Officer de Telefónica; Enrique Blanco, Global CTO de Telefónica, Pedro Pablo Pérez, CEO de ElevenPaths y destacados expertos del sector.

Nuestro CEO, Pedro Pablo Pérez, nos explicará en su ponencia de Seguridad en la red cómo Telefónica ofrece seguridad de forma masiva a todos nuestros clientes sin importar si su conectividad es fija o móvil. Explicará cómo en Telefónica estamos convencidos de que debemos incorporar la seguridad en el propio diseño de los servicios de comunicaciones, y en este sentido, hemos incorporado en ellos las funciones de seguridad de red que los clientes pueden activar, modificar y consumir con agilidad dónde y cuándo sean requeridos, para proteger sus recursos con independencia de dónde se sitúen dentro de este nuevo modelo de red “extendida”.

¡No dejes pasar esta oportunidad! Te esperamos el próximo 14 de junio a las 9:30h (CET) en el Auditorio de Distrito Telefónica.

Consulta los contenidos que se presentarán en el evento Network Innovation Day 2018:

9.30 Acreditación
10.00 La innovación en el core. José María Álvarez-Pallete
10.30 Planificación y operación de redes Data-Driven. Chema Alonso
11.00 Virtualizando la red extremo a extremo. Enrique Blanco
11.45 Café
12.15 Seguridad desde la red. Pedro Pablo Pérez
12:25 Ordenadores cuánticos y la seguridad de las redes. Ignacio Cirac (special guest)
13.00 Hacia redes dinámicas basadas en Inteligencia Artificial. Juan Carlos García
13.30 Cierre institucional. Ángel Vilá

¡No te pierdas ningún detalle! Síguenos en nuestras redes sociales con el hashtag #NID2018. Recuerda que si no puedes asistir al evento, accede aquí y regístrate al evento en streaming.

Security Day - Cybersecurity On Board imagen

Hoy se ha celebrado la V edición del evento Security Day, organizado por ElevenPaths, la Unidad de Ciberseguridad de Telefónica, bajo el lema “Cybersecurity On Board”. Una importante cita, que ha congregado a más de 400 personas, y que ha servido de marco para presentar las nuevas integraciones tecnológicas llevadas a cabo junto a partners estratégicos con el objetivo de ayudar a las empresas a combatir ciberataques contra sus infraestructuras tecnológicas. La unidad de Ciberseguridad de la compañía trabaja para acompañar a sus clientes en un viaje end to end y, así, lograr la madurez en seguridad.

Por otro lado, Telefónica se consolida como una Intelligent MSSP (Proveedor de Servicios Gestionados de Seguridad) para ofrecer soluciones ciber-resilientes de extremo a extremo a todos sus clientes y dotar de mayor seguridad a las organizaciones en todos los aspectos de su día a día.

La ciberseguridad se extiende a todos los dispositivos y usuarios

Además, la Unidad de Ciberseguridad de Telefónica ha presentado Conexión Segura, una nueva solución para llevar la seguridad a todos los hogares de los clientes de la compañía. Sin necesidad de realizar una descarga, todos los routers HGU de los clientes se protegerán automáticamente con un antivirus McAffee, que se hará extensible a todos los dispositivos, además de a la parte encriptada de las VPN, y que incluirá un control parental.

También se ha anunciado la integración de novedades de productos de la compañía ya reconocidos como Latch, el interruptor de seguridad para la vida digital de las empresas y usuarios, y otros nuevos como Shadow Online, una herramienta que realiza trazabilidades a documentos mediante el uso de técnicas de marcas de agua digitales invisibles, FaasT for WordPress, que permite efectuar un pentesting persistente a sitios web basado en esta tecnología, y el servicio Managed Detection & Response (MDR), que proporciona servicios a empresas con el objetivo de mejorar la forma en la que se detectan las amenazas, se responde a los incidentes y se supervisan los activos de TI (Tecnologías de la Información) .

A su vez, se han presentado varias colaboraciones con fabricantes que incorporan productos con tecnología de ElevenPaths. La colaboración entre HP Enterprise y Telefónica ha logrado integrar Mobile Connect en el producto ClearPass, permitiendo la autenticación de usuarios en la red a través de un teléfono móvil para, posteriormente, aplicar una política completa de seguridad. Se han integrado los servicios de Metashield y Shadow Online para mejorar las capacidades de la solución DRM de la empresa SealPaths e integración de Panda Adaptive Defense con la tecnología LogTrust, para proporcionar una solución que ayude al cumplimiento del RGPD, permitiendo así identificar dónde se ubican los datos personales.

Queremos destacar las nuevas adquisiciones e inversiones en empresas y startups punteras que ha realizado la compañía en el ámbito de ciberseguridad. Por un lado, la adquisición de Dinoflux para el análisis masivo de malware y generación de inteligencia de amenazas en tiempo real y muestreo de productos IoT (IoT Anomaly Detection). Al mismo tiempo, se ha realizado una inversión mediante la participación en el accionariado de la empresa Govertis, con la renovación del acuerdo de colaboración e innovación para la mejora del productoSandaS GRC, adquirido hace 3 años.

Esta jornada llega pocas semanas después de la creación de la primera Alianza Global de Seguridad Telco Security Alliance entre operadoras de telecomunicaciones, acuerdo firmado por Etisalat, Singtel, SoftBank y Telefónica, con el objetivo de obtener sinergias operativas y económicas y ampliar la oferta y la accesibilidad a los más de 1.2 billones de clientes a los que se llegará. “La alianza ayudará a todos sus miembros a ofrecer innovación disruptiva que permita proteger la vida digital de nuestros clientes”, afirmaPedro Pablo Pérez, vicepresidente de Seguridad de Telefónica y CEO de ElevenPaths.

Durante aproximadamente una hora la noche de las elecciones primarias en mayo, los residentes del condado de Knox, Tennessee, no podían saber quién había ganado. Habían dejado sin disponibilidad el sitio web de seguimiento de las elecciones del condado, bloqueando la página a las 8 de la tarde, justo cuando se cerraban las urnas. El director de TI del condado, Dick Moran, dijo que el sitio web había visto "tráfico de red extremadamente pesado y inusual". Su alcalde pidió una investigación sobre el ataque cuyas señales apuntan a que lo más probable es que hubiera sido un ataque DDoS.

Los ataques se disparan durante los ciclos electorales en diferentes partes del mundo. En este sentido, Jigsaw, una incubadora tecnológica propiedad de la empresa matriz de Google, Alphabet, ha anunciado Project Shield, una herramienta gratuita de protección DDoS. En el pasado había estado disponible solo para periodistas, defensores de los derechos humanos y a partir de ahora estará disponible para elecciones locales.

Los ataques contra las elecciones se han convertido en una preocupación de seguridad nacional para Estados Unidos, ya que existen múltiples tácticas disponibles para desbaratar la democracia. El Departamento de Seguridad Nacional ha ofrecido ayuda a los funcionarios electorales del estado para asegurarse de que sus máquinas de votación estén a prueba de intrusos y se aseguren de que los funcionarios de campaña sepan cómo mantenerse a salvo.

Más información en Google

Noticias destacadas

Los sistemas de armas, en busca de un sistema de desarrollo seguro

La competencia entre los fabricantes de armas estadounidenses les impide colaborar en problemas de ciberseguridad y está causando vulnerabilidades nuevas y duraderas en los sistemas de armas del ejército de Estados Unidos. Se supone que el Departamento de Defensa debe completar las evaluaciones sobre las vulnerabilidades para un total de 31 programas de armas diferentes antes de 2019, según un requisito de la Ley de Autorización de Defensa Nacional (NDAA) de 2016. Pero el problema de asegurar lo que generalmente son sistemas de armas, que a menudo se ejecutan en sistemas operativos obsoletos o personalizados, ha sido un desafío bien conocido durante décadas. El gobierno, cada vez más consciente de estas amenazas específicas y dirigidas a este tipo de tecnología, el ejército ahora se apoya en el sector privado para priorizar la seguridad durante el ciclo de desarrollo.

Más información en CyberScoop

FBI emite una alerta sobre el nuevo software relacionado con el grupo Hidden Cobra

El US-CERT ha lanzado una alerta conjunta con el DHS y el FBI, advirtiendo sobre dos nuevas piezas de malware identificadas que están siendo utilizadas por el grupo Hidden Cobra como son un RAT conocido como Joanap y un gusano conocido como Brambul. Se cree que Hidden Cobra, que a menudo es conocido también como Lazarus Group y Guardians of Peace, está respaldado por el gobierno de Corea del Norte y atacar contra organizaciones de medios de comunicación, aeroespaciales, sectores financieros y de infraestructura crítica en todo el mundo. DHS y el FBI también han proporcionado listas descargables de direcciones IP con las que se comunica el malware Hidden Cobra y otros IOC, para ayudarlo a bloquearlo y así reducir la exposición a cualquier actividad por este grupo.

Más información en IC3

Noticias del resto de la semana

Error crítico descubierto en la plataforma EOS basada en Blockchain

Investigadores de seguridad han descubierto una serie de nuevas vulnerabilidades en la plataforma de blockchain EOS, en la que una de ellas podría permitir de forma remota tomar el control completo de los nodos que ejecutan las aplicaciones críticas basadas en blockchain. Para lograr la ejecución remota de código en un nodo específico, todo lo que un atacante debe hacer es cargar en el servidor un archivo WASM creado con fines maliciosos (un smart contract) escrito en WebAssembly.

Más información en The Hacker News

Se encuentran contraseñas hardcodeadas en el software de Cisco Enterprise

Cisco ha lanzado recientemente 16 avisos de seguridad, incluyendo alertas para tres vulnerabilidades clasificadas como críticas y que recibieron la máxima puntuación de severidad de CVSSv3. Las tres vulnerabilidades incluyen un backdoor y dos omisiones del sistema de autenticación para el Centro de arquitectura de red digital de Cisco (ADN).

Más información en CISCO

El malware VPNFilter afecta a 500.000 dispositivos de red en todo el mundo

Según Talos, el malware VPNFilter podría ser la base de una de las mayores redes de dispositivos descubiertos hasta la fecha. Mediante esta botnet, los atacantes podrían compartir datos entre los dispositivos y coordinar un ataque masivo utilizando los equipos como nodos. Sin embargo, al incluir un kill switch, también podría destruir los equipos dejándolos inoperativos y eliminar el acceso a Internet para cientos de miles de usuarios, además de inspeccionar el tráfico y robar datos confidenciales.

Más información en Talos Intelligence

Otras noticias

Un error en Git permite la ejecución de código arbitrario

Más información en Security Affairs

El stealer TeleGrab dedicado a sustraer la caché y las claves de Telegram

Más información en SC Magazine

La botnet Wicked utiliza un conjunto de exploits para infectar redes IoT

Más información en ThreatPost

¡Regístrate a la newsletter!

En la entrada anterior sobre este tema, analizamos cómo las claves privadas de Bitcoin son suficientemente seguras, siempre que se utilicen de forma correcta. Pero, ¿qué sucede con las claves públicas y sobre todo, con los algoritmos de hash SHA-256 y RIPEMD-160?, ¿serán suficientemente seguros para impedir colisiones en las direcciones de Bitcoin? ¡Vamos a verlo!

Claves públicas y direcciones de Bitcoin

En los criptosistemas de curva elíptica, cada clave pública es un punto de la curva referenciado por sus coordenadas (x,y), el cual ha sido obtenido a parir de la clave privada. En el caso de Bitcoin y su curva “secp256k1”, las coordenadas “x” e “y” son dos números de 256 bits de tamaño.

La clave pública puede expresarse de dos formas, según se utilicen una (x), o las dos coordenadas (x,y), generalmente en codificación hexadecimal:

Sin comprimir (uncomppressed) 65 bytes: “04” + x + y
Comprimida (compressed) 33 bytes: “02 o 03” + x (02 si X es par o 03 si es impar)

Desde la primera versión del protocolo Bitcoin se soportan dos “métodos de pago” o posibles salidas de una transacción:

P2PK (Pay to Public Key): Pago a una clave pública
P2PKH (Pay to Public Key Hash): Pago al hash de una clave pública (dirección de Bitcoin)

Un P2PKH es lo que se conoce generalmente por “dirección” (address) de Bitcoin. Se obtiene realizando un “doble Hash” (a veces llamado HASH160). Primero un hash SHA-256 sobre la clave pública, ya sea comprimida o sin comprimir, y sobre el resultado de este, un nuevo hash RIPEMD-160. Posteriormente, se le añade un byte de versión al inicio y cuatro de suma de verificación al final, y se codifica todo en Base58.

Comienzan siempre por un “1” si la versión se corresponde con la red real de Bitcoin. No es posible distinguir si la clave pública de origen está en formato comprimido o sin comprimir; únicamente para facilitar su gestión, se puede expresar una misma clave privada en formato WIF de dos maneras diferentes: cuando comienzan por “L” o “K” para generar la dirección comprimida, y cuando comienzan por “5” para generar la dirección sin comprimir.

En 2012, mediante la adopción del BIP0016, se añadió la posibilidad de realizar el pago a un hash de script o P2SH (Pay to Script Hash) lo que permite, por ejemplo, definir las direcciones, monederos o carteras multifirma, como destino de una transacción. Los hashs de script se identifican fácilmente, ya que al codificar el hash en Base58 siempre comienzan con un “3” en lugar de con un “1” como lo hacen los hashs de clave pública. A día de hoy, los P2SH representan aproximadamente el 25 % de las salidas en transacciones de Bitcoin. Este dato está disponible en tiempo real en la web informativa p2sh.info.

Satoshi Nakamo debió recelar ante los avances en computación cuántica, sobre todo, a raíz de la implementación del algoritmo de Shor. Este mismo temor inquieta a la NSA, ya que cada vez está más próximo el día en que los ordenadores cuánticos dispongan de los “qubits” suficientes para reventar los criptosistemas actuales. Ignacio Cirac, director de la División Teórica para la Óptica Cuántica del Instituto Max-Planck desde 2001b , y desde 2016 consejero adjunto de Telefónica, lo explica de forma clara y amena en cualquiera de sus conferencias. Si quieres saber más, no te pierdas esta.

Para evitar este riesgo, implementó el método de “pago a hash de clave pública” P2PKH, en detrimento del pago directo a clave pública P2PK. De esta forma, la clave pública sólo se expone en el momento de “gastar”, utilizar los bitcoins en el input de una transacción, pero no al recibirlos en el output de una transacción previa; y siguiendo la recomendación de no reutilizar direcciones, se suprime toda posibilidad de ataque al algoritmo ECDSA.

El hash de P2PKH es doble; por si un sólo hash SHA-256 (256 bits) no fuese suficiente, al resultado se le hace otro hash, pero en este caso un RIPEMD-160 (160 bits). 160 bits, ¡menuda reducción!.

Puede entenderse que quisiera redoblar la seguridad con un segundo hash, y que eligiera RIPEMD por su origen Europeo en contraste con los SHA Norteamericanas que vimos en la primera parte de la serie, como el equivalente de 160 bits “SHA-1” propuesto por la NSA es vulnerable al encontrarse la forma de generar colisiones. Pero, la reducción de 256 bits a 160 bits tiene notables consecuencias, que además, podían haberse evitado simplemente con utilizar la variante RIPEMD-256, aunque las direcciones de Bitcoin resultasen un poco más largas.

¿Qué implica reducir de 2^256 posibles valores, a 2^160 posibles valores? Colisiones, sí, y muchas. Exactamente (2^256 / 2^160) = 2^96. Es decir, para cada dirección de Bitcoin existen casi “ocho mil cuatrillones” de claves públicas que generan la misma dirección. Esto es más de 10^28. Hay muchas más claves que generan una misma dirección de Bitcoin que estrellas en el Universo.

Entonces, si el protocolo de Bitcoin prevé un volumen tan ingente de colisiones, ¿no hay nadie buscando alguna? Probablemente habrá muchos proyectos, aunque por diferentes cuestiones, no son públicos y, por tanto, tampoco conocidos, pero merece la pena mencionar uno tan peculiar como controvertido: el “Gran Colisionador de Bitcoin”.

El LBC es un pool que agrupa a diferentes workers que han unido su capacidad de trabajo en busca de una colisión de claves de Bitcoin. Lo hacen de una forma un tanto peculiar, ya que para comprobar que han encontrado una colisión real, sólo comparan las direcciones que generan con direcciones ya utilizadas en la cadena de bloques, y que además aun contengan bitcoins sin gastar, con la esperanza de que el propietario original reclame los fondos, pudiendo entonces verificar que se trata de dos claves diferentes y no de una misma.

Para solucionar la problemática que implica la comparación de las direcciones generadas con una muestra valida, dicen utilizar una estructura de datos probabilística conocida como “filtro de Bloom”. Pero, tanto la elaboración del filtro como cualquier otro detalle del funcionamiento del pool, no es compartido, y la mayor parte del software está ofuscado, por lo que pese a que han publicado varios casos de existo en su sección de “trofeos”, no puede considerarse un proyecto serio. Mantiene, eso sí, una fiel copia de directory.io.

Aunque, posiblemente sean los generadores de direcciones de vanidad el intento que más se aproxime a la búsqueda de una colisión. Se conocen como direcciones de vanidad a aquellas direcciones de Bitcoin que comienzan o contienen una secuencia específica de caracteres, cuya única forma de encontrar es mediante fuerza bruta, generando miles de millones de direcciones e ir comparándolas con el patrón especificado, normalmente con una expresión regular.

Si bien comenzó como una curiosidad, el software para generar estas direcciones ha evolucionado considerablemente, implementándose en OpenCL para ser ejecutado en los cientos o miles de núcleos disponibles en las GPUs, y extendiéndose a otras criptomonedas.

Pese a la elevada capacidad de computo que se alcanza con la implementación en GPUs, el número de intentos requeridos para encontrar un pequeño texto es tan enorme, que el tiempo necesario, literalmente, se eterniza. Por ejemplo, dar con una dirección de Bitcoin que comience por “11Paths” como “11PathsQEx9FmFSiGY873i4BtTtDdYcKh”, necesitaría un billón de intentos (10^12), que pueden realizarse en menos de un día. Pero con tan solo dos cárteres más “11Paths11”, los intentos necesarios se acercan al trillón (10^18), elevándose el tiempo necesario a varios años.

Si tienes una tarjeta gráfica de última generación, y en lugar de participar en una competición online, decides ponerla a generar, tan solo, los ocho mil cuatrillones (10^28) de claves que serían necesarios tener, una probabilidad razonable de encontrar una colisión de dirección completa, tardarías unos 10000 millones de años, que es algo menos de la edad del Universo. La edad del Universo está estimada entre 13761 y 13835 millones de años.

Dada la extrema dificultad que conlleva generar direcciones de vanidad, existen pooles para agrupar el trabajo de varios usuarios, e incluso webs que lo ofrecen como un servicio de pago. De cualquier forma, utilizar estas direcciones es una práctica totalmente desaconsejada, sobre todo si te la provee un tercero, ya que será conocedor de la clave privada correspondiente.

En términos generales, el grueso de los usuarios de Bitcoin se ciñen a las practicas recomendadas en la especificación del protocolo, generando las direcciones de forma totalmente aleatoria y no reutilizándolas en más de una ocasión. La mayoría de las más de 100 millones de direcciones que figuran en la cadena de bloques, solo tiene dos transacciones, una primera de entrada y una segunda de salida. Esto, sumado a que cada vez es mayor el uso pago a hash de script P2SH, hacen que el riesgo de pérdida de bitcoins por una colisión de dirección sea prácticamente nulo.

Podemos concluir por tanto que, los algoritmos criptográficos utilizados en Bitcoin, ECDSA curva “secp256k1”, hash SHA-256 y hash RIPEMD-160, son suficientemente seguros al no existir vulnerabilidades conocidas, y pese a que el protocolo de Bitcoin prevé un importante número de colisiones de dirección, la probabilidad de verse afectado por una es insignificante.

Como usuarios finales, la criptografía que hay detrás del Bitcoin no debería preocuparnos, pero sí que debemos tener otras muchas precauciones, incluso si utilizamos wallets físicos;. En anteriores ocasiones, comentamos la facilidad con la que un mal uso te hace perderlo todo.

Recuerda que si tienes dudas o quieres discutir más sobre el tema, puedes visitarnos en la comunidad de ElevenPaths.

Jorge Rivera

CSA, Chief Security Ambassador

jorge.rivera@11paths.com

» Colisiones, haberlas hay(las). Parte 1
» Colisiones, haberlas hay(las). Parte 2
» Colisiones, haberlas hay(las). Parte 3

Infosecurity Europe (Infosec) es uno de los eventos de seguridad más grandes de Londres. Se trata de una feria donde se reúnen casi 20.000 profesionales alrededor de unos 400 stands de fabricantes, y se muestran los últimos avances en seguridad de la información. Además de esto, se ofrecen conferencias de todo tipo en varios tracks en paralelo. Nos encontraremos en el denominado “Geeck Street” donde hablaremos de "Commands and Control" persistentes para malware a través de Blockchain.

Del 5 al 7 de junio se celebra en el Olympia de Londres esta feria internacional de seguridad. En el track de “Geek Street”, donde solo se admiten conferencias relacionadas con la investigación en seguridad más técnicas, Félix Brezo presentará "Blockchain-Based C&C Techniques: Towards a Persistent Channel", una investigación que demuestra cómo el malware podría valerse de blockchain para crear una infraestructura totalmente persistente e inquebrantable.

Félix Brezo, analista de inteligencia en ElevenpPaths imagen

Siguiendo la línea de publicaciones que ya hicimos en el pasado, en eventos como EuskalHack de junio de 2017 ("Make This Last Forever"), hablaremos de cómo las propiedades de la tecnología de la cadena de bloques pueden ser usadas también con fines menos benignos.

La cadena de bloques mantiene un registro de transacciones de las distintas criptodivisas. Las transacciones, una vez firmadas, se notifican al resto de nodos que conforman la red y son añadidas por los mineros en bloques de transacciones que se encadenan criptográficamente al bloque anterior. De esta manera, se garantiza que una vez que se añade un bloque a la cadena, su modificación conllevaría la modificación de todos los bloques anclados posteriormente, lo que va siendo cada vez más costoso de asegurar conforme se encadenan más bloques nuevos. Aunque el objetivo original de cadenas de bloques como la de Bitcoin era el anclaje de transacciones que registraban los operaciones entre dos direcciones, existe la posibilidad de anclar información adicional codificada como salidas especiales. Este concepto es utilizado para fines legítimos como el anclaje de resúmenes criptográficos de documentos por ejemplo (véase el proyecto poex.io). Sin embargo, la persistencia e inmutabilidad de la información anclada en la cadena de bloques de Bitcoin también puede ser utilizada para anclar información maliciosa como la localizacíón, por ejemplo, de los servidores desde los que administrar una red de equipos infectados.

Para ello, se realiza una prueba en la que se usa uno de los campos de los bloques para almacenar el dominio necesario como "command and control". El malware solo necesitaría registrar otro dominio en el siguiente bloque en caso de que el primero fuera bloqueado o eliminado. De esta manera, garantizamos una persistencia de infraestructura. No solo se muestra cómo es posible, sino que se reflexiona sobre las consecuencias de un malware dañino con estas capacidades.

Innovación y laboratorio

www.elevenpaths.com

Ya conocéis Metashield. Básicamente, es una tecnología propia para analizar y limpiar metadatos que se utiliza en varios de nuestros productos. Aunque los metadatos parecen ya un "viejo" problema, todavía son útiles a la hora de analizar datos filtrados, como en el caso de los discos duros de Bin Laden que ya cubrimos, o incluso resultó ser una pieza clave en la investigación el autor de Wannacry, cuando averiguamos cómo trabajaba el creador e incluso cuál era su idioma por defecto configurado en su Word. Hoy vamos a presentar una nueva forma de usar Metashield, para todos y desde cualquier parte, puesto que hemos creado bots para Telegram, Skype y Slack. Ahora es más fácil que nunca. ¡Vamos a por ello!

Si se quiere utilizar Metashield, tenemos varias opciones. Clean-up online, un cliente para Windows, como tecnología interna de proyectos inminentes como Path8, o la FOCA… pero, ¿cómo usarlo desde tu ordenador, portátil, tablet y/o teléfono? Ahora tenemos la respuesta. Simplemente añade estos bots como un nuevo chat en Skype, Telegram o Slack y envía (o comparte) un fichero.

https://msbot.e-paths.com

Los bots analizarán y mostrarán los metadatos y, si quieres, lo limpiarán. Esto permite:

Limpiar y analizar ficheros desde cualquier plataforma o sistema operativo donde se puedan usar Telegram, Slack o Skype.
Limpiar y analizar ficheros antes de compartirlos con solo arrastrar y soltar. Si tienes Skype, Telegram o Slack sincronizado entre diferentes dispositivos, el fichero analizado o limpiado también estará disponible en ellos. Es como si se utilizara un "Metashield distribuido".

Además, en el caso de Telegram, por ejemplo, te permite crear tus propios desarrollos, como API, si se quieren usar los bots de forma automática.

Se pueden analizar hasta 500 ficheros cada hora, pero, hemos limitado las limpiezas a dos ficheros por hora para que no se abuse del servicio. Por favor, ten en cuenta que estos servicios todavía se encuentran en beta, así que rogamos disculpéis una posible caída temporal. No almacenamos ningún fichero, así que la privacidad está garantizada.

Hemos grabado varios vídeos que muestran lo sencillo que es configurar y usar los bots en cada una de estas plataformas.

Metashield Bots para Slack:

Metashield Bots para Telegram:

Metashield Bots para Skype:

Equipo de Innovación y laboratorio

www.elevenpaths.com

Si quieres estar al día en seguridad informática no puedes faltar a las citas que hemos seleccionado para ti. Aquí tienes la lista de actividades en las que participamos a lo largo del mes de junio, si coincide alguna de ellas en tu ciudad, acércate a conocernos. También hay eventos online a los que puedes asistir estés donde estés y de manera gratuita. ¡Haz hueco en tu agenda!

Network Innovation Day 2018 - We Are In

El próximo 14 de junio, Telefónica celebra la primera edición del Network Innovation Day, el evento de seguridad en la red más importante de la compañía. Contará con ponentes de destacado nivel comoChema Alonso, nuestro Chairman y Chief Data Officer de Telefónica; Enrique Blanco, Global CTIO de Telefónica y expertos del sector. Accede a la web y regístrate al evento, si no puedes asistir, regístrate vía streaming para poder verlo estés donde estés.

Network Innovation Day evento Telefónica

OpenExpo 2018

Durante hoy y mañana se celebra OpenExpo, el mayor Congreso y Feria profesional sobre Open Source & Software Libre y Open World Economy (Open Data y Open Innovation) de Europa. Un evento de referencia internacional para tecnologías abiertas con oportunidades de exhibición, sponsorship, conferencias, mesas redondas, talleres y actividades dentro del ecosistema de tecnologías gratuitas. Varios de nuestros expertos y hackers como Chema Alonso, Yaiza Rubio y Pablo González, han participado a lo largo del día de hoy con ponencias relevantes sobre ciberseguridad. Si estás en Madrid, pásate mañana y conoce a nuestro equipo en el stand 64, junto a LUCA (la unidad de Big Data de Telefónica).

InfoSecurity Europe

Infosecurity Europe (Infosec) es uno de los eventos de seguridad más grandes de Londres. Se reúnen casi 20.000 profesionales, alrededor de unos 400 stands de fabricantes, y se muestran los últimos avances en seguridad de la información. Nuestro analista de inteligencia, Félix Brezo, estuvo allí los pasados 5, 6 y 7 de junio en el denominado “Geeck Street”, donde presentó "Blockchain-Based C&C Techniques: Towards a Persistent Channel", una investigación que demuestra cómo el malware podría valerse de blockchain para crear una infraestructura totalmente persistente e inquebrantable.

CCI La Voz de la Industria

El CSA Manager Claudio Caracciolo viaja a Uruguay para participar como ponente en este encuentro dirigido a la industria, presentándose por primera vez los resultados preliminares del estudio sobre el estado de la ciberseguridad en la industria de Uruguay. El 7 de junio estará en la mesa de debate como experto en ciberseguridad hablando sobre las diferentes maneras de implementar protección de infraestructuras críticas para el negocio y para el país.

II Conferencia Internacional de Resiliencia Organizacional

La ciber-resiliencia es la capacidad de los sistemas y las organizaciones para resistir ante ciber-eventos. Implica, por tanto, la preparación ante amenazas y vulnerabilidades, los controles que se han implementado y las capacidades de los recursos disponibles ante la materialización del fallo de seguridad. El 11 de junio en Barcelona, y 12 de junio en Madrid, el CISO de Telefónica Alejandro Ramos participará en esta conferencia con su ponencia sobre "Ciber-resiliencia: contribución de un sistema de gestión de la seguridad de la información". ¡No te lo pierdas!

Ciberseguridad: la protección de las infraestructuras críticas en España

El próximo 12 de junio, nuestro VP de Estrategias de Seguridad, Luis Francisco González, participará en la mesa redonda de esta jornada, en Madrid. El objetivo es analizar los riesgos a los que se ven sometidas las infraestructuras críticas de España, además, se conocerán las directrices y estrategias que se deben seguir en materia de ciberseguridad y ciberdefensa. Regístrate aquí.

Security Innovation Conference

Esta conferencia se celebrará el 13 de junio en Perú y contará con varios de nuestros expertos y CSAs. Security Innovation Conference está focalizada en la temática de la ciberseguridad y las novedades de esta. Rames Sarwat, VP de alianzas, hablará sobre cómo Blockchain puede salvar el mundo. También, los CSAs Diego Espitia, y Gabriel Bergel, revelarán un análisis de seguridad de LATAM. Y, por último, los CSAs Fabian Chiera y Carlos Ávila, expondrán sobre la seguridad en el diagnóstico por imágenes.

Hacking París

A finales de mes, el 28 de junio, el CSA Manager Claudio Caracciolo y la experta Sheila Berta, expondrán en la conferencia Hacking París acerca de "The Bicho: an Advanced Car Backdoors Makers". Los intentos de intrusión son cada vez más frecuentes y sofisticados, independientemente de su objetivo. Hacking Paris tiene como objetivo hablar sobre las prácticas de piratería desde un enfoque técnico. El programa incluye lo último en seguridad de IT, espionaje industrial, pruebas de penetración, seguridad física, análisis forense y técnicas de análisis de malware.

ElevenPaths Talks: La red bajo ataque

¿Quieres saber cómo proteger tu navegador red de ataques? Apúntate a este webinar en el que hablaremos sobre temas relacionados con Yara Rules y herramientas del mercado para mantener nuestros navegadores seguros. Mañana, a las 17:30h (CET), disponible este #11PathsTalks en la comunidad de ElevenPaths. ¡No te lo pierdas!

Code Talks for Devs: 'UAC-A-Mola', un framework que permite investigar, detectar y mitigar bypasses de UAC

En este #CodeTalks4Devs, nuestros expertos Pablo González y Santiago Hernández, hablarán sobre una de nuestras herramienta llamada UAC-A-MOLA. Además, veremos qué es un bypass de UAC y cómo podemos utilizarla para investigar, detectar, explotar y mitigar este tipo de fallos de seguridad en los últimos sistemas operativos Windows. El próximo 20 de junio te esperamos en la comunidad de ElevenPaths para poner tus conocimientos a prueba.

Code Talks for Devs: 'UAC-A-Mola webinar

Os dejamos todas los seminarios completos de las temporadas de nuestros ElevenPaths Talks y Code Talks for Devs:

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

» Code Talks for Devs - Temporada 1
» Code Talks for Devs - Temporada 2

Si eres un amante de la seguridad informática no te puedes perder estas citas con otros profesionales y expertos del mundo de la ciberseguridad.

En esta edición de 2018 de la JNIC estaremos presentando nuestro paper llamado “Descubriendo y dibujando redes ocultas creadas con dispositivos USB”. Más concretamente, será la mañana del día 13 de junio en San Sebastián (Gipuzkoa).

Pero esta no será la única aportación de ElevenPaths a esta edición del JNIC, también hemos participado con una serie de nuevos retos científicos sobre temáticas interesante y diversas que detallamos aquí:

Así que ya sabéis, manos a la obra y os esperamos en esta edición de JNIC. ¡Gracias!

Fran Ramírez

Equipo de Crazy Ideas en CDO (Telefónica) e investigador de Seguridad Informática en ElevenPaths

@cyberhadesblog

franciscojose.ramirezvicente@telefonica.com

Los antivirus han sido (y siguen siendo) una de las herramientas más prácticas a nivel de usuario para combatir las amenazas de ciberseguridad. Aunque resulte difícil mantenerse completamente actualizado ante los nuevos retos, proporcionan una herramienta muy útil para la detección y mitigación de amenazas conocidas. Uno de los retos de la industria (aunque ya casi que se ha tirado la toalla) ha sido siempre el intentar homogeneizar sus firmas para que todos los motores cataloguen, al menos de forma parecida, las diferentes familias de malware. Esto ayuda a que el usuario pueda determinar qué malware ha detectado y permite que disponga de más información a la hora de tomar decisiones sobre la gravedad de la situación, y actuar en consecuencias. Detectar un Trojan.Generic no suele ayudar mucho a tomar una contramedida adecuada, mientras que Adware.Generic, o Ransom.SamSam, por poner algunos ejemplos, pueden resultar más útiles. Incluso así, siempre existirá la duda de si estas firmas corresponden con la naturaleza del malware.

Hubo un momento en que se trabajó para que existiese un esquema de nomenclatura del malware homogéneo. Se hizo a través de la organización CARO. Si visitamos su página, todavía lo listan como una prioridad, aunque lo cierto es que se dejó de intentar hace muchos años. Resulta irónico que a pesar de afirmar que es importante, la web lleva a un 404 cuando se busca más información.

Aunque resulte importante la terminología del malware, en realidad el proyecto no cuajó

Una firma de antivirus corresponde al fragmento de texto que cada motor emite cuando detecta que una muestra analizada es o contiene algún tipo de malware. Aunque cada motor utiliza nomenclaturas y fórmulas muy diferentes, existe cierto consenso con respecto a mantener en información genérica sobre la naturaleza de la muestra. Por ejemplo:

a variant of Android/AdDisplay.Startapp.B

Adware/Startapp.A

Adware.AndroidOS.Youmi.Startapp (v)

Que corresponden a las detecciones proporcionadas por tres antivirus distintos a la misma muestra. En este mismo ejemplo se evidencia el principal problema que tiene utilizar más de un antivirus para tomar decisiones. En especial cuando se utilizan múltiples motores para el análisis.

SignatureMiner al rescate

Para solventar este problema, hemos desarrollado una prueba de concepto que se ha materializado en la herramienta que hemos bautizado como SignatureMiner. Ayuda a sus usuarios a descubrir reglas que rigen la generación de la mayoría de firmas y usar esas reglas para homogeneizar firmas a un esquema normalizado. Hemos aprovechado Tacyt y la clasificación de malware usada en otras investigaciones, para abordar el proyecto centrándonos en malware para Android.

La herramienta se ha escrito en Python y consta de dos componentes (equivalentes a scripts): classMiner y classAssigner. Vamos a revisar cada uno de los componentes y cómo se usan para identificar reglas (como expresiones regulares de Python) y normalizar firmas para, por ejemplo, determinar la clase de malware de una muestra por voto mayoritario (majority voting).

Instancia del programa funcionando

ClassMiner: El componente de minería de reglas de SignatureMiner está basado en un algoritmo de similitud de textos conocido como Min-hashing, que calcula funciones de hash sobre distintos trozos del mismo texto para quedarse con el mínimo de cada firma. De este modo, cada firma tiene asociado un hash mínimo o "minhash" que será el identificador de su grupo. ClassMiner limpia y separa las firmas de antivirus por puntos, calculando sobre cada elemento resultante su minhash. Una vez calculados los minhashes, SignatureMiner agrupa los distintos trozos de firmas con igual minhash y se los presenta al usuario para que los analice. Es en este momento, cuando el usuario recorre la lista de elementos y genera expresiones regulares, reglas que puedan unir bajo la misma clase un conjunto de firmas similares. Tras elaborar las reglas, el usuario puede volver a ejecutar ClassMiner aplicando las reglas que ha encontrado, de modo que el resultado pueda ayudar a mejorar esas reglas (si se encuentran nuevos trozos de texto que antes no se habían encontrado) y verifique su funcionamiento (cuando los grupos que se encuentren sean circunstanciales). Una vez elaboradas estas reglas, se pasan al componente ClassAssigner de SignatureMiner, que será el encargado de asignar una clase única a cada muestra.

ClassAssigner: El componente de normalización de firmas de SignatureMiner utiliza las reglas extraídas por ClassMiner para normalizar cualquier firma "en crudo". Para ello, simplemente, limpia las firmas y les aplica las reglas extraídas en riguroso orden de aparición, según el principio de first match. Además, ClassAsigner soporta la votación de mayoría, siendo capaz de elegir, de entre todas las detecciones normalizadas, aquella en la que más antivirus coinciden. Dentro de las reglas, ClassAssigner introduce una regla por defecto que engloba todas aquellas firmas que no han podido ser detectadas por ninguna otra regla.

Mediante estos dos componentes, SignatureMiner proporciona una herramienta capaz de ayudar a identificar patrones de normalización (reglas) de firmas de antivirus y clasificar cada una de ellas en su clase correcta. De hecho, SignatureMiner proporciona una amplia versatilidad al usuario, ya que al ser este el encargado último de determinar las reglas, puede usar la herramienta para descubrir detalles de un conjunto de muestras (como versiones, sistemas operativos, etc.) así como personalizar la granularidad de las familias de malware (en nuestra prueba, adware sólo por ejemplo o más granularidad como startApp, Revmob, etc.).

SignatureMiner está pública en Github, donde se puede encontrar tanto la herramienta como su guía detallada de uso ( Para más detalles: http://github.com/ignmarti/signatureminer).

Premio al mejor póster en la IEEE CNS de Pekín 2018

Este desarrollo parte de una investigación anterior ya publicada, que ahora, promovida desde el área de innovación y laboratorio de ElevenPaths, se ha mejorado y desarrollado en conjunto con la Universidad Carlos III de Madrid. Fue aceptada para participar en la IEEE Conference on Communications and Network Security en Pekín, donde a finales de mayo se presentaron los resultados. Resultó ganadora del mejor póster del congreso.

Ignacio Martín y el Equipo de Innovación y Laboratorio de ElevenPaths

ignmarti@it.ic3m.es