A veces traemos fallos bastante sofisticados y hasta difíciles de seguir. En este caso…

En Cracking The Dave & Buster’s Anomaly nos hablan de uno verdaderamente curioso: si se envía un mensaje de audio en la aplicación Messages, el receptor también utiliza esa misma aplicación e incluye el nombre “Dave and Buster’s”, el mensaje nunca se recibirá.

The bug is that, if you try to send an audio message using the Messages app to someone who’s also using the Messages app, and that message happens to include the name “Dave and Buster’s”, the message will never be received.

Nos cuenta cómo busca si es un error conocido y no encontrando explicaciones satisfactorias se puso a investigar por su cuenta.

El problema parece tener que ver con que el mensaje se transcribe:

Something else you may have noticed is that when you send an audio message using the Messages app, the message includes a transcription of the audio.

Y el traductor lo convierte en una cadena con el carácter &:

the transcription engine on iOS will recognize¹ the brand name and correctly write it as “Dave & Buster’s” (with an ampersand).

Pero este carácter tiene significado en HTML (y XHTML). El problema era que el traductor no tenía en cuenta este significado y no aplicaba los métodos de marcado adecuado para que no se interprete como parte de una etiqueta:

The audio-transcription attribute includes the full transcription from the audio, and it clearly has the unescaped ampersand symbol.

En algún punto se detecta que ese código no está bien construido, falla y deja de procesar el mensaje.

Since BlastDoor was designed to thwart hacking attempts, which frequently rely on faulty data parsing, it immediately stops what it’s doing and just fails.

Como dice el autor, ¿es un fallo de seguridad? Es posible que lo sea, pero en principio parece más bien lo contrario: una protección contra los problemas de seguridad que va más allá de lo necesario.

On the surface, this does sound like it could be used to “hack” someone’s iPhone via a bad audio message transcription, but in reality what this bug demonstrates is that Apple’s BlastDoor mechanism is working as designed.

Interesante. Es un tipo de fallos muy difíciles de controlar y que tienen muchas posibilidades para realizar ataques, aunque en este caso nos quedamos en el lado de la seguridad.

Suelo comentar siempre que puedo (y tiene sentido) cómo los protocolos de internet son bastante simples y, además, puro texto (que es algo que uno no siempre espera cuando lo que ve son imágenes, sonido, …).

En Talking To Your Mailserver Is Not as Hard as You Think! nos hablan del protocolo de correo IMAP (acceso remoto a carpetas en nuestro servidor) y cómo podemos ‘hablar’ con nuestro servidor de manera bastante sencilla.

Empieza recordándonos que se trata de un protocolo descentralizado.

Unlike WhatsApp, Telegram or other messenger services, where the service provider has a centralized server (or nowadays a network of servers) processing all the messages; with emails, everybody can host their own mailserver to send and receive messages to everybody else.

IMAP son las siglas de protocolo de acceso a mensajes de internet y alrededor del correo electrónico es uno de los protocolos que hay, en este caso, para leerlo.

IMAP, which stands for Internet Message Access Protocol.

Luego entra en detalles de las instrucciones (‘comandos’) necesarios para establecer una comunicación con nuestro servidor y poder interactuar para ver qué mensajes hay, leerlos, y realizar algunas operaciones. No es la experiencia más amigable, pero nos dará una idea de todo lo que nuestro programa de correo hace por nosotros.

En el mundo actual, con las IAs generativas trabajando a todo trapo y mejorando a buen paso, la pregunta no es si se hará alguna tarea concreta con ellas, sino cuando.

En este caso, en Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library nos cuentan una experiencia de Microsoft re-escribiendo una biblioteca criptográfica con la ayuda de una de estas IAs.

Nos hablan del proceso de verificación formal para asegurarse de que lo que obtienen es correcto y algunas otras pruebas.

Formal verification will confirm that implementations behave as intended and don’t deviate from algorithm specifications, critical for preventing attacks. We’ll also analyze compiled code to detect side-channel leaks caused by timing or hardware-level behavior.

