Un método sencillo de generación de números seudoaleatorios
Entre lo poco que escribimos aquí y que hacía ya algún tiempo que no nos encontrábamos una lectura interesante ha pasado tiempo desde la última vez que hablamos de generadores de números aleatorios.
En An RNG that runs in your brain [0] encontré un generador ‘sencillo’ e interesante. No sería válido para aspectos criptográficos y de seguridad, pero nos puede ayudar a comprender mejor el concepto. El proceso es:

Elegir un número de 2 cifras, por ejemplo 23, la ‘semilla’
"Elegir un número de 2 cifras, por ejemplo 23, la ‘semilla’"

Generar un nuevo número de dos cifras a partir del primero: a las decenas les sumamos 6 veces las unidades.
"Generar un nuevo número de dos cifras a partir del primero: a las decenas les sumamos 6 veces las unidades."

El resultado con nuestra semilla sería: 23 –> 20 –> 02 –> 12 –> 13 –> 19 –> 55 –> 35 –> …
"El resultado con nuestra semilla sería: 23 –> 20 –> 02 –> 12 –> 13 –> 19 –> 55 –> 35 –> …"

su periodo es el orden del multiplicador, 6, en el grupo de los residuos primos relativos al módulo, 10. (59 en este caso).
"su periodo es el orden del multiplicador, 6, en el grupo de los residuos primos relativos al módulo, 10. (59 en este caso)."

Los “dígitos aleatorios” son las cifras unidad de los números de dos cifras, esto es: 3,0,2,2,3,9,5,… la secuencia módulo 10.
"Los “dígitos aleatorios” son las cifras unidad de los números de dos cifras, esto es: 3,0,2,2,3,9,5,… la secuencia módulo 10."
La pregunta ahora es, ¿cómo de buenos son los números generados de esta forma?, y el autor nos muestra algo de la teoría (y algunas pruebas) que hay detrás del métido.
Y la siguiente, ¿con qué semillas y otras combinaciones de números funcionaría?
No vamos a entrar en ello, pero me gustó porque me parece un ejercicio sencillo (pero no trivial) de programación, que además nos ayuda a pensar un poco en los temas relacionados con la aleatoriedad en los sistemas informáticos.
[0] An RNG that runs in your brain
https://www.hillelwayne.com/post/randomness/

Las limitaciones de los analizadores de código para la seguridad
El análisis de una aplicación (web o no) para detectar problemas de seguridad es una tarea inexcusable que puede llevar una buena cantidad de tiempo. Hay herramientas pero, como siempre, llegan hasta donde llegan y eso puede ser un problema.
En The Blind Spots of Automated Web App Assessments [0] nos hablaban un poco de este asunto y de la importancia de la revisión manual.

This post illustrates the importance of manual code review when doing application security. Relying heavily on automated tools can give you some grim blind spots that pose a significant risk to the application.
"This post illustrates the importance of manual code review when doing application security. Relying heavily on automated tools can give you some grim blind spots that pose a significant risk to the application."
Para ello, seleccionan varios fallos habituales y ven cómo se comportan diversos analizadores. El problema fundamental que detecta es que los analalizadores no suelen ser capaces de determinar el contexto ni la lógica de negocio, con lo que algunos fallos pueden pasarse por alto.

The scanners simply can’t do this. All of these rules are application logic which is laws defined by the programmer. One application might have a friend invitation system where you actually are allowed to view other users profiles. Another is a private application where you are only supposed to see your own profile. How does the scanner distinguish between these rules that are man made on a project-to-project basis?
"The scanners simply can’t do this. All of these rules are application logic which is laws defined by the programmer. One application might have a friend invitation system where you actually are allowed to view other users profiles. Another is a private application where you are only supposed to see your own profile. How does the scanner distinguish between these rules that are man made on a project-to-project basis?"
Sin embargo, esto no es una llamada a dejar de usar ese tipo de herramientas, sino a ser conscientes de sus limitaciones.

We’re not here to tell you to stop using automated tools. They’re great for the job, but you should use them with an understanding of what might be missed if you don’t couple them with manual assessments by a vetted application security professional.
"We’re not here to tell you to stop using automated tools. They’re great for the job, but you should use them with an understanding of what might be missed if you don’t couple them with manual assessments by a vetted application security professional."
Interesante.
[0] The Blind Spots of Automated Web App Assessments
https://baldur.dk/blog/automated-web-assessment.html

Algunas ideas sobre problemas de seguridad habituales en WordPress
Soy un usuario bastante básico de WordPress: algún sitio de los que ofrecen gratis y alguno más de los que nos proporcionan en el trabajo para diversos asuntos. Pero los fallos de seguridad siempre son interesantes, porque casi siempre se pueden extraer conclusiones y enseñanzas para nuestro contexto. Incluso cuando no sea el mismo.
Por eso hoy traemos The Real Attack Vector Responsible for 60% of Hacked WordPress Sites in 2023 [0] donde se habla de los plugins desactualizados como punto principal de los ataques a sitios de WordPress.

