Parece que hoy en día la cuenta de usuario es la moneda (mínima) de cambio. Luego ya hablamos de como protegerlas, las contraseñas y otros artefactos y allí estamos. Es verdad que para muchas cosas sería necesario, pero parece que es inevitable y la gente de f-droid nos muestran que no es así.

En No user accounts, by design nos recuerdan que es posible proporcionar servicios sin este elemento, y que su decisión de diseño fue no hacer seguimiento de los usuarios, y evitar recopilar sus datos.

There are no user accounts used, ever, in the process of delivering apps to users. This is by design. F-Droid has never had a method to identify or track users in the Android client app, and getting information from f-droid.org has also never required any kind of identity information.

Tener una cuenta simplifica algunas cuestiones, como son los votos para conocer las mejores aplicaciones. Pero el precio que se paga es tener información del usuario fácilmente identificable (diría que sin cuentas, probablemente, también haya formas, pero no estamos hablando de eso aquí).

Having user accounts makes some problems much easier to solve: it makes it easy to include ratings and reviews and to manage editing of documentation. However, having user accounts makes other problems much more difficult to solve. User accounts inevitably mean that personally identifiable information (PII) will be collected and stored.

Pero, como decíamos, ¿son necesarias las cuentas para proporcionar un servicio? En f-droid creen que no.

It turns out that user accounts are rarely a requirement for building a service, even though many services make it seem that way.

Lo cierto es que hay algunas cosas que funcionan bien sin cuentas de usuario: el navegador (chrome, Google, atentos…), wikis, libretas compartidas y otros servicios.

It turns out that F-Droid is not alone in delivering key services without user accounts or profiles. There are browsers, wikis, shared notepads, video conferencing, and even messaging and analytics. Many systems that use accounts also allow reading and even editing without logging in.

Vale la pena leer y aprender de los que toman estos caminos, en un mundo donde el ‘dato’ parece que es tan importante.

A finales del año pasado se estuvo hablando de la Vulnerabilidad crítica en Apache Log4j. Rápidamente se le puso remedio, se empezó a discutir sobre el asunto (¿dependemos de programas que desarrolla gente en su tiempo libre o con pocos recursos? y otros temas relacionados), se actualizó quién pudo y allí seguimos.

en Log4j postmortem: Developers are taking a hard look at software supply-chain security gaps se hablaba del asunto con más calma y por eso lo traemos aquí.

El primer problema (y ya lo anunciábamos diciendo lo de quién pudo) es que no siempre es tan fácil actualizar los sistemas y eliminar las versiones vulnerables.

One of the most troublesome aspects of Log4j was not the vulnerability itself, but how deeply embedded the technology is in legacy code. After all, Java is one of the world’s most popular platforms, and Log4j is an incredibly popular Java logging system whose initial release dates all the way back to 2001. So Log4J touches not only a ton of production systems, but also a lot of legacy code.

Y no es que no haya voluntad; el problema es que, a veces, intentando arreglar algo estropeas otra cosa. Y ni siquiera puedes estar muy seguro de si lo hiciste bien.

“You don’t just need to fix a security vulnerability, you need to know that you fixed the vulnerability without breaking your system. When you have a vulnerability with a super popular logging library like Log4j, you are talking about dependencies on legacy code that typically lacks any testing, and where sometimes the developers who wrote the code and understand how it works don’t even work at the company anymore.”

Sin olvidar que cualquier reparación tiene que tener un análisis del coste/beneficio. En particular, cómo y a cuántos usuarios pueden afectar nuestras soluciones.

“There is a cost-benefit analysis that needs to take place on any security remediation. You have to determine the right interval to deploy the fix, which requires a complete understanding of the risk in terms of how many users it could affect, and the acceptable level of unreliability you can accept.”

Al final las aplicaciones modernas están construidas a partir de muchas piezas, que a lo mejor ni siquiera tenemos inventariadas.

“Modern applications are built from many components, many of which are not developed in-house but are rather assembled using ‘off the shelf’ solutions,” according to John France, CISO at (ISC)2. “A large part of qualifying and identifying issues is knowing what components and libraries are used by your software and keeping a software bill of materials (SBOM).”

Hasta ahora hemos sido muy laxos a la hora de tener en cuenta los riesgos que se asumen por utilizar este código de terceros.

“Developers in general have been very lax about tracking what they use in their software. When an event like this requires us to identify whether some library or component is used by our code, that lack of traceability becomes a major pain point. It turns a simple exercise of checking inventories and SBOMs into a complex scanning process, with many opportunities for false positives and false negatives. If we ever needed a wake-up call, we got a big one with Log4j.”

Tal vez este incidente sea la llamada que hacía falta para empezar a prestar atención.

