Las URLs y los programas de escritorio. Otro problema de seguridad.

Nasas Si nuestra aplicación tiene que procesar datos de los usuarios, tenemos un problema: tradicionalmente ha sido una vía de ataque que ha tenido muchos éxitos.

En Allow arbitrary URLs, expect arbitrary code execution nos cuentan el caso de vulnerabilidades en aplicaciones de escritorio por no validar suficientemente los datos de entrada, que son interpretados como URLs y manejados por el sistema operativo.

In this post, we show code execution vulnerabilities in numerous desktop applications, all with the same root cause: insufficient validation of user input that is later treated as a URL and opened with the help of the operating system.

Esto puede llevarnos a ejecución de código, fundamentalmente por dos caminos: atacar el comportamiento del sistema operativo ante determinados esquemas y extensiones de ficheros; y explotando vulnerabilidades de aplicaciones de terceros que gestionan algunas de estas peticiones.

Con estas premisas en el artículo se hace un repaso de varios fallos de seguridad en el manejo de estas URLs, en aplicaciones como el cliente de Nexcloud, Telegram, VLC y otras aplicaciones.

Termina con algunos consejos para los desarrolladores, tanto de sistemas operativos (no montar directorios remotos, por ejemplo), entornos y aplicaciones (validar las URLs, y ser cuidadosos cuando registremos nuestra aplicación como gestor de URLs o extensiones).

Interesante.

Estás desarrollando tu propia criptografía. Y (¿no?) lo sabes.

Enigma Uno de los consejos que siempre se da con respecto a la criptografía es no meterse en ese negociado sin experiencia (“don’t roll your own crypto”).

De este tema se habla en Actually, You Are Rolling Your Own Crypto.

Así que solemos preocuparnos por los algoritmos y, sin embargo, lo cierto es que solo son una parte del tema. Luego hay que tener en cuenta más aspectos, que podrían tener consecuencias nefastas.

What they might not realize is that the algorithms themselves are the first in a series of traps, each of which can have catastrophic effects on the outcomes of cryptography use.

La elección de los algoritmos, su uso y su inclusión en otros procesos (protocolos) también tienen sus dificultades.

Algorithm selection, algorithm use, and protocol creation are all potential pitfalls that await once you’ve decided not to create your own algorithm.

En cuanto a la selección de algoritmos, podemos empezar por la diferencia entre criptografía simétrica y asimétrica, y dentro de ellas las distintas opciones disponibles.

There are a massive number of existing algorithms that do a wide range of things. The encryption space, for example, can first be broken down into symmetric and asymmetric. Each of those categories has a number of usable algorithms, and many of those algorithms have some other number of usable modes.

No sólo eso, no hay que olvidar que esos algoritmos pueden quedarse obsoletos con el tiempo (y por eso no comentaremos nada aquí sobre ellos).

En cuanto al uso, comenta que hay que tener cuidado con las opciones, como se inicializan… sin olvidar que hay que tener en cuenta nuestro contexto y luego elegir las implementaciones.

So you’ve chosen a secure algorithm in a secure mode that fits your operational environment. Now you need an implementation, no problem!…

Y ahora, hay que usarlos dentro de un proceso que permite algún tipo de comunicación segura: un protocolo. Es posible que no haya ninguno que se adapte bien a nuestro caso y entonces comienzan nuestros problemas.

your crypto is probably going to be deployed inside a protocol scheme that enables secure communication. When it comes to protocols, there is rarely an off-the-shelf solution. As a result, developers are often forced to implement their own protocols, even though they understand it is risky.

Muchas veces serán modificaciones de otros conocidos, pero que necesitamos adaptar a nuestras necesidades. Y aquí podríamos estar introduciendo debilidades, o suponiendo propiedades que no se cumplirán en el nuevo contexto.

They frequently need to be modified to meet the constraints of a particular operating environment. What’s often overlooked is that even small deviations to the designs can completely invalidate a security argument. What’s more, the threat model under which the original protocol was designed may not be valid for the environment in which it is deployed.

El consejo sería utilizar los bloques predefinidos más grandes posibles que se adapten a nuestras necesidades. Primitivas de alto nivel, protocolos ya desarrollados y, en general, algo que sea de uso amplio y que no tenga muchas opciones para configurarlo.

