Español | English
rss facebook linkedin Twitter

Sonae IM y S21sec refuerzan su posición en Europa gracias a la adquisición de SysValue.


La posibilidad de aprovechar sinergias entre S21sec y SysValue convertirá a Sonae Investment Management (IM) en la mayor entidad cibernética de Portugal.


Sonae Investment Management (IM) ha confirmado la adquisición de SysValue, una compañía de servicios de ciberseguridad con presencia en el sector de las telecomunicaciones, servicios financieros, energía y gobierno. Las actividades de auditoría, consultoría, integración, formación e I+D de la entidad consolidarán a Sonae IM como una pieza clave en el liderazgo del mercado portugués.

Esta adquisición, tras la operación de S21sec en septiembre de 2014, representa otro hito significativo en el liderazgo de Sonae IM en el mercado europeo de la ciberseguridad y en la estrategia de expansión internacional de la compañía.

Según Carlos Alberto Silva, miembro del Consejo de Sonae IM, "Estamos orgullosos de este paso que va ayudar a fortalecer nuestro portafolio de ciberseguridad, ya que creemos que hay una clara oportunidad de crecimiento para nosotros. SysValue representa un activo importante para nosotros en Portugal e incluso en otros mercados. Vamos a seguir buscando oportunidades de crecimiento orgánico e inorgánico”.

Según Xabier Michelena, fundador y CEO de S21sec, “Es un paso muy importante en nuestra expansión internacional ya que podremos ampliar nuestra cartera de clientes y ofrecer servicios específicos de gran calidad a nuestros clientes”. Con la adquisición de Sysvalue, S21sec refuerza su capacidad y especialización en el mercado Portugués.

En esta línea, João Barreto, Fundador y Presidente del Consejo de SysValue, afirma que: "Formar parte de la estrategia de ciberseguridad de Sonae IM es el resultado de 14 años de dedicación a la seguridad de la información. Formar equipo con S21sec es una oportunidad para elevar la prestación de servicios de ciberseguridad a niveles sin precedentes de experiencia y sofisticación. Gracias a este acuerdo, se ampliará la oferta de servicios, la orientación al mercado de las iniciativas de I+D de SysValue y la prestación de servicios a nivel internacional”.

La integración de SysValue a la cartera de Sonae IM también permitirá la obtención de sinergias significativas que implicarán la puesta en común de conocimientos y experiencia en técnicas de suministro y recursos de I+D, el establecimiento de estructuras comunes, la alineación de las estrategias de orientación al mercado y la consolidación de posiciones en las cuentas clave.

De aquí en adelante, Sonae IM podrá aprovechar las relaciones y actividades de sus compañías con el objetivo de reforzar la estrategia de la Unión Europea de fortalecer la solidez y preparación de las regiones a la hora de hacer frente a incidentes de ciberseguridad. A través de S21sec, Sonae IM asume la Presidencia del Grupo Europeo de Ciberseguridad (ESCG), una alianza de 5 empresas líderes europeas.


S21sec
www.s21sec.com

NEVERQUEST EVOLUTION



Neverquest también conocido como “Vawtrak”, es un troyano, que lleva jugando un papel importante desde hace un par de años, y durante los últimos meses, nuestro equipo de investigación ha descubierto una evolución del mismo.

Lo  que persigue Neverquest, es el robo de credenciales, principalmente bancarias. No solo opera con ataques dirigidos al sector financiero, sino que también ataca a otros sectores.


Sus objetivos, están definidos en un fichero de configuración, es  capaz de realizar inyecciones en procesos de Firefox, Internet Explorer, Chrome o inyecciones HTML.

Los cambios que nos encontramos a priori en esta nueva evolución son los siguientes:
  • Encriptación para todos los datos que utiliza (archivos, comunicación..)
  • Hace uso de diferentes tipos de cifrado para cada tipo de datos que maneja, pero en general se basa en un generador de números alegatorios (RNG), que genera diferentes secuencias de números y diferentes algoritmos (basados en combinaciones de xor, sub…) que descifra los datos.
Para el caso de la configuración que descarga desde el C&C, este malware lleva varias capas de cifrado adicionales; Una primera capa basada en el RNG, una segunda capa de compresión con LZMAT, y por último, independientemente para cada bloque de la configuración, vemos otra capa más de cifrado basado en una tabla de sustitución.

En la configuración recibida del servidor aparecen principalmente las inyecciones que el malware va a realizar para robar información al usuario infectado, pero al final de la misma, también aparecen 5 URL´s más. Las 4 primeras son URL´s de módulos, y la última de update. De estas URL´s,  el malware puede descargar módulos adicionales (pueden ser otros malware o pueden ser complementos del propio Neverquest) o “updates”.
Tanto los módulos, como los updates, van cifrados con una capa de cifrado basada en el RNG que comentábamos.