A particularly pervasive one is the unsubstantiated claim that “95% of WordPress hacks are due to outdated plugins or themes.“
"A particularly pervasive one is the unsubstantiated claim that “95% of WordPress hacks are due to outdated plugins or themes.“"
Esencialmente, alguien contrata la realización de su web, se la hacen con esta tecnología y luego vienen los problemas: o no se contrata el mantenimiento, o éste es deficienten….
Luego entra en detalles sobre el tipo de problemas que suelen ocurrir:

Fallos en la autentificación


Authentication Compromise (stolen session cookies + compromised credentials) and
"Authentication Compromise (stolen session cookies + compromised credentials) and"
Los robos de cookies tienen que ver algunas veces con el acceso local con algún tipo de sistema de robo.
Los robos de usuarios y contraseñas se pueden producir de formas similares, y también son frecuentes.

Fallos en los plugins, los ‘temas’ y las funcionalidades básicas.


Plugin, Theme & Core vulnerabilities
"Plugin, Theme & Core vulnerabilities"
En este caso, cuando aparecen vulnerabilildades está bastante claro que después aparecerán los ataques.

Meaning, we can clearly tie the presence of a vulnerability to a potential exploit of the vulnerability.
"Meaning, we can clearly tie the presence of a vulnerability to a potential exploit of the vulnerability."
Los consejos: desconectarse del sitio cuando terminsmos, logout, para evitar el robo de sesiones, utilizar doble factor de autentificación, actualizarlo todo cuando toca…
[0] The Real Attack Vector Responsible for 60% of Hacked WordPress Sites in 2023
https://wewatchyourwebsite.com/the-real-attack-vector-responsible-for-60-of-hacked-wordpress-sites-in-2023/

Generación de paquetes Android, seguridad y tranquilidad
Siempre he pensado que en el mundo del sofware libre es difícil estar seguros de que estamos ejecutando el programa del que tenemos el código en dos situaciones: cuando instalamos un binario que alguien nos proporciona, o cuando utilizamos una aplicación web.
Si hablamos de teléfonos móviles y las tiendas de aplicaciones, en muchas ocasiones miro en F-Droid [0] antes de instalar una aplicación de la ‘tienda’ de Google. Es más fea y tiene menos programas, pero también nos da la tranquilidad (si nos instalamos programas con un historial razonable y gente confiable) de que estamos un poquito más cerca del desarrollador.
Por eso me gustó leer algunas novedades que anunciaron hace algunas semanas en Reproducible builds, signing keys, and binary repos [1].
Las construcciones reproducibles (reproducible builds) nos aportan garantías desde el punto de vista de poder verificar que lo que se instala corresponde, efectivamente, al código fuente asociado. A eso le han añadido la posibilidad de que el desarrollador firme los paquetes que instalamos, lo que nos protegería frente a un ataque malicioso que sustituyera algo en la plataforma.

A few advantages are pretty clear: higher trust is the first thing coming to mind, as now two parties (F-Droid and the developer) can both confirm the integrity of the distributed APK.
"A few advantages are pretty clear: higher trust is the first thing coming to mind, as now two parties (F-Droid and the developer) can both confirm the integrity of the distributed APK."
El artículo desarrolla un poco más algunos temas, pero dejamos a quien tenga interés su lectura.
[0] F-Droid
https://f-droid.org/
[1] Reproducible builds, signing keys, and binary repos
https://f-droid.org/en/2023/09/03/reproducible-builds-signing-keys-and-binary-repos.html

Las amenazas en los tiempos de la IA
Hace unos meses podíamos leer Staying ahead of threat actors in the age of AI [0] que me gustó porque nos da algunas pistas de algunos de los aspectos peligrosos de la inteligencia artificial, desde el punto de vista de la seguridad informática.
Proporcionan una lista de diversas organizaciones que aparecen frecuentemente en diversos ataques y los usos que han observado de la inteligencia artificial para estos fines.
No entraremos en esos detalles (aunque puede ser interesante echar un ojo) sino que nos centraremos en el final del artículo, donde se hace un resumen.

Reconocimiento (LLM-informed reconnaissance): esto es, obtener información sobre tecnologías y vulnerabilidades.
Mejora de los programas (LLM-enhanced scripting techniques): se pueden utilizar los modelos de lenguaje grandes para generar programas o mejorar los que ya tenemos.
Desarrollo asistido de programas (LLM-aided development:): parecido al anterior, pero ya integrado en el ciclo de vida de nuestros desarrollos.
Ingeniería social mejorada (LLM-supported social engineering): se puede usar para mejorar las traducciones y los mensajes que se utilizan para manipular a los objetivos.
Investigación de vulnerabilidades asistida (LLM-assisted vulnerability research): utilizar estos sistemas para comprender mejor las vulnerabilidades en los programas y en los sistemas.
Optimización del desarrollo de payloads (LLM-optimized payload crafting): seguimos con ideas parecidas, cuando necesitamos generar o mejorar algún trozo de código que utilizaremos en un ataque.
Evasión mejorada de los sistemas de detección de anomalías (LLM-enhanced anomaly detection evasion): ayuda para tratar de hacer pasar nuestros ataques dentro de la actividad normal de nuestro objetivo.
Saltar las características de seguridad (LLM-directed security feature bypass): ayuda en la búsqueda de formas de evitar los mecanismos de seguridad (doble factor, CAPTCHAS, …)
Recomendaciones en el desarrollo de recursos (LLM-advised resource development:): no sólo desarrollo de herramientas, sino también modificación e incluso planificación estratégica.