always use the biggest pre-built building blocks possible that meet your needs. For primitives, you can consider using the highest level interfaces of a library such as NaCl. For protocols, see if something such as an existing TLS implementation will meet your needs. In general, something widely used and with fewer configuration choices will be harder to misuse than something highly configurable.

Interesante.

El ecosistema del cibercrimen: algunos actores, distribución de tareas y sus conexiones

Mercado medieval. Equilibrista Si hay algo que tenemos claro en ciberseguridad es que ahora existe una industria y que se ha profesionalizado de manera notable. En This chart shows the connections between cybercrime groups.

Se habla del ecosistema del cibercrimen y sus conexiones:

… the cybercrime ecosystem is much smaller and far more interconnected than the layperson might realize.

Establece tres grandes categorías de lo que serían tecnologías disponibles para usar por teceros, servicios, distribución y monetización.

According to cybersecurity firm CrowdStrike, these third-party technologies can be classified into three categories: services, distribution, and monetization.

Y cada una de ellas incluye, a su vez, diferentes herramientas. Por ejemplo, en la de servicios habría intermediarios de gestión de accesos, herramientas de denegación de servicio, servicios de anonimato y cifrado, y unas cuantas más.

En los aspectos de distribución estaríamos hablando de las campañas de spam y redes sociales, compra-venta de tráfico, paquetes de explotación de vulnerabilidades…

Finalmente, en el apartado de monetización habría servicios como los de las ‘mulas’ (la gente que tiene que hacer las transacciones económicas ‘reales’), servicios de lavado de dinero, pagos de secuestros y extorsiones, recolección y venta de tarjetas, etc.

Es difícil, nos dice, conocer las conexiones entre todos estos grupos pero parece haber evidencias de su cooperación.

However, in the realm of malware attacks, some signs of cooperation can be observed by the way the malware moves from attackers to infected hosts.

E incluso ofrecen un índice de adversarios en este negocio: Crowdstrike adversary universe

Interesante.

Una condición de carrera en el manejo de sesiones en GitHub

Reloj y campanas En How we found and fixed a rare race condition in our session handling una historia sobre una condición de carrera en el manejo de sesiones en GiHub.

Las condiciones de carrera son fallos que aparecen en sistemas concurrentes, suelen ser difíciles de encontrar y solucionar, porque pueden aparecer o no, y podremos ver los resultados sólo en algunas ocasiones. Recordemos que una condición de carrera ocurre cuando se debe cumplir alguna condición durante un cierto tiempo pero, por algún motivo, esto no se cumple. Si nos encontramos en una situación así, el código se comporta como si la condición fuera cierta y los resultados pueden ser incorrectos.

Todo comienza cuando reciben un aviso de un usuario que habiéndose identificado con su usuario aparecía, de pronto, identificado como otro.

On March 2, 2021, we received a report via our support team from a user who, while using GitHub.com logged in as their own user, was suddenly authenticated as another user.

Aparentemente, el usuario recibía la respuesta correcta salvo la cookie de sesión que pertenecía a un usuario diferente.

The affected users from the support reports received a session cookie from a user who very recently had a request handled inside the same process. In one case, the two requests were handled sequentially, one after the other. In the second case, there were two other requests in between.

Uno de los problemas de las condiciones de carrera es que son fallos que parecen casuales y suelen ser difíciles de redproducir. En este caso lo consiguieron, determinando además que eran neceasrias algunas circunstancias adicionales.

With this information, we tried to reproduce the issue in a development environment. When we attempted to sequence the exact requests, we found that one additional condition was needed and that was an anonymous request that started the whole sequence.

En la entrada están los pasos, que no reproduciremos aquí. El resumen sería que podía ocurrir una excepción y a la vez se producían una serie de peticiones, la sesión era sustituida para el usuario.

In summary, if an exception occurred at just the right time and if concurrent request processing happened in just the right sequence across multiple requests, we ended up replacing the session in one response with a session from an earlier response.

Una vez detectado el problema, y solucionado para que no se volviera a producir era necesario saber quién podría haber estado afectado.

In addition to fixing the underlying bug, we took action to make sure we identified affected user sessions. We examined our logging data for patterns consistent with incorrectly returned sessions.

