En la comunidad de investigadores es frecuente investigar con lo que se tiene más a mano que son los dispositivos caseros. Este es el caso de Marie Moe, que tiene implantado un marcapasos y se ha dedicado a analizar su seguridad, Hacking Yourself: Marie Moe and Pacemaker Security.

Hace unos años inició su trabajo sobre la seguridad de los marcapasos y encontró cosas interesantes ICS Medical Advisory (ICSMA-20-170-05). Fundamentalmente, problemas de:

• Autentificación incorrecta.
• Transmisión en texto claro de credenciales.
• Reutilización de credenciales.
• Almacenamiento de datos médicos en claro.
• Almacenamiento incorrecto de contraseñas en el dispositivo.

Es cierto que, aparentemente, no hay ataques conocidos públicos que saquen partido de estas vulnerabilidades y tampoco pueden usarse para cambiar la programación del dispositivo.

Note for the record that so far, “no known public exploits specifically target these vulnerabilities,” the Advisory says. Also note that these vulnerabilities can’t be used to directly reprogram a pacemaker or hack someone’s heart.

La generación de números aleatorios en sistemas informáticos es un tema que tratamos por aquí de vez en cuando. Por eso me gustó How Do Computers Generate Random Numbers donde dan algunos detalles.

Siempre decimos que un computador es un sistema determinista y, por lo tanto, con muchos parámetros predecibles, lo que hace difícil resolver el problema de generar datos impredecibles.

Anyone with any programming experience understands that computers are deterministic machines. If you provide the same input, you’ll always get the same output. That’s why having computers generate something by chance is trickier than it may seem.

Luego habla de posibbles fuentes de entropia (aleatoriedad), como pueden ser los movimientos del ratón, el ruido del ventilador, la presión atmosférica y otros, como semilla de los algoritmos generadores.

We just need to pick a seed that an attacker wouldn’t be able to predict. This seed value will then be passed into an algorithm, similar to PRNGs, that will generate a random number to use.

Finalmente, muestra algunos de los algoritmos y sus implementaciones.

Interesante.

Ante un incidente de segurida la respuesta tradicional es utilizar el registro de actividad (los logs) pero esta no es la única alternativa y en Using API’s to Track Attackers nos dan algunas ideas sobre el tema.

Un atacante utiliza el API de Dropbox para conseguir algunos datos interesantes.

The attackers reused exactly the same piece of coded (link above) to decrypt the master key - hey, why reinvent the wheel? To exfiltrate data, they decided to use Dropbox. The well-known file sharing service provides indeed a nice Python interface to its API[3] which is very easy to use…

De paso, nos hablan un poco de instrospección en Python:

When you don’t have experience with Python library objects, your first reflex must be to search for the available methods via dir()

Y, en este caso, sobre la obtención de información del atacante.

The very first interesting method to use is users_get_current_account() to get information about the account. Now, we know more information about the attackers.

Nunca se sabe dónde podemos conseguir la mejor información.

En cualquier texto de seguridad informática que miremos por ahí leeremos el consejo de ‘no desarrollar nuestra propia criptografía’. En So you want to roll your own crypto? hay ideas interesantes sobre el tema.

Parte de una pregunta que no es despreciable: ¿cómo vamos a aprender (de nuestros errores) si no podemos hacer nuestra propia criptografía?

How are people supposed to learn (from mistakes) if they don’t roll their own crypto?

Y la respuesta también es secncilla: hazlo, pero no utilices lo que hagas en producción.

The short answer is do roll your own crypto, but don’t use it in production until it’s vetted by professionals. The long answer below might take a few years to hash out.

Equivocarse es un proceso inevitable para conseguir aprender (y aquí hablamos en sentido amplio) aunque también podemos aprender de los errores de otros. Cursos, retos, …

I found that the cheapest way to learn from mistakes is to learn from other people’s mistakes. I recommend taking Cryptography I, doing CTFs, and solving crypto challenges. This won’t take long, and very quickly you’d be pretty dangerous because you’d be able to find many crypto bugs.