Interesante.
[0] Staying ahead of threat actors in the age of AI
https://www.microsoft.com/en-us/security/blog/2024/02/14/staying-ahead-of-threat-actors-in-the-age-of-ai/

Los protocolos de la web explicados
El protocolo HTTP (Hypertext Transfer Protocol) es el que proporciona las bases fundamentales para la web. A mi me parece bastante interesante saber cómo funciona (aunque sea a nivel generalista) para comprender un poco mejor la web y por eso me gustó leer HTTP/2 and HTTP/3 explained [0].
Conviene recordar que la web, tal y como la conocemos se basa en un lenguaje para escribir documentos (HTML), un protocolo de transmisión (HTTP) y en una arquitectura cliente (el navegador) servidor (el que nos proporciona la información cuando nos conectamos).
El protocolo ha pasado por varias versiones, desde la HTTP/0.9, que fue el primer borrador hasta el más moderno, la versión 3 del protocolo (que apareció en 2012) que todavía no es de uso mayoritario (ver, por ejemplo, el dato de Examining HTTP/3 usage one year on [1], que tiene datos del año pasado).
Hacia el final nos recuerdan que HTTP/3 nació para dar mejor servicio a las conexiones menos estables, como los teléfonos móviles.

HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. To counter network instabilities, QUIC has a great degree of independence between the data streams and good resilience if packets are lost.
"HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. To counter network instabilities, QUIC has a great degree of independence between the data streams and good resilience if packets are lost."
Así como las mejores prestaciones de la versión 2 del protocolo cuando las conexiones son estables.

On reliable and stable connections, HTTP/2 many times offers better performance than HTTP/3.
"On reliable and stable connections, HTTP/2 many times offers better performance than HTTP/3."
[0] HTTP/2 and HTTP/3 explained
https://alexandrehtrb.github.io/posts/2024/03/http2-and-http3-explained/
[1] Examining HTTP/3 usage one year on
https://blog.cloudflare.com/http3-usage-one-year-on

Los peligros del correo con HTML y CSS
Esta es una batalla perdida: yo mismo utilizo clientes de correo que lo interpretan y envío mensajes en HTML. Sin embargo, es bueno recordarlo, y de vez en cuando alguien lo hace. En Kobold letters. Why HTML emails are a risk to your organization [0] nos recordaban algunos aspectos relevantes.
Es un problema desde el punto de vista técnico, tanto de interpretación del mensaje, como desde el punto de vista de la seguridad, nos dice:

Anyone who has had to deal with HTML emails on a technical level has probably reached the point where they wanted to quit their job or just set fire to all the mail clients due to their inconsistent implementations. But HTML emails are not just a source of frustration, they can also be a serious security risk.
"Anyone who has had to deal with HTML emails on a technical level has probably reached the point where they wanted to quit their job or just set fire to all the mail clients due to their inconsistent implementations. But HTML emails are not just a source of frustration, they can also be a serious security risk."
En esta caso hablan de las llamadas Kobold letters que, esencialmente, tienen diferente aspecto cuando se reciben por primera vez; y cambian cuando son reenvíadas (forward).

The email your manager received and forwarded to you was something completely innocent, such as a potential customer asking a few questions. All that email was supposed to achieve was being forwarded to you. However, the moment the email appeared in your inbox, it changed.
"The email your manager received and forwarded to you was something completely innocent, such as a potential customer asking a few questions. All that email was supposed to achieve was being forwarded to you. However, the moment the email appeared in your inbox, it changed."
Esto se debe a la posibilidad de utilizar las hojas de estilo en cascada (CSS) y los cambios que se producen al reenviar un mensaje, que permiten activar reglas diferentes, que muestran alguna parte del mensaje que el receptor original no podía ver.

This attack is possible because most email clients allow CSS to be used to style HTML emails. When an email is forwarded, the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.
"This attack is possible because most email clients allow CSS to be used to style HTML emails. When an email is forwarded, the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded."
Desde el punto de vista del usuario no hay mucho que podamos hacer (algunos clientes permiten ver HTML básico, sin estilo, o podemos desactivarlo completamente, pero entonces habrá correos que no podremos leer completamente).
Según nos cuentan en la historia, los diversos clientes toman medidas contra esto, dentro de sus posibilidades.
[0] Kobold letters. Why HTML emails are a risk to your organization
https://lutrasecurity.com/en/articles/kobold-letters/

Operaciones modulares y sesgos en la aleatoriedad
El diablo está en los detalles y la realidad se empeña en mostrárnoslo (poco a poco, eso sí) continuamente. En este caso, The definitive guide to “Modulo Bias and how to avoid it”! [0] habla de lo que llaman sesgo del módulo (modulo bias), y sus consecuencias.
Como sabemos, nos dice, las operaciones modulares se utilizan ampliamente en criptografía, y también en informática en general.