En esta investigación, realizamos una comparativa de ataques en cuanto a países y sectores, con un peso significante en la dirección y evolución del malware del 2016 frente al año 2015; Es relevante destacar que durante su evolución, el principal impacto da lugar a ataques mucho más controlados y dirigidos, etc… ,  dejan de ser el principal objetivo para estos cibercriminales de Neverquest.
 

Gráfica de principales países afectados durante 2016

Consejos para evitar ser víctima de este ciberataque  y cuáles son las medidas de seguridad desde nuestros especialistas de ACSS:

  • Cómo siempre, el uso del sentido común, y evitar cualquier enlace, archivo que te pueda parecer sospechoso o no venga de una fuente fiable en los correos electronicos.
  • Actualizaciones del Sistema Operativo, Software y Sistema Antivirus.
  • Control periodico de los movimientos de tu cuenta bancaria y comprobar que ningún movimiento es extraño, y todos los cargos son conocidos.
  • Desactivar las extensiones por defecto Flash y Java del navegador.

S21sec

Drown a fondo: Un nuevo ataque al SSL. (PARTE III)



En los anteriores posts [parte1] [parte2] hemos ido viendo algunos conceptos necesarios para entender DROWN en su totalidad. Recordemos que el artículo original en el que se describe el ataque en profundidad puede encontrarse en la siguiente dirección https://drownattack.com/drown-attack-paper.pdf

La situación partía de que existe un mensaje “m0” conocido como pre-master-secret que contiene información sobre la clave simétrica utilizada en una conexión SSLv3/TLS, del que sólo conocemos “c0”, que es el mensaje cifrado con la clave pública RSA del servidor. También hemos visto que es posible derivar a partir de “c0” un mensaje “c1”, que es la versión cifrada de un mensaje “m1”, y que conociendo la relación entre “c0” y “c1” (que es un valor escogido por el atacante y al que llamamos “s”), conocemos también la relación entre “m0” y “m1”, por lo que si conseguimos descubrir el valor de “m1”, seremos capaces de calcular “m0”, a partir de él las claves simétricas de la conexión  SSLv3/TLS y por tanto podríamos descifrar la comunicación. El objetivo ahora mismo es encontrar un “m1” que sea aceptado como master-key por un servidor SSLv2 que comparta la clave RSA con el servidor SSLv3/TLS original.

El problema es que escogiendo un valor “s” al azar la posibilidad de conseguir que el mensaje “m1” sea aceptado como master-key por el servidor SSLv2 es inferior a 1 entre 33 millones, y que necesitamos aplicar 240 operaciones de descifrado simplemente para saber si m1 es un master-key o no, lo que hace que esta aproximación sea inviable.

Es necesario aumentar las posibilidades de éxito en lugar de elegir valores de s al azar. Para ello, hay que analizar cómo se cifran tanto pre-master-secret (SSLv3/TLS) como master-key (SSLv2). Ambos datos no se cifran directamente con RSA sino que para aumentar la seguridad del cifrado, se formatean de tal manera que se les añade información aleatoria antes de cifrarlos. El formato se conoce como PKCS#1 v1.5 y tiene la siguiente estructura:



Los bytes marcados en rojo son fijos, mientras que los bytes marcados en azul son los datos que estamos cifrando. Los bytes marcados en verde actúan de relleno. El número de bytes de relleno depende del tamaño de la clave RSA utilizada pero será como mínimo 8. Para el caso de una clave RSA 2048, el tamaño total será de 256 bytes. Estos bytes tomarán un valor aleatorio pero siempre distinto de 0, ya que en caso contrario se podría confundir con el separador entre el relleno y los datos que se están cifrando.

Teniendo en cuenta la estructura anterior, los paquetes pre-master-secret (SSLv3/TLS) y master-key (SSLv2) quedan:


El objetivo del atacante en este caso es conseguir un valor “s” que convierta el mensaje superior en el inferior, para que sea aceptado por el servidor en un algoritmo de cifrado EXPORT de 40 bits (de ahí que en el caso de SSLv2 M sólo tenga 5 bytes frente a los 48 del caso SSLv3/TLS). En este caso puede verse claramente que haga lo que haga el atacante, el resultado tras la multiplicación por  “s” debe empezar por 0x00, 0x02. Al tratarse de aritmética modular, es posible encontrar valores muy diferentes entre sí que den como resultado un número que empiece por 0x00, 0x02. Sin embargo, está claro que muchos valores válidos serán muy cercanos a 1.

