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.

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

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