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).

De vez en cuando hablamos de estos ataques a través de estos canales laterales donde uno puede estar perfectamente tranquilo, en un entorno controlado y aún así poder ser espiado. En este caso se trata de Si usas auriculares por cable, eres vulnerable: son todo un caramelo para los hackers y la idea es que el cable podría hacer de antena para retransmitir información delicada.

Periscope es el nuevo sistema de espionaje mediante radiación electromagnética desarrollado en laboratorio, con el fin de probar que los dispositivos que estén conectados a este tipo de auricular son vulnerables.

Uno podría pensar en un problema en el caso de los auriculares inalámbricos pero… ¿también con cable?

La señal no es muy buena, pero eso no es un impedimento para conseguir algo.

Estas señales son imperfectas, pero pueden limpiarse de ruido y distorsión mediante ordenador. Se logró una reconstrucción completa del audio con un 7,44% de error, haciendo que el audio fuese inteligible tanto por humanos como por inteligencia artificial.

Más detales en [PDF] Eavesdropping on Black-box Mobile Devices via Audio Amplifier’s EMR

Para sopresa de nadie la pregunta surge de manera inmediata: Is Your AI-Generated Code Really Secure? y la respuesta también lo parece: si los ejemplos de los libros, los foros, y casi todo lo que hay disponible es inseguro, en general, será difícil que nada que se entrene con ello lo sea (por lo menos de momento).

A research done by academia claims that AI code generation is the leading cause for top 10 vulnerabilities and nearly 40% of code has security bugs.

El entrenamiento:

But, AI models are trained on every bit of information available on the internet. The code quality, reliability, security, and more might differ from that which is generated by human developers. A model trained on web development examples may contain poor data validation practices, for instance.

Y luego nos detallan algunos fallos comunes.

• Inferencia de tipos y validación de entradas El entrenamiento:

But, AI models are trained on every bit of information available on the internet. The code quality, reliability, security, and more might differ from that which is generated by human developers. A model trained on web development examples may contain poor data validation practices, for instance.

Y luego nos detallan algunos fallos comunes.

• Inferencia de tipos y validación de entradas.

1. Type Inference and Input Validations are Not Enforced

• Contexto y estados compartidos de forma no estándar entre clases y objetos.

1. Non-Standard State and Context Sharing Between Classes/Objects

• Implementaciones malas para el manejo de datos y técnicas para compartir.

1. Weak Implementation of Data Handling and Sharing Techniques

• Gestión inadecuada de la autorización y la gestión de secretos.

1. Inadequate Secrets and Auth Handling

• Dependencias desactualizadas con uso de funcionalidades obsoletas

1. Outdated Dependencies with Deprecated Functionality Usage

Los consejos para mejorar esta situación serían:

• Revisión del código por gente especializada (¡como con los humanos!)

Code review with security and architecture teams should be a standard part of your life cycle.

• Integración de las pruebas de seguridad y validación en las herramientas de control de versiones.

Integrate automated security testing and validation steps in version control tools.

• Inclusión de comprobaciones de cumplimiento y dependencias en los indicardores.

Include dependency and compliance checks in testing KPIs.

• Adopción de arquitecturas sin confianza (zero trust) y herramientas de seguridad dinámicas.

Adopt Zero-Trust architecture with static and dynamic security testing tools.

• Aprovechar las prácticas DevSecOps Y la IA en la sombra.

Leverage DevSecOps practices and shadow AI.

Aprovechar los sistemas automáticos (en este caso recomiendan Github Actions) para pasar las pruebas que se consideren oportunas sobre el código.

Handling Unsafe AI-Generated Code with a Simple Github Action

A veces nos ponemos con una herramienta a realizar algún proyectito y cuando nos damos cuenta hemos invertido tantas horas que tal vez nos habría ido mejor utilizar alguna otra aproximación. Esto tiene que ver con las herramientas no code, de lo que va este artículo, pero podría aplicarse perfectamente a los auténticos monstruos que algunas personas construyen con las IAs y su vibe coding.

En Code is the new no-code nos provocan un poco con estas ideas.

La mayoría de la gente no sabe programar, así que tiene mucho sentido proporcionarles algún tipo de herramienta que les permita hacer sus programas sin saber.

A promised third option was that you could just drag-and-drop some blocks, connect a few nodes, and voilà — you’ve built a fully functional app without writing a single line of code!

Los problemas de esta aproximación son varios:

• Empezar es sencillo, pero cuando queremos ir más allá la cosa se complica.

You start with a simple workflow, add a few conditions, and suddenly you’re staring at a tangled spider web that even you, its creator, can’t understand.

• Llegaremos a un momento en que nos encontraremos con los detalles técnicos: las herramientas los esconden hasta que ya no es posible hacerlo más.

No-code tools hide complexity until they don’t. Then you’re stuck googling technical concepts you were promised you’d never need to learn.

• Terminamos descubriendo que lo que queremos sería posible con estructuras simples de programación.

Nearly every power user of no-code tools eventually hits the wall and thinks, “I wish I could just write a simple if statement here!”

Con la llegada de los modelos gigantes del lenguaje (Large Language Models, LLMs) todo se ha puesto más interesante: pueden generar código y (si les preguntamos) explicarlo.

AI got really, really good at writing and explaining code.

Ya no es necesario entender cada línea y lo que obtenemos puede ser más fácil de leer que esos grafos complejos que construimos con las herramientas no code, con la ventaja de que podemos ‘rellenar los huecos’ y probar simplemente escribiendo instrucciones.

Notice how readable this is compared to a visual flow with dozens of connected nodes. And if you want to add a condition? Just add an if statement.

Esto ha rebajado mucho la barrera de entrada y ya podemos hablar de programación dirigida por preguntas.

This brings us to this new phenomenon what’s commonly known as Vibe Coding or what refers to as Prompt-Driven Development as its more sophisticated cousin..

El proceso se convierte en

1. Describir lo que queremos
2. Comprender el código que se nos sugiere
3. Hacer pequeños ajustes y preguntas
4. Absorber conceptos de programación poco a poco.

Esta aproximación sería más sostenible, según el autor, porque nos moveremos todo el tiempo en un contexto más manejable, aprenderemos y no tendremos las restricciones que tiene una plataforma definida por otros.

You’re working with a medium (text) that scales infinitely better than visual nodes

You’re learning transferable skills that work across platforms and tools

You’re not constrained by what the no-code platform creators thought you might need

También nos habla de que el resultado que se obtiene de esta forma es más fácil de leer, autodocumentado, adaptable y trasnferible.

Yo no termino de estar de acuerdo porque creo que se dan dos fenómenos que afectan a toda esta ‘bondad’.

• Somos perezosos: este tipo de programación se presta a verificar que funciona y darlo por bueno
• La ignorancia es atrevida, lo que nos puede llevar a aceptar cosas sin ni siquiera ser conscientes de loque estamos haciendo.

No se me entienda mal, creo que lo que dice es una aproximación bastante buena y correcta, pero luego llegamos nosotros y tomamos los atajos.

Además las IAs no tienen ningún inconveniente en repetir cosas, añadir complejidad, …

Luego nos recomienda un proyecto, que no he probado pero que puede ser interesante.