The modulo operation is used a lot in Cryptography, since we are usually dealing with number theory and algebraic structures that rely on the modulo operation at their core. But it is also used more broadly in Computer Science. It is typically represented in code by the symbol % and it is a binary operator that will take two integers as input and give one integer as output.
"The modulo operation is used a lot in Cryptography, since we are usually dealing with number theory and algebraic structures that rely on the modulo operation at their core. But it is also used more broadly in Computer Science. It is typically represented in code by the symbol % and it is a binary operator that will take two integers as input and give one integer as output."
Pero el sesgo aparece cuando elegimos un número aleatorio y queremos obtener valores en un determinado rango. La causa es que típicamente utilizaremos un generador que proporciona números en otro rango diferente, y nosotros haremos la conversión. Pero si la cantidad de números de uno y otro rango no son compatibles (la grande es múltiplo de la pequeña), nos vamos a llevar un disgusto si medimos las frecuencias de los números generados: los primeros (el exceso de ese múltiplo) va a estar ligeramente sobre-representados.

The problem is basically the same as when you’re cutting a rope into smaller pieces of a given size: the last piece will most likely not be of the same size as the others, except if the initial length of your rope was perfectly divided by the length of the pieces.
"The problem is basically the same as when you’re cutting a rope into smaller pieces of a given size: the last piece will most likely not be of the same size as the others, except if the initial length of your rope was perfectly divided by the length of the pieces."
No parece un problema muy grave, nos dice, pero quién sabe por dónde pueden evolucionar las técnicas de criptoanálisis.

It is true in general that biases are “just” reducing the actual entropy of a randomly generated value and thus are not as dangerous as for the above schemes, but future cryptanalytic breakthroughs might exploit them. As such we definitively prefer to have uniformly distributed random values, plus they also usually allow us to really rely on the mathematical proofs of security, when we have one.
"It is true in general that biases are “just” reducing the actual entropy of a randomly generated value and thus are not as dangerous as for the above schemes, but future cryptanalytic breakthroughs might exploit them. As such we definitively prefer to have uniformly distributed random values, plus they also usually allow us to really rely on the mathematical proofs of security, when we have one."
¿Se puede remediar?
Existen varias formas, la primera sería descartar los valores que no pertenecen a nuestro rango a la hora de obtener números aleatorios.

Rejection sampling consists in sampling a random value and rejecting all values that do not fall into the right range.
"Rejection sampling consists in sampling a random value and rejecting all values that do not fall into the right range."
El problema de este método es que si la diferencia entre rangos es muy grande podemos añadir un coste extra a la obtención de valores. Se puede aliviar un poco truncando el número al tamaño adecuado, pero no resuelve el problema completamente.
Otra posibilidad es seguir usando el módulo, pero teniendo en cuenta las limitaciones señaladas: esencialmente se puede utilizar el módulo para un conjunto de valores ‘equilibrado’; esto es, los números del

final, que son los que nos provocarían las desigualdades pueden ser rechazados cuando salgan y calcular el módulo para el resto.

As we discussed earlier, if you are generating a value between 0 and 106, using one byte of randomness, then you can combine both rejection sampling and modulo reduction
"As we discussed earlier, if you are generating a value between 0 and 106, using one byte of randomness, then you can combine both rejection sampling and modulo reduction"
Siguen pudiendo aparecer problemas, sobre todo si el exceso de números con respecto a la operación modular es grande.
Me gustó mucho leerlo, y no era consciente del problema, la verdad.
[0] The definitive guide to “Modulo Bias and how to avoid it”!
https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/

Interesante visualización de contraseñas frecuentes
Hoy una entrada ligera y que no va a llamar la atención de nadie que venga por aquí habitualmente, salvo por la visualización. En Most Common Passwords [0] justamente eso.
Para ver, jugar, y -tal vez- concienciarnos un poco más.
[0] Most Common Passwords
https://informationisbeautiful.net/visualizations/top-500-passwords-visualized/

Los nombres son importantes en la nube
En How an empty S3 bucket can make your AWS bill explode [0] un (otro) recordatorio de la importancia de los nombres de las cosas.
En este caso, descubierto por casualidad: el autor habilita un entorno en la nube para una prueba de concepto de un cliente suyo, sube unos documentos y dos días después, cuando vuelve a mirarlo, se encuentra con una factura importante.
En un servicio que en teoría casi no había tenido uso:

A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files there for testing. Two days later, I checked my AWS billing page, primarily to make sure that what I was doing was well within the free-tier limits. Apparently, it wasn’t. My bill was over $1,300, with the billing console showing nearly 100,000,000 S3 PUT requests executed within just one day!
"A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files there for testing. Two days later, I checked my AWS billing page, primarily to make sure that what I was doing was well within the free-tier limits. Apparently, it wasn’t. My bill was over $1,300, with the billing console showing nearly 100,000,000 S3 PUT requests executed within just one day!"
¿El problema?
El nombre que había elegido para su recurso coincidía con uno que utiliza una conocida herramienta por defecto.

