Estamos viendo ataques que no habíamos visto nunca. En este caso, el desarrollador de un proyecto lo boicotea para llamar la atención o mostrar su enfado por el estado de las cosas: Dev corrupts NPM libs ‘colors’ and ‘faker’ breaking thousands of apps

Los usuarios de bibliotecas populares, como ‘colors’ y ‘faker’ descubrieron de manera desagradable que alguien las había cambiado y sus programas empezaban a mostrar cosas diferentes de lo esperado:

Users of popular open-source libraries ‘colors’ and ‘faker’ were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.

Algo simple, como introducir un bucle infinito:

The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on ‘colors’ and ‘faker.’

Mostraban basura, y diversos mensajes.

… were left stunned on seeing their applications print gibberish messages on their console.

Había una componente revindicativa y de protesta, frente a todas esas empresas que utilizan los programas de software libre sin contribuir.

The reason behind this mischief on the developer’s part appears to be retaliation-against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.

La cuestión, claro, es que el software libre funciona así: se publica y lo usa quien quiere (y para lo que quiere) así que igual este desarrollador se equivocó en la forma de distribuir su trabajo.

“If you have problems with business using your free code for free, don’t publish free code. By sabotaging your own widely used stuff, you hurt not only big business but anyone using it. This trains people not to update, ‘coz stuff might break.”

Hay una componente que siempre veremos cuando utilizamos servicios de tercero y es que GitHub le suspendió la cuenta:

GitHub has reportedly suspended the developer’s account.

Lo que provoca la paradoja de dejar al desarrollador sin acceso a su propio proyecto. Y a preguntarnos si estamos siguiendo el camino correcto.

“Removing your own code from [GitHub] is a violation of their Terms of Service? WTF? This is a kidnapping. We need to start decentralizing the hosting of free software source code,…

Todo esto tiene algo de relación con el problema de log4j y los problemas que causó en un montón de proyectos que, por supuesto, sólo se quejaban cuando la cosa iba mal.

But, shortly after mass-exploitation of the Log4shell vulnerability, the maintainers of the open-source library worked without compensation over the holidays to patch the project, …

Un debate que probablemente haya hecho pensar a mucha gente sobre estos temas.

El consejo que siempre le damos a los usuarios es actualizar sus sistemas, para parchear los fallos de seguridad. Típicamente, un sistema actualizado es mucho más robusto frente ataques (inmune no, claro) que uno sin actualizar.

Cuando vamos al entorno coroporativo, eso no siempre es fácil ni posible. Y entonces hacen falta otras estrategias (compartimentalizar, aislar, …). En Patching is security industry’s ‘thoughts and prayers’: ex-NSA man Aitel hablan del tema y afirman que parchear es inútil.

Aitel pointed out that if there were vulnerable devices on a network, then they should be removed and substituted with others, rather than being continuously patched.

De hecho, recomendaba a sus clientes incluir claúsulas permitiendo rescindir los contratos en caso de que se demostrara que los programas tenían muchos fallos.

Aitel said many of his customers had been big financial firms and he had advised that any contracts they signed with software vendors also contain a clause that would enable them to walk out of contracts if any software proved to be overly buggy.

Y, según él, el problema tendría que ver con la (mala) calidad de los programas.

He had harsh words for Microsoft and other big software vendors whom he said had done little to actually mitigate the problems posed by poor-quality software. He also criticised PHP for its numerous security problems.

Finalmente habla de que los gobiernos deberían tomar cartas en este asunto, porque el resto no tendrían capacidad para resolver este tipo de problemas.

Aitel called for vulnerability management, advocating the government as the best entity to handle this. His argument was that no other entity had sufficient power to push back against the lobby of the big software vendors and the security industry.

Bruce Schneier es otro de los que hablan de que las empresas no tienen capacidad para atacar estos problemas, por ejemplo en It’s the Economy, Stupid.

A veces las APIs (estoy pensando que existe una analogíca ‘clásica’ con los gestores de bases de datos) no nos proporcionan suficiente granularidad a la hora de gestionar los activos digitales (en los gestores de bases de datos suele haber la granularidad, pero no siempre querremos dedicar tiempo a configurar nuestros programas y, además, los permisos de las bases de datos; seguramente un error, pero es lo que se hace a veces).

Sobre este tema y cómo lo gestionaron en su caso nos habla ‘Statgirl Flowers’ en Building a stateless API proxy:

It turns out GitHub’s API has extremely coarse access control on API tokens. For example, imagine if you wanted to write an editor plug-in to turn your Gists into easily-accessible snippets in your editor. People would have to grant your plug-in write access even though it only really needs read access. There’s a big Dear GitHub post on the subject, but this is not uncommon - many APIs have permissions systems that don’t quite always fit the needs of users.

