Introducción e historia de los contenedores

Contenedor y herramientas Aunque de manera profesional son algo de nuestro día a día, en el apartado de ‘cosas que han sucedido mientras no estábamos atentos’ han explotado en los últimos años los contenedores: por decirlo de manera muy simplificada, un contenedor es un sistema virtual que nos permite aislar un ‘programa’ y sus dependencias de forma que no interfiere con otros procesos dentro del mismo sistema donde se ejecuta, pero de manera más ligera que si ejecutáramos una máquina virtual para él solo.

En The Missing Introduction To Containerization hablan del tema, empezando con un repaso histórico: las jaulas ‘chroot’, y otras tecnologías que se han venido usando con la misma finalidad.

It all started when the Chroot Jail and the Chroot system call were introduced during the development of Version 7 Unix in 1979. Chroot jail is for “Change Root” and it’s considered as one of the first containerization technologies.

Lectura interesante.

¿Dónde guardas tus secretos?

Escondido El otro día hablábamos de fugas de información a través de los canales de comunicación de las empresas y cómo los ‘malos’ podían sacar partido de diversos automatismos en Interacciones inseguras entre sistemas de ayuda y otros. Hoy traemos otro How bad can it git? Characterizing secret leakage in public GitHub repositories relacionado con la difusión de secretos que no deberían estar en los sistemas de control de versiones.

Los desarrolladores no deberían incluir secretos en los sistemas de control de versiones, nada nuevo:

On the one hand you might say there’s no new news here. We know that developers shouldn’t commit secrets, and we know that secrets leaked to GitHub can be discovered and exploited very quickly.

Ofrecen expresiones regulares que podrían utilizarse como chequeo antes de enviar la información al sistema de control de versiones, que pueden encontrarse en el artículo, en How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories.

Hay una implementación previa, que incorpora el sistema en truffleHog y otro proyecto con ideas similares git-secrets.

Vale la pena leerlo todo, muy interesante.

¿Eres predecible?

Sorteo En How random can you be? una vez más un recordatorio sobre lo poco hábiles que somos generando aletaoriedad (y comprendiéndola, usándola, manejándola, …).

Hay un jueguecito que podemos probar donde el sistema trata de adivinar nuestro próximo movimiento y nos dice si va acertando o no.

También hay algo más de información sobre el tema en los enlaces. Interesante.

¿Llegó la hora de matar la web?

tela de araña Una provocadora entrada de Mike Hearn It’s time to kill the web donde se habla del mal estado (en este caso desde el punto de vista de la seguridad y el desarrollo) de la web. Concretamente, en este artículo se centra en los problema.

Por ejemplo, la guía de Google sobre errores frecuentes, que el autor califica de un conjunto de hechicería y folklore que es muy preocupante.

Reading this ridiculous pile of witchcraft and folklore always makes me laugh. It should be a joke, but it’s actually basic stuff that every web developer at Google is expected to know, just to put some data on the screen.

Luego, la dificultad para contratar personas que hagan este trabajo correctamente:

My experience has been that attempting to hire a web developer that has even heard of all these landmines always ends in failure, let alone hiring one who can reliably avoid them. Hence my conclusion: if you can’t hire web devs that understand how to write secure web apps then writing secure web apps is impossible.

Y así sigue, con unos cuantos problemas más.

No estoy seguro de que sus propuestas (que aún tengo pendientes de leer) vayan a traer la felicidad al mundo (por decirlo de alguna manera) pero creo que es una buena panorámica de las cosas que van mal y no debemos cerrar los ojos a esto. También creo que si esos mismos desarrolladores fueran contratados para desarrolar productos eficaces (dejando de lado efectos, y otras cuestiones visuales que no deberían ser tan importantes) igual nos iba un poco mejor. Pero igual estamos colocando los incentivos (como sociedad) en los lugares incorrectos. También tengo que reconocer que hace tiempo que navegar me parece aburrido y molesto y que trato de evitarlo manejando el contenido de formas alternativas, cuando es posible. Pero no creo que sea fácil prescindir de la web. Ni aconsejable.

Falsedades que los programadores pueden creer sobre la numeración telefónica

Teléfono antiguo Hay toda una saga de documentos titulados ‘falsedades que creen los programadores sobre …’ y sigue con fechas, nombres, y otros temas. Recientemente descubrí la exitencia del Falsehoods Programmers Believe About Phone Numbers.