Was it some kind of DDoS-like attack against my account? Against AWS? As it turns out, one of the popular open-source tools had a default configuration to store their backups in S3. And, as a placeholder for a bucket name, they used… the same name that I used for my bucket.
"Was it some kind of DDoS-like attack against my account? Against AWS? As it turns out, one of the popular open-source tools had a default configuration to store their backups in S3. And, as a placeholder for a bucket name, they used… the same name that I used for my bucket."
Eso era un riesgo solo por los accesos de consultas, pero también podría ser un asunto de seguridad si se permite escribir, porque alguien lo hará y puede encontrarse con sus datos confidenciales por ahí.

I opened my bucket for public writes and collected over 10GB of data within less than 30 seconds. Of course, I can’t disclose whose data it was. But it left me amazed at how an innocent configuration oversight could lead to a dangerous data leak!
"I opened my bucket for public writes and collected over 10GB of data within less than 30 seconds. Of course, I can’t disclose whose data it was. But it left me amazed at how an innocent configuration oversight could lead to a dangerous data leak!"
Además del susto, algunos aprendizajes:

Si alguien conoce los nombres de nuestros recursos puede darnos un buen susto con la factura


Lesson 1: Anyone who knows the name of any of your S3 buckets can ramp up your AWS bill as they like.
"Lesson 1: Anyone who knows the name of any of your S3 buckets can ramp up your AWS bill as they like."

Siempre es una buena idea añadir un sufijo aleatorio a nuestros recursos para que sea más difícil que el nombre coincida con el que alguien pueda usar.


Lesson 2: Adding a random suffix to your bucket names can enhance security.
"Lesson 2: Adding a random suffix to your bucket names can enhance security."

Controlar desde dónde se puede acceder a los recursos, por lo menos.


Lesson 3: When executing a lot of requests to S3, make sure to explicitly specify the AWS region.
"Lesson 3: When executing a lot of requests to S3, make sure to explicitly specify the AWS region."
[0] How an empty S3 bucket can make your AWS bill explode
https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

Abuso de los comentarios en GitHub
La afirmación habitual de muchos desarrolladores, a veces, es: ¿quién usaría esto para hacer esto otro?. La respuesta de muchos atacantes es: vamos a ver qué podemos hacer con esta característica a la que no han prestado mucha atención.
En este caso hablamos de los comentarios de GitHub y cómo han sido utilizados para enviar malware GitHub comments abused to push malware via Microsoft repo URLs [0].
La clave está en que al enviar un comentario en GitHub es posible adjuntar un fichero (documentos, archivos, …) que se subirá al sitio que tienen previsto para ello y que tendrá una dirección web (URL) con el nombre del proyecto.

When leaving a comment, a GitHub user can attach a file (archives, documents, etc), which will be uploaded to GitHub’s CDN and associated with the related project using a unique URL in this format: ‘https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}.’
"When leaving a comment, a GitHub user can attach a file (archives, documents, etc), which will be uploaded to GitHub’s CDN and associated with the related project using a unique URL in this format: ‘https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}.’"
Pero el problema es que la URL no se genera después de publicar el comentario, sino que está disponible incluso cuando el comentario no ha sido ni siquiera guardado todavía.

Instead of generating the URL after a comment is posted, GitHub automatically generates the download link after you add the file to an unsaved comment, as shown below.
"Instead of generating the URL after a comment is posted, GitHub automatically generates the download link after you add the file to an unsaved comment, as shown below."
Se genera la URL, se almacena el fichero, incluso cuando no publiquemos el comentario.

Even if you decide not to post the comment or delete it after it is posted, the files are not deleted from GitHub’s CDN, and the download URLs continue to work forever.
"Even if you decide not to post the comment or delete it after it is posted, the files are not deleted from GitHub’s CDN, and the download URLs continue to work forever."
Y estas direcciones parece que son legítimas del proyecto, así que ahí tenemos una vía para distribuir cosas peligrosas.
¡Qué cosas!
[0] GitHub comments abused to push malware via Microsoft repo URLs
https://www.bleepingcomputer.com/news/security/github-comments-abused-to-push-malware-via-microsoft-repo-urls/

Factor múltiple de autentificación y algunos problemas
El consejo que damos normalmente en estos días cuando hablamos de la seguridad de las contraseñas es doble: utiliza un gestor de contraseñas y activa el doble factor de autentificación. Si sólo vas a aplicar una, mejor la segunda (aunque tiene sus propios inconvenientes, cuando los mensajes no llegan y alguna situación curiosa se puede dar…).
Como sabemos la autentificación con factor múltiple se basa en que el sistema en el que nos queremos identificar nos puede enviar algún tipo de reto (típicamente una segunda contraseña, un mensaje en alguna aplicación específica, o un mensaje en la misma aplicación pero en otro dispositivo…). Tiene la ventaja de que si adivinan nuestra contraseña podemos esperar que no tengan acceso al dispositivo donde recibiremos ese mensaje y, por lo tanto, la clave no les servirá de mucho.
En How MFA is falling short [0] hablan de este sistema y de algunos de los problemas que pueden aparecer.

Ingeniería Social.