Para asegurarse de que todo sería correcto, el último paso fue revocar todas las sesiones activas.

As a final step, we decided to take a further preventative action to ensure the safety of our users’ data and revoked all active user sessions on GitHub.com.

Todo no termina aquí, porque ahora hay que asegurarse de que no puedan ocurrir fallos similares en otras partes del código.

Lastly, we’re looking at also improving the thread safety across our codebase in areas such as exception handling and instrumentation. We don’t want to just fix this specific bug, we want to ensure that this class of issues can’t happen again in the future

Desarrollar. Teniendo en cuenta la seguridad

Muralla Es ya un tema viejo debatir si la seguridad es cosa de desarrolladores o no. Yo tengo clarísimo que los desarrolladores deben saber de estos temas, deben tener directrices claras y resolver los problemas pensando -también- en la seguridad.

En Developers vs. Security: Who is Responsible for Application Security? nos hablaban de ello y por eso lo traemos aquí.

Lo primero, parece que la gente de seguridad desconfía de los desarrolladores y de su conocimiento sobre el tema, según un estudio de GitLab.

Results from a recent GitLab survey underscore the issue: most security professionals lack faith in developers’ ability to write secure code, while most developers feel they lack proper guidance. What’s worse, many companies surveyed aren’t being serious enough about their defense.

Puede haber aproximaciones diferentes, según la empresa y sus objetivos, nos dice Vikram Kunchala, responsable de Deloitte.

“It’s a mixed bag, and a lot of that is defined by how the company perceives security, and how important security is for their products and solutions,” he says.

La prioridad de los desarrolladores siempre es entregar código que funcione tan pronto como sea posible, sobre todo teniendo en cuenta la presión que sufren por la demanda.

With higher and higher demand for more software and apps, even more so in today’s business climate, the top priority for any developer is to get the code out quickly.

Pero claro, el código de calidad debe cumplir los requisitos de la organización y del negocio.

But to developers, and in most business entities, good quality code means that it meets organizational and business goals.

Esto no impide que los desarrolladores vean la seguridad como un freno para avanzar.

Making security the best it can be, from a developer’s perspective, is like a cop with a radar gun slowing them down when they only want to go faster.

Desde el punto de vista de los expertos en seguridad, se trataría de explorar de qué forma trabajar con los desarrolladores para generar productos más seguros.

But instead of talking about the mindset, it’s more important to explore how security experts can work with developers to achieve the collective goal of secure code.

Según nuestro experto, tres cosas ayudarían:

Primero, no tiene que ser perfecto, pero sí ir en la dirección correcta.

It doesn’t have to be perfect. […] to have a framework to say something like, “If I do these ten things, I’m on the right track.”

Segundo, la seguridad debería ser fácil de aplicar para ellos.

Security for developers should be frictionless and easy to consume.

Finalmente, cambiar la perspectiva. Esto es, prestar atención a qué tipo de desarrollo estamos haciendo y aplicar las medidas que sean adecuadas al proyecto, con ayuda de los especialistas.

For a developer looking to create a product or an app, they need to engage with application security teams to answer several questions that drive various risk elements

Idealmente, que sea fácil de verificar que todo está como se debe en las fases de integración y desarrollo continuo.

Those teams must provide an easy way to consume these controls as part of the development process and CICD (continuous integration/continuous delivery) pipeline.

Y los expertos deben ayudar a que la parte defensiva sea más sencilla.

Now, security experts need to make defense easier to do.

Teniendo en cuenta que cuanto más se retrase la solución de los problemas, más complicao será resolverlos.

Perhaps the most critical advice you should impart to the development team is that the longer it takes to fix the issue, the more expensive it gets.

Parece que poco a poco va calando la cultura de que las aplicaciones deben ser seguras y proteger los datos, así que eso debería ayuda.

… 78% of U.S. respondents believe it is extremely important for a company to keep their data private, building security into your product or service is putting your customer first.

En definitiva, la seguridad debería ser una fase más del diseño/desarrollo, y nho algo que se añade después.

“With any process, security should be built in, not bolted on,” Kunchala says. “Anything that organizations can do to consider shifting left and start engaging security at the conception phase is going to be beneficial.”

Supongo que no es muy nuevo para nadie que venga por aquí de vez en cuando, pero está bien tener estos recordatorios.