Porque utilizar la IA y aceptar sus resultados sin más sería suicida, ¿no es así?

Interesante.

El secuestro de datos (ransomware) es un problema que sigue de actualidad, aunque ahora esté un poco silenciado por los riesgos de la IA. Hace algún tiempo podíamos leer On average, manufacturing companies lose $1.9 million per day to downtime from ransomware attacks. Esto es, este tipo de ataques estarían teniendo unas consecuencias del orden de 1.9 millones de dólares diarios. Se centra en empresas de fabricación (manufacturing companies).

Estos datos siempre hay que tomarlos con cuidado, porque suelen provenir de vendedores de algún producto que intentará evitarnos el problema, pero tampoco suelen ser inventados (o no del todo). En este caso los datos venían de 858 empresas que desde octubre de 2018 habrían sufrido ataques de este tipo con unos costes muy imporantes.

From 2018 to October 2024, 858 manufacturing companies suffered a confirmed ransomware attack. On average, this costs companies over $1.9 million per day of downtime, resulting in total estimated losses of $17 billion.

Este ataque es bien conocido, pero por si acaso, vale la pena recordar que se trata de que alguien (o algo) accede a nuestros sistemas y cifra la información, haciendo que no podamos utilizarla. A partir de ese momento nos piden un rescate y las pérdidas pueden venir por dos caminos:

• Por un lado, relacionadas con el tiempo que la empresa no puede desarrollar su trabajo con normalidad
• Por el otro, si tiene que pagar el rescate

Los ataques se producen a nivel mundial, siendo las zonas más desarrolladas las más afectadas, como es natural (ojo, seguramente también porque son de las que se tienen datos).

Luego proporciona una serie de números de los que saco que el tiempo de no dispoinibilidad iba de unas pocas horas a más de cuatro meses.

Downtime varied from several hours to 129 days

Las cantidades solicitadas por los secuestradores podían ir desde los 5000 dólares a los 200 millones, con una media de 10.7 millones.

Ransom demands varied from $5,000 to $200 million. The latter was demanded after LockBit’s attack on Boeing (which wasn’t paid)

On average, attackers demanded $10.7 million in ransom. Based on that figure, we can estimate that around $9.3 billion in ransom has been demanded in total

Hay un montón de cifras más y creo que vale la pena echarle un vistazo, aunque sean datos de hace poco más de un año.

Los países más afectados serían EEUU, Alemania, Francia, Japón, ….

Muy interesante.

Estoy haciendo algunos experimentos con el denominado vibe coding y me parece bastante interesante: por un lado, se pierde la pereza a realizar determinados cambios que supondrían esfuerzo de mover código, renombrar cosas, … porque la IA lo hace bastante bien; por otro, algunas veces se ‘enganchan’ en determinadas decisiones y si no tenemos cuidado podemos tener un pequeño monstruo en nuestras manos. Además, desde siempre he reivindicado el verbo ‘jugar’ para aprender: en el sentido de probar cosas, hacer experimentos, ver qué sucede cuando cambiamos cosas…

Voy recopilando ideas en este hilo de X:

De eso que te encuentras un código viejo y le das un remate. aunque no me convence la visualización. pic.twitter.com/1BoLAuShy2

— fernand0 (@fernand0) December 28, 2023

Pero hoy quería traer aquí al experto oficial del tema, Simon Willison, que no solo lo utiliza, hace recomendaciones y seguimiento de las novedades, sino que también aporta reflexiones y terminología. En Not all AI-assisted programming is vibe coding (but vibe coding rocks) hablaba de vibe coding, un término acuñado por Andrej Karpathy,

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

La definición incluye la idea de que se trata de fluir con la IA y nuestras ideas, llegando a olvidar la existencia del propio código.