Sin embargo, todo esto puede ser insuficiente. Leer código es una buena forma de aprender, pero en criptografía esto no es tan sencillo. El código no es obvio, tiene detalles sutiles y la mala criptografía produce muchas veces resultados indistinguibles de la buena.

They say you can become a better programmer by reading good code. Unfortunately, I’ve learned the hard way that this rule usually does not work in crypto, …

Tampoco hay un buen sustituto de aprender los fundamentos. Sin embargo, después de conocerlos a lo mejor tampoco es un buen momento para desarrollar nuevos sistemas criptográficos, porque el campo es amplio y cada una de sus partes tiene sus propias características.

The funny thing is that after spending years studying these resources, you still don’t have a free pass to roll all the crypto in the world. You’d realize and appreciate that crypto is a deep and vast field of study with a very long food chain. Sitting on top are cryptanalysts who…

Y tampoco hay que olvidar las interacciones entre ellas. Esto significa que incluso utilizando los protocolos desarrollados por otros nos podemos equivocar (y lo haremos).

Así que la conclusión es que deberemos estar seguros de que comprendemos bien lo que tenemos entre manos, y estudiar para eliminar nuestras limitaciones.

So if you want to roll your own crypto, make sure you understand where you are in the crypto food chain and what are the reasons preventing you from moving up. Study and eliminate said reasons. Good luck and have fun!

El correo electrónico es una de las aplicaciones más viejas de internet. Además es una de las pocas que se ha mantenido verdaderamente descentralizada: es cierto que hay una cierta tendencia al uso de los proveedores habituales, pero sigue habiendo muchos servidores de correo ‘independientes’ y con los que todo el mundo tiene que poder interactuar.

Esto provoca que haya algunos problemas de seguridad (y el spam, claro). En Decades-Old Email Flaws Could Let Attackers Mask Their Identities hablan del tema, centrándose en algunos de los sistemas que se han añadido para hacer que el correo sea más seguro y confiable. En particular, el marco de política de envíos, el correo identificado mediante claves de dominios y la autentificación basada en dominios.

The study looked at the big three protocols used in email sender authentication—Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-Based Message Authentication, Reporting and Conformance (DMARC)—and found 18 instances of what the researchers call “evasion exploits.”

Nos dicen que el problema no está en los protocolos, sino en cómo los implantan diferentes servicios.

The vulnerabilities don’t stem from the protocols themselves but from how different email services and client applications implement them. Attackers could use these loopholes to make spear-phishing attacks even harder to detect.

Hay ataques dentro del servidor, basados en inconsistencias sobre como un servicio obtiene los datos de las cabeceras para autentificar a un usuario.

The first set, called “intra-server” attacks, prey on inconsistencies in how a given email service pulls data from headers to authenticate a sender.

El segundo se basa en manipular inconsistencias similares, pero entre el servidor que recibe el mensaje y la aplicación que usamos para leerlo.

The second category focuses on manipulating similar inconsistencies, but between the mail server that receives your message and the app that actually displays it to you.

Finalmente, las ‘respuestas ambiguas’ por problemas en cómo se manejan algunas cabeceras de autentificación.

The researchers call the third category “ambiguous replay,” because it includes different methods of hijacking and repurposing (or replaying) a legitimate email an attacker has received. These attacks take advantage of a known quality of the cryptographic authentication mechanism DKIM where you can receive an email that has already been authenticated, craft a new message where all of the headers and the body are the same as they were in the original email, and essentially resend it, preserving its authentication.

Todos estos problemas abren la puerta a poder enviar sin demasiados problemas toda clase de basura, en muchos casos porque los proveedores se mueven buscando la compatibilidad, más que el rigor. Sin darse cuenta de la existencia de esos casos límite, que serán explotados por alguien para seguir abusando de los sistemas de correo.