No será la primera vez que hablamos de contraseñas y de las políticas que se definen para ‘mejorarlas’. Ya sabemos que muchas de estas políticas son contraproducentes por varios motivos:

• Reducen el tamaño de búsqueda de las claves (a pesar de aumentar la diversidad).
• Hacen que los usuarios elijan contraseñas peores.

Pero, aún así, parece que hay que repetirlo de vez en cuando. Por eso me gustó leer How some of the world’s most brilliant computer scientists got password policies so wrong.

Nos dice que las reglas nacieron hace un montón de años, con buena intención y dictadas por gente muy inteligente:

The story of why password rules were recommended and enforced without scientific evidence since their invention in 1979 is a story of brilliant people, at the very top of their field, whose well-intentioned recommendations led to decades of ignorance. These mistakes are worth studying, in part, because the people making them were so damn brilliant and the consequences were so long lasting.

Ya en el año 1979 hacían análisis de las contraseñas y descubrían que no eran de muy buena calidad.

They discovered that 2,339 (71%) were either six or fewer characters of the same type (lower-case, upper-case, or digits) or 3 characters of mixed types. They found an additional 492 of the remainder (15% of all the passwords) were available in “dictionaries, name lists, and the like.”

Y, claro, diseñaron una política de contraseñas para mejorarlas.

They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong.

La lectura es muy agradable y vale la pena ver la historia (y cómo algunas organizaciones permanecen ancladas en esas ideas obsoletas) y quedarse con la conclusión. Más aún cuando no ha sido hasta fechas relativamente recientes que se ha abordado el problema con más seriedad y los descubrimientos son claros, y los consejos también.

As a result of Morris and Thompson’s recommendations, and those who believed their assumptions without evidence, it was not until well into the 21st century that the scientific community learned just how ineffective password policies were. This period of ignorance finally came to an end, in part, because hackers started stealing password databases from large websites and publishing them.

El ingenio humano es infinito. Y se puede usar para el mal. En Hackers now use ZIP file concatenation to evade detection nos cuentan un truco que se basa en la utilización de varios ficheros ZIP (el formato permite utilizar varios para facilitar el envío de cantidades grandes de información). El problema es que el resultado parece un fichero ZIP normal pero contiene algo mucho más complicado (por ejemplo, otros datos en formato ZIP, que pueden ser pasados por alto por algunas soluciones de análisis).

Siempre se había dicho que había que tener cuidado con lo que había en la definición de los sitios donde nuestro sistema busca los ejecutables por defecto (el PATH). La cuestión es que la superficie de exposición y dónde puede haber elementos peligrosos se va ampliando con el tiempo. En This New Supply Chain Attack Technique Can Trojanize All Your CLI Commands nos dan idea sobre elllo.

Primero nos habla de los ‘puntos de entrada’ (entry points) que es un mecanismo que permite que algunas funcionalidades estén disponibles a través de la línea de instrucciones sin necesidad de que el usuario conozca la estructura de un paquete; esto es, no sólo tenemos una biblioteca (librería) o un programa, sino que podemos tener otras formas de ejecutar algunas partes que puedan ser interesantes por algún motivo.

Entry points are a powerful feature of the packaging system that allows developers to expose specific functionality as a cli command without requiring users to know the exact import path or structure of the package.

¿El truco? Los malos pueden insertar en paquetes de apariencia normal sustitutos de algunas instrucciones habituales y utilizar estos puntos de entrada para ejecutar sus programas.

Malicious packages can use entry points to masquerade as widely-used third-party tools. This tactic is particularly effective against developers who frequently use these tools in their workflows.

En casos como estos podría ser bastante fácil darse cuenta de que algo va mal, así que una solución puede ser utilizar el nombre para hacer un programa que tiene el efecto esperado, además de los efectos maliciosos.

In addition to silently executing the attacker’s malicious code, it calls the original, legitimate command with all the user’s arguments.

La clave aquí (y la dificultad) es que el usuario ejecutará una instrucción, recibirá el resultado esperado y puede que a la vez esté sufriendo algún tipo de ataque (robo, borrado, ejecución de otras cosas,…).

Otro motivo para tener mucho cuidado con lo que se instala, dónde y cómo lo ejecutamos.

En File hosting services misused for identity phishing hablan del uso de los sitios de alojamiento de ficheros para realizar ataques: se comprometen las credenciales (o algún sistema de acceso) de un usuario, se sube un fichero al servicio y se comparte con la organización objetivo del ataque. El ataque tiene éxito porque la gente confía en estos servicios de alojamiento (estamos acostumbrados a usarlos, recibir compartidos, …)

The attack typically begins with the compromise of a user within a trusted vendor. After compromising the trusted vendor, the threat actor hosts a file on the vendor’s file hosting service, which is then shared with a target organization. This misuse of legitimate file hosting services is particularly effective because recipients are more likely to trust emails from known vendors, allowing threat actors to bypass security measures and compromise identities

Una vez que se ha compartido el fichero el servicio enviará un enlace a las víctimas. No es un mensaje falso, sino uno de los que generan este tipo de servicios habitualemente.

Once the threat actor shares the files on the file hosting service with the intended users, the file hosting service sends the target user an automated email notification with a link to access the file securely.

Cuando el usuario accede al enlace se le pide que se identifique (con posible uso de medidas adicionales de seguridad del servicio)

When the targeted user accesses the shared file, the user is prompted to verify their identity by providing their email address:

Finalmente, el usuario puede ver el documento que, típicamente, invita a pinchar en algún enlace (ahora ya sí, malicioso)

the user is successfully authorized and can view a document, often masquerading as a preview, with a malicious link, which is another lure to make the targeted user click the “View my message” access link.

Ahora este enlace redirige al usuario a una página de phishing que emula el procedimiento de acceso habitual y allí ya le roban sus credenciales.

This link redirects the user to an adversary-in-the-middle (AiTM) phishing page, where the user is prompted to provide the password and complete multifactor authentication (MFA). The compromised token can then be leveraged by the threat actor to perform the second stage BEC attack and continue the campaign.

Estamos tan acostumbrados a identificarnos, reidentificarnos y volvernos a identificar en estas plataformas con este tipo de flujos de trabajo que, aparentemente, los usuarios caen sin darle muchas vueltas.

Atención.

La polución de parámetros HTTP tiene una larga historia y Mahmoud M. Awali hace un repaso sobre cómo gestionan las peticiones diferentes tecnologías de las que se utilizan hoy en día en aplicaciones web. En HTTP Parameter Pollution in 2024 !.o

Comienza con los delimitadores (fundamentalmente & y ;), pero luego añadió otras comprobaciones.