December 12h: Innovation Day in Eleven Paths

viernes, 29 de noviembre de 2013

On December 12th, 2013, in Madrid, Eleven Paths will come out in society in an event we have named Innovation Day. In this event Eleven Paths will introduce old an new services, besides some surprises. Registration is necessary to assist, from this web.

Eleven Paths started working inside Telefónica Digital six months ago. After quite a lot of hard word, it is time to show part of the effort we have been trough during this time. Besides Eleven Paths, Telefónica de España and Vertical de Seguridad de Telefónica Digital will present their products and services as well, in this Innovation Day.


We will talk about Teléfónica CiberSecurity services, FaastMetaShield Protector family products, Saqqara, antiAPT services... and, finally, about a project that has remained secret so far and dubbed "Path 2" internally. December 12th and later on, this technology will be revealed step by step. For Eleven Paths, it has been a real challenge to deploy it during this period. But right now, it is a reality. It is already integrated in several sites and world level patented.

Clients, security professionals and systems administrators... they are all invited. The event will occur on Thursday, December 12th during the afternoon (from 16:00)  in the central building Auditorio of campus DistritoTelefónica in Madrid. Besides announcing all this exiting technology, we will enjoy live music concerts. Finally, there will be a great party, thanks to all security partners in Telefónica.

Registration is limited, so a pre-registering form is available. Once filled up, a confirmation email will be sent (if it is still possible to assist).

12 de diciembre: Innovation Day de Eleven Paths

jueves, 28 de noviembre de 2013

El 12 de diciembre de 2013, en Madrid, Eleven Paths celebrará su puesta de largo en un evento al que se ha llamado Innovation Day. En él se presentarán los viejos y nuevos servicios de la compañía, además de otras sorpresas. Es necesario registrarse para asistir, desde esta web.

Eleven Paths comenzó su andadura dentro de Telefónica Digital hace seis meses. Después de mucho trabajo, ha llegado el momento de mostrar parte del esfuerzo realizado durante este tiempo. Además de Eleven Paths, Telefónica de España y el Vertical de Seguridad de Telefónica Digital presentarán otros productos y servicios en un acto que se ha llamado Innovation Day.


Se hablará de los servicios de CiberSeguridad de Teléfónica, de Faast, de toda la familia de MetaShield Protector, de Saqqara, de servicios anti APT y, por fin, de un proyecto hasta ahora secreto en Eleven Paths que internamente hemos llamado "Path 2". A partir del 12 de diciembre, ofreceremos más información sobre esta tecnología, que, para Eleven Paths, ha supuesto un verdadero reto desarrollar. Pero ya es una realidad. Se han conseguido patentes a nivel mundial, y en un tiempo tan corto ya se integre en muchos sitios.


Están invitados a participar en la jornada clientes, responsables y profesionales de seguridad, responsables de sistemas... Se desarrollará el jueves 12 de diciembre a las 16 horas, en el Edificio central, Auditorio principal del campus Distrito Telefónica en Madrid. Además de anunciar los servicios y tecnologías, contará con la partición de música en directo. Para finalizar, se celebrará una fiesta gracias a la colaboración de todos los partners de seguridad con los que contamos en Telefónica.

El registro es limitado, por lo que se ha habilitado una web de pre-registro. Una vez solicitado, se recibirá la confirmación de la plaza si aún es posible.

La publicidad en las apps de Google Play. Más que una "molestia"

"Google is now just an ad company". No es que sean noticias nuevas, pero ya lo afirman o cuestionan algunos abiertamente desde hace tiempo. La novedad, quizás, no es que su negocio principal sea la publicidad (no hay nada malo en eso) sino en cuestionar qué está dispuesta a sacrificar por ella. En concreto, la publicidad en Google Play puede que refleje mejor esta situación. Veamos por qué.

El modelo de Google Play y los programadores

El modelo de crecimiento de Google Play está claro: relajar todo lo posible las restricciones con el fin de que desarrollen para esta plataforma cuantos más programadores mejor. Desde la baja cuota de inscripción, pasando por la "simbólica" política de firma de aplicaciones y la facilidad para publicar de un día para otro sin acreditar nada, todos son métodos que fomentan su popularidad... pero también que a Google Play llegue más adware y malware (en comparación con los casi impolutos markets de Apple y Microsoft gracias a sus procesos de publicación).

El modelo de los programadores, por otro lado, también está claro: aplicaciones gratuitas en su mayoría que se intentan financiar con publicidad. Bajo el calor de la demanda de estos usuarios, y la permisividad de Google Play, se han potenciado numerosas (unas 50 oficiales) "redes de publicidad" especializadas en móviles. Exactamente igual que la publicidad en la web externalizada, se encargan de facilitar al programador que se suscribe (le abstraen a través de SDKs) la labor de posicionar la publicidad, gestionarla, optimizarla y por supuesto... cobrarla. Esto implica dar vía libre a que la publicidad tenga cierto poder sobre la app y, por lo visto, sobre el teléfono. Algunos nombres son: AppNext, Appenda, LeadBolt, MOcean, AppGrade, Adbuddiz....

Hasta aquí, nada que no se pueda trasladar al mundo de la web y la publicidad online. Pero sabemos que se han dado casos, en los que los anuncios externalizados en webs ha permitido que ciertas páginas relevantes sirvan malware, o incluso que se introduzcan en sus redes... ¿Se han de cometer los mismos errores en Android?

