Tenemos un poco descuidada la parte de programación de esta bitácora. Espero poner algo de código en los próximos días pero eso cuesta más tiempo y no es algo que fluya libremente en estos tiempos.

El caso es que lei la primera parte de Coding for SSDs – Part 1: Introduction and Table of Contents y me resultó interesante. La guardé, en parte para ponerla aquí, y en parte para leer el resto de capítulos (aquí estoy reconociendo que sólo he leído el primero). La programación a bajo nivel no es lo mío, pero siempre es bueno tener una idea sobre estas cosas.

Los fallos que viven y sobreviven a múltiples actualizaciones y cambios terminarán teniendo su propia categoría por aquí. No hace mucho leíamos 11-year-old VM escape bug opens host machines to compromise y lo traemos aquí a título de inventario.

“The VENOM vulnerability has existed since 2004, when the virtual Floppy Disk Controller was first added to the QEMU codebase,” the researchers shared. If you’re wondering why it is still added to new virtual machines by default, it’s because it’s still occasionally used in a number of situations.

No hay mucho más que decir. Siguiendo la moda, el fallo tiene su propia página web: VENOM.

Si tenemos acceso al registro de actividad de un servidor cualquiera podemos ver todo tipo de intentos de obtención de información; muchas veces se trata de simples troyanos de máquinas infectadas por ahí que simplemente tratan de propargarse y otras de intentos dirigidos (seguramente más raros en servidores ‘caseros’).

En Who’s Scanning Your Network? (A: Everyone) hablaban del tema entrevistando a Zakir Durumeric y Michael D. Bailey que son investigadores de la Universidad de Michigan y que, entre otros proyectos, mantienen el Internet-Wide Scan Data Repository que es un archivo público de datos recolectados mediante escaneos de la parte pública de internet. La respuesta es, como decíamos arriba, que mucha gente nos está vigilando y tratando de obtener información.

Con estos datos son capaces de detectar servidores y servicios vulnerables (e incluso avisarles en situaciones de crisis como el reciente Heartbleed del que hablamos en su momento en [Heartbleed, código y memoria](http://fernand0.github.io/Heartbleed-Y-Certificados/].

Pero no sólo eso, sino también tener cierta capacidad predictiva, com dice Durumeric en:

So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing.

Por supuesto, no hay que olvidar que esto mismo lo pueden hacer los ‘malos’, vigilando nuestra ‘meta’-información pueden ser capaces de encontrar nuestros puntos débiles y los mejores momentos para atacar (como en las películas ‘clásicas’ de ladrones de bancos, que el atacante aprende los protocolos y momentos adecuados para actuar).

Dicen muchas más cosas interesantes pero nos recuerdan que la seguridad no sólo es algo tecnológico, sino que también tiene que ver con nuestros procesos y forma de actuar. Y que aunque esa información no sea pública tal vez sea posible deducirla.

Tengo la teoría de que una forma de acabar con el spam sería atacar los recursos de los ‘malos’: si todos respondiéramos no podrían desarrollar correctamente su labor. Tanto es así que a veces, cuando recibo algún correo de Phishing lo relleno con datos falsos con la idea de que tratarán de utilizarlos y consumo, en pequeña medida, sus recursos.

Por eso me hizo gracia leer The best way to protect your passwords may be creating fake ones donde explican una propuesta experimental para asegurar las contraseñas almacenadas con un gestor la creación de algunas nuevas (y falsas) que harían perder el tiempo a un hipotético atacante.

Además, como el almacenamiento de contraseñas estaría cifrado, el gestor genera un fichero de contraseñas de aspecto razonable para cada posible clave de descifrado que un atacante pueda probar (por fuerza bruta) así que ralentizaríamos todavía más sus ataques.

La utilización de frames es vieja en la red: permite incluir contenido de otros sitios en nuestra página y es un mecanismo que algunos servicios ofrecen como el habitual para este cometido.

Nowadays, old-school (Netscape style) frames have fallen out of fashion, but iframes are more popular than ever. They’re used for advertising, social plugins (e.g. Facebook “like” buttons and “Share on Twitter” functionality), webpage widgets, and so on.

En You’ve Been Framed! A survey of iframes and the sandbox attribute se comenta sobre estas técnicas y su prevalencia, así como el atributo sandbox, que permite controlar políticas de seguridad sobre contenido incrustado en nuestra web:

Just how popular are iframes? Not all websites have them but those that do tend to have quite a lot. To find out, I recently crawled the top ranking sites on the web and counted the iframes. Most iframes are dynamically generated by javascript, so you need to use a crawler which evaluates js. I wrote about the method I used in a follow-up post.

72% of the Alexa top 5000 sites have iframes on their landing pages. Of those, each has on average 7.1 iframes. Some sites have well over 50 frames.

Of all these 25,849 iframes on the top 5000 sites, only 10 use the HTML5 sandbox security attribute. That’s a whopping 0.04%! We’ll learn more about this attribute in a bit.

Examining the top 50 sites, there are a lot fewer iframes. But no one is using the aforementioned sandbox attribute. Of the top 1000, only two sites employ it.

Los riesgos son, esencialmente, que alguien saque partido de estar en nuestra página web al estar integrando contenido que está fuera de nuestro control:

However, external content is completely beyond your control. It can control the browser and the user experience to a degree. Unrestricted iframes can run javascript, Flash and other plugins, open pop-up windows, and even navigate from the containing page. If the site is just intended to display an ad or social button, does it really need to be able to do all (or even any) of these things?

En sitios de perfil alto esto no debería ser un problema (pero mejor no fiarse) pero nunca sabemos lo que puede pasar con otros sitios: esos botones tan chulos que proporcionaba alguien y que, en algún momento, no puede seguir con el servicio, abandona el dominio y es utilizado por otra persona.

En Play safely in sandboxed IFrames se habla un poco más del marco general (principios básicos de seguridad, mínimo privilegio y compartimentalización) y se explica la forma de incluir iframes de forma más segura:

The sandbox attribute of the iframe element gives us just what we need to tighten the restrictions on framed content. We can instruct the browser to load a specific frame’s content in a low-privilege environment, allowing only the subset of capabilities necessary to do whatever work needs doing.