Bastante frecuente, alguien intenta entrar en nuestra cuenta, se le solicita el factor y trata de engañarnos para que se lo demos.

MFA risk #1: social engineering
"MFA risk #1: social engineering"

What’s the easiest way to steal a user’s authentication factors? Just ask them nicely.
"What’s the easiest way to steal a user’s authentication factors? Just ask them nicely."

Robo de la sesión.

Este es un poco más técnico, pero es tan viejo, casi, como la web: robar las cookies que las plataformas envían para mantener nuestra información. Se hace, por ejemplo, a través de extensiones maliciosas del navegador.

MFA risk #2: session hijacking
"MFA risk #2: session hijacking"

Cookies have long been the way the internet has saved our browsing information and preferences; however, they also risk allowing threat actors to steal your credentials after login.
"Cookies have long been the way the internet has saved our browsing information and preferences; however, they also risk allowing threat actors to steal your credentials after login."

Interposición.

Se trata de interponer entre el sistema real y el usuario algún otro que puede obtener la información que vamos transmitiendo.

MFA risk #3: man-in-the-middle (MITM) attacks
"MFA risk #3: man-in-the-middle (MITM) attacks"

In MITM attacks, hackers create a fake network/server/webpage that intercepts user credentials when a user thinks they’re entering them into the legitimate destination.
"In MITM attacks, hackers create a fake network/server/webpage that intercepts user credentials when a user thinks they’re entering them into the legitimate destination."

Robo de la SIM

En este caso engañamos al proveedor de comunicaciones de la persona atacada: conseguimos un duplicado de la SIM, después de conseguir tanta información como sea posible, para que sea más sencillo el engaño.

MFA risk #4: SIM swapping
"MFA risk #4: SIM swapping"

They then contact the target’s phone carrier and impersonate them to receive a new SIM card. This allows the attacker to insert the SIM card into the mobile device of their choosing and effectively take over the target’s number.
"They then contact the target’s phone carrier and impersonate them to receive a new SIM card. This allows the attacker to insert the SIM card into the mobile device of their choosing and effectively take over the target’s number."

Hartazgo de notificaciones.

Si hacemos que al usuario le llegen tantas que está ya cansado y nervioso por el bombardeo es posible que baje la guardia y tengamos éxito.

MFA risk #5: MFA fatigue/bombing/flooding
"MFA risk #5: MFA fatigue/bombing/flooding"

The goal of an MFA bombing attack is to coerce the victim into confirming their identity via notification, which is almost always the second factor.
"The goal of an MFA bombing attack is to coerce the victim into confirming their identity via notification, which is almost always the second factor."
Después pasa a analizar algunas alternativas, y por donde podemos esperar que ev

olucionen las soluciones y recomienda, a día de hoy:

Formación de los usuarios
Utilización de un gestor de contraseñas
Prestar atención a los dispositivos (para que no estén comprometidos).
[0] How MFA is falling short
https://blog.1password.com/how-mfa-is-falling-short/

Cross-site scripting y OAuth… ¿problemas?
El Cross-site scripting, XSS (no conozco una buena traducción del término, ¿programación cruzada entre sitios?) es uno de los fallos de seguridad más habituales en la web. En Over 1 Million websites are at risk of sensitive information leakage - XSS is dead. Long live XSS [0] nos recuerdan cómo a lo largo del tiempo se han proporcionado soluciones para evitar el problema, es bien conocido y eso significa que muchos sitios están protegidos.

Throughout the years, many protection layers have been placed to detect XSS and prevent its exploitation. From an attacker’s perspective, these protections pose a real challenge. While XSS is still alive and kicking, it has become astronomically more difficult to exploit it successfully than before, which explains why we gradually see fewer instances of it in the wild.
"Throughout the years, many protection layers have been placed to detect XSS and prevent its exploitation. From an attacker’s perspective, these protections pose a real challenge. While XSS is still alive and kicking, it has become astronomically more difficult to exploit it successfully than before, which explains why we gradually see fewer instances of it in the wild."
Sin embargo, aparecen nuevas formas de ataque y eso nos impide poder estar tranquilos. En este caso se trata de una combinación entre el XSS y el sistema de autorización OAuth.

However, similar to many other cases in the cybersecurity ecosystem - sometimes new, seemingly unrelated developments can lead to the reincarnation of old and, at times, forgotten vulnerabilities. In this blog post, we demonstrate why this is exactly the case of XSS when smartly combined with a new emerging technology - OAuth.
"However, similar to many other cases in the cybersecurity ecosystem - sometimes new, seemingly unrelated developments can lead to the reincarnation of old and, at times, forgotten vulnerabilities. In this blog post, we demonstrate why this is exactly the case of XSS when smartly combined with a new emerging technology - OAuth."
El problema del XSS se basa en la inserción de código en JavaScript en el navegador del usuario. Este JavaScript tiene acceso a lo que hay disponible para ese navegador y se pueden conseguir ataques que roban credenciales, sesiones, ….