En algunas ocasiones tenemos nuestras APIs en un dominio diferente del que utilizamos para nuestra web. Pero la web necesita acceder al API y eso significa que podríamos tener problemas con el acceso a los recursos.

Para situaciones como esta se define Cross-Origin Resource Sharing (CORS) y en Clarifying CORS - Cross-origin Resource Sharing nos ayudan a comprenderlo mejor.

Interesante.

A veces recomendamos demasiado alegremente que la gente registre un dominio para gestionar su ‘marca’ (personal o de empresa) y nos olvidamos de las consecuencias negativas que esto puede tener si no se tiene un poco de cuidado. Actualización (2022-11-19): casualmente veo este artículo argumentando a favor del uso de un dominio, Why everyone should register a domain name. Es de hace tiempo, pero muestra la idea.

Vale: utilizar una dirección de correo electrónico genérico puede parecer poco profesional, pero todavía es peor si no mantenemos el compromiso con el dominio que elijamos.

En Thousands of npm accounts use email addresses with expired domains nos cuentan el caso de un análisis de los paquetes npm y han descubierto que hay miles de desarrolladores de JavaScript que han utilizado dominios de correo que después han caducado para registrar sus cuentas en npm (Node Package Manager):

An academic research project found that thousands of JavaScript developers are using an email address with an expired domain for their npm accounts, leaving their projects exposed to easy hijacks.

De hecho, algunos de estos dominios estarían a la venta en algunos sitios.

Researchers said they found that 2,818 project maintainers were still using an email address for their accounts that had an expired domain, some of which they found on sale on sites like GoDaddy.

Esto es un problema porque alguien que lo descubra podría intentar hacerse pasar por el desarrollador en cuestión y, tal vez, conseguir algún objetivo peligroso.

The team argued that attackers could buy these domains, re-register the maintainer’s address on their own email servers, and then reset the maintainer’s account password and take over his npm packages.

Algunos paquetes, al instalarse, ejecutan scripts, muchos paquetes tienen un número importante de personas manteniéndolos y algunos lo que tienen son contribuidores. Sin olvidar las dependencias que existen entre unos paquetes y otros.

2.2% (33,249) of packages used install scripts, which could be abused to run malicious commands and is against npm best security practices;

The Top 1% packages (14,941) had an average of 32.4 maintainers per package, opening the door for attacks via the accounts of inactive or inattentive developers;

389 packages had 40 contributors for every maintainer, opening the door for the accidental insertion of security flaws or flooding a project with contributions to sneak in malicious code;

The top 1% maintainers own an average number of 180.3 packages with direct dependents of 4,010 average packages, meaning some developers could be overworked or not have time to thoroughly maintain or review package changes.

Al final, el problema se debe a una identificación débil de las personas: una dirección de correo. Pero mientras las cosas estén así debemos tener cuidado con los dominios y lo que hacemos con ellos, porque nos podemos llevar un disgusto. Con cualquiera de los activos digitales que hayamos registrado usando estos dominios.

Seguimos con la cadena de suministro. Recordatorio: se trata de atacar alguno de los elementos de los que depende nuestro proyecto, pero que están gestionados por otras personas (servicios, bibliotecas, …).

En How Hackers Compromise the Software Supply Chain hablan del tema.

If you consider all the components you need for your software, you have a pretty long chain, and those components have dependencies too. Any weak link can compromise the entire software supply chain, putting your business at risk.

¿Ocupación de nombres? Ya habíamos hablado de los paquetes que se llaman parecido a otros legítimos y que la gente termina instalando sin darse cuenta. Imaginemos ahora que un atacante descubre algún nombre de un proyecto que se aloja en un repositorio privado. ¿Podría registrar ese nombre en uno público y engañarnos?

If hackers find the name of one of the private repositories, they can register public repositories with the same name and upload their version of what is supposed to be an internal library.

En cualquier caso, es muy difícil evitar cualquier problema de este tipo que pueda aparecer. Los consejos: seguir una política muy estricta de proveedores, registrar repositorios públicos con los nombres de los privados, actualizar los programas (con sus propios riesgos), asegurar todos los ficheros de configuración, tener especial cuidado con las cuentas privilegiadas (si les engañan a ellos será peor), tener niveles de defensa y monitorización (vigilancia) y compartimentalizar. Nada muy nuevo, pero a veces lo olvidamos.

Have a stricter vendor policy. Don’t source from multiple private registries when you can use only one.

When you register a private repository, register a public repository with the same name to prevent typosquatting.

Keep all software up to date, even if the update process is now a risk too.

Secure all configuration files and never deploy them on production, or, at least restrict their access.

Be extremely careful with IT management interfaces. Privileged accounts with a super high level of access should be few.

Have several layers of defense and use monitoring tools such as SIEM or SOAR to detect suspicious behaviors early.

Segment your networks. Don’t let any breach at a low level expose the whole system.