Dos redes de anuncios con vulnerabilidades y otra "insoportable"

Al margen de la molestia que la publicidad agresiva puede suponer de por sí, FireEye ya ha descubierto que dos de estas redes de anuncios sufren serias vulnerabilidades. Ya sabemos que estas librerías suponen un riesgo para la intimidad del usuario (recolectan todo tipo de información), pero algo muy diferente es que permitan controlar un teléfono... La primera la descubrieron en octubre de 2013. La llamaron Vulnaggressive (Vulnerable & Aggressive), y no quisieron decir el nombre concreto, porque ponía en peligro a los millones de usuarios que tuvieran cualquier aplicación que se sustentase con esta librería de publicidad. Un 1.8% de las apps en Google Play con más de un millón de descargas, la usaban. La propia librería permitía (de forma más o menos "oficial"):
  •  Descargar y ejecutar cualquier binario en el teléfono.
  •  Aceptar comandos de un servidor y enviar información (todo en texto claro por HTTP)
  •  Usar WebViews de Android (ventanas en la aplicación que en realidad son páginas web interpretadas... donde se muestran los anuncios) con "enlaces" de JavaScript a Java de forma insegura (gracias a addJavascriptInterface). Muy resumido, esto quiere decir que, con solo visitar una página, se podría llegar a lanzar instrucciones JavaScript (limitadas al navegador, en teoría) que a su vez llaman a Java (ejecución de código en el terminal).
En resumen, suponía una jugosa botnet de teléfonos para cualquier atacante, casi lista para ser usada. Google eliminó "algunas" de esas aplicaciones que usaban esa "desconocida" Vulnaggressive...

Otro ejemplo es más reciente. InMobi (a esta sí la nombraron). También por FireEye. Unas 2000 aplicaciones en Google Play usan esta red de anuncios. Para poner en situación, es necesario explicar que @JavascriptInterface es una notación que se introdujo en Android 4.1 para mitigar precisamente ese problema de enlaces entre JavaScript y Java. El programador debe usar esta herramienta para limitar los métodos de Java que son accesibles desde JavaScript. InMobi lo usa justo al revés, para poder hacer "de todo" a través de WebViews y JavaScript... desde enviar SMS hasta realizar llamadas sin consentimiento, pasando por la posibilidad de tomar fotografías. Si un atacante simplemente esnifara el tráfico mientras el usuario usa una app y tuviera la posibilidad de modificarlo, podría llegar a controlar el teléfono a través de los anuncios servidos.

Por último, mención aparte merece AirPush. Una red de anuncios tan agresiva y un método de publicidad tan insoportable, que la propia Google prohibió su uso en 2012. En realidad estableció por políticas (no técnicamente) la prohibición de utilizar las notificaciones AirPush para enviar spam al usuario... y AirPush era una de las redes que más abusaba de esta técnica. Aunque por supuesto, todavía se pueden encontrar aplicaciones con AirPush en el market... Google Play les dio de plazo hasta el 30 de septiembre de 2013 para ser retiradas... y ahora las va eliminando "a su ritmo".
Ejemplo de publicidad más que agresiva
en Android, suministrada por appNext

¿Qué es permisible en publicidad?

Una vez más, se tropiezan en las mismas piedras. A finales de los 90, internet se convirtió en un campo de batalla de la publicidad y el adware, que se aprovechaban del dominio de Internet Explorer (y su ineficacia) para realizar todo tipo de trucos: pop-ups, anuncios que no podían cerrarse, JavaScript, páginas directamente a favoritos, vídeos, animaciones... Pasaron varios años hasta que los navegadores mejoraron y "se protegieron" contra la publicidad insoportable. Pero no sin "negociar". A la publicidad no se puede renunciar... como mucho, se le ponen ciertos límites. El perfecto ejemplo es cómo Google eliminó de Google Play el eficaz AdBlock Plus, y actúa contra ciertas redes de anuncios "que se pasan" como AirPush. Pero no le pidas más. Su negocio es llevarse bien con todas las partes y el secreto está en mantener el equilibrio, sin molestar demasiado a los usuarios... Esto choca frontalmente con la publicidad tan bien gestionada en su producto estrella, el buscador (no agresiva, no estridente, respetuosa, diferenciada...) que le granjeó la fidelidad de muchos usuarios precisamente a principios de la década pasada. ¿Está dispuesta a perder esa percepción por parte de los usuarios a cambio de un menor control en los programas subidos a su market oficial, a cambio de hacer la vista gorda ante una publicidad "un poco más agresiva"? No lo sabemos, pero sí que según la propia Google, el "problema" del malware en Android, no es para tanto. Una "exageración de las casas antivirus". ¿Se incluye el "adware" en esa afirmación?

En definitiva, que quizás habrá que vivir una "guerra" en el campo de batalla de Android, para que probablemente, se sigan finalmente los pasos que convirtieron la publicidad en la red algo regulado y en cierta manera, sostenible, con acuerdos como  la coalición AntiSpyware, que "oficializó" en el mundo del escritorio lo que podía o no caracterizarse como publicidad y cruzaba la línea hacia el adware. En la práctica los atacantes siguen abusando en la web, pero al menos existe una especie de regularización y, desde luego, la situación es mejor que hace una década.

Sergio de los Santos
ssantos@11paths.com

MD5: vulnerabilidades y evoluciones (y II)

miércoles, 27 de noviembre de 2013