Drown a fondo: Un nuevo ataque al SSL. (PARTE II)


En este segundo post seguimos describiendo el ataque DROWN. Más información sobre este ataque puede encontrarse en el siguiente artículo: https://drownattack.com/drown-attack-paper.pdf

En el post anterior llevamos a cabo un análisis del protocolo de negociación de las diferentes versiones SSL/TLS. Vimos cómo dicho protocolo es diferente entre las versiones SSLv2 y las versiones superiores (SSLv3/TLS), e identificamos un valor concreto de 48 bytes de la negociación SSLv3/TLS (pre-master-secret) que de alguna forma pensamos que podemos descifrar sin necesidad de conocer la clave privada, engañando a un servidor SSLv2 que use la misma clave RSA. El siguiente paso a dar era convertir este pre-master-secret en un mensaje que el servidor SSLv2 identifique como un master-key válido y vimos que no era posible recortar a lo bruto el mensaje.

¿Cómo podemos continuar?
La respuesta se encuentra en el cifrado homomórfico. Este tipo de cifrado ya ha sido descrito por otro compañero en este mismo blog. Básicamente un algoritmo de cifrado homomórfico es aquél en el que se puede realizar cualquier operación entre dos mensajes cifrados sin necesidad de descifrarlos. Este tipo de algoritmos realmente no son usables actualmente debido a que la complejidad de las operaciones que hay que realizar sobre los datos cifrados para efectuar lo que en esencia es una suma o multiplicación sobre los datos originales es muy grande (aunque viene reduciéndose de forma notable en los últimos años).

Esta explicación está muy bien, pero no parece acercarnos al objetivo de transformar el pre-master-secret en un master-key. El detalle radica en que RSA es lo que se conoce como parcialmente homomórfico. Es decir, permite un número limitado de operaciones sobre los datos cifrados que llevan a modificaciones concretas en los datos originales. Si tenemos dos mensajes m1 y m2, y definimos E(x) como la operación de encriptar el mensaje x, entonces se da:

E(m1) * E(m2) = E(m1 * m2)

Donde * no es una multiplicación normal, sino una multiplicación en aritmética modular (en RSA todos los mensajes, tanto el mensaje original como el cifrado se tratan como números enteros). Por tanto, dado un valor al que llamamos m0, y del que únicamente se conoce su valor cifrado, al que llamamos c0, el objetivo es encontrar un número s tal que al multiplicar su valor cifrado por c0 nos devuelva un valor al que llamaremos c1, correspondiente a un m1 que es el resultado de multiplicar m0 por s. Es decir, operando con el valor cifrado conseguimos modificar a nuestro gusto el valor original.

En concreto, podemos pensar que m0 es el pre-master-secret que hemos capturado de la comunicación SSLv3/TLS, y el objetivo es descubrir un valor s tal que nos lo convierta en un m1 que sea adecuado para actuar como master-key en la negociación SSLv2:

E(s) * c0 = E(s) * E(m0) = E(s * m0) = E(m1) = c1

Drown a fondo: Un nuevo ataque al SSL. (PARTE I)


A lo largo de las últimas semanas se ha hablado mucho de un nuevo ataque dirigido contra el protocolo SSL/TLS. Este ataque, conocido como DROWN, acrónimo en inglés de "Descifrado de RSA con cifrado débil y obsoleto", permite atacar y descifrar comunicaciones que utilizan incluso la versión más actual de este protocolo, TLSv1.2.

A lo largo de los siguientes posts intentaremos desgranar por qué y cómo funciona este ataque y, lo que es más importante, qué podemos hacer para protegernos contra él. El artículo en el que se describe este ataque en profundidad puede verse en https://drownattack.com/drown-attack-paper.pdf

Para entender DROWN es importante comprender cómo funciona SSL/TLS. Mucha gente sabe que este protocolo se basa en criptografía asimétrica, de tal modo que el servidor dispone de una clave formada por una parte pública (que se presenta al cliente en forma de certificado) y una parte privada, que (idealmente) sólo conoce el servidor. Cualquier dato cifrado con la clave pública debe descifrarse con la clave privada y viceversa. Sin embargo, lo que ya menos gente conoce es que, en general, los algoritmos asimétricos son, para proporcionar un nivel de protección similar, considerablemente más lentos que los algoritmos simétricos. Por ello, cliente y servidor utilizan la criptografía asimétrica únicamente para identificarse entre ellos e intercambiarse información suficiente para generar una serie de claves simétricas, que serán las utilizadas posteriormente durante la comunicación en sí.