La solución pasa por crear un proxy donde se gestionan los permisos y qué cosas pueden hacer unos programas y otros no.

So what I really want is a token that can read but not write gists. The proxy can issue its own token. It can keep track of the fact that the token is only allowed to read Gists and not write them. When it gets a request for the GitHub API it can check permissions before forwarding the request and the real token to GitHub.

Curioso.

Estoy convencido de que la mayoría de los desarrolladores quieren que su código sea seguro. El problema es que, además, quieren cumplir plazos, sus jefes quieren mantener los costes contenidos, …. y eso lleva a que la seguridad no sea una prioridad.

En 86% of developers don’t prioritize application security nos lo confirmaban. En una encuesta de Secure Code Warrior, el 86% de los desarrolladores no consideraban la seguridad una prioridad de primer nivel.

While many developers acknowledge the importance of applying a security-led approach in the software development lifecycle, 86% do not view application security as a top priority when writing code.

No sólo eso, sino que solamente un 29% de ellos creen que esto debería ser una prioridad.

This is a contributing factor to another major finding – that only 29% of developers believe the active practice of writing code free of vulnerabilities should be prioritized.

Entre los aspectos que deberían ayudar, como no, la formación:

Training remains a major influence over developers’ application of secure coding as 81% are utilizing the knowledge gleaned from training on a near-daily basis.

Las responsabilidades de que esto no se considere una prioridad: cumplir los plazos, desconocimiento, falta de formación al respecto y, finalmente, los fallos que introducen otros.

36% attribute the priority of meeting deadlines as a primary reason their coding still possesses vulnerabilities

33% don’t know what makes their code vulnerable

30% feel that their in-house security training could most be improved if it had more practical training with real world scenarios and outcomes

30% say the biggest concern with the implementation and practice of secure coding is dealing with vulnerabilities introduced by co-workers

Le vamos dedicando más atención a las APIs (esos sistemas que nos permiten ofrecer la funcionalidad de nuestro sitio a otros -o a nuestros propios desarrolladores- más allá de la que sea nuestra aplicación principal -si es que eso existe-).

En Secure APIs in ASP.NET una serie de recomendaciones para este lenguaje (poco nombrado, aunque con su cuota de uso) pero, como casi siempre, con uso en muchos otros casos.

Las recomendaciones:

Validar que la petición es correcta, esto es: formato adecuado, tamaño adecuado, contenido adecuado…

The first step in the model is to validate that the incoming request is valid HTTP, with the correct format and a reasonable size. Otherwise, it should be rejected as early as possible before reaching our application code.

Validar los tokens, que sería una forma de validar las peticiones, pero refiriéndose a la parte de identificación, autentificación, autorización… Siempre, con el modelo de aceptar lo que es correcto, esto es: hacer obligatoria la autorización.

An essential part of step 2 is that we make authorization mandatory. The policy lines in the code above ensure that the default behavior requires an authenticated request. Security should never be opt-in. Instead, you opt out when needed.

Transformar los tokens de acceso en permisos: a una autentificación correcta, y ante cualquier intento de realizar acciones hay que estar seguros de que esa autorización permite realizar la acción solicitada.

Before moving to step 4, we want to emphasize the importance of striking the right balance between what the token contains and the permissions we need for access control.

Validar los datos de la petición: los parámetros son los que tienen que ser, de los tipos adecuados, … Así evitaremos que a través de los parámetros puedan entrar inyecciones peligrosas de datos.

For the endpoint in our controller, we have one parameter: the product identifier. In our case, the identifier is not an arbitrary string of any size! It can contain only letters and digits and be ten characters or less. If the input string does not follow those rules, we can immediately return a 400 Bad Request. This input validation will make injection attacks a lot harder.

Validar los permisos para realizar la operación. Si una petición no viene con la solicitud adecuada de permisos (de acuerdo a nuestro sistema interno, claro), no permitiremos la acción.

We base the permission to perform an operation on the transformed permissions in our domain code and not directly with scopes and user identity.

Finalmente, validar los permisos para acceder a los datos: una vez que los permisos son correctos, están adecuadamente incluidos, tenemos que validar en nuestra aplicación que esos datos se pueden proporcionar de acuerdo a la política que tengamos definida.

The final step is to validate access to the actual data that the request will read or modify. Sometimes we can validate access by looking at the request, and other times we need to retrieve the data before deciding.

Viene con ejemplos en el lenguaje y más comentarios interesantes.