Ahora que Microsoft y Google (e incluso Twitter) se han embarcado en una especie de carrera criptográfica para potenciar los algoritmos de cifrado, firma, hash y clave pública, es un buen momento para repasar y entender por qué algunos de estos algoritmos dejan de ser útiles y qué alternativas se manejan. El ejemplo más claro de algoritmo obsoleto (pero aún usado) es MD5.

Vulnerabilidades de MD5

Se pueden dar dos tipos principales de vulnerabilidades en los algoritmos de resumen y su seguridad se mide en base a los resultados de la evaluación de estas vulnerabilidades.
  • Resistencia a la preimagen o resistencia a ataques de fuerza bruta. Numéricamente, estos ataques suponen aplicaciones de la función hash 2n veces, siendo n la longitud del resumen.
  • Resistencia a colisiones o a la localización de dos mensajes de entrada que den lugar a un mismo resumen para un mismo algoritmo de cifrado hash (segunda preimagen). Teóricamente se cumple que para confiar en que podemos encontrar dos mensajes que colisionen, no hay que realizar 2n operaciones, sino sólo 2n/2
Esta segunda vulnerabilidad da lugar a cuatro tipos de ataques, con un índice de peligrosidad incremental. El Tipo1 se aplica cuando el atacante es capaz de encontrar colisiones pero no de forma sistemática. El Tipo4 cuando el atacante es capaz de crear un mensaje con sentido cuyo hash colisiona con el hash del mensaje verdadero.
La vulnerabilidad frente a la preimagen no fue la mayor debilidad de MD4, pero en todo caso la longitud de resumen de ambos (128 bits) resulta baja en la actualidad. Es en el aspecto de colisiones y segunda preimagen donde MD4 tuvo mayores problemas, y donde se ha demostrado que MD5 también los presenta.

El origen de la determinación del algoritmo de cifrado MD5 como vulnerable o "oficialmente roto" data de 2004, cuando Xiaoyun Wang y su equipo anunciaron el descubrimiento de colisiones de hash para MD5. En función de este artículo, quedó demostrado que era posible encontrar una colisión a partir de dos mensajes de 1024 bits con un determinado valor inicial. De ahí en adelante, han surgido numerosas publicaciones en esta línea. Destacar entre ellas la realizada en 2007 por Arjen Lenstra de Bell Laboratories. Basándose en el trabajo de Wang desarrolló un método para construir colisiones en 224.8 procesados (unos 10 segundos). El objetivo de todas estas técnicas es el de conseguir multicolisiones, algunas de las cuales surgen a partir de la demostración de la posibilidad de generar nuevos pares de colisiones a partir de una dada. Este hecho quedó probado tras la comprobación matemática de la siguiente enunciación:

Esto se debe al uso de la construcción de Merkle-Damgård, que permite trabajar con números ilimitados de bloques de entrada, pero también la aparición de esta vulnerabilidad.

Teniendo en cuenta que el algoritmo de cifrado MD5 presenta debilidades en la tarea de resistencia a la colisión y que la resistencia a la segunda preimagen queda más que comprometida tras los resultados de los estudios citados, se puede efectivamente concluir que el algoritmo MD5 está "roto".

MD5 roto en la vida real

Desde 1996 se empezaron a conocer "indicios" sobre la debilidad del algoritmo. En 2004 se consiguió crear dos certificados  X.509 distintos con igual hash MD5. En verano de 2005, un australiano consiguió anular una multa de tráfico. El abogado que representaba al amonestado recurrió una denuncia,  argumentando que no se había probado que la imagen obtenida por  la cámara asociada al radar no hubiese sido modificada de ninguna forma. Las autoridades australianas de tráfico respondieron que se utilizaba el algoritmo MD5 para obtener el hash de las imágenes obtenidas. No encontraron a ningún perito que demostrase ante el tribunal la validez de este algoritmo, y por tanto se libró de la multa.

A finales de 2008, Alexander Sotirov, Marc Stevens y otros investigadores consiguieron (usado la potencia de 200 consolas PlayStation3) hacer que cualquier certificado SSL pareciese válido usando certificados que basaban su confianza en MD5. Pero en cierta forma, todo fueron ataques de laboratorio hasta que llegó TheFlame, y usó varias debilidades (entre ellas de MD5) para conseguir un certificado de Microsoft válido. Los problemas hasta entonces más o menos "teóricos" estaban siendo usados por atacantes.

Además de las colisiones, MD5 tiene otros problemas. Para una firma o hash debe ser matemáticamente muy complicado realizar el proceso contrario: calcular los datos que produjeron el hash. Por esta razón, muchos programas almacenan el MD5 de las contraseñas de usuarios en las bases de datos. Hace algunos años se popularizaron las tablas rainbow con información preprocesada sobre hashes MD5. Esto, en teoría, permite a alguien que tenga acceso a esos resúmenes, realizar el proceso inverso en tiempo razonable. Se ha popularizado como método eficaz de "crackeo" para contraseñas de este tipo, con lo que el almacenamiento de credenciales en este formato también se considera ya inseguro.

Conclusión: Evolución hacia SHA-1, SHA-3 y Whirlpool

La resistencia del algoritmo SHA-1 se ha puesto en duda últimamente, por lo que resulta una solución temporal. Aunque su diseño resulta más robusto que el de MD5 con un mayor tamaño de hash code (160 bits), presenta ciertas similaridades con MD4 y MD5 que lo hacen vulnerable al igual que los son éstos. Microsoft ya ha declarado que no lo quiere en sus certificados.