En este sentido, lo que decía arriba no sería vibe coding porque mis viejas costumbres me fuerzan en muchos casos a revisar, recolocar cosas, sugerir detalles a la IA… en definitiva, lo que hace un viejo programador (si es que puedo lamarme así) para asegurarse de que lo que le entrega la IA funcionará, podrá mantenerse y seguir desarrollándose en el futuro, tendrá las prestaciones adecuadas, accesibilidad, seguridad, coste razonable (aunque aquí, moviéndonos en el tiempo ‘libre’ a veces lo podemos descuidar).

We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future.

…

We need to consider performance, accessibility, security, maintainability, cost efficiency.

…

We also need to read the code.

Pero, nos dice, no se trata de transformar el vive coding en un término peyorativo o un uso poco responsable de la tecnología, porque puede haber valor en ello.

I don’t want “vibe coding” to become a negative term that’s synonymous with irresponsible AI-assisted programming either. This weird new shape of programming has so much to offer the world!

Todo el mundo, nos dice, debería poder automatizar tareas aburridas, y no debería ser necesario un informático para eso.

I believe everyone deserves the ability to automate tedious tasks in their lives with computers. You shouldn’t need a computer science degree or programming bootcamp in order to get computers to do extremely specific tasks for you.

Y es posible que esta aproximación sea útil para mucha gente, que de otra forma no tendría acceso a estas comodidades.

If vibe coding grants millions of new people the ability to build their own custom tools, I could not be happier about it.

Naturalmente, mucha de esa gente se llevará sustos y disgustos y no conseguirá lo que quería, pero también habrá gente que empezará a mirar lo que ha generado, aprenderá sobre ello y, tal vez, terminen siendo buenos desarrolladores.

Some of those people will get bitten by the programming bug and go on to become proficient software developers.

La curva de aprendizaje es muy empinada al principio, pero las IAs son muy adeucadas para explicarnos lo que hace el código que han generado, y no se cansan nunca.

Por lo tanto, ¿qué deberíamos tener en cuenta?

• Proyectos de bajo riesgo: cuando algún fallo no vaya a producir problemas catastróficos o problemas de cualquier tipo.

Projects should be low stakes. Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities.

• Atentos a la seguridad, cuidado con los secretos (contraseñas, identificadores, ..) y también a la privacidad.

• Ser un buen ciudadano de la red. Que nuestras pruebas no vayan a provocar algún problema en los servidores de alguien

Be a good network citizen. Anything that makes requests out to other platforms could increase the load (and hence the cost) on those services.

• Cuidado con el coste. No será la primera vez que alguien se pone a programar ocn una herramienta de estas, se lía y termina teniendo una factura importante que pagar correspondiente al uso de la herramienta.

I’ve seen horror stories about people who vibe coded a feature against some API without a billing limit and racked up thousands of dollars in charges.

Finalmente nos hace algunas recomendaciones.

Fundamentalmente, hacer las pruebas con cuidado, no nos vayamos a cargar nuestros datos, nuestro sistema o cualquier otra cosa a la que tengamos acceso. Habla de algunas herramientas, pero todavía no hay demasiado.

Safe vibe coding for complete beginners starts with a sandbox.

¡A jugar!

La IA lleva una temporada trayéndonos cada poco tiempo términos nuevos. Uno de ellos es el MCP (Model Context Protocol) y me gustó MCP (Model Context Protocol): Simply explained in 5 minutes porque cumple lo que promete, que es explicar este protocolo en un ratito.

La idea es integrar nuestros LLMs (las IAs de moda, los modelos de lenguaje gigantes) con herramientas externas.

Put simply, MCP is a way for LLMs to more easily integrate with external tools.

Esencialmente es, por lo tanto, un mecanismo que pueden seguir estas IAs para trabajar con sistemas (o aplicaciones) que proporcionan alguna forma para que estas IAs interactúen.

Esto nos ahorraría el esfuerzo de integrar cada uno de los mecanismos de interacción que puedan proporcionar estos sistemas (sus APIs).

So why was MCP introduced? It solves the problem of needing to manually integrate the different APIs you want to use.

