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?

Los consejos, a veces, son como las opiniones

Cantidad y no calidad Este es otro de los temas recurrentes en este sitio es los errores que se transmiten a modo de ejemplos, ayudas y otros mecanismos que los programadores utilizan para resolver sus dudas. Hace algún tiempo lo comentamos en Seguir la corriente resolviendo problemas y la seguridad y el tema volvió a principios de este año con una nueva investigación. Nos lo contaban en Popular coding advice doesn’t necessarily equal secure coding advice y hablan de una investigación más reciente:

According to more recent research by a group of researchers from Virginia Tech, TU Munich and the University of Texas at San Antonio, the answer is “no.”

cuando se preguntan si estos foros ayudan a diferenciar elecciones seguras frente a las inseguras.

El estudio lo realizarn en el sitio Stack Overflow buscando contenido relacionado con la seguridad, en particular seguridad en Java.

The researchers conducted a study on security-related Stack Overflow posts and contrasted secure and insecure advice with the community-given content evaluation. To ensure a fair comparison between secure and insecure suggestions, they focused on the discussion threads related to Java security.

Stack Overflow es un sitio muy conocido entre los programadores e informáticos en general y, además, están orgullosos de hacer un seguimiento de las respuestas para evitar repeticiones, imprecisiones, y otros defectos de sitios donde cualquiera puede responder. Sin embargo, no parecen muy eficaces aclarando temas con la seguridad en mente:

“Compared with secure suggestions, insecure ones had higher view counts (36,508 vs. 18,713), received a higher score (14 vs. 5), and had significantly more duplicates (3.8 vs. 3.0) on average. 34% of the posts provided by highly reputable so-called trusted users were insecure.”

Esto es, los mecanismos que tiene el sitio para mejorar la seguridad no funcionan bien a la hora de identificar respuestas confiables.

Also, its reputation mechanism fails to point out trustworthy users with respect to security questions.

Muy interesante.

Computación biológica y el problema del viajante de comercio

De viaje De vez en cuando nos salimos un poco más del tema y traemos alguna curiosidad. En este caso tiene que ver con amebas y problemas difíciles, de la mano de An Amoeba-Based Computer Calculated Approximate Solutions to a Very Hard Math Problem.

El problema difícil es el viejo conocido del viajante de comercio (Travelling Salesman problem TSP) y podemos hablar de computación biológica (y no la más habitual, que es la bioinspirada). No se si vale la pena recordar que el problema consiste en determinar un recorrido óptimo para visitar una serie de ciudades volviendo a la de origen y pasando una vez por cada una. A pesar de lo sencillo que es describirlo, es un problema que es costoso de resolver de forma exacta cuando el número de ciudades crece.

Por lo visto las amebas son capaces de generar soluciones aproximadas al problema (recordamos aquí que cuando los problemas son difíciles -desde el punto de vista del coste, aclaro- nos conformamos con tener soluciones aproximadas suficientemente buenas).

A team of Japanese researchers from Keio University in Tokyo have demonstrated that an amoeba is capable of generating approximate solutions to a remarkably difficult math problem known as the “traveling salesman problem.”

Por lo visto, lo resuelven hasta 8 ciudades con una calidad de la solución bastante buena, en un tiempo que crece de manera lineal:

Yet as these Japanese researchers demonstrated, a certain type of amoeba can be used to calculate nearly optimal solutions to the traveling salesman problem for up to eight cities. Even more remarkably, the amount of time it takes the amoeba to reach these nearly optimal solutions grows linearly, even though the number of possible solutions increases exponentially.

Por lo visto, este tipo de amebas son capaces de expandir su cuerpo en varias direcciones en busca de alimento, lo que las hace particularmente interesantes:

The reason this amoeba is considered especially useful in biological computing is because it can extend various regions of its body to find the most efficient way to a food source and hates light.

¿Cuándo podremos usar esto? De momento son solo experimentos de laboratorio que podrían ser la base para construir computadores biológicos de bajo consumo energético. Esto es, de momento, no.

For now, however, the Japanese researchers’ experiment remains in the lab, but it provides the foundation for low-energy biological computers that harness the natural mechanisms of amoebas and other microorganisms to compute.

Europa se despierta: apoyando la seguridad en el software libre

Dinero Que Europa tiene un papel puramente seguidista en tecnología no es algo que vayamos a descubrir aquí y ahora. De los temas regulatorios ni hablamos. Creo que los factores que contribuyen a ello son muchos y merecerían un análisis que alguien debería hacer.

Los botines por descubrimiento de fallos (Bug Bounties) es algo que existe desde hace tiempo pero que en los últimos años ha cobrado mucha importancia: una empresa, organización o lo que sea paga a los que descubren fallos para agradecerles el hallazgo y también para incentivar que se lo comuniquen a ellos, en lugar de a los ‘malos’.