El proceso de determinar estas claves simétricas e intercambiarlas de forma segura se conoce como "handshake", y tiene la misma estructura para las versiones SSLv3 y TLS del protocolo. Se muestra de forma esquemática (en su caso más sencillo, en que el cliente no se autentica mediante certificado, y para intercambio de claves mediante RSA) en la siguiente figura:


El cálculo de las claves simétricas se realiza a partir de tres valores que se intercambian durante este proceso:
  • Un número aleatorio enviado por el cliente en el mensaje ClientHello
  • Un número aleatorio enviado por el servidor en el mensaje ServerHello
  • Un tercer código de 48 bytes conocido como pre-master-secret, generado aleatoriamente por el cliente y enviado al servidor en el mensaje ClientKeyExchange, cifrado con la clave pública del servidor.

Descifrando Ransomware



Días atrás, fuimos testigos de la trama en relación al hospital de Presbyterian Medical Center Hollywood, que era víctima de un ataque de cibercrimen, causando en este ataque la paralización de todos los servicios del hospital por una agresiva infección de malware de ramsonware, dejando cifrados miles de documentos. Este Malware se expandió a través de sus  unidades compartidas dejando la red del hospital completamente inoperativa. Esto derivó en la suspensión de todos los servicios durante 10 días, lo cual provocó que el personal del centro se viera obligado a usar papel y fax en todo lo relacionado con los trámites que tenían que ver con sus pacientes y ocasionando el caos en el desarrollo de la actividad habitual del hospital. Muchos pacientes tuvieron que ser trasladados a clínicas cercanas, desencadenando la confusión y desorden en el funcionamiento del centro.
 
El objetivo de este ataque era obtener un “rescate económico” a cambio del cual, los cibercriminales entregarían las claves de descifrado. Este rescate tenía un precio de  unos 9.000 BTC  (3,9 billones de dólares), sin embargo, el hospital fue capaz de volver a poner operativa la red comprando claves de descifrado por valor de 17.000 $. Por supuesto, las pérdidas generadas en este suceso fueron mucho más elevadas, ya que produjo un impacto directo en la continuidad del negocio.

Los ciberdelincuentes responsables de estas campañas, no han inventado nada nuevo, simplemente se han limitado a unir las piezas ya existentes: Cifrado asimétrico, Herramientas para la distribución de malware,  Criptodivisas (en este caso Bitcoin) y aprovecharse de la dependencia de los sistemas informáticos para la continuidad de los negocios o el desarrollo de la vida diaria gestionando nuestra información.

Las ventajas

Desde el punto de vista del ciberdelincuente, el ramsonware presenta tres ventajas sustanciales respecto a los troyanos bancarios tradicionales. La primera es que,  técnicamente resultan sencillos de programar; este malware no requiere capacidades especiales como ocultación o escalada de privilegios, y además el código responsable del cifrado se limita a llamar a funciones de la API del sistema. Esta relativa simplicidad en su código tiene varias consecuencias en la manera en la que se estructuran estas nuevas amenazas:

  • Variabilidad: en un corto espacio de tiempo han aparecido multitud de familias (Cryptolocker, Cryptowall Teslacrypt, Locky y otros nombres, a cual más original), a diferencia con el malware bancario cuyo desarrollo es lento y la aparición de nuevas variantes se espacia en el tiempo. A pesar de esta variabilidad las muestras presentan un funcionamiento muy similar; Si bien hay peculiaridades locales, como la captura de contactos de correo que realiza Torrentlocker para alimentar nuevas campañas de spam.
  • Economía: Al no requerir los servicios de programadores especializados en inyecciones contra banca online, el desarrollo resulta aún más barato y la inversión en un ciberataque es muy rentable
  • Mejoras: Resulta más fácil introducir parches y mejoras en el código. Por ejemplo, algunas versiones iniciales contenían un fallo en la implementación del cifrado que permitió crear una herramienta para recuperar los documentos. Sin embargo, los desarrolladores corrigieron rápidamente el error pasando a usar AES en modo CBC (cipher-block chaining). Otro detalle que ha cambiado es la proporción del fichero que se cifra, mientras que las variantes antiguas actuaban sobre los dos primeros Mb de cada fichero, las últimas únicamente cifran el primer mega. El archivo queda inservible igualmente y se mejora la rapidez del malware.

Recorremos RootedCON 2016

Jueves 3 de marzo, nos enfundamos nuestras camisetas de S21sec, montamos nuestro stand, y nos preparamos para vivir la experiencia. ¡Comienza la RootedCON 2016!