Esto no quita, sin embargo, esfuerzo de configuración, porque para cada sitio será necesario establecer algunos parámetros. También será necesario configurar la IA para que interactúe con este intermediario.

Each MCP will have its own instructions, but in general, you just need your MCP client (Cursor in this case) to run the MCP server. Things get more complicated when you need additional integrations, API keys, or permissions.

En Model Context Protocol está la definición del protocolo y mucha más información.

Tengo sentimientos enfrentados con el código generado por inteligencias artificiales. Por un lado, ando haciendo pruebas y me permite avanzar en cosas aburridas y que no haría por mi propia cuenta o me costaría esfuerzo abordarlas. Por otro lado, de vez en cuando me la lía y pierdo tiempo que podría estar dedicando a otras cosas.

De eso que te encuentras un código viejo y le das un remate. aunque no me convence la visualización. pic.twitter.com/1BoLAuShy2

— fernand0 (@fernand0) December 28, 2023

En AI-generated code could be a disaster for the software supply chain. Here’s why. dan una visión pesimista, por losproblemas que pueden aparecer.

Nos habla de un estudio donde se observa como las IAs alucinan, y generan dependencias que no existen, por ejemplo. Eso no sería un problema salvo que alguien se de cuenta y las cree para nosotros: entonces nuestro código dependerá de algo que se ha creado a propósito para perjudicarnos.

These non-existent dependencies represent a threat to the software supply chain by exacerbating so-called dependency confusion attacks. These attacks work by causing a software package to access the wrong component dependency, for instance by publishing a malicious package and giving it the same name as the legitimate one but with a later version stamp. Software that depends on the package will, in some cases, choose the malicious version rather than the legitimate one because the former appears to be more recent.

Estas alucinaciones, como sabemos, se corresponden con propuestas incorrectas generadas como respuesta a determinadas peticiones por la propia naturaleza de los LLMS.

In AI, hallucinations occur when an LLM produces outputs that are factually incorrect, nonsensical, or completely unrelated to the task it was assigned.

Lo peor del caso es que en algunos casos esas alucinaciones se concentran en situaciones muy concretas, dando lugar a que sea relativamente sencillo concentrarse en estos casos y que todo sea más problemático.

In other words, many package hallucinations aren’t random one-off errors. Rather, specific names of non-existent packages are repeated over and over. Attackers could seize on the pattern by identifying nonexistent packages that are repeatedly hallucinated. The attackers would then publish malware using those names and wait for them to be accessed by large numbers of developers.

Actualización (2025-12-23) En LLMs can’t stop making up software dependencies and sabotaging everything otro enlace donde hablan del tema.

El mundo ha cambiado mucho: cuando antes bastaba con un identificador y una contraseña, ahora utilizamos sistemas algo más sofisticados. En Identity Tokens Explained: Best Practices for Better Access Control hablan de los objetos de identificación identity tokens, como base para los mecanismos modernos de autentificación.

Identity tokens—particularly JSON Web Tokens (JWTs) and OpenID Connect tokens—can be considered the backbone of modern application security, as they enable most of the authentication solutions we’ve come to rely on.

La clave está en que, normalmente, una cosa es la gestión de la identidad y la autorización de lo que pueden hacer las aplicaciones.

This article will walk through what identity tokens are, the types of tokens you might encounter, and why you need to decouple authentication from authorization.

Todo ello desde el punto de vista de una solución concreta, que tampoco es muy relevante para lo que podemos aprender allí.

Estos objetos (valores, variables, …) permiten representar alguna forma de identidad dentro de entorno de alguna solución informática. Se trata de alguna información generada por un proveedor de identidad o un servicio de autentificación que la aplicación o servicio pueden validar y utilizar.

First off, when I say “identity tokens,” I’m referring to tokens intended to represent some form of identity—either a human user or a machine identity—within your software ecosystem. They’re basically a packet of information generated by an identity provider or authentication service, which your application or service can then validate.