If you write HTML/JS code instead of the input, the browser will think that the code was generated by the backend and parse it as legitimate HTML/JS.
"If you write HTML/JS code instead of the input, the browser will think that the code was generated by the backend and parse it as legitimate HTML/JS."
Hay algunas técnicas para mitigar el problema como pueden ser: limpiar las entradas y codificar las salidas (Manual Input Sanitization and Output Encoding), utilizar entornos de programación modernos, que nos ayudan a manejar estos problemas (Using Modern Web Frameworks), parámetros como HTTP-Only, que evitan que los programitas peligrosos accedan a las cookies (HTTP-Only) y las políticas de seguridad de contenidos (CSP) que permiten especificar de dónde se pueden cargar determinados elementos peligrosos.
Después de esta introducción nos explican cómo encontraron un problema en hotjar [1], que es una herramienta de analítica web.
Descargan sus programas en JavaScript (porque tienen que estar disponibles para enviarlos al navegador), los analizan hasta encontrar algún problema, y enconctaron algún problema.
Sin embargo, el sitio estaba bien protegido contra estas cosas (con HTTP-Only) así que no era posible atacar directamente.
Y aquí entra en juego OAuth, gracias que hotjar utiliza login social mediante Google:

One of the features in Hotjar—and almost any other modern website today—is social login, which is based on OAuth (the open standard for authorization).
"One of the features in Hotjar—and almost any other modern website today—is social login, which is based on OAuth (the open standard for authorization)."
Esto significa que si pinchamos en la identificación con Google, el sitio confi

ará en lo que nos mande (si le hemos autorizado en el pasado) y por allí habrá códigos de autorización que estarán visibles para los programas en JavaScript.

In other words - the secret code, at the end of the OAuth flow, will be located in the URL - and that’s something that the javascript code can read.
"In other words - the secret code, at the end of the OAuth flow, will be located in the URL - and that’s something that the javascript code can read."
Por lo tanto, si enviamos una petición adecuadamente preparada en el proceso de autorización, cuando nos vuelva tendremos acceso a esos códigos.

With this method, the javascript code opens a new tab to Google, and Google automatically redirects the user back to https://insights.hotjar.com with the OAuth code in the URL:
"With this method, the javascript code opens a new tab to Google, and Google automatically redirects the user back to https://insights.hotjar.com with the OAuth code in the URL:"
A veces los fallos son muy sencillos, y otras veces muy complejos. Aquí estamos en un camino intermedio donde la comodidad de los usuarios (y de los gestores del sitio) junto con la obligada confianza (necesaria para que todo funcione) nos juegan una mala pasada.
En este momento el problema estaría resuelto en este proveedor, pero es fácil que haya muchos sitios donde todavía no sean ni siquiera conscientes del problema.
[0] Over 1 Million websites are at risk of sensitive information leakage - XSS is dead. Long live XSS
https://salt.security/blog/over-1-million-websites-are-at-risk-of-sensitive-information-leakage---xss-is-dead-long-live-xss
[1] hotjar
http://fernand0.github.io/xss-sigue-vivo/*hotjar*

Entrada a los programas, visibilidad y posibilidades de espiar
En Why you should use STDIN to read your program arguments [0] nos recordaban hace unas semanas que la lectura de parámetros para un programa es más segura si se hace desde la entrada estándar que desde variables de entorno o parámetros de la línea de órdenes.

STDIN is more secure than environment variables or command-line arguments
"STDIN is more secure than environment variables or command-line arguments"
Algunas razones son que los parámetros de la línea de órdenes son visibles cuando se ejecuta la instrucción ps, lo que significa que cualquier usuario local podría verlos y, por lo tanto, obtener información útil.

When you pass command-line arguments to a program, they are visible to anyone who can run the ps command. Allowing others to read arguments is a security risk if the arguments contain sensitive information like passwords or API keys.
"When you pass command-line arguments to a program, they are visible to anyone who can run the ps command. Allowing others to read arguments is a security risk if the arguments contain sensitive information like passwords or API keys."
Por otra parte, cuando hablamos de las variables de entorno también son accesibles para alguien que pueda ejecutar ps (ps eww <PID>), y además son visibles para el programa y, por lo tanto, cualquier parte de nuestra aplicación podría tener acceso a ellas.

Environment variables are also visible to anyone who can run the ps command. They are also globally visible to the program, so any arbitrary code in your application can extract the environment variables.
"Environment variables are also visible to anyone who can run the ps command. They are also globally visible to the program, so any arbitrary code in your application can extract the environment variables."
Sin embargo, si usamos STDIN, lo que hay allí no es visible para ps, y tampoco es visible de manera global para todo el programa.

STDIN is more secure because it is not visible to the ps command and is not globally visible to the program. Thus, only the parts of the program that explicitly read from STDIN can access this data.
"STDIN is more secure because it is not visible to the ps command and is not globally visible to the program. Thus, only the parts of the program that explicitly read from STDIN can access this data."
Luego da algún ejemplo sobre la forma de hacerlo en Go, y cómo integrarlo con otros mecanismos para guardar información.
[0] Why you should use STDIN to read your program arguments
https://victoronsoftware.com/posts/get-args-from-stdin/