Desde algunos sencillos como el de supone que un individuo siempre tiene un número telefónico (que puede ser falso o simplemente una cuestión de privacidad), pasando por suponer que si tenemos un número de teléfono simpre podremos hacerle una llamada, hasta suponer que los organismos competentes tienen perfectamente controlados y publicados cómo son sus números de teléfono y que lo que publican se corresponde con la realidad en un momento dado.

La seguridad y los gestores de contraseñas

Escondido Me gustó leer Password managers may leave your online crown jewels ‘exposed in RAM’ to malware – but hey, they’re still better than the alternative porque trata dos temas sobre los que pasamos de largo habitualmente: los usuarios no utlizan los gestores de contraseñas y, en general, no se preocupan demasiado de la calidad de sus claves; por otro lado, los desarrolladores no suelen prestar atención a los secretos almacenados en memoria. Esto es, cuando desciframos un dato con un programa ese dato reside en alguna parte (o algunas) de nuestro computador. Y lo de algunas tiene que ver con las cachés, mecanismos de paginación y otros artefactos que aparecen en nuestra vida diaria.

Sobre este segundo tema, dice:

The problem here is mainly secure memory management. To some degree, every one of the four password managers left passwords – either the master password or individual credentials – accessible in memory. This would potentially allow malware on a system, particular malware with admin rights, to obtain those passwords.

Y no se trata de una afirmación puramente teórica, sino que hicieron las pruebas:

“Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.”

porque este trabajo proviene de una investigación sobre la seguridad de 1Password, KeePass, LastPass y Dashline, algunos de los gestores más conocidos. Se pueden ver más detalles en Password Managers: Under the Hood of Secrets Management.

De todas formas, y volviendo a los usuarios normales, ¿debemos dejar de usar los gestores porque tienen fallos? La respuesta es claramente negativa porque con esos problemas y con todo lo que podamos pensar, siguen siendo una manera más eficaz de resolver el problema para la mayoría de la gente:

The report doesn’t by any means suggest you should not be using a password manager. Even with the mild flaws ISE found, a password manager remains by far the best way to keep your login credentials secure, and experts routinely recommend them as a way to manage multiple unique and strong passphrases for your online accounts.

Por lo tanto, ya saben ustedes: si son desarrolladores, que los secretos descifrados estén el menor tiempo posible así y sólo en memoria. Si son usuarios, utilicen un gestor de contraseñas. Serán mejores y ustedes estarán más seguros.

Interacciones inseguras entre sistemas de ayuda y otros

Muro roto A veces confiamos en sistemas externos para las comunicaciones de nuestra empresa, y no siempre comprendemos bien las consecuencias de algunas de sus funcionalidades. Casi siempre nos olvidamos de que los ataques más sencilos se pueden realizar sin (casi) tecnología: basta con engañar a alguien con el acceso adecuado a la información o sacar partido de su buena voluntad de ayudar para conseguir muchas cosas. En este caso, ni siquiera hay engaño a personas, sino a los sistemas que sirven para que las personas resuelvan sus problemas o pidan ayuda. De eso nos hablaba Inti De Ceukelaire en How I hacked hundreds of companies through their helpdesk y cualquier responsable de información (y explícitamente evito la palabra sistemas o informática) debería leer.

En este caso, el atacante sacaba partido de las características de sistemas comoTwitter, Slack y otros… Esencialmente, sistemas que aceptan o mandan un mensaje sin hacer demasiadas verificaciones. El problema sucede cuando alguien puede acceder al mensaje de alguna forma alternativa (por ejemplo, porque se publica su contenido en alguna parte).

Months ago I discovered a flaw hackers can use to access a company’s internal communications. The flaw only takes a couple of clicks to potentially access intranets, social media accounts such as Twitter, and most commonly Yammer and Slack teams.

GitLab, por ejemplo, tiene una dirección @gitlab.com de correo electrónico para crear peticiones (issues):

At the same time, GitLab offers a feature to create issues by e-mail by sending them… to a unique @gitlab.com e-mail address. See where this is headed?

Esta se publicará directamente en el sitio adecuado y esto lo utilizó para unirse al Slack de los desarolladores: pone como dirección de la cuenta la de gitlab del proyecto y Slack manda el mensaje típico de verificación como respuesta (de forma que se publican como una petición). ‘Tachán! … Acceso conseguido.