Estamos hablando de protocolos comop OpenID Connector u OAuth 2.0 que generan típicamente cadenas de caracteres (strings) que codifican algunos detalles de identidad.

A common approach is to rely on a protocol such as OpenID Connect or OAuth 2.0 to manage these tokens. In these cases, the tokens can be short strings that encode vital identity details.

Esto nos permite delegar la confianza, sin manejar las credenciales del usuario directamente, lo que reduce la visibilidad y exposición de estas credenciales.

An interesting thing about identity tokens is how they let you delegate trust. When a user logs in through an identity provider, you don’t need to handle that user’s credentials directly. You can simply trust the identity token the provider generates, assuming you validate its signature.

Sin embargo, podemos tener la tentación de incluir en los objetos demasiada información, con lo que perdermos las ventajas de esta aproximación.

However, they’re far from all-encompassing, and if you try to cram every piece of user-related information into one token, you’re gonna have a bad time.

Luego detalla algunas características de algunos tipos de objetos de este tipo, como pueden ser los JSON Web Tokens (JWTs), OpenID Connect Tokens, Opaque Tokens, o diferentes Machine Identity Tokens / API Keys.

Las ventajas, además de la compartimentalización señalada arriba, tienen que ver con la simplificación a través de la centralización en la gestión de la autentificación, mientras se permite a las aplicaciones realizar su cometido.

That identity provider issues a token, and suddenly all your services know how to trust that user or machine without juggling credentials.

Se añaden otras ventajas como la escalabilidad, su estandarización, mecanismos de identificación única single sign-on, gestión del ciclo de vida/revocación, gestión consistente de las identidades….

Alguonos errores comunes tienen que ver con pedirles demasiado: por ejemplo, incluir ámbitos, conjutos de permisos, o información de estado más o menos complicada.

If you put entire permission sets or complicated state data into a token, you’re forcing a re-issuance of the token every time something changes. That’s not realistic for a dynamic environment, and it’s definitely not secure.

Esto puede ser hasta difícil, por las limitaciones de tamaño.

Tokens have practical limits on size. Some identity providers or networks even place limits on header sizes.

Otro problema puede tener que ver con la duración, que puede ser demasiado corta (y por lo tanto una molestia, o una sobrecarga para el proveedor de identidad) o demasiado larga (con los consiguientes riesgos de que ya no corresponda a lo que necesita el usuario, si es que todavía lo es).

A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.

Otro problema puede tener que ver con la gestión de las sesiones interactivas (para los humanos) y las sesiones para los servicios (para las máquinas). Si las manejamos de forma diferente tendremos problemas de complejidad, confusión y divergencia en la gestión de las políticas de seguridad.

Sometimes teams think machine identities (service-to-service tokens) deserve a completely different approach than human tokens. While there can be some differences, if you diverge too far, you’ll cause confusion, complexity, and potentially misaligned security policies.

Por lo tanto, nuestros objetivos será:

• Desacoplar la autentificación de la autorización.

Decouple Authentication and Authorization

• Mantener los objetos sencillos

Keep Tokens Lean

• Utilizar protocolos estándar.

Use Standard Protocols

• Mantener un balance adecuado en la duración.

Balance Token Lifespan

• Disponer de mecanismos de revocación.

Plan for Token Revocation

También debemos tener en cuenta los aspectos de aseguramiento de los identificadores: utilizar HTTPs para que no pueda verlos nadie, tener cuidado al almacenarlos (cuidado con el registro de actividad, log), verificarlos, cambiarlos de vez en cuando por si alguien consiguiera robarlos, …

Además hay algunos casos de uso (identificación unificada, aplicaciones móviles, comunicaciones entre servicios, microservicios en la nube, …) y termina con algunas preguntas frecuentes.

Me ha gustado.

No solemos hablar aquí de guerras ni armamento, pero el caso es que muchos fallos de seguridad pueden convertirse con cierta facilidad en armas y entonces se habla de una herramienta más dentro del ciber-armamento.