Despliegue de URLs, interacción en Slack y sus riesgos
El desplegado de URLs (unfurling) tiene que ver con esas aplicaciones que cuando tienen una URL la descargan para mostrarnos una previsualización de la página. Se puede ver, por ejemplo, en redes sociales, pero en este caso nos hablan de Slack.
En The dangers of AI agents unfurling hyperlinks and what to do about it [0] nos hablan del problema que esto puede supone cuando, por ejemplo, cuando un chatbot puede recibir a través de este proceso datos y generar un ataque de inyeción de preguntas (prompt injection attack).

This becomes a threat in LLM (large language model) powered Chatbots and Slack Apps when untrusted data enters a chat, for instance via a prompt injection attack.
"This becomes a threat in LLM (large language model) powered Chatbots and Slack Apps when untrusted data enters a chat, for instance via a prompt injection attack."
Podría ocurrir, por ejemplo, que un atacante provocara el desplegado de enlaces que contengan parte de algun de las conversaciones de nuestro Slack. Al hacer la consulta este contenido terminaría en el registro de actividad (log) del servidor.

Now, during a prompt injection attack an attacker can cause rendering hyperlinks that contain past chat information in the URL (or other data that might be accessible), and Slack would send the data off to the third party server automatically.
"Now, during a prompt injection attack an attacker can cause rendering hyperlinks that contain past chat information in the URL (or other data that might be accessible), and Slack would send the data off to the third party server automatically."
La verdad es que parece un poco truculento, pero ya sabemos que el diablo está en los detalles.
[0] The dangers of AI agents unfurling hyperlinks and what to do about it
https://embracethered.com/blog/posts/2024/the-dangers-of-unfurling-and-what-you-can-do-about-it/

Cuidado con los secretos divulgados en las nubes
Un experimento curioso: se dejan credenciales de la API de AWS en diversos sitios y se espera a ver qué sucede, monitorizando la actividad.

In this research, I used AWS API credentials as canary tokens, strategically placing them in publicly accessible locations on the internet.
"In this research, I used AWS API credentials as canary tokens, strategically placing them in publicly accessible locations on the internet."
Los lugares elegidos fueron:

Servidores públicos de código (GitHub, Gitlab, itBucket, DockerHub)
Servicios públicos manejados por el atuor: servidores de FTP, web, blog
Servicios Saas: Pastebin, JSFiddle
Gestores de paquetes de código: NPMJS, PyPi
Almacenes de datos en la nube (Cloud Storage Buckets): AWS S3, GCP Google Cloud Storage

Los resultados dicen que los intentos más rápidos de ataque viniveron desde las credenciales depositadas en npmJs (menos de 60 segundos), Pypi (119 segundos) y GitHub (127 segundos). En Pastebin tardaron 50 minutos y en otros ya pasamos a más de un día.

Grab Quickness – I find it pretty amazing that some tokens were grabbed and used after a few seconds. The NPMJS token was grabbed in less than a minute which includes the overhead time of logging and detecting the access attempt. GitHub and Pypi were close behind with about 2 minutes until the access attempt.
"Grab Quickness – I find it pretty amazing that some tokens were grabbed and used after a few seconds. The NPMJS token was grabbed in less than a minute which includes the overhead time of logging and detecting the access attempt. GitHub and Pypi were close behind with about 2 minutes until the access attempt."
La otra sorpresa es que no hubo ningún acceso en los servicios BitBucket y GitLab.

No access attempts on BitBucket and GitLab. Going into this I was sure the tokens on these services will be grabbed pretty quickly, probably not as fast as on GitHub, but still, I didn’t’ expect 0 hits. I’m still not sure the reason for this, perhaps it’s due to them being less popular or maybe it is harder to scrape them automatically.
"No access attempts on BitBucket and GitLab. Going into this I was sure the tokens on these services will be grabbed pretty quickly, probably not as fast as on GitHub, but still, I didn’t’ expect 0 hits. I’m still not sure the reason for this, perhaps it’s due to them being less popular or maybe it is harder to scrape them automatically."
Espeluznante.

La seguridad de esos servicios que utiliza y conoce poca gente
A veces la seguridad se basa en que el servicio es oscuro y utilizado por poca gente, y a la pregunta de ‘¿quién podría intentar atacar esto?’ la respuesta es, efectivamente, ‘nadie’. Pero en algunas ocasiones esta respuesta se transforma en ‘casi nadie’ y eso puede ser un problema.
De un caso de estos nos hablaban en Bypassing airport security via SQL injection [0] donde Ian Carroll y Sam Curry descubren que los sistemas que permiten aligerar el control para algunos de los usuarios más habituales de los aeropuertos (tripulaciones, fundamentalmente) utilizar mecanismos para ahorrarse las verificaciones que sufrimos el resto de los mortales.
El caso es que esto depende de un sistema que la TSA (Transportation Security Agency) subcontrata a otra empresa que no le pone el cariño suficiente a estas cosas y los investigadores descubren que tiene un API que no se preocupa de cosas tan básicas como las comillas en una petición de datos. Tirando del hilo, encuentran la forma de manipular los datos y algunas otros problemas más.

We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue.
"We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue."
[0] Bypassing airport security via SQL injection
https://ian.sh/tsa