Con la participación de Juan Antonio Gómez Bule, presidente del consejo asesor de S21sec, como ponente y con presencia en nuestro stand corporativo de People Culture, nuestros expertos del departamento de ecrime, ventas y marketing...



 

¿Qué vivimos en la RootedCON 2016?

  • Un intenso Intercambio de experiencias con expertos en ciberseguridad, antiguos compañeros de S21sec y otros muchos nuevos contactos.
  • Estar rodeados de talento, talento y más talento.
  • Participación en foros específicos.
  • Novedosas charlas con contenido más que interesante.
  • Ejercicios de concienciación en temas de ciberseguridad con familias y menores, donde los más pequeños fueron los protagonistas.


¿Qué destacamos?


Nuestro compañero Carlos Rubio del departamento de ecrime, nos hizo llegar sus conclusiones en lo referente a contenido y ponencias, y es que llamó la atención la calidad de las presentaciones que nos ofrecieron, y destacamos las siguientes : 

 
Windows BootKits: Cómo analizar malware persistente en MBR/VBR por Abel Valero, que nunca defrauda y que nos presentó las características del bootkit Rovnix y las herramientas que fueron necesarias para depurarlo. Ponencia imprescindible si te dedicas a analizar malware.

CERTIFI-GATE: Has your Android device been Pwned?: Jonathan Shimonovich nos demostró que Android tiene un serio problema con los certificados. Esta vulnerabilidad deja expuestos a todos los dispositivos de Android, incluso en las versiones más recientes.
 
Odin: Footprinting en la era del BigData: Una herramienta muy interesante de la mano de Elías Grande, que permite realizar un inventariado de las direcciones IP y dominios que componen la presencia de una organización en Internet. La cantidad de información que es capaz de cotejar esta herramienta a través de su proceso de Big Data, incluso de manera pasiva, nos ha dejado muy sorprendidos y esperamos saber más de ella una vez esté disponible en 2017.
 
Broker & MQ injection (Con demo en directo donde liberó la herramienta en tiempo real): Daniel García nos mostró la facilidad con la que podemos tomar el control de los Broker de mensajería (Message Queues), a través de su herramienta Enteletaor y la técnica que él denomina MQ injection. Destacó lo expuesta que estaría una organización si un atacante llega a tomar el control de esta forma.
Teniendo en cuenta que sistemas como Storm, que hacen uso de Brokers, son usados para el análisis de stocks, este ataque podría usarse para inyectar información incorrecta y llegar a afectar al sistema financiero.
 
All your bebop drones still belong to us: drone hijacking: Pedro Cabrera explico cómo realizo el análisis del dron Parrot Bebop y nos demostró cómo puede, a través de ingeniería inversa del protocolo de comunicaciones, tomar el control completo del dron. 
 
Atacando 3G Vol. 3: Los cofundadores de Layakk, José Picó y David Pérez ganadores del premio a mejor ponencia de la RootedCON 2015, nos demostraron cómo podían hacer distintos ataques a la tecnología 3G como el IMSI Catching usando una estación falsa, geolocalización de dispositivos, denegación de servicio usando códigos de rechazo (LUPRC) e illegal MS y ataques selectivos a través de downgrade 2G. Nos mostraron todo eso sin afectar a nuestros dispositivos gracias a la caja de Faraday que traían para realizar la demostración. Esperamos con ganas verles de nuevo en la RootedCON 2017 para que nos muestren sus avances con la tecnología 4G.
 
Attack is old. Defense is cooler: Juan Garrido nos demostró cómo podemos enfrentarnos al creciente problema del ransomware, haciendo hincapié en la importancia de hacer una correcta configuración de las infraestructuras para detectarlo y erradicarlo, porque como él dice “una buena defensa también puede ser cool”.
 
Hardware Backdooring X11 with much class and no privileges: Una ponencia curiosa donde Matias Katz exponía cómo a través del bus X11 podía comunicarse con los dispositivos, a pesar de estar bloqueados. Además nos presentó cómo podía bloquear y desbloquear su ordenador, siguiendo un patrón y haciendo uso de un simple conector de tipo jack.




 

Conclusiones

El ambiente, con unos destacables 1000 asistentes, fue excepcional y el contenido de gran interés.

Destacar también los tradicionales desayunos de conchas codan, las camisetas más “frickis”, los gadgets más divertidos, el dron que atacó la mano de nuestro querido Román… ¿o fue al contrario? ;-), así como la gran fiesta que se llevó a cabo al finalizar el evento donde no faltó nadie y donde ya en un entorno mucho más relajado por organizadores, ponentes, etc., pudimos disfrutar como enanos.
 
¡Volveremos!

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login