En Ukraine’s Trojan Horse Drones: A New Frontier in Cyber Warfare habla de los drones y cómo en Ukrania los utilizan para atacar a sus enemigos rusos, incorporándoles diversos programas maliciosos, con objetivos diversos.

• Sabotaje: si en uno de estos aparatos incluye un ataque sencillo que estropee la conexión USB puede causar algunas molestias a quien intente analizarlos.

Hardware Sabotage: Basic malware triggers upon connection to enemy systems, physically burning out USB ports or damaging internal components to prevent data extraction or repurposing.

• Bloqueo de sistemas: si los programas son algo más avanzados pueden bloquear las actualizaciones, deshabilitar ciertos componentes, dejando el aparato inutilizable.

System Lockout: Intermediate versions target onboard chips, blocking firmware updates and disabling critical components, effectively rendering the drone unusable.

• Espionaje: si el aparato entra en territorio enemigo y es transportado a instalaciones militares, puede atacar a los sistemas que utilizan contra ellos o mostrar la localización de estos lugares.

Covert Cyber Espionage: Advanced malware remains undetected until reaching enemy territory, where it hijacks control systems to redirect drones or geolocates Russian operators attempting to reuse them.

Al final, estamos hablando de una guerra convencional, pero que tiene una componente importante de innovación informática. Esto tiene muchas consecuencias en cuanto al balance de fuerzas, pero también a la forma en que los contendientes tienen que trabajar.

Ukraine’s strategy exemplifies how cyber capabilities are reshaping warfare, forcing adversaries to balance innovation with security.

No es una casualidad que un experto en ciberseguridad como Mikko Hyppönen decidiera hace unos meses pasarse al mundo de los drones (Ukraine war spurred infosec vet Mikko Hyppönen to pivot to drones.

Una técnica habitual para evitar ataques por desbordamiento de memoria y otros es la aleatorización del espacio de direcciones: si los datos no están almacenados siempre de la misma manera (que es lo que se haría sin aleatorización, más o menos) son más difíciles de encontrar, analizar y, en definitiva, atacar.

En To keep hardware safe, cut out the code’s clues hablan de un método para eliminar información sobre el código en ejecución para evitar que los ‘malos’ puedan utilizar algunos de sus trucos.

Para mejorar la aleatorización en el MIT han prensado una forma de ponerlo más difícil: se trata de eliminar partes aleatorias de las direcciones que llevan a las instrucciones del programa antes de ejecutarse, de forma que serán más difíciles de encontrar por un atacante.

Their “Oreo” method mitigates hardware attacks by removing randomized bits of addresses that lead to a program’s instructions before they’re translated to a physical location. It scrubs away traces of where code gadgets (or short sequences of instructions for specific tasks) are located before hackers can find them, efficiently enhancing security for operating systems like Linux.

Se trata de añadir lo que llaman un ‘espacio enmascarado’ entre el espacio de direcciones virtuales y el espacio de direcciones físicas.

Oreo has three layers, much like its tasty namesake. Between the virtual address space (which is used to reference program instructions) and the physical address space (where the code is located), Oreo adds a new “masked address space.”

Esto reconfigura el espacio de direcciones en tiempo de ejecución antes de ejecutarse, haciendo más difícil conocer las localizaciones originales a través de ataques de hardware.

This re-maps code from randomized virtual addresses to fixed locations before it is executed within the hardware, making it difficult for hackers to trace the program’s original locations in the virtual address space through hardware attacks.

Una preocupación que podríamos tener es que todo vaya más lento por estos cambios, pero nos dicen que eso no es un problema.

While Oreo adds an extra step to program execution by scrubbing away revealing bits of data, it doesn’t slow down applications.

Siguen siendo posible otros ataques, como la ejecución especulativa, así que no se puede utilizar este método en solitario.

To defend against speculative execution attacks, the team emphasizes that Oreo needs to be coupled with other security mechanisms (such as Spectre mitigations).