¿Es algo exclusivo de GitLab? No, lo cierto es que muchos portales permiten enviar por correo consultas similares.

Pero se pueden hacer otras cosas, por ejemplo abusar de los sistemas de identificación con single sign-on. En este caso un usuario autenticado tiene acceso directo al portal de apoyo y, en muchos casos, no se utiliza corero de verificación por lo que podríamos utilizar practicamente cualquier dirección y, en particular, una relacionada -nuevamente- con slack. Cuando Slack nos responde (después de buscar el espacio de trabajo que nos interesa) llega la notificación al sistema de ayuda al que nosotros ya teníamos acceso.

Behind the scenes, feedback@slack.com now sends an e-mail to support@[censored*].com containing the verification link.

When support@[censored*].com receives the e-mail, it will be classified as a support ticket created by feedback@slack.com… which is the exact e-mail I signed up with.

Aunque los ejemplos se realizaron con el acceso a Slack, no es la única posibilidad (nombra Yammer).

Muy curioso. Al final se trata de un ejemplo más de interacciones inseguras entre sistemas que son seguros (o que no son inseguros).

En This hacker gained access to hundreds of companies through their helpdesk está la presentación (menos ténica) del caso.

La seguridad, el análisis de riesgos, lo viejo y lo nuevo

Puerta Me gustó mucho leer Those Bashing Smart Locks Have Forgotten How Easy it is to Pick Regular Ones por dos motivos: el contenido sobre las cerraduras inteligentes (y no tanto) y también porque cuando aparece un elemento tecnológico que propone sustituir otro más tradicional, siempre hay quién trata de atacar al nuevo porque tiene algunos inconvenientes. El caso más paradigmático sería el del coche autónomo y esas preguntas que podemos leer por ahí sobre a quién debería atropellar un coche autónomo en caso de tener delante diferentes ‘alternativas de atropello’. No digo que no sea un debate interesante y, si se pudiera elegir, habría que pensar en ello. Pero olvidamos que un pobre conductor humano, en una circunstancia análoga no podría elegir con una alta probabilidad: haría lo que pudiera; seguramente, poco. Atropellaría a cualquiera de las alternativas disponibles sin haber podido evaluar (ni un poquito) la situación.

En este caso hablamos de cerraduras y como parece que hay gente criticando a las nuevas, y defendiendo las bondades de las de toda la vida. En cierto modo, nos dice Daniel Miessler, la situación consiste en que hemos olvidado los inconvenientes de la tecnología vieja y ya hemos aceptado los riesgos que supone:

The problem I see in this discussion is that we’ve somehow—in the information security community—forgotten about the risk that we have already accepted. For hundreds of years we’ve protected our homes …

Luego pasa a hacer un análisis de amenazas, que es como debería actuarse frente a un problema de seguridad. No voy a detallar sus conclusiones, pero descataré algunos comentarios de las conclusiones.

Es cierto que pueden tener sus vulnerabilidades y problemas pero atacar un sistema de este tipo tendría sentido si hubiera muchos en los alrededores y pudiéramos sacar ventaja de un ataque a mayor escala:

So we did see a few situations where attacking a smart lock could make sense, assuming they were similar enough for it to be quick and easy—like in a housing complex for tech employees (in say 5 years).

Por lo demás, en condiciones normales es más sencillo hacer lo que haríamos con una puerta que tenga una cerradura de estilo tradicional: echarla abajo de una patada, o entrar por una ventana.

It’s easier to kick in the door or go through a window (or pick the lock) than it is to even look at a smart lock, or…

Por otro lado, es fácil imaginar que los atacantes asocien cerraduras inteligentes (smart) con otros sistemas añadidos de vigilancia (¿cámaras? ¿vigilancia remota?…) que sumarían como elementos disuasorios.

Attackers are likely to start associating smart locks with video capture, remote monitoring, and lots of other IoT-ish functionality, which will mean a higher risk of getting caught.

En definitiva, cuando nos encontremos con una medida de seguridad, vale la pena hacer un análisis más completo (en este caso leerlo) para comprender mejor el escenario y si, efectivamente, aporta o no ventajas.

La complejidad y la seguridad: el caso de las tarjetas de memoria