A pesar de que las demostraciones presentadas consiguen superar la seguridad del algoritmo en 263 operaciones, relativamente más rápido que un ataque de fuerza bruta (que requeriría 280 operaciones), todavía son muchas operaciones. Aunque en el futuro es cada vez más probable que romper esta función sea trivial, al aumentar las capacidades de los sistemas de cálculo y, previsiblemente, al centrarse los ataques y estudios en SHA-1 ahora que MD5 ya está "roto".

Actualmente, ya se contemplan y utilizan funciones de SHA de mayor tamaño (por ejemplo, SHA‑512, de 512 bits de longitud es muy usada en certificados). Sin embargo, se busca ya una nueva función hash estandarizada que permita sustituir a SHA-1. Entre las candidatas, SHA-3 (originalmente Keccak, elegido a finales de 2012) y Whirlpool (adoptado como parte del estándar ISO/IEC 10118-3).

 * MD5: vulnerabilidades y evoluciones (I)


Julia Llanos

MD5: vulnerabilidades y evoluciones (I)

lunes, 25 de noviembre de 2013

Ahora que Microsoft y Google (e incluso Twitter) se han embarcado en una especie de carrera criptográfica para potenciar los algoritmos de cifrado, firma, hash y clave pública, es un buen momento para repasar y entender por qué algunos de estos algoritmos dejan de ser útiles y qué alternativas se manejan. El ejemplo más claro de algoritmo obsoleto (pero aún usado) es MD5.

Hash codes

Los hashes (hash codes) son los resultados de mapear unos determinados valores de entrada a un código de tamaño fijo. Las funciones hash se encargan de llevar a cabo este proceso. Su uso en criptografía dio lugar a la aparición del grupo de algoritmos criptográficos denominados algoritmos de resumen o hash, donde los hash codes resultantes se definirán como resúmenes. Las tres propiedades más importantes que debe presentar una función hash o en su defecto, un algoritmo de resumen, son:
  • Resistencia a la colisión. Las colisiones son el problema inherente a establecer una relación entre un conjunto infinito de entrada (cualquier flujo de bytes) y un conjunto finito (el número de combinaciones que ofrezca la longitud del hash). Esta resistencia se definirá como la dificultad para encontrar dos entradas que den como salida un mismo hash code. 
  • Resistencia a la preimagen o dificultad presentada para deducir la entrada a partir de la función hash y el hash code. Este problema es el que tienen por ejemplo, las bases de datos que almacenan el hash MD5 de las contraseñas. Actualmente es relativamente sencillo deducir el texto claro a partir del hash, gracias en parte a los precáculos realizados con las rainbow tables.
  • Resistencia a la segunda preimagen o dificultad para que, dado una entrada fija, sea posible encontrar otra que tenga un mismo hash code resultante.
La gran mayoría de funciones hash que han sido utilizadas en la práctica para la criptografía, pertenecían a la familia MD (Message-Digest Algorithm). Inspiradas en ellas, o en sus debilidades, han surgido algunas de las funciones hash modernas, entre las que destacan la familia SHA (Secure Hash Algorithm) y RIPEMD (RACE Integrity Primitives Evaluation Message Digest). Existen algunas otras funciones, como Whirlpool, que comienzan a surgir en la actualidad, aunque su tasa de uso aún es muy baja. Daremos un repaso a sus principales características.

MD family

Esta colección de funciones fue originalmente desarrollada por Ron Rivest (MIT) para RSA Security. La primera propuesta fue MD2, un novedoso diseño orientado a byte. Esta fue rápidamente seguida por MD4 y MD5, dos funciones hash más modernas con un diseño de 32 bits. A pesar de tratarse de algoritmos que irrevocablemente están condenados a la aparición de colisiones, MD4 inspiró la mayoría de los diseños de funciones hash posteriores como los ya citados SHA y RIPEMD.

SHA family

La familia SHA es un sistema de funciones hash criptográficas relacionadas con la Agencia de Seguridad Nacional de los Estados Unidos y publicadas por el National Institute of Standards and Technology (NIST). Presenta una metodología de operación muy similar a la de MD5, aunque con la variación de ofrecer un resumen de 160 bits, lo que lo hace más robusto. El primero en salir fue SHA (posteriormente renombrado SHA-0 para evitar confusiones). Dos años más tarde el primer sucesor de SHA fue publicado con el nombre de SHA-1. Hoy en día existen cuatro variantes más publicadas bajo el nombre de SHA-2, cuyas diferencias se basan en un diseño algo modificado y rangos de salida incrementados: SHA-224, SHA-256, SHA-384, y SHA-512. En la actualidad empieza a dibujarse el SHA-3 elegido como tal en octubre de 2013.

RIPEMD family

Fueron desarrollados por el grupo de investigación COSIC en Bélgica. El primer algoritmo de RIPEMD nació basado en los principios de diseño de MD4. Debido a los fallos de seguridad detectados, apareció la versión RIPEMD‑160, con 160 bits de resumen, similar en seguridad a SHA-1. Con RIPEMD‑160 también surgieron RIPEMD‑256 y RIPEMD‑320, entre otros. Si bien sus niveles de seguridad son igual de altos, el incremento en el número de bits del resumen reduce las posibilidades de colisión aleatoria.

