Un simple correo puede causarnos problemas

En How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole cuentan como un simple correo y el intento de verificar si es original o no llevó a Zachary Harris a descubrir que Google utilizaba una clave criptográfica pequeña para la autentificación de los envíos.

De todas formas, casi nadie mira estas cosas…

Harris found three classes of key lengths used by vulnerable domains – 384 bits, 512 bits, and 768 bits.

“A 384-bit key I can factor on my laptop in 24 hours,” he says. “The 512-bit keys I can factor in about 72 hours using Amazon Web Services for $75. And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off.”

In addition to Google, he found that eBay, Yahoo, Twitter and Amazon were all using 512-bit keys. PayPal, LinkedIn, US Bank and HSBC were using 768-bit keys.

“It was good that PayPal and the banks were in the 768 category, but still, for domains that are as heavily phished as PayPal, 768 is really not okay,” Harris says. “They really should have been at 1024, and they have heeded the message and said they really should have had stronger keys all along.”

Fallos por todas partes

Algo que la gente no cree cuando se lo decimos es que todo el mundo comente fallos (algunos que pueden tener consecuencias verdaderamente graves), hasta los más grandes. Por eso es bueno recopilarlos, para tenerlos a mano cuando hace falta recordarlo. En este caso es Hacking Google for Fun and Profit donde nos cuentan algunos fallos para desvelar información sobre usuarios de gmail: por ejemplo, cómo era posible determinar si un usuario había enviado un mail a otro. Se utilizaban fallos de Cross Site Request Forgery (CSRF), esto es, cuando engañamos al navegador (y al sitio, claro) para que haga una petición en nombre del usuario de la que somos capaces de sacar partido.

Fuzzing en Google

Ya hemos hablado de Fuzzing varias veces por aquí. Por eso me gustó ver lo que hacen en Google al respecto. Lo cuentan brevemente en Fuzzing at scale.
No todo el mundo tiene esos recursos, claro.

Otras veces que hemos hablado del tema:
Fuzzing en teléfonos móviles
Fuzzing, ciclos vacíos y fallos
JBroFuzz para hacer fuzzing
Fuzzing y cubrimiento de código.

Seguridad en aplicaciones de colaboración según Google

En [PDF] Security Whitepaper. Google Apps Messaging and Collaboration Products. Introduction un documento de Google con directrices generales, con su declaración inicial:

The security of online services is a topic of increasing interest to enterprises as the number of third party hosted service offerings has expanded in recent years. The emergence of various “cloud computing” concepts and definitions has highlighted not only questions about data ownership and protection, but also how various vendors of cloud computing technologies build and implement their services. Security experts, end-users and enterprises alike are all considering the security implications of the cloud computing model.

Y los consejos ya vistos tantas veces, pero que no se si están calando:

… the Google Security Team maintains an engineering outreach and education program that currently includes:
– Security training for new engineers.
– The creation and maintenance of extensive documentation on secure design and coding practices.

Entrenamiento sobre diseño seguro para los nuevos ingenieros.

Los riesgos de utilizar el DNS de Google

A principios del mes pasado Google anunció Google DNS. Ellos lo proponen como un servicio más rápido y alternativo a los que nos proporcionan habitualmente las empresas que nos dan acceso a la red y además nombran unas cuantas alternativas más:

OpenDNS, a popular third-party DNS resolving service, offers more feature than Google Public DNS: web content filtering, stats, typo correction, shortcuts, but they’re available if you create an account and enter personal information like your name and address. When you type an invalid URL, OpenDNS redirects you to its own search engine to show suggestions and ads. Other free DNS resolution services: Comodo Secure DNS, OpenNIC, DNS Advantage.

Incluso una herramienta para comprobar la velocidad del nuestro: Domain Name Speed Benchmark.

De todas formas, no creo que a nadie le sorprenda que si apostamos por este sistema asumimos algunos riesgos. De eso hablan en Potential risks of using Google’s free DNS service?: más información para la empresa que, esperemos, utilicen adecuadamente y para mejorar sus servicios.

Controlar una botnet desde Google Groups

En Researchers Discover Botnet Commanded by Google Groups cuentan de un caso de una botnet controlada desde los Grupos de Google (listas de correo y algunas herramientas más). Tradicionalmente las botnets se controlaban mediante el IRC, aunque también habíamos leido de controles usando Twitter.

Palabras infecciosas

Considero el Una al día de Hispasec una lectura altamente recomendable. Es una sabia mezcla entre contenido técnico y no tanto que nos ayuda a estar al tanto del panorama de la actualidad en el mundillo de la seguridad y en nuestro idioma.

Me gustó la entrada de hace unas semanas Las palabras más infecciosas, donde se hacen eco de un estudio de McAfee:

McAfee ha buscado 2.658 palabras y frases en 413.368 URLs para comprobar qué términos pueden exponer al usuario a un mayor número de direcciones que alojen malware o fraudes. Concluye que todas las búsquedas que incluyan la palabra “free” (en este contexto, sería “gratis”) tienen un mayor riesgo (un 21%) mientras que las más seguras suelen ser las búsquedas relacionadas con términos médicos o de salud.

Para mucha gente internet es el buscador, así que parece bastante relevante el dato relacionado con las palabras ‘infecciosas’.