Viejos discos duros En informática todo se vuelve tan complejo que es difícil estar seguro de que nada puede fallar. Es un viejo dicho el de que una forma de mejorar la seguridad es buscar diseños simples, que sean fáciles de comprender, gestionar y utilizar. En On Hacking MicroSD Cards la enésima prueba de esto: las tarjetas de memoria son tan complejas que algunas permiten algo tan desagradable como la ejecución de código.

[…] disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution — on the memory card itself.

Por un lado, las tarjeta son tan baratas que contienen de manera inevitable defectos. Estos fallos han de enmascararse mediante sistemas de corrección y esto lleva de forma inevitable a tener problemas:

Flash memory is really cheap. So cheap, in fact, that it’s too good to be true. In reality, all flash memory is riddled with defects — without exception. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions. This is the result of a constant arms race between the engineers and mother nature; with every fabrication process shrink, memory becomes cheaper but more unreliable. Likewise, with every generation, the engineers come up with more sophisticated and complicated algorithms to compensate for mother nature’s propensity for entropy and randomness at the atomic scale.

Al final, la tarjeta incluye un microcontrolador que hace abstracción del sistema físico que tiene debajo:

These algorithms are too complicated and too device-specific to be run at the application or OS level, and so it turns out that every flash memory disk ships with a reasonably powerful microcontroller to run a custom set of disk abstraction algorithms.

El motivo casi siempre es el precio: es mucho más barato añadir esta complicación que fabricar mejor las tarjetas.

Amazingly, the cost of adding these controllers to the device is probably on the order of $0.15-$0.30, particularly for companies that can fab both the flash memory and the controllers within the same business unit. It’s probably cheaper to add these microcontrollers than to thoroughly test and characterize each flash memory chip, which explains why managed flash devices can be cheaper per bit than raw flash chips, despite the inclusion of a microcontroller.

A mi me ha recordado un poco la presentación aquella de Wietse Venema [PDF] The broken file shredder Programming traps and pitfalls donde nos hablaba de las complejidades del borrado de información en los abuelos de las tarjetas de memoria, los discos duros. Y me hace recordar cada vez que alguien habla de borrado seguro de información en los medios generalitas. Casi nada es tan fácil como parece.

Interesante.

JMAP: evoluciones alternativas abiertas para el viejo correo electrónico

Buzón Damos por supuesto el funcionamiento del correo como algo que hemos tenido siempre pero, igual exagero, yo estoy algo preocupado: no hay grandes avances ni evoluciones y todos damos por hecho el uso de los grandes proveedores. No tengo nada que objetar, pero sí que me preocupa que esos grandes proveedores vayan cambiando los protocolos y el correo electrónico deje de ser lo que era. Por ejemplo, uno puede consultar su cuenta de GMail mediante IMAP o POP3 pero… cuando lo habilita, si no recuerdo mal nos avisan de que es un protocolo ‘menos seguro’. Quien dice eso, si echamos un vistazo a los clientes el panorama tampoco es muy halagüeño: los clientes parece que van evolucionando poco y casi por inercia, rendidos ante la ‘potencia’ de los clientes web. Y no hay una gran diversidad, ni siquiera en el mundo móvil donde lo que podemos encontrar son cambios estéticos sobre algunas bases comunes. Para mi sería paradigmático el caso de Ubuntu Touch que, abandonado como está y en manos de voluntariosos desarrolladores nunca ha tenido un buen cliente de correo (aunque el que promovía traía ideas interesantes) lo que significaría que Ubuntu no consideró esa pieza como algo importante en sus desarrollos (y nadie lo ha hecho después).

Seguro que solo son impresiones y el tiempo nos lo dirá pero me gustó leer JMAP: It’s like IMAP But Not Really del que ya había leído algo pero no había entendido muy bien en qué consistía. En esta nota nos explican que JMAP sería un sustituto de IMAP/SMTP (protocolos de lectura y envío de mensajes de correo) basado en JSON, JMAP (JSON Meta Application Protocol) y que parece que trata de atacar a la complicación que supone actualmente desarrollar un cliente de correo (y que, de paso, daría la razón a Google explorando sus propios mecanismos y APIs).

Nos dicen también que se trata de una API REST que mejora sustancialmente al protocolo IMAP:

Astute readers may have added this up by now, but just to clarify: JMAP is a modern REST like API that can do everything IMAP does but better.

Además de ser abierto, moderno…

¿Hay esperanza en el mundo del correo electrónico?