Un repaso a MD5 (Message Digest Algorithm 5)

El algoritmo fue propuesto como reemplazo a MD4 después de que Hans Dobbertin presentase formalmente sus vulnerabilidades en 1994. También fue de los primeros en alertar, en 1996, de que MD5 debía ser reemplazado. El diseño de MD5 se llevó a cabo orientado a máquinas de 32 bits. Sin embargo, su funcionamiento, más seguro que su predecesor, conllevaba un proceso más lento. Atendiendo al artículo publicado por Rivest, el funcionamiento de MD5 se resume en 4 pasos, a saber:



  • Adición o padding de bits hasta alcanzar los tamaños deseados. Más concretamente, se añade un 1 y una cadena de ceros hasta ser congruente con 448 módulo 512.
  • Sobre el mensaje "padeado" se añade una variable de 64 bits (448+64=512) que completará el último bloque y que contendrá la información de la longitud del mensaje pre-padding.
  • Inicializar el búfer MD donde se llevará a cabo la computación del hash del mensaje. Cada búfer será un registro de 32 bits inicializados como sigue:
  • Procesado del mensaje en bloques de 16 palabras. Tomando de entrada estas palabras de 32 bits, se definen cuatro funciones auxiliares: 

Mediante un proceso iterativo que utiliza adicionalmente una tabla de 64 valores construida a partir de la función seno detallado en el artículo de Rivest, se producen cuatro palabras de salida de 32 bits que compondrán el resumen (4x32=128 bits). El efecto final sobre el mensaje será un procesado de una longitud arbitraria del mensaje en bloques de 512 bits generando un resumen de 128 bits.


Veremos en la siguiente entrega sus debilidades y qué alternativas se han propuesto.

MD5: vulnerabilidades y evoluciones (y II)

Julia Llanos

The "cryptographic race" between Microsoft and Google

jueves, 21 de noviembre de 2013

Google and Microsoft are taking bold steps forward to improve the security of cryptography in general and TLS / SSL in particular, raising standards in protocols and certificates. In a scenario as reactive as the security world, these movements are surprising. Of course, these are not altruistic gestures (they improve their image in the eyes of potential customers, among other things). But in practice, are these movements useful?

Google: what have they done

Google announced months ago that it was going to improve the security in certificates using 2048 bits RSA keys as minimum. They have finished before they thought. They want to remove 2014 bit certificates from the industry before 2014 and create all of them with 2048 bit key length from now on. Something quite optimistic, keeping in mind that they are still being used a lot. Beginning 2014, Chrome will warn users when certificates don't match their requisites. Rising the key bits up to 2048 in certificates involves that trying to break the cipher by brute forcing it becomes less practical with current technology.

Besides, related with this effort towards encrypted communications, since October 2011, Google encrypts traffic for logged users. Last September, it started to make it in every single search. Google is trying as well to establish "certificate pinning" and HSTS to stop intermediate certificates when browsing the web. If that wasn't enough, their certificate transparency project goes on.

Seems like Google is particularly worried about its users security and, specifically (although it may sound funny for many of us) for their privacy. In fact, they asset that"the deprecation of 1024-bit RSA is an industry-wide effort that we’re happy to support, particularly light of concerns about overbroad government surveillance and other forms of unwanted intrusion.".

Microsoft: what have they done

In the latest Microsoft update, important measures to improve cryptography in Windows were announced. In the first place, it will no longer support RC4, very weak right now (it was created in 1987) and responsible for quite a lot of attacks. Microsoft is introducing some tools to disable it in all their systems and wants to eradicate it soon from every single program. In fact, in Windows 8.1 with Internet Explorer 11, the default TLS version is raised to TLS 1.2 (that is able to use AES-GMC instead of RC4). Besides, this protocol also uses SHA2 usually.

Another change in certificates is that it will no longer allow hashing with SHA1 for certificates used in SSL or code signing. SHA1 is an algorithm that produces a 160 bits output, and is used when generating certificates with RSA protocol to hash the certificate. This hash will be signed by the Certificate Authority, showing its trust this way. It has been a while since NIST encouraged to stop using SHA1, but fewer cared about that claim. It looks like a quite proactive for Microsoft, that got us used to an exasperate reactive behavior.

Why all this? Is this useful?

Microsoft and Google are determined to improve cryptography in general and TLS/SSL in particular. With these measures adopted between both of them, the security of the way traffic is encrypted, is substantially raised.

2048 bits certificate using SHA2
(SHA256).
Certificates that identify public keys calculated with 512 bits RSA keys, were broken in practice in 2011. In 2010,  a 768 bits number (212 digit) was factored with a general purpose algorithm and in a distributed way. The higher known. So, in practice, using a 1024 bits number is "safe", although it could be discussed if it represents a threat in near future. Google is playing safe.