La revisión de software libre por diversos organismos y empresas también tiene una cierta tradición (podemos recordar el caso de Coverity Scan OOS. La empresa facilita los informes a los desarrolladores para que mejoren el software que tanta gente usa.

Finalmente, vale la pena recordar, que uno de los fallos de seguridad más importantes es la utilización de componentes de terceros (ver, por ejemplo Component Analysis).

Así que, con todo este preámbulo, me llevé un alegrón al conocer que In January, the EU starts running Bug Bounties on Free and Open Source Software . Esto es, Europa financia la búsquead y localización de fallos en programas de software libre.

Cuentan como se realizó un inventario del software libre que utilizan e incluso auditaron Apache y KeePass EU aims to increase the security of password manager and web server software: KeePass and Apache chosen for open source audits.

Ahora han decidido lanzar un serie de recompensas sobre los proyectos que han considerado más importante: incluyen Filezilla, Apache Kafka, Notepad++, Putty y otros… La lista.

el proyecto tiene su propia página web FOSSA y nos hace pensar que, a veces, se hacen algunas cosas bien.

Algunas intrucciones útiles cuando estamos usando una terminal

Terminal Me reconozco un gran usuario de la línea de instrucciones en una terminal: cuando se maneja medianamente la productividad puede ser excelente. Por eso me gustó leer Some of My Favorite Shell Aliases From Over the Years donde Daniel Miessler nos da algunas recomendaciones. Los expresa en forma de alias, para tener que teclear menos.

Por ejemplo, para buscar:

$ alias f="find . -name"

O algo que pregunta muchas veces la gente nueva, ¿cómo se mi IP?:

$ alias gip="curl ipinfo.io/ip && curl ipinfo.io/org"

Un generador de contraseñas:

$ alias np="openssl rand -base64 24"

Y algunos más. Interesante.

Falsedades que los programadores creen sobre los nombres

Sobre nombres Hay una cierta tradición de hacer listas de ‘verdades’ que los programadores creen sobre determinados aspectos (nombres, tiempo, fechas, …) y que no tienen por qué se ciertas. Típicamente tienen que ver con temas culturales y de internacionalización, que no son siempre tenidos en cuenta por los desarrolladores habituales. Recientemente podíamos leer Falsehoods Programmers Believe About Names – With Examples que nos trae de nuevo el tema de los nombres, y al que vale la pena echar un vistazo.

Creo que puede ser un texto interesante incluso para personas que no programan, por lo que se puede aprender de otras culturas y formas de hacer las cosas. Para desarrolladores, es posible que alguna vez tengan que enfrentarse a estos dilemas.

Las restricciones sobre contraseñas generan contraseñas peores

Teclas Algunos administradores que pueden hacerlo (seguramente, los mismos que pueden obligarnos a cambiar de contraseña, como contábamos en Los cambios frecuentes de contraseña son contraproducentes creen que añadir una restricción a nuestra contraseña indicando que contenga una cifra y un caracter especial (o variaciones similares) mejora las contraseñas. Lo cierto es que, si permitimos estos caracteres en las claves puede que mejoren (siempre que no se hagan substituciones obvias: l por 1, e por 3, …). Pero siobligamos a que estén, le estamos dando pistas a los ‘malos’: pueden hacer búsquedas en el espacio de claves, poniendo menos alternativas en algunas posiciones (el caso más delirante, que he visto en un par de sitios es ‘forzar’ a que esos caracteres estén en determinadas posiciones). Sin olvidarnos de que cuando eso contraviene nuestras propias costumbres en la generación de contraseñas, tenemos la receta segura para que no la recordemos, o la hagamos peor para estar seguros de recordarla.

De eso hablaban en How Password Constraints Give You a False Sense of Security y yo lo traigo aquí para animar a tantos y tantos administradores a no ser creativos en estas cosas.

Hace un poco de numerología con lo que ahorraría un hipotético atacante sabiendo que tiene que haber, digamos, un dígito:

Assume they can test about 31 billion passwords per second. Cracking their way through your reasonably complicated eight-character password could take, at most, 212,903 seconds. That’s 3,548 minutes, or roughly two and a half days.

Now, let’s talk about constraints for a minute. Assume that the service you’re using requires you to have an eight-character password. Abrams notes that takes 70.6 trillion passwords out of the mix, since every password from a single character long to seven character long is now invalid. That saves the cracking tool a whopping 2,277 seconds, or nearly 38 minutes. That’s not too bad.

Vale la pena leer el resto de argumentos numéricos pero, al final, la conclusión es que lo mejor es que la contraseña sea más larga, incluso en sistemas con restricciones.

Instead of worrying about the best way to make your shorter password harder to guess or brute-force, Abrams advises that it’s a lot better to pick a longer password, because even if a service has password constraints, they’ll have much less of an impact: […]