But there are some other problems to focus on. Using stronger certificates in SSL, is not the main obstacle for users. In fact, introducing new warnings (Chrome will warn about 1024 bit certificates) may just make the user even more confused: "What does using 1024 bits mean? Is it safe or not? is this the right place? what decision should I take?". Too many warnings just relaxes security ("which is the right warning when I am warned about safe and unsafe sites?"). The problem with SSL is that it's socially broken, and is not understood... it's not about the technical standpoint but from the users. Users will be happy that their browser of choice uses stronger cryptography (so the NSA can't spy on them...), but it will be useless if, confused, accepts an invalid certificate when browsing, not being aware that it's introducing a man-in-the-middle.

If we adopt the theory that NSA is able to break into communications because it already has adequate technology as to bruteforce 1024 bits certificates, this is very useful. There would be a problem if it wasn't necessary to break or brute force anything at all, because the companies were already cooperating to give NSA plain text traffic... We could dismiss that NSA had already their own advanced systems ready to break 2048 bit keys, and that is why they "allow" its standardization... couldn't we? We just have to look back a few years to remember some conspiracy tales like these in the world of SSL.
Selfsigned certificate created in Windows 8 and using
MD5 and 1024 bits.

The case of Microsoft is funny, too. Obviously, this movement in certificates is motivated because of  TheFlame. Using MD5 with RSA played a bad trick, allowing the attackers to sign code in its name. It can't happen again. This puts Microsoft ahead of deprecating SHA1 for certificates, because the industry will follow. But if RC4 is really broken, SHA1 health is not that bad. We have just started getting rid of MD5 in some certificates, when Microsoft claims the death of SHA1. This leaves as just with the possibility of using SHA2 (sha256RSA or sha256withRSAEncryption normally in certificates, although SHA2 allows the use from 224 to 512 bits output). It's the right moment, because XP is dying, and SHA2 wasn't even natively supported (just from service pack 3). There is still a lot of work to be done, because SHA1 is very extended (Windows 7 signs most of its binaries with SHA1, Windows 8, with SHA2), that is why deadline is 2016 in signing certificates and 2017 for SSL certificates. The way Certification Authorities will react... is still unknown.

On the other hand, regarding the user of mandatory TLS 1.2 (related in a way, because it's the protocol supporting SHA2), we have to be aware of the recent attacks against SSL to know what it's really trying to solve. Very briefly:
  • BEAST, in 2011. The problem was based in CBC and RC4. It was really solved with  TLS 1.1 and 1.2. But both sides (server and browser) have to be able to support these versions.
  • CRIME: This attack allows to retrieve cookies if TLS compression is used. Disabling TLS compression solves the problem.
  • BREACH: Allows to retrieve cookies, but is based on HTTP compression, not TLS, so it may not be "disabled" from the browser. One is vulnerable whatever TLS version is being used.
  • Lucky 13: Solved in software mainly and in TLS 1.2.
  • TIME: A CRIME evolution. It doesn't require an attacker to be in the middle, just JavaScript. It's a problem in browsers, not TLS itself.
A very common certificate yet, using
SHA1withRSAEncryption and 1024 keys
We are not aware of these attacks being used in the wild by attackers. Imposing 1.2 without RC4 is a necessary movement, but risky yet. Internet Explorer (until 10) supports TLS 1.2 but  is disabled by default (only Safari enables it by default, and the others just started to implement it). Version 11 will enable it by default. Servers have to support TLS 1.2 too, so we don't know how they will react.

To summarize, it looks like these measures will bring technical security (at least in the long term). Even if there are self interests to satisfy  (avoiding problems they already had) and an image to improve (leading to the "cryptographic race"), any enhancement is welcome and this "war" to lead the cryptography, (that fundamentally means being more proactive that your competitors), will raise up the bar.

Sergio de los Santos
ssantos@11paths.com

La "carrera criptográfica" entre Google y Microsoft

miércoles, 20 de noviembre de 2013

Google y Microsoft están dando llamativos pasos adelante para mejorar la seguridad de la criptografía en general y de TLS/SSL en particular, elevando los estándares en los certificados y protocolos. En un mundo tan reactivo como el de la seguridad, sorprenden estos movimientos. Desde luego, no son gestos gratuitos (mejoran su imagen de cara a potenciales clientes, entre otras cosas). Pero en la práctica, ¿son útiles?

Google: qué ha hecho

Google anunció hace meses que iba a elevar la seguridad de sus certificados utilizando claves RSA de 2048 bits como mínimo. Ha terminado de hacerlo antes de lo previsto. Quieren eliminar de la industria los certificados de 1024 bits para el año 2014 y crear todos de 2048 a partir de ahora. Algo bastante optimista, teniendo en cuenta que son muy usados aún. A principios del año que viene, Chrome advertirá a los usuarios de los certificados que no cumplan sus requisitos al visitar una web. Elevar a 2048 los bits de las claves de los certificados implica que intentar romper el cifrado por fuerza bruta se vuelve poco práctico con la tecnología actual.

Además, relacionado con este esfuerzo hacia las comunicaciones cifradas, desde octubre de 2011 Google cifra el tráfico para usuarios presentados en sus dominios. Este septiembre de 2013, comenzó a hacerlo para todas las búsquedas. También ha intentado instaurar poco a poco el "certificate pinning" y el HSTS para intentar que no se interpongan certificados intermedios en la navegación. Por si fuera poco, sigue adelante con su proyecto de certificate transparency.

Parece que Google está muy preocupada por la seguridad de sus usuarios y en concreto (aunque a muchos les pueda resultar irónico) por su privacidad. De hecho, afirman que "eliminar las claves RSA de 1024 bits en los certificados, significa un esfuerzo de la industria que estamos contentos de apoyar, particularmente a la luz de las preocupaciones surgidas por la vigilancia gubernamental y otras formas de intrusión no deseada".

Microsoft: qué ha hecho

En la última actualización de Microsoft, se anunciaron medidas importantes para mejorar la criptografía general del sistema operativo. Para empezar no soportará el cifrado RC4, sobradamente superado (se creó en 1987) y culpable de muchos ataques. Ofrece herramientas para deshabilitarlo en todos sus sistemas y pretende erradicarlo en breve de toda aplicación. De hecho, en la versión 8.1 de su sistema operativo y con Internet Explorer 11, se cambia por defecto la versión de cifrado a TLS 1.2 (que puede usar AES-GCM  en vez de RC4). Este protocolo también usa SHA2 normalmente.

Otro cambio en los certificados, es que no permitirá el algoritmo de hash SHA1 ni en certificados para firmar código ni en certificados SSL. SHA1 es un algoritmo que produce un hash de 160 bits, y se utiliza durante la generación de certificados con el protocolo RSA para "hashear" el propio certificado. El hash será lo que firme la autoridad certificadora, demostrando así su confianza.  Hace ya tiempo que NIST desaconsejó el uso de SHA1, pero nadie le hizo mucho caso. Resulta un movimiento muy anticipativo para Microsoft, acostumbrados a una reactividad exasperante. 

¿Por qué todo esto? ¿Es útil?

Microsoft y Google están decididos a mejorar la criptografía en general, y el TLS/SSL en particular. Con las medidas adoptadas entre los dos, se eleva sustancialmente la seguridad de esta forma fundamental de cifrar el tráfico en la red.

Certificado de 2048 bits, usando SHA2
(SHA256, concretamente).
Los certificados que acreditan claves públicas calculadas según RSA con valores de 512 bits, fueron rotos en la práctica en 2011. En 2010, se factorizó de forma distribuida y con un algoritmo de propósito general un número de 768 bits (212 dígitos), el más alto conocido. Así que en la práctica, el uso de un número representable en 1024 bits es "seguro", aunque se podría discutir si un futuro cercano supondrían un problema. Google se cura en salud.

Pero el foco del problema también es otro. El uso de certificados más robustos en SSL, no es el principal obstáculo para el usuario. De hecho, la introducción de nuevas advertencias (Chrome alertará sobre certificados de 1024 bits) solo puede confundirlo más: "¿Qué significa que usa 1024 bits? ¿Es seguro o no? ¿Esto en el sitio correcto? ¿Qué decisión tomo?". El exceso de alertas solo relaja la seguridad ("¿Qué alerta es la buena cuando se me alerta tanto de sitios seguros como de inseguros?"). El problema del SSL es que está socialmente roto, que no se entiende... y no tanto técnico desde el punto de vista del usuario. Al usuario le alegrará que su navegador utilice criptografía más robusta (porque supuestamente la NSA no podrá espiarle...), pero no servirá de nada si, confundido, acepta un certificado no válido durante la navegación, sin ser consciente de que está introduciendo un hombre en el medio.

Si adoptamos la teoría de que la NSA puede romper las comunicaciones porque dispone ya de la tecnología necesaria para aplicar la fuerza bruta contra certificados de 1024 bits, esto sí es útil. El problema sería que no fuese necesario romper ni aplicar fuerza bruta sobre nada, sino que las compañías ya colaborasen para entregarle a la NSA el tráfico descifrado... También podríamos descartar que la NSA cuente ya con sistemas propios para romper cifrado de claves de 2048 bits y por eso ahora se permita su estandarización... ¿o no? No hay que remontarse mucho en la historia (apenas 10 años) para oír historias "conspiranoicas" como estas en el mundo del SSL.
Certificado autofirmado creado en Windows 8 que usa
MD5 y 1024 bits.

En el caso de Microsoft también es curioso. Obviamente, este movimiento en los certificados está motivado por TheFlame. Utilizar MD5 con RSA les jugó una mala pasada, permitiendo que los atacantes firmaran código en su nombre. Y no puede volver a ocurrir. Esto pone a Microsoft al frente de la retirada del uso de SHA1 para certificados, puesto que la industria le seguirá. Pero en realidad, si bien RC4 sí está roto, SHA1 no tiene tan mala salud. Apenas nos hemos desecho de MD5 en ciertos certificados cuando ya Microsoft adelanta la muerte de SHA1. Esto nos deja solo con la posibilidad de usar SHA2 (sha256RSA o sha256withRSAEncryption normalmente en los certificados, aunque SHA2 permite el uso de salidas de 224 hasta 512 bits).  Curiosamente, es el momento oportuno porque XP se retira, y ni siquiera soportaba nativamente SHA2 (lo hizo a partir del service pack 3). Todavía tiene trabajo que hacer, porque el SHA1 está muy arraigado (Windows 7 firma la mayoría de sus binarios con SHA1, Windows 8, con SHA2), por eso se ha puesto como fecha de retirada definitiva 2016 en certificados para firmar y 2017 en certificados para su uso en SSL. Queda por saber cómo reaccionarán las autoridades certificadoras.

Por otro lado, con respecto al uso de TLS 1.2 obligatorio (relacionado, porque es el protocolo que soporta SHA2), tenemos que conocer qué ataques se han publicado recientemente contra SSL para saber qué soluciona realmente. Muy sucintamente:
  • BEAST, en 2011. El error se fundamentaba en CBC y RC4. Efectivamente se soluciona con TLS 1.1 y 1.2. Pero debemos tener en cuenta que ambas partes (servidor y navegador) deben soportarlo.
  • CRIME: Es un ataque que permite recuperar cookies si se usa compresión en TLS. Deshabilitando la compresión TLS, es posible eludirlo.
  • BREACH: Permite también recuperar cookies. Pero se basa en la compresión HTTP, no TLS, por tanto no se puede "deshabilitar" desde el navegador. Se es vulnerable se use la versión TLS que se use.
  • Lucky 13: Solucionado en software principalmente. También en TLS 1.2.
  • TIME: Una evolución de CRIME. No requiere que un atacante haga de man-in-the-middle, sino que solo necesita JavaScript. Un problema más en los navegadores que en el TLS.
Certificado todavía muy común, que usa
SHA1withRSAEncryption y claves de 1024
De ninguno de estos ataques se tiene constancia de que estén siendo usados por atacantes. La imposición de 1.2 sin RC4 es un movimiento necesario, pero aún arriesgado. Internet Explorer (hasta el 10) soporta TLS 1.2 aunque deshablitado (solo Safari lo activa por defecto y los demás, lo implementan desde muy recientemente). La versión 11 lo hará por defecto.Queda por saber cómo reaccionarán los servidores, que también deben dar soporte a TLS 1.2.

En resumen, parece que estas medidas aportan seguridad técnica (al menos a largo plazo). Aunque lógicamente detrás se encuentren tanto intereses propios de la empresa (evitar problemas que ya han sufrido) como de imagen (liderar la "carrera de la criptografía"), cualquier mejora es bienvenida y esta "guerra" para liderar la criptografía, que fundamentalmente significa ser el más proactivo "frente a la competencia", elevará sustancialmente el listón.

Sergio de los Santos
ssantos@11paths.com

Fokirtor, a sophisticated? malware for Linux

lunes, 18 de noviembre de 2013

Symantec has just released some details about how a new malware for Linux works. It is relevant for its relative sophistication. It was discovered in June as a fundamental part of a targeted attack to a hosting provider, but it's now when they disclose technical details about how it works. Although sophisticated for Linux environment, technically it's not so relevant if we compare it with malware for Windows.


In May 2013, an important hosting provided was attacked. They knew exactly what they were doing and what errors to avoid. They wanted financial data and user passwords (oddly enough they were stored ciphered, but they cannot rule out the master key was not compromised...). This happens everyday, but the difference is the method used: Fokirtor, that is the way Symantec has baptised the trojan used as the attacking tool.


It was a quite important company, and they needed to evade the security systems, so they tried to be unnoticed injecting the trojan to some servers process as a SSH daemon. In this way, they disguised their presence physically (no new processes were needed) and in the traffic (that would be merged with the one generated by the SSH service itself). This is a "standard" method in malware for Windows, where regular trojans usually inject themselves inside the browser and cover their traffic under HTTP.



Of course, the malware needed connectivity with the outside world to receive commands. In the world of Windows, malware usually connects outbound periodically (to elude inbound firewall) towards a C&C via HTTP. In the case of Fokirtor, what it did was hooking functions and wait for commands injected in SSH process, preceded by " :!;. " characters (without quotes). This would indicate that the attacker wanted to make some action. This method isn't new. Usually, when some legitimate software is trojanized in Linux's world, a reacting way for a certain pattern is embedded in its code, and then is published so it's downloaded by the future victims. What isn't so usual is to make it "on the fly" injecting it in a process. Although the news doesn't make it clear, we understand that the attacker had to get root privileges in the compromised machine.


The attacker just had to connect via SSH to the servers and send the magic sequence to take over the machine. Received commands were coded in base64 and ciphered with blowfish (designed by Bruce Schneier in 1993). This traffic wasn't logged.

Sophisticated?

In absolute terms, technically it's under the "standard" malware for Windows, and light years behind professional malware as a "ciberwapon" (TheFlame, Stuxnet, etc). Nevertheless, it does represent an interesting milestone that doesn't usually happen: finding specific malware for Linux servers that actively seeks to be unnoticed. 



To recall similar news, we have to go a year back. An user sent an email to the security list "Full Disclosure", stating he had found his Debian servers infected with what seemed to be a "rootkit working with nginx". It was about an administrator that had realized that the visitors of its web were being redirected to infected sites. Some kind of requests to that web server, returned an iframe injected in the page, that took to a point where Windows users tried to be infected. The administrator discovered some hidden processes and kernel modules responsible for the problem, and attached them to the email so it could be studied. After analyzed, we didn't have too many news about that rootkit.

Some questions without answers


Something that calls the eye but doesn't seem to have an explanation, is that Symantec detected this malware in June, with the same name, but hasn't offered technical details about the way it works since now. What happened during these five months? Probably they have been studying it in cooperation with the affected company. Unless they have come across with administrative or legal problems, technically it's not necessary to spend so much time to analyze a malware like this. And what happened before June? The attack was detected in May, but nothing is said about for how long the company was infected. It would be interesting to know the success of its hiding strategy during a real infection period. Being a hosting provider, have webpages of their costumers been compromised?



They say nothing about the trojan being able to replicate itself, or about detecting it in any other system. Possibly it's a targeted attack to a specific company, and the attackers didn't add this functionality to their tool. Just the strictly necessary to accomplish their task.

Although we instinctively relate Windows systems with malware world, when the attackers have a clear target, whatever operating system it is, there are no barriers. Or they are even weaker. Do not forget malware, technically speaking, is just a program "as any other" and only the will of programming it separates it from becoming a reality for a specific platform.

Sergio de los Santos